* Re: [PATCH v3 04/12] ppc64/kexec_file: avoid stomping memory used by special regions
From: Thiago Jung Bauermann @ 2020-07-16 21:59 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <0582476e-415e-3f60-2bb2-6199d0340156@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 15/07/20 8:09 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>
> <snip>
>
>>> +/**
>>> + * __locate_mem_hole_top_down - Looks top down for a large enough memory hole
>>> + * in the memory regions between buf_min & buf_max
>>> + * for the buffer. If found, sets kbuf->mem.
>>> + * @kbuf: Buffer contents and memory parameters.
>>> + * @buf_min: Minimum address for the buffer.
>>> + * @buf_max: Maximum address for the buffer.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +static int __locate_mem_hole_top_down(struct kexec_buf *kbuf,
>>> + u64 buf_min, u64 buf_max)
>>> +{
>>> + int ret = -EADDRNOTAVAIL;
>>> + phys_addr_t start, end;
>>> + u64 i;
>>> +
>>> + for_each_mem_range_rev(i, &memblock.memory, NULL, NUMA_NO_NODE,
>>> + MEMBLOCK_NONE, &start, &end, NULL) {
>>> + if (start > buf_max)
>>> + continue;
>>> +
>>> + /* Memory hole not found */
>>> + if (end < buf_min)
>>> + break;
>>> +
>>> + /* Adjust memory region based on the given range */
>>> + if (start < buf_min)
>>> + start = buf_min;
>>> + if (end > buf_max)
>>> + end = buf_max;
>>> +
>>> + start = ALIGN(start, kbuf->buf_align);
>>> + if (start < end && (end - start + 1) >= kbuf->memsz) {
>>
>> This is why I dislike using start and end to express address ranges:
>>
>> While struct resource seems to use the [address, end] convention, my
>
> struct crash_mem also uses [address, end] convention.
> This off-by-one error did not cause any issues as the hole start and size we try to find
> are at least page aligned.
>
> Nonetheless, I think fixing 'end' early in the loop with "end -= 1" would ensure
> correctness while continuing to use the same convention for structs crash_mem & resource.
Sounds good.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 11/11] usb: dwc3: gadget: Set speed only up to the max supported
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
The setting of device speed should be limited by the device's
maximum_speed. This patch adds a check and prevent the driver from
attempting to configure higher than the maximum_speed.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/dwc3/gadget.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 87a69a096b57..155251d67b4d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2254,6 +2254,7 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
enum usb_device_speed speed)
{
struct dwc3 *dwc = gadget_to_dwc(g);
+ enum usb_device_speed selected_speed = speed;
unsigned long flags;
u32 reg;
@@ -2278,7 +2279,10 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
!dwc->dis_metastability_quirk) {
reg |= DWC3_DCFG_SUPERSPEED;
} else {
- switch (speed) {
+ if (speed > dwc->maximum_speed)
+ selected_speed = dwc->maximum_speed;
+
+ switch (selected_speed) {
case USB_SPEED_LOW:
reg |= DWC3_DCFG_LOWSPEED;
break;
@@ -2298,7 +2302,8 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
reg |= DWC3_DCFG_SUPERSPEED_PLUS;
break;
default:
- dev_err(dwc->dev, "invalid speed (%d)\n", speed);
+ dev_err(dwc->dev, "invalid speed (%d)\n",
+ selected_speed);
if (DWC3_IP_IS(DWC3))
reg |= DWC3_DCFG_SUPERSPEED;
@@ -2307,7 +2312,7 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
}
}
- if (DWC3_IP_IS(DWC32) && speed < USB_SPEED_SUPER_PLUS)
+ if (DWC3_IP_IS(DWC32) && selected_speed < USB_SPEED_SUPER_PLUS)
reg &= ~DWC3_DCFG_NUMLANES(~0);
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
--
2.11.0
^ permalink raw reply related
* [PATCH 10/11] usb: dwc3: gadget: Track connected lane and sublink speed
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Track the number of lanes connected in gadget->num_lanes and track the
current sublink speed attribute ID for super-speed-plus operations.
Note: if the device is running in gen1x2, set the gadget->speed to
USB_SPEED_SUPER_PLUS.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/dwc3/core.h | 2 ++
drivers/usb/dwc3/gadget.c | 21 ++++++++++++++++++++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 92ab65a46771..63178549428d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -464,6 +464,8 @@
#define DWC3_DEVTEN_USBRSTEN BIT(1)
#define DWC3_DEVTEN_DISCONNEVTEN BIT(0)
+#define DWC3_DSTS_CONNLANES(n) (((n) >> 30) & 0x3) /* DWC_usb32 only */
+
/* Device Status Register */
#define DWC3_DSTS_DCNRD BIT(29)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 01bdd51f6b47..87a69a096b57 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2306,6 +2306,10 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
reg |= DWC3_DCFG_SUPERSPEED_PLUS;
}
}
+
+ if (DWC3_IP_IS(DWC32) && speed < USB_SPEED_SUPER_PLUS)
+ reg &= ~DWC3_DCFG_NUMLANES(~0);
+
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -3175,12 +3179,19 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc)
struct dwc3_ep *dep;
int ret;
u32 reg;
+ u8 lanes = 1;
u8 speed;
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
speed = reg & DWC3_DSTS_CONNECTSPD;
dwc->speed = speed;
+ if (DWC3_IP_IS(DWC32))
+ lanes = DWC3_DSTS_CONNLANES(reg) + 1;
+
+ dwc->gadget.num_lanes = lanes;
+ dwc->gadget.speed_ssid = 0;
+
/*
* RAMClkSel is reset to 0 after USB reset, so it must be reprogrammed
* each time on Connect Done.
@@ -3195,6 +3206,7 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc)
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512);
dwc->gadget.ep0->maxpacket = 512;
dwc->gadget.speed = USB_SPEED_SUPER_PLUS;
+ dwc->gadget.speed_ssid = DWC3_SSP_SSID_GEN2;
break;
case DWC3_DSTS_SUPERSPEED:
/*
@@ -3215,7 +3227,13 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc)
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512);
dwc->gadget.ep0->maxpacket = 512;
- dwc->gadget.speed = USB_SPEED_SUPER;
+
+ if (lanes > 1) {
+ dwc->gadget.speed = USB_SPEED_SUPER_PLUS;
+ dwc->gadget.speed_ssid = DWC3_SSP_SSID_GEN1;
+ } else {
+ dwc->gadget.speed = USB_SPEED_SUPER;
+ }
break;
case DWC3_DSTS_HIGHSPEED:
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(64);
@@ -3696,6 +3714,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
dwc->gadget.sg_supported = true;
dwc->gadget.name = "dwc3-gadget";
dwc->gadget.lpm_capable = true;
+ dwc->gadget.num_lanes = 1;
/*
* FIXME We might be setting max_speed to <SUPER, however versions
--
2.11.0
^ permalink raw reply related
* [PATCH 09/11] usb: dwc3: gadget: Implement setting of sublink speed
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Implement gadget ops udc_set_num_lanes_and_speed. This allows the
gadget/core driver to select number of lanes to use and the sublink
speed the controller supports.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/dwc3/core.h | 2 ++
drivers/usb/dwc3/gadget.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index e346ae12e69e..92ab65a46771 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -389,6 +389,8 @@
#define DWC3_GUCTL2_RST_ACTBITLATER BIT(14)
/* Device Configuration Register */
+#define DWC3_DCFG_NUMLANES(n) (((n) & 0x3) << 30) /* DWC_usb32 only */
+
#define DWC3_DCFG_DEVADDR(addr) ((addr) << 3)
#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1ca57af23994..01bdd51f6b47 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2311,6 +2311,62 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
spin_unlock_irqrestore(&dwc->lock, flags);
}
+static void dwc3_gadget_set_num_lanes_and_speed(struct usb_gadget *g,
+ unsigned int num_lanes,
+ unsigned int ssid)
+{
+ struct dwc3 *dwc = gadget_to_dwc(g);
+ struct usb_sublink_speed *ssa = NULL;
+ unsigned int lanes;
+ unsigned long flags;
+ u32 reg;
+ int i;
+
+ spin_lock_irqsave(&dwc->lock, flags);
+ if (dwc->maximum_speed < USB_SPEED_SUPER_PLUS)
+ goto done;
+
+ for (i = 0; i < g->ssac + 1; i++) {
+ if (g->sublink_speed[i].id == ssid) {
+ ssa = &g->sublink_speed[i];
+ break;
+ }
+ }
+
+ if (!ssa) {
+ dev_err(dwc->dev, "SSID not found (%d)\n", ssid);
+ goto done;
+ }
+
+ reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+ reg &= ~DWC3_DCFG_SPEED_MASK;
+
+ switch (ssa->mantissa) {
+ case DWC3_LSM_5_GBPS:
+ reg |= DWC3_DCFG_SUPERSPEED;
+ break;
+ case DWC3_LSM_10_GBPS:
+ reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+ break;
+ default:
+ dev_err(dwc->dev, "invalid lane speed mantissa (%d)\n",
+ ssa->mantissa);
+ goto done;
+ }
+
+ /* Lane configuration is only available to DWC_usb32 */
+ if (DWC3_IP_IS(DWC32)) {
+ lanes = clamp_t(unsigned int, num_lanes, 1,
+ dwc->maximum_num_lanes);
+ reg &= ~DWC3_DCFG_NUMLANES(~0);
+ reg |= DWC3_DCFG_NUMLANES(lanes - 1);
+ }
+
+ dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+done:
+ spin_unlock_irqrestore(&dwc->lock, flags);
+}
+
static const struct usb_gadget_ops dwc3_gadget_ops = {
.get_frame = dwc3_gadget_get_frame,
.wakeup = dwc3_gadget_wakeup,
@@ -2319,6 +2375,7 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
.udc_start = dwc3_gadget_start,
.udc_stop = dwc3_gadget_stop,
.udc_set_speed = dwc3_gadget_set_speed,
+ .udc_set_num_lanes_and_speed = dwc3_gadget_set_num_lanes_and_speed,
.get_config_params = dwc3_gadget_config_params,
};
@@ -3719,7 +3776,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
- dwc3_gadget_set_speed(&dwc->gadget, dwc->maximum_speed);
+ if (DWC3_IP_IS(DWC32) && dwc->maximum_speed == USB_SPEED_SUPER_PLUS)
+ dwc3_gadget_set_num_lanes_and_speed(&dwc->gadget,
+ dwc->maximum_num_lanes,
+ dwc->gadget.max_speed_ssid);
+ else
+ dwc3_gadget_set_speed(&dwc->gadget, dwc->maximum_speed);
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH 08/11] usb: dwc3: gadget: Report sublink speed capability
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Report the sublink speed attributes to the usb_gadget structure based on
the dwc3 device capability maximum_lsm and maximum_num_lanes,
Only DWC_usb32 supports 2 sublink speeds if it can operate with 2 lanes.
(i.e. at SSP, it can operate as gen1x2)
Note: the SSID DWC3_SSP_SSID_GEN2 and DWC3_SSP_SSID_GEN1 are arbitrary.
There's no standard according to the USB 3.2 spec as long as they are
unique and within 0-15.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/dwc3/core.h | 4 ++++
drivers/usb/dwc3/gadget.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 33cfd7f4a7e0..e346ae12e69e 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -44,6 +44,10 @@
#define DWC3_LSM_5_GBPS 5
#define DWC3_LSM_10_GBPS 10
+/* Sublink Speed Attribute ID */
+#define DWC3_SSP_SSID_GEN2 2
+#define DWC3_SSP_SSID_GEN1 1
+
#define DWC3_SCRATCHBUF_SIZE 4096 /* each buffer is assumed to be 4KiB */
#define DWC3_EVENT_BUFFERS_SIZE 4096
#define DWC3_EVENT_TYPE_MASK 0xfe
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 80c3ef134e41..1ca57af23994 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3662,6 +3662,47 @@ int dwc3_gadget_init(struct dwc3 *dwc)
dwc->revision);
dwc->gadget.max_speed = dwc->maximum_speed;
+ dwc->gadget.max_num_lanes = dwc->maximum_num_lanes;
+
+ if (dwc->maximum_speed == USB_SPEED_SUPER_PLUS) {
+ struct usb_sublink_speed *ssa;
+ int i;
+
+ /*
+ * Multiple sublink speeds are only available to DWC_usb32
+ * devices that can operate at gen2x2 max.
+ */
+ if (dwc->maximum_lsm == DWC3_LSM_10_GBPS &&
+ dwc->maximum_num_lanes == 2) {
+ dwc->gadget.ssac = 3;
+ dwc->gadget.min_speed_ssid = DWC3_SSP_SSID_GEN1;
+ dwc->gadget.max_speed_ssid = DWC3_SSP_SSID_GEN2;
+ } else {
+ dwc->gadget.ssac = 1;
+ dwc->gadget.min_speed_ssid = DWC3_SSP_SSID_GEN2;
+ dwc->gadget.max_speed_ssid = DWC3_SSP_SSID_GEN2;
+ }
+
+ for (i = 0; i < dwc->gadget.ssac + 1; i++) {
+ ssa = &dwc->gadget.sublink_speed[i];
+
+ if (i > 1) {
+ ssa->id = DWC3_SSP_SSID_GEN1;
+ ssa->mantissa = DWC3_LSM_5_GBPS;
+ } else {
+ ssa->id = DWC3_SSP_SSID_GEN2;
+ ssa->mantissa = DWC3_LSM_10_GBPS;
+ }
+
+ if (i % 2)
+ ssa->type = USB_ST_SYMMETRIC_TX;
+ else
+ ssa->type = USB_ST_SYMMETRIC_RX;
+
+ ssa->exponent = USB_LSE_GBPS;
+ ssa->protocol = USB_LP_SSP;
+ }
+ }
/*
* REVISIT: Here we should clear all pending IRQs to be
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 10/12] ppc64/kexec_file: prepare elfcore header for crashing kernel
From: Thiago Jung Bauermann @ 2020-07-16 21:57 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <929db6fe-b221-a514-8ea1-93227f8d47b0@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:52 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> /**
>>> + * get_crash_memory_ranges - Get crash memory ranges. This list includes
>>> + * first/crashing kernel's memory regions that
>>> + * would be exported via an elfcore.
>>> + * @mem_ranges: Range list to add the memory ranges to.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +static int get_crash_memory_ranges(struct crash_mem **mem_ranges)
>>> +{
>>> + struct memblock_region *reg;
>>> + struct crash_mem *tmem;
>>> + int ret;
>>> +
>>> + for_each_memblock(memory, reg) {
>>> + u64 base, size;
>>> +
>>> + base = (u64)reg->base;
>>> + size = (u64)reg->size;
>>> +
>>> + /* Skip backup memory region, which needs a separate entry */
>>> + if (base == BACKUP_SRC_START) {
>>> + if (size > BACKUP_SRC_SIZE) {
>>> + base = BACKUP_SRC_END + 1;
>>> + size -= BACKUP_SRC_SIZE;
>>> + } else
>>> + continue;
>>> + }
>>> +
>>> + ret = add_mem_range(mem_ranges, base, size);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + /* Try merging adjacent ranges before reallocation attempt */
>>> + if ((*mem_ranges)->nr_ranges == (*mem_ranges)->max_nr_ranges)
>>> + sort_memory_ranges(*mem_ranges, true);
>>> + }
>>> +
>>> + /* Reallocate memory ranges if there is no space to split ranges */
>>> + tmem = *mem_ranges;
>>> + if (tmem && (tmem->nr_ranges == tmem->max_nr_ranges)) {
>>> + tmem = realloc_mem_ranges(mem_ranges);
>>> + if (!tmem)
>>> + goto out;
>>> + }
>>> +
>>> + /* Exclude crashkernel region */
>>> + ret = crash_exclude_mem_range(tmem, crashk_res.start, crashk_res.end);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_rtas_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_opal_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>
>> Maybe I'm confused, but don't you add the RTAS and OPAL regions as
>> usable memory for the crashkernel? In that case they shouldn't show up
>> in the core file.
>
> kexec-tools does the same thing. I am not endorsing it but I was trying to stay
> in parity to avoid breaking any userspace tools/commands. But as you rightly
> pointed, this is NOT right. The right thing to do, to get the rtas/opal data at
> the time of crash, is to have a backup region for them just like we have for
> the first 64K memory. I was hoping to do that later.
>
> Will check how userspace tools respond to dropping these regions. If that makes
> the tools unhappy, will retain the regions with a FIXME. Sorry about the confusion.
No problem, thanks for the clarification.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 07/11] usb: dwc3: Initialize lane count and sublink speed
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
DWC_usb32 supports dual-lane operating at different sublink speeds.
Initialize and validate the maximum number of lanes and speed the
controller supports captured from the dwc3 device properties.
Currently the controller has no visibility into the HW parameter to
determine the maximum number of lanes the phy supports. If the number of
lanes is not specified, then set the default to 2 for DWC_usb32 and 1
for DWC_usb31 if operate in SSP.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/dwc3/core.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/dwc3/core.h | 10 ++++++++
2 files changed, 74 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25c686a752b0..dcc76705862f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1299,6 +1299,10 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,usb3_lpm_capable");
dwc->usb2_lpm_disable = device_property_read_bool(dev,
"snps,usb2-lpm-disable");
+ device_property_read_u8(dev, "snps,num-lanes",
+ &dwc->maximum_num_lanes);
+ device_property_read_u8(dev, "snps,lane-speed-mantissa-gbps",
+ &dwc->maximum_lsm);
device_property_read_u8(dev, "snps,rx-thr-num-pkt-prd",
&rx_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,rx-max-burst-prd",
@@ -1426,6 +1430,66 @@ static void dwc3_check_params(struct dwc3 *dwc)
break;
}
+
+ /*
+ * If it's not DWC_usb32 IP or speed is less than SSP, no need to
+ * validate the number of lanes or lane speed mantissa.
+ *
+ * Currently the controller does not have visibility into the HW
+ * parameter to determine the maximum number of lanes the phy supports.
+ * If the number of lanes is not specified in the device property, then
+ * set the default to 2 for DWC_usb32 and 1 for DWC_usb31 if the device
+ * is capable of super-speed-plus.
+ */
+ if (!DWC3_IP_IS(DWC32) ||
+ dwc->maximum_speed < USB_SPEED_SUPER_PLUS) {
+ if (dwc->maximum_lsm || dwc->maximum_num_lanes)
+ dev_warn(dev, "Ignore num_lanes and LSM properties\n");
+
+ if (DWC3_IP_IS(DWC31) &&
+ dwc->maximum_speed == USB_SPEED_SUPER_PLUS) {
+ dwc->maximum_lsm = DWC3_LSM_10_GBPS;
+ dwc->maximum_num_lanes = 1;
+ } else {
+ dwc->maximum_lsm = DWC3_LSM_UNSPECIFIED;
+ dwc->maximum_num_lanes = 0;
+ }
+
+ return;
+ }
+
+ switch (dwc->maximum_lsm) {
+ case DWC3_LSM_10_GBPS:
+ case DWC3_LSM_5_GBPS:
+ break;
+ default:
+ dev_err(dev, "Invalid LSM (%dGbps)\n", dwc->maximum_lsm);
+ fallthrough;
+ case DWC3_LSM_UNSPECIFIED:
+ dwc->maximum_lsm = DWC3_LSM_10_GBPS;
+ break;
+ }
+
+ switch (dwc->maximum_num_lanes) {
+ case 2:
+ break;
+ case 1:
+ if (dwc->maximum_lsm == DWC3_LSM_5_GBPS) {
+ dev_err(dev, "Invalid num_lanes (%d) and LSM (%dGbps) for %s\n",
+ dwc->maximum_num_lanes,
+ dwc->maximum_lsm,
+ usb_speed_string(dwc->maximum_speed));
+ dwc->maximum_lsm = DWC3_LSM_10_GBPS;
+ }
+ break;
+ default:
+ dev_err(dev, "Invalid number of lanes (%d)\n",
+ dwc->maximum_num_lanes);
+ fallthrough;
+ case 0:
+ dwc->maximum_num_lanes = 2;
+ break;
+ }
}
static int dwc3_probe(struct platform_device *pdev)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 013f42a2b5dc..33cfd7f4a7e0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -40,6 +40,10 @@
#define DWC3_XHCI_RESOURCES_NUM 2
#define DWC3_ISOC_MAX_RETRIES 5
+#define DWC3_LSM_UNSPECIFIED 0
+#define DWC3_LSM_5_GBPS 5
+#define DWC3_LSM_10_GBPS 10
+
#define DWC3_SCRATCHBUF_SIZE 4096 /* each buffer is assumed to be 4KiB */
#define DWC3_EVENT_BUFFERS_SIZE 4096
#define DWC3_EVENT_TYPE_MASK 0xfe
@@ -958,6 +962,8 @@ struct dwc3_scratchpad_array {
* @nr_scratch: number of scratch buffers
* @u1u2: only used on revisions <1.83a for workaround
* @maximum_speed: maximum speed requested (mainly for testing purposes)
+ * @maximum_lsm: maximum lane speed mantissa in Gbps
+ * @maximum_num_lanes: maximum number of lanes
* @ip: controller's ID
* @revision: controller's version of an IP
* @version_type: VERSIONTYPE register contents, a sub release of a revision
@@ -988,6 +994,7 @@ struct dwc3_scratchpad_array {
* @ep0state: state of endpoint zero
* @link_state: link state
* @speed: device speed (super, high, full, low)
+ * @num_lanes: number of connected lanes
* @hwparams: copy of hwparams registers
* @root: debugfs root folder pointer
* @regset: debugfs pointer to regdump file
@@ -1119,6 +1126,8 @@ struct dwc3 {
u32 nr_scratch;
u32 u1u2;
u32 maximum_speed;
+ u8 maximum_lsm;
+ u8 maximum_num_lanes;
u32 ip;
@@ -1184,6 +1193,7 @@ struct dwc3 {
u8 u1pel;
u8 speed;
+ u8 num_lanes;
u8 num_eps;
--
2.11.0
^ permalink raw reply related
* [PATCH 06/11] usb: devicetree: dwc3: Introduce num-lanes and lsm
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, linux-usb, devicetree,
Rob Herring
Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Introduce num-lanes and lane-speed-mantissa-gbps for devices operating
in super-speed-plus. DWC_usb32 IP supports multiple lanes and can
operate in different sublink speeds. Currently the device controller
does not have the information of the phy's number of lanes supported. As
a result, the user can specify them through these properties if they are
different than the default setting.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
Documentation/devicetree/bindings/usb/dwc3.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index d03edf9d3935..4eba0615562f 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -86,6 +86,15 @@ Optional properties:
- snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
register for post-silicon frame length adjustment when the
fladj_30mhz_sdbnd signal is invalid or incorrect.
+ - snps,num-lanes: set to specify the number of lanes to use. Valid inputs are
+ 1 or 2. Apply if the maximum-speed is super-speed-plus
+ only. Default value is 2 for DWC_usb32. For DWC_usb31,
+ it is always 1 at super-speed-plus.
+ - snps,lane-speed-mantissa-gbps: set to specify the symmetric lane speed
+ mantissa in Gbps. Valid inputs are 5 or 10. Apply if
+ the maximum-speed is super-speed-plus only. Default
+ value is 10. For DWC_usb31, it's always 10 at
+ super-speed-plus.
- snps,rx-thr-num-pkt-prd: periodic ESS RX packet threshold count - host mode
only. Set this and rx-max-burst-prd to a valid,
non-zero value 1-16 (DWC_usb31 programming guide
--
2.11.0
^ permalink raw reply related
* [PATCH 05/11] usb: composite: Properly report sublink speed
From: Thinh Nguyen @ 2020-07-16 21:59 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Use the max sublink speed attributes reported in the gadget structure
to write to the super-speed-plus BOS descriptor if available.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/gadget/composite.c | 76 +++++++++++++++++++++++++++++-------------
1 file changed, 52 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index a231ae382ac3..d9fb29a72f94 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -729,45 +729,73 @@ static int bos_desc(struct usb_composite_dev *cdev)
/* The SuperSpeedPlus USB Device Capability descriptor */
if (gadget_is_superspeed_plus(cdev->gadget)) {
struct usb_ssp_cap_descriptor *ssp_cap;
+ unsigned int ssac = 1;
+ unsigned int ssic = 0;
+ unsigned int min_ssid = 0;
+ int i;
+
+ if (cdev->gadget->ssac) {
+ ssac = cdev->gadget->ssac;
+
+ /*
+ * Paired RX and TX sublink speed attributes share
+ * the same SSID.
+ */
+ ssic = (ssac + 1) / 2 - 1;
+ min_ssid = cdev->gadget->min_speed_ssid;
+ }
ssp_cap = cdev->req->buf + le16_to_cpu(bos->wTotalLength);
bos->bNumDeviceCaps++;
- /*
- * Report typical values.
- */
-
- le16_add_cpu(&bos->wTotalLength, USB_DT_USB_SSP_CAP_SIZE(1));
- ssp_cap->bLength = USB_DT_USB_SSP_CAP_SIZE(1);
+ le16_add_cpu(&bos->wTotalLength, USB_DT_USB_SSP_CAP_SIZE(ssac));
+ ssp_cap->bLength = USB_DT_USB_SSP_CAP_SIZE(ssac);
ssp_cap->bDescriptorType = USB_DT_DEVICE_CAPABILITY;
ssp_cap->bDevCapabilityType = USB_SSP_CAP_TYPE;
ssp_cap->bReserved = 0;
ssp_cap->wReserved = 0;
ssp_cap->bmAttributes =
- cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_ATTRIBS, 1) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_IDS, 0));
+ cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_ATTRIBS, ssac) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_IDS, ssic));
ssp_cap->wFunctionalitySupport =
- cpu_to_le16(FIELD_PREP(USB_SSP_MIN_SUBLINK_SPEED_ATTRIBUTE_ID, 0) |
+ cpu_to_le16(FIELD_PREP(USB_SSP_MIN_SUBLINK_SPEED_ATTRIBUTE_ID, min_ssid) |
FIELD_PREP(USB_SSP_MIN_RX_LANE_COUNT, 1) |
FIELD_PREP(USB_SSP_MIN_TX_LANE_COUNT, 1));
- ssp_cap->bmSublinkSpeedAttr[0] =
- cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_SSID, 0) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSE, USB_LSE_GBPS) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST,
- USB_ST_SYMMETRIC_RX) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LP, USB_LP_SSP) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSM, 10));
-
- ssp_cap->bmSublinkSpeedAttr[1] =
- cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_SSID, 0) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSE, USB_LSE_GBPS) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST,
- USB_ST_SYMMETRIC_TX) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LP, USB_LP_SSP) |
- FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSM, 10));
+ /*
+ * If the sublink speed attributes are not specified, then the
+ * default will be a pair symmetric RX/TX sublink speed
+ * attributes of 10 Gbps.
+ */
+ for (i = 0; i < ssac + 1; i++) {
+ struct usb_sublink_speed default_ssa;
+ struct usb_sublink_speed *ptr;
+
+ if (cdev->gadget->ssac) {
+ ptr = &cdev->gadget->sublink_speed[i];
+ } else {
+ default_ssa.id = i / 2;
+ default_ssa.protocol = USB_LP_SSP;
+ default_ssa.exponent = USB_LSE_GBPS;
+ default_ssa.mantissa = 10;
+
+ if (i % 2)
+ default_ssa.type = USB_ST_SYMMETRIC_TX;
+ else
+ default_ssa.type = USB_ST_SYMMETRIC_RX;
+
+ ptr = &default_ssa;
+ }
+
+ ssp_cap->bmSublinkSpeedAttr[i] =
+ cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_SSID, ptr->id) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSE, ptr->exponent) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST, ptr->type) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LP, ptr->protocol) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSM, ptr->mantissa));
+ }
}
return le16_to_cpu(bos->wTotalLength);
--
2.11.0
^ permalink raw reply related
* [PATCH 04/11] usb: gadget: Set max speed for SSP devices
From: Thinh Nguyen @ 2020-07-16 21:58 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb,
Peter Chen, Alan Stern, Dejin Zheng, Roger Quadros, Jun Li
Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
A super-speed-plus device may operate at different sublink speeds (e.g.
gen2x2, gen1x2, or gen2x1). If the USB device supports different sublink
speeds at super-speed-plus, set the device to operate at the maximum
number of lanes and sublink speed possible. Introduce gadget ops
udc_set_num_lanes_and_speed to set the lane count and sublink speed for
super-speed-plus capable devices.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/gadget/udc/core.c | 24 +++++++++++++++++++-----
include/linux/usb/gadget.h | 3 +++
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 2e28dde8376f..1e916b3943fe 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1112,12 +1112,26 @@ static inline void usb_gadget_udc_stop(struct usb_udc *udc)
static inline void usb_gadget_udc_set_speed(struct usb_udc *udc,
enum usb_device_speed speed)
{
- if (udc->gadget->ops->udc_set_speed) {
- enum usb_device_speed s;
+ struct usb_gadget *gadget = udc->gadget;
+ enum usb_device_speed s;
- s = min(speed, udc->gadget->max_speed);
- udc->gadget->ops->udc_set_speed(udc->gadget, s);
- }
+ if (speed == USB_SPEED_UNKNOWN)
+ s = gadget->max_speed;
+ else
+ s = min(speed, gadget->max_speed);
+
+ /*
+ * If the UDC supports super-speed-plus and different sublink speeds,
+ * then set the gadget to the max possible sublink speed for
+ * super-speed-plus symmetric lanes.
+ */
+ if (s == USB_SPEED_SUPER_PLUS &&
+ gadget->ops->udc_set_num_lanes_and_speed)
+ gadget->ops->udc_set_num_lanes_and_speed(gadget,
+ gadget->max_num_lanes,
+ gadget->max_speed_ssid);
+ else if (gadget->ops->udc_set_speed)
+ gadget->ops->udc_set_speed(gadget, s);
}
/**
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 2ab929eed928..ec4ed17e7bf5 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -322,6 +322,9 @@ struct usb_gadget_ops {
struct usb_gadget_driver *);
int (*udc_stop)(struct usb_gadget *);
void (*udc_set_speed)(struct usb_gadget *, enum usb_device_speed);
+ void (*udc_set_num_lanes_and_speed)(struct usb_gadget *,
+ unsigned int num_lanes,
+ unsigned int ssid);
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
--
2.11.0
^ permalink raw reply related
* [PATCH 03/11] usb: gadget: Expose sublink speed attributes
From: Thinh Nguyen @ 2020-07-16 21:58 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
The USB 3.2 specification supports dual-lane and different transfer
rates for super-speed-plus. Devices operating in super-speed-plus can
be gen2x1, gen1x2, or gen2x2.
A gadget driver may need to know the gadget's sublink speeds to properly
setup its transfer requests and describe its capability in its
descriptors. To describe the transfer rate in super-speed-plus fully,
let's expose the lane count and sublink speed attributes when operating
in super-speed-plus.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
include/linux/usb/gadget.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 6a178177e4c9..2ab929eed928 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -338,6 +338,15 @@ struct usb_gadget_ops {
* @speed: Speed of current connection to USB host.
* @max_speed: Maximal speed the UDC can handle. UDC must support this
* and all slower speeds.
+ * @num_lanes: Number of lanes in use.
+ * @max_num_lanes: Maximum number of lanes the UDC supports.
+ * @ssac: Sublink speed attribute count. The number of sublink speed
+ * attributes is ssac + 1.
+ * @sublink_speed: Array of sublink speed attributes the UDC supports. Sublink
+ * speed attributes are paired, and an RX followed by a TX attribute.
+ * @speed_ssid: Current sublink speed attribute ID in use.
+ * @min_speed_ssid: Sublink speed attribute ID with the minimum speed.
+ * @max_speed_ssid: Sublink speed attribute ID with the maximum speed.
* @state: the state we are now (attached, suspended, configured, etc)
* @name: Identifies the controller hardware type. Used in diagnostics
* and sometimes configuration.
@@ -405,6 +414,17 @@ struct usb_gadget {
struct list_head ep_list; /* of usb_ep */
enum usb_device_speed speed;
enum usb_device_speed max_speed;
+
+ /* SSP only */
+ unsigned num_lanes;
+ unsigned max_num_lanes;
+ unsigned ssac;
+#define USB_GADGET_MAX_SSAC 3
+ struct usb_sublink_speed sublink_speed[USB_GADGET_MAX_SSAC + 1];
+ unsigned speed_ssid;
+ unsigned min_speed_ssid;
+ unsigned max_speed_ssid;
+
enum usb_device_state state;
const char *name;
struct device dev;
--
2.11.0
^ permalink raw reply related
* [renesas-devel:renesas-dt-bindings-for-v5.9] BUILD SUCCESS 8210a6c057703b15d75f6bb841e7611726c4a551
From: kernel test robot @ 2020-07-16 21:57 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-renesas-soc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git renesas-dt-bindings-for-v5.9
branch HEAD: 8210a6c057703b15d75f6bb841e7611726c4a551 dt-bindings: arm: renesas: Document beacon-rzg2m
elapsed time: 723m
configs tested: 86
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200716
i386 randconfig-a005-20200716
i386 randconfig-a002-20200716
i386 randconfig-a006-20200716
i386 randconfig-a003-20200716
i386 randconfig-a004-20200716
i386 randconfig-a016-20200716
i386 randconfig-a011-20200716
i386 randconfig-a015-20200716
i386 randconfig-a012-20200716
i386 randconfig-a013-20200716
i386 randconfig-a014-20200716
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [renesas-devel:topic/renesas-defconfig] BUILD SUCCESS 3ae3046bc2f56778914830e9a17b73fce484ba2a
From: kernel test robot @ 2020-07-16 21:57 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-renesas-soc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git topic/renesas-defconfig
branch HEAD: 3ae3046bc2f56778914830e9a17b73fce484ba2a arm64: renesas: defconfig: Enable R8A774E1 SoC
elapsed time: 723m
configs tested: 80
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a016-20200716
i386 randconfig-a011-20200716
i386 randconfig-a015-20200716
i386 randconfig-a012-20200716
i386 randconfig-a013-20200716
i386 randconfig-a014-20200716
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH 02/11] usb: gadget: composite: Avoid using magic numbers
From: Thinh Nguyen @ 2020-07-16 21:58 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
Magic numbers are difficult to read. Use macros for super-speed-plus BOS
descriptor attributes in the composite driver. They're self-documented.
So there's no need to provide comments as we did previously for the
magic numbers.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
drivers/usb/gadget/composite.c | 41 ++++++++++++++++++++---------------------
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 5c1eb96a5c57..a231ae382ac3 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/device.h>
#include <linux/utsname.h>
+#include <linux/bitfield.h>
#include <linux/usb/composite.h>
#include <linux/usb/otg.h>
@@ -743,32 +744,30 @@ static int bos_desc(struct usb_composite_dev *cdev)
ssp_cap->bReserved = 0;
ssp_cap->wReserved = 0;
- /* SSAC = 1 (2 attributes) */
- ssp_cap->bmAttributes = cpu_to_le32(1);
+ ssp_cap->bmAttributes =
+ cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_ATTRIBS, 1) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_IDS, 0));
- /* Min RX/TX Lane Count = 1 */
ssp_cap->wFunctionalitySupport =
- cpu_to_le16((1 << 8) | (1 << 12));
+ cpu_to_le16(FIELD_PREP(USB_SSP_MIN_SUBLINK_SPEED_ATTRIBUTE_ID, 0) |
+ FIELD_PREP(USB_SSP_MIN_RX_LANE_COUNT, 1) |
+ FIELD_PREP(USB_SSP_MIN_TX_LANE_COUNT, 1));
- /*
- * bmSublinkSpeedAttr[0]:
- * ST = Symmetric, RX
- * LSE = 3 (Gbps)
- * LP = 1 (SuperSpeedPlus)
- * LSM = 10 (10 Gbps)
- */
ssp_cap->bmSublinkSpeedAttr[0] =
- cpu_to_le32((3 << 4) | (1 << 14) | (0xa << 16));
- /*
- * bmSublinkSpeedAttr[1] =
- * ST = Symmetric, TX
- * LSE = 3 (Gbps)
- * LP = 1 (SuperSpeedPlus)
- * LSM = 10 (10 Gbps)
- */
+ cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_SSID, 0) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSE, USB_LSE_GBPS) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST,
+ USB_ST_SYMMETRIC_RX) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LP, USB_LP_SSP) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSM, 10));
+
ssp_cap->bmSublinkSpeedAttr[1] =
- cpu_to_le32((3 << 4) | (1 << 14) |
- (0xa << 16) | (1 << 7));
+ cpu_to_le32(FIELD_PREP(USB_SSP_SUBLINK_SPEED_SSID, 0) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSE, USB_LSE_GBPS) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST,
+ USB_ST_SYMMETRIC_TX) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LP, USB_LP_SSP) |
+ FIELD_PREP(USB_SSP_SUBLINK_SPEED_LSM, 10));
}
return le16_to_cpu(bos->wTotalLength);
--
2.11.0
^ permalink raw reply related
* [PATCH 01/11] usb: ch9: Add sublink speed struct
From: Thinh Nguyen @ 2020-07-16 21:58 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb; +Cc: John Youn
In-Reply-To: <cover.1594935978.git.thinhn@synopsys.com>
USB 3.2 specification supports dual-lane for super-speed-plus. USB
devices may operate at different sublink speeds. To avoid using magic
numbers and capture the sublink speed better, introduce the
usb_sublink_speed structure and various sublink speed attribute enum.
See SSP BOS descriptor in USB 3.2 specification section 9.6.2.5
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
---
include/uapi/linux/usb/ch9.h | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 2b623f36af6b..d4fd403a3664 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -1145,6 +1145,48 @@ enum usb_device_speed {
USB_SPEED_SUPER_PLUS, /* usb 3.1 */
};
+/* USB 3.2 sublink speed attributes */
+
+enum usb_lane_speed_exponent {
+ USB_LSE_BPS = 0,
+ USB_LSE_KBPS = 1,
+ USB_LSE_MBPS = 2,
+ USB_LSE_GBPS = 3,
+};
+
+enum usb_sublink_type {
+ USB_ST_SYMMETRIC_RX = 0,
+ USB_ST_ASYMMETRIC_RX = 1,
+ USB_ST_SYMMETRIC_TX = 2,
+ USB_ST_ASYMMETRIC_TX = 3,
+};
+
+enum usb_link_protocol {
+ USB_LP_SS = 0,
+ USB_LP_SSP = 1,
+};
+
+/**
+ * struct usb_sublink_speed - sublink speed attribute
+ * @id: sublink speed attribute ID (SSID)
+ * @mantissa: lane speed mantissa
+ * @exponent: lane speed exponent
+ * @sublink type: sublink type
+ * @protocol: sublink protocol
+ *
+ * Super-speed-plus supports multiple lanes. Use the sublink speed attributes to
+ * describe the sublink speed.
+ *
+ * See USB 3.2 spec section 9.6.2.6 for super-speed-plus capability for more
+ * information.
+ */
+struct usb_sublink_speed {
+ u8 id;
+ u16 mantissa;
+ enum usb_lane_speed_exponent exponent;
+ enum usb_sublink_type type;
+ enum usb_link_protocol protocol;
+};
enum usb_device_state {
/* NOTATTACHED isn't in the USB spec, and this state acts
--
2.11.0
^ permalink raw reply related
* [PATCH 00/11] usb: Handle different sublink speeds
From: Thinh Nguyen @ 2020-07-16 21:58 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Thinh Nguyen, linux-usb,
devicetree, Rob Herring, Peter Chen, Alan Stern, Dejin Zheng,
Roger Quadros, Jun Li
Cc: John Youn
A USB super-speed-plus device may operate at different sublink speed and lane
count (e.g. gen2x2, gen1x2, or gen2x1). The usb gadget stack needs to be able
to handle a couple things:
1) Report the sublink speed attributes the device support
2) Select the sublink speed attribute
This series introduces sublink speed attribute structure to ch9.h to capture
the device capability of the gadget. It also introduces a new gadget ops
udc_set_num_lanes_and_speed to select a specific sublink speed.
DWC3 needs this support for DWC_usb32 IP. Implement the new changes for DWC3.
Thinh Nguyen (11):
usb: ch9: Add sublink speed struct
usb: gadget: composite: Avoid using magic numbers
usb: gadget: Expose sublink speed attributes
usb: gadget: Set max speed for SSP devices
usb: composite: Properly report sublink speed
usb: devicetree: dwc3: Introduce num-lanes and lsm
usb: dwc3: Initialize lane count and sublink speed
usb: dwc3: gadget: Report sublink speed capability
usb: dwc3: gadget: Implement setting of sublink speed
usb: dwc3: gadget: Track connected lane and sublink speed
usb: dwc3: gadget: Set speed only up to the max supported
Documentation/devicetree/bindings/usb/dwc3.txt | 9 ++
drivers/usb/dwc3/core.c | 64 ++++++++++++
drivers/usb/dwc3/core.h | 18 ++++
drivers/usb/dwc3/gadget.c | 135 ++++++++++++++++++++++++-
drivers/usb/gadget/composite.c | 81 ++++++++++-----
drivers/usb/gadget/udc/core.c | 24 ++++-
include/linux/usb/gadget.h | 23 +++++
include/uapi/linux/usb/ch9.h | 42 ++++++++
8 files changed, 360 insertions(+), 36 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH 2/2] configure: add support for Control-Flow Integrity
From: Daniele Buono @ 2020-07-16 21:57 UTC (permalink / raw)
To: Daniel P. Berrangé; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <20200702095252.GF1888119@redhat.com>
On 7/2/2020 5:52 AM, Daniel P. Berrangé wrote:
> The need to maintain this list of functions makes me feel very
> uneasy.
>
> How can we have any confidence that this list of functions is
> accurate ? How will maintainers ensure that they correctly update
> it as they are writing/changing code, and how will they test the
> result ?
Hi Daniel,
I gave it some thought and studied more of clang's options. It is
possible to disable cfi on specific functions by using an __attribute__
keyword, instead of providing a list in an external file.
In terms of maintaining, this is much better since we are removing the
need to update the list. I would suggest defining a macro,
__disable_cfi__, that can be prepended to a function. The macro would
expand to nothing if cfi is disabled, or to the proper attribute if it
is enabled. Here's example code snippet
/* Disable CFI checks.
* The callback function has been loaded from an external library so we
do not
* have type information */
__disable_cfi__
void qemu_plugin_vcpu_syscall_ret(CPUState *cpu, int64_t num, int64_t ret)
{
...
}
This would take care of renaming and removal of functions that need cfi.
It would also probably be beneficial to the developers since they can
see immediately that the function they are working with needs to have
CFI checks disabled, and why.
If you think this is a better approach, I'll submit v2 with this
approach instead of the external function list.
For new code, however, the best thing is proper education and testing.
I'll work on a document for docs/devel to detail what it is and how to
make code cfi-safe.
A good approach should be to test code changes with CFI enabled. CFI is,
after all, a sanitizer and therefore it makes sense to use it also
during development, together with ASan, UBSan and the likes.
Unfortunately, since it works only with clang, I don't think this can
ever be a hard requirement.
Daniele
^ permalink raw reply
* [PATCH][next] i2c: busses: Use fallthrough pseudo-keyword
From: Gustavo A. R. Silva @ 2020-07-16 22:03 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-i2c, linux-kernel, Gustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/i2c/busses/i2c-amd8111.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 8 ++++----
drivers/i2c/busses/i2c-viapro.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-amd8111.c b/drivers/i2c/busses/i2c-amd8111.c
index 2b14fef5bf26..34862ad3423e 100644
--- a/drivers/i2c/busses/i2c-amd8111.c
+++ b/drivers/i2c/busses/i2c-amd8111.c
@@ -381,7 +381,7 @@ static s32 amd8111_access(struct i2c_adapter * adap, u16 addr,
if (status)
return status;
len = min_t(u8, len, I2C_SMBUS_BLOCK_MAX);
- /* fall through */
+ fallthrough;
case I2C_SMBUS_I2C_BLOCK_DATA:
for (i = 0; i < len; i++) {
status = amd_ec_read(smbus, AMD_SMB_DATA + i,
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 1fc7ae77753d..638e7f7c66cc 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1765,19 +1765,19 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
case PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS1:
case PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS2:
priv->features |= FEATURE_IDF;
- /* fall through */
+ fallthrough;
default:
priv->features |= FEATURE_BLOCK_PROC;
priv->features |= FEATURE_I2C_BLOCK_READ;
priv->features |= FEATURE_IRQ;
- /* fall through */
+ fallthrough;
case PCI_DEVICE_ID_INTEL_82801DB_3:
priv->features |= FEATURE_SMBUS_PEC;
priv->features |= FEATURE_BLOCK_BUFFER;
- /* fall through */
+ fallthrough;
case PCI_DEVICE_ID_INTEL_82801CA_3:
priv->features |= FEATURE_HOST_NOTIFY;
- /* fall through */
+ fallthrough;
case PCI_DEVICE_ID_INTEL_82801BA_2:
case PCI_DEVICE_ID_INTEL_82801AB_3:
case PCI_DEVICE_ID_INTEL_82801AA_3:
diff --git a/drivers/i2c/busses/i2c-viapro.c b/drivers/i2c/busses/i2c-viapro.c
index 05aa92a3fbe0..970ccdcbb889 100644
--- a/drivers/i2c/busses/i2c-viapro.c
+++ b/drivers/i2c/busses/i2c-viapro.c
@@ -228,7 +228,7 @@ static s32 vt596_access(struct i2c_adapter *adap, u16 addr,
goto exit_unsupported;
if (read_write == I2C_SMBUS_READ)
outb_p(data->block[0], SMBHSTDAT0);
- /* Fall through */
+ fallthrough;
case I2C_SMBUS_BLOCK_DATA:
outb_p(command, SMBHSTCMD);
if (read_write == I2C_SMBUS_WRITE) {
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v3 10/12] ppc64/kexec_file: prepare elfcore header for crashing kernel
From: Thiago Jung Bauermann @ 2020-07-16 21:57 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Nayna Jain, Kexec-ml, Mahesh J Salgaonkar,
Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain, Petr Tesarik,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <929db6fe-b221-a514-8ea1-93227f8d47b0@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:52 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> /**
>>> + * get_crash_memory_ranges - Get crash memory ranges. This list includes
>>> + * first/crashing kernel's memory regions that
>>> + * would be exported via an elfcore.
>>> + * @mem_ranges: Range list to add the memory ranges to.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +static int get_crash_memory_ranges(struct crash_mem **mem_ranges)
>>> +{
>>> + struct memblock_region *reg;
>>> + struct crash_mem *tmem;
>>> + int ret;
>>> +
>>> + for_each_memblock(memory, reg) {
>>> + u64 base, size;
>>> +
>>> + base = (u64)reg->base;
>>> + size = (u64)reg->size;
>>> +
>>> + /* Skip backup memory region, which needs a separate entry */
>>> + if (base == BACKUP_SRC_START) {
>>> + if (size > BACKUP_SRC_SIZE) {
>>> + base = BACKUP_SRC_END + 1;
>>> + size -= BACKUP_SRC_SIZE;
>>> + } else
>>> + continue;
>>> + }
>>> +
>>> + ret = add_mem_range(mem_ranges, base, size);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + /* Try merging adjacent ranges before reallocation attempt */
>>> + if ((*mem_ranges)->nr_ranges == (*mem_ranges)->max_nr_ranges)
>>> + sort_memory_ranges(*mem_ranges, true);
>>> + }
>>> +
>>> + /* Reallocate memory ranges if there is no space to split ranges */
>>> + tmem = *mem_ranges;
>>> + if (tmem && (tmem->nr_ranges == tmem->max_nr_ranges)) {
>>> + tmem = realloc_mem_ranges(mem_ranges);
>>> + if (!tmem)
>>> + goto out;
>>> + }
>>> +
>>> + /* Exclude crashkernel region */
>>> + ret = crash_exclude_mem_range(tmem, crashk_res.start, crashk_res.end);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_rtas_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_opal_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>
>> Maybe I'm confused, but don't you add the RTAS and OPAL regions as
>> usable memory for the crashkernel? In that case they shouldn't show up
>> in the core file.
>
> kexec-tools does the same thing. I am not endorsing it but I was trying to stay
> in parity to avoid breaking any userspace tools/commands. But as you rightly
> pointed, this is NOT right. The right thing to do, to get the rtas/opal data at
> the time of crash, is to have a backup region for them just like we have for
> the first 64K memory. I was hoping to do that later.
>
> Will check how userspace tools respond to dropping these regions. If that makes
> the tools unhappy, will retain the regions with a FIXME. Sorry about the confusion.
No problem, thanks for the clarification.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v3 10/12] ppc64/kexec_file: prepare elfcore header for crashing kernel
From: Thiago Jung Bauermann @ 2020-07-16 21:57 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <929db6fe-b221-a514-8ea1-93227f8d47b0@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:52 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> /**
>>> + * get_crash_memory_ranges - Get crash memory ranges. This list includes
>>> + * first/crashing kernel's memory regions that
>>> + * would be exported via an elfcore.
>>> + * @mem_ranges: Range list to add the memory ranges to.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +static int get_crash_memory_ranges(struct crash_mem **mem_ranges)
>>> +{
>>> + struct memblock_region *reg;
>>> + struct crash_mem *tmem;
>>> + int ret;
>>> +
>>> + for_each_memblock(memory, reg) {
>>> + u64 base, size;
>>> +
>>> + base = (u64)reg->base;
>>> + size = (u64)reg->size;
>>> +
>>> + /* Skip backup memory region, which needs a separate entry */
>>> + if (base == BACKUP_SRC_START) {
>>> + if (size > BACKUP_SRC_SIZE) {
>>> + base = BACKUP_SRC_END + 1;
>>> + size -= BACKUP_SRC_SIZE;
>>> + } else
>>> + continue;
>>> + }
>>> +
>>> + ret = add_mem_range(mem_ranges, base, size);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + /* Try merging adjacent ranges before reallocation attempt */
>>> + if ((*mem_ranges)->nr_ranges == (*mem_ranges)->max_nr_ranges)
>>> + sort_memory_ranges(*mem_ranges, true);
>>> + }
>>> +
>>> + /* Reallocate memory ranges if there is no space to split ranges */
>>> + tmem = *mem_ranges;
>>> + if (tmem && (tmem->nr_ranges == tmem->max_nr_ranges)) {
>>> + tmem = realloc_mem_ranges(mem_ranges);
>>> + if (!tmem)
>>> + goto out;
>>> + }
>>> +
>>> + /* Exclude crashkernel region */
>>> + ret = crash_exclude_mem_range(tmem, crashk_res.start, crashk_res.end);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_rtas_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + ret = add_opal_mem_range(mem_ranges);
>>> + if (ret)
>>> + goto out;
>>
>> Maybe I'm confused, but don't you add the RTAS and OPAL regions as
>> usable memory for the crashkernel? In that case they shouldn't show up
>> in the core file.
>
> kexec-tools does the same thing. I am not endorsing it but I was trying to stay
> in parity to avoid breaking any userspace tools/commands. But as you rightly
> pointed, this is NOT right. The right thing to do, to get the rtas/opal data at
> the time of crash, is to have a backup region for them just like we have for
> the first 64K memory. I was hoping to do that later.
>
> Will check how userspace tools respond to dropping these regions. If that makes
> the tools unhappy, will retain the regions with a FIXME. Sorry about the confusion.
No problem, thanks for the clarification.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH][next] i2c: digicolor: Use fallthrough pseudo-keyword
From: Gustavo A. R. Silva @ 2020-07-16 22:00 UTC (permalink / raw)
To: Baruch Siach
Cc: Gustavo A. R. Silva, linux-i2c, linux-arm-kernel, linux-kernel
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/i2c/busses/i2c-digicolor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-digicolor.c b/drivers/i2c/busses/i2c-digicolor.c
index 332f00437479..f67639dc74b7 100644
--- a/drivers/i2c/busses/i2c-digicolor.c
+++ b/drivers/i2c/busses/i2c-digicolor.c
@@ -187,7 +187,7 @@ static irqreturn_t dc_i2c_irq(int irq, void *dev_id)
break;
}
i2c->state = STATE_WRITE;
- /* fall through */
+ fallthrough;
case STATE_WRITE:
if (i2c->msgbuf_ptr < i2c->msg->len)
dc_i2c_write_buf(i2c);
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [patch V3 01/13] entry: Provide generic syscall entry functionality
From: Thomas Gleixner @ 2020-07-16 21:55 UTC (permalink / raw)
To: Kees Cook
Cc: LKML, x86, linux-arch, Will Deacon, Arnd Bergmann, Mark Rutland,
Keno Fischer, Paolo Bonzini, kvm, Gabriel Krisman Bertazi
In-Reply-To: <202007161336.B993ED938@keescook>
Kees Cook <keescook@chromium.org> writes:
> On Thu, Jul 16, 2020 at 08:22:09PM +0200, Thomas Gleixner wrote:
>> This code is needlessly duplicated and different in all
>> architectures.
>>
>> Provide a generic version based on the x86 implementation which has all the
>> RCU and instrumentation bits right.
>
> Ahh! You're reading my mind!
I told you about that plan at the last conference over a beer :)
> I was just thinking about this while reviewing the proposed syscall
> redirection series[1], and pondering the lack of x86 TIF flags, and
> that nearly everything in the series (and for seccomp and other
> things) didn't need to be arch-specific. And now that series
> absolutely needs to be rebased and it'll magically work for every arch
> that switches to the generic entry code. :)
That's the plan.
> Notes below...
>
> [1] https://lore.kernel.org/lkml/20200716193141.4068476-2-krisman@collabora.com/
Saw that fly by. *shudder*
>> +/*
>> + * Define dummy _TIF work flags if not defined by the architecture or for
>> + * disabled functionality.
>> + */
>
> When I was thinking about this last week I was pondering having a split
> between the arch-agnositc TIF flags and the arch-specific TIF flags, and
> that each arch could have a single "there is agnostic work to be done"
> TIF in their thread_info, and the agnostic flags could live in
> task_struct or something. Anyway, I'll keep reading...
That's going to be nasty. We rather go and expand the TIF storage to
64bit. And then do the following in a generic header:
#ifndef TIF_ARCH_SPECIFIC
# define TIF_ARCH_SPECIFIC
#endif
enum tif_bits {
TIF_NEED_RESCHED = 0,
TIF_...,
TIF_LAST_GENERIC,
TIF_ARCH_SPECIFIC,
};
and in the arch specific one:
#define TIF_ARCH_SPECIFIC \
TIF_ARCH_1, \
TIF_ARCH_2,
or something like that.
>> +/**
>> + * syscall_enter_from_user_mode - Check and handle work before invoking
>> + * a syscall
>> + * @regs: Pointer to currents pt_regs
>> + * @syscall: The syscall number
>> + *
>> + * Invoked from architecture specific syscall entry code with interrupts
>> + * disabled. The calling code has to be non-instrumentable. When the
>> + * function returns all state is correct and the subsequent functions can be
>> + * instrumented.
>> + *
>> + * Returns: The original or a modified syscall number
>> + *
>> + * If the returned syscall number is -1 then the syscall should be
>> + * skipped. In this case the caller may invoke syscall_set_error() or
>> + * syscall_set_return_value() first. If neither of those are called and -1
>> + * is returned, then the syscall will fail with ENOSYS.
>
> There's been some recent confusion over "has the syscall changed,
> or did seccomp request it be skipped?" that was explored in arm64[2]
> (though I see Will and Keno in CC already). There might need to be a
> clearer way to distinguish between "wild userspace issued a -1 syscall"
> and "seccomp or ptrace asked for the syscall to be skipped". The
> difference is mostly about when ENOSYS gets set, with respect to calls
> to syscall_set_return_value(), but if the syscall gets changed, the arch
> may need to recheck the value and consider ENOSYS, etc. IIUC, what Will
> ended up with[3] was having syscall_trace_enter() return the syscall return
> value instead of the new syscall.
I was chatting with Will about that yesterday. IIRC he plans to fix the
immediate issue on arm64 first and then move arm64 over to the generic
variant. That's the reason why I reshuffled the patch series so the
generic parts are first which allows me to provide will a branch with
just those. If there are any changes needed we can just feed them back
into that branch and fixup the affected architecture trees.
IOW, that should not block progress on this stuff.
Thanks,
tglx
^ permalink raw reply
* Re: [iptables PATCH v2] iptables: accept lock file name at runtime
From: Phil Sutter @ 2020-07-16 21:55 UTC (permalink / raw)
To: Giuseppe Scrivano; +Cc: netfilter-devel, Florian Westphal
In-Reply-To: <20200715065152.4172896-1-gscrivan@redhat.com>
Hi,
On Wed, Jul 15, 2020 at 08:51:52AM +0200, Giuseppe Scrivano wrote:
> allow users to override at runtime the lock file to use through the
> XTABLES_LOCKFILE environment variable.
>
> It allows using iptables from a network namespace owned by an user
> that has no write access to XT_LOCK_NAME (by default under /run), and
> without setting up a new mount namespace.
This sentence appears overly complicated to me. Isn't the problem just
that XT_LOCK_NAME may not be writeable? That "user that has no write
access" is typically root anyway as iptables doesn't support being
called by non-privileged UIDs.
> $ XTABLES_LOCKFILE=/tmp/xtables unshare -rn iptables ...
>
> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
> ---
> iptables/xshared.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Could you please update the man page as well? Unless you clarify why
this should be a hidden feature, of course. :)
Cheers, Phil
^ permalink raw reply
* [PATCH][next] i2c: digicolor: Use fallthrough pseudo-keyword
From: Gustavo A. R. Silva @ 2020-07-16 22:00 UTC (permalink / raw)
To: Baruch Siach
Cc: linux-i2c, linux-arm-kernel, linux-kernel, Gustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/i2c/busses/i2c-digicolor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-digicolor.c b/drivers/i2c/busses/i2c-digicolor.c
index 332f00437479..f67639dc74b7 100644
--- a/drivers/i2c/busses/i2c-digicolor.c
+++ b/drivers/i2c/busses/i2c-digicolor.c
@@ -187,7 +187,7 @@ static irqreturn_t dc_i2c_irq(int irq, void *dev_id)
break;
}
i2c->state = STATE_WRITE;
- /* fall through */
+ fallthrough;
case STATE_WRITE:
if (i2c->msgbuf_ptr < i2c->msg->len)
dc_i2c_write_buf(i2c);
--
2.27.0
^ permalink raw reply related
* [PATCH][next] i2c: slave-eeprom: Use fallthrough pseudo-keyword
From: Gustavo A. R. Silva @ 2020-07-16 21:59 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-kernel, Gustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/i2c/i2c-slave-eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c
index 593f2fd39d17..5c7ae421cacf 100644
--- a/drivers/i2c/i2c-slave-eeprom.c
+++ b/drivers/i2c/i2c-slave-eeprom.c
@@ -66,7 +66,7 @@ static int i2c_slave_eeprom_slave_cb(struct i2c_client *client,
case I2C_SLAVE_READ_PROCESSED:
/* The previous byte made it to the bus, get next one */
eeprom->buffer_idx++;
- /* fallthrough */
+ fallthrough;
case I2C_SLAVE_READ_REQUESTED:
spin_lock(&eeprom->buffer_lock);
*val = eeprom->buffer[eeprom->buffer_idx & eeprom->address_mask];
--
2.27.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.