This is a note to let you know that I've just added the patch titled
usb: dwc2: fix STM ID/VBUS detection startup delay in
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fac6bf87c55f7f0733efb0375565fb6a50cf2caf Mon Sep 17 00:00:00 2001
From: Amelie Delaunay <amelie.delaunay(a)foss.st.com>
Date: Tue, 7 Dec 2021 13:45:10 +0100
Subject: usb: dwc2: fix STM ID/VBUS detection startup delay in
dwc2_driver_probe
When activate_stm_id_vb_detection is enabled, ID and Vbus detection relies
on sensing comparators. This detection needs time to stabilize.
A delay was already applied in dwc2_resume() when reactivating the
detection, but it wasn't done in dwc2_probe().
This patch adds delay after enabling STM ID/VBUS detection. Then, ID state
is good when initializing gadget and host, and avoid to get a wrong
Connector ID Status Change interrupt.
Fixes: a415083a11cc ("usb: dwc2: add support for STM32MP15 SoCs USB OTG HS and FS")
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay(a)foss.st.com>
Link: https://lore.kernel.org/r/20211207124510.268841-1-amelie.delaunay@foss.st.c…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index c8f18f3ba9e3..c331a5128c2c 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -575,6 +575,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
ggpio |= GGPIO_STM32_OTG_GCCFG_IDEN;
ggpio |= GGPIO_STM32_OTG_GCCFG_VBDEN;
dwc2_writel(hsotg, ggpio, GGPIO);
+
+ /* ID/VBUS detection startup time */
+ usleep_range(5000, 7000);
}
retval = dwc2_drd_init(hsotg);
--
2.34.1
On Wed, Oct 20, 2021 at 12:23:26PM +0200, Hans de Goede wrote:
> On 10/19/21 23:52, Bjorn Helgaas wrote:
> > On Thu, Oct 14, 2021 at 08:39:42PM +0200, Hans de Goede wrote:
> >> Some BIOS-es contain a bug where they add addresses which map to system
> >> RAM in the PCI host bridge window returned by the ACPI _CRS method, see
> >> commit 4dc2287c1805 ("x86: avoid E820 regions when allocating address
> >> space").
> >>
> >> To work around this bug Linux excludes E820 reserved addresses when
> >> allocating addresses from the PCI host bridge window since 2010.
> >> ...
> > I haven't seen anybody else eager to merge this, so I guess I'll stick
> > my neck out here.
> >
> > I applied this to my for-linus branch for v5.15.
>
> Thank you, and sorry about the build-errors which the lkp
> kernel-test-robot found.
>
> I've just send out a patch which fixes these build-errors
> (verified with both .config-s from the lkp reports).
> Feel free to squash this into the original patch (or keep
> them separate, whatever works for you).
Thanks, I squashed the fix in.
HOWEVER, I think it would be fairly risky to push this into v5.15.
We would be relying on the assumption that current machines have all
fixed the BIOS defect that 4dc2287c1805 addressed, and we have little
evidence for that.
I'm not sure there's significant benefit to having this in v5.15.
Yes, the mainline v5.15 kernel would work on the affected machines,
but I suspect most people with those machines are running distro
kernels, not mainline kernels.
This issue has been around a long time, so it's not like a regression
that we just introduced. If we fixed these machines and regressed
*other* machines, we'd be worse off than we are now.
Convince me otherwise if you see this differently :)
In the meantime, here's another possibility for working around this.
What if we discarded remove_e820_regions() completely, but aligned the
problem _CRS windows a little more? The 4dc2287c1805 case was this:
BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved)
pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
where the _CRS window was of size 0x20100000, i.e., 512M + 1M. At
least in this particular case, we could avoid the problem by throwing
away that first 1M and aligning the window to a nice 3G boundary.
Maybe it would be worth giving up a small fraction (less than 0.2% in
this case) of questionable windows like this?
Bjorn
When linux memory is not aligned with page block size and have hole in zone,
the 5.4-lts arm kernel might crash in move_freepages() as Kefen Wang reported in [1].
Backport the upstream fix commits by Mike Rapoport [2] to 5.4 can fix this issue.
And free_unused_memmap() of arm and arm64 are moved to generic mm/memblock in
the below upstream commit, so I applied the first two patches to free_unused_memmap()
in arch/arm/mm/init.c.
(4f5b0c178996 arm, arm64: move free_unused_memmap() to generic mm)
[1] https://lore.kernel.org/lkml/2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.co…
[2] https://lore.kernel.org/lkml/20210630071211.21011-1-rppt@kernel.org/#t
Mike Rapoport (5):
memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER
memblock: align freed memory map on pageblock boundaries with
SPARSEMEM
memblock: ensure there is no overflow in memblock_overlaps_region()
arm: extend pfn_valid to take into account freed memory map alignment
arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM
arch/arm/mm/init.c | 37 +++++++++++++++++++++++++------------
arch/arm/mm/ioremap.c | 4 +++-
mm/memblock.c | 3 ++-
3 files changed, 30 insertions(+), 14 deletions(-)
--
2.18.0
Here are some fixes backported to v5.10.
Adrian Hunter (8):
perf inject: Fix itrace space allowed for new attributes
perf intel-pt: Fix some PGE (packet generation enable/control flow packets) usage
perf intel-pt: Fix sync state when a PSB (synchronization) packet is found
perf intel-pt: Fix intel_pt_fup_event() assumptions about setting state type
perf intel-pt: Fix state setting when receiving overflow (OVF) packet
perf intel-pt: Fix next 'err' value, walking trace
perf intel-pt: Fix missing 'instruction' events with 'q' option
perf intel-pt: Fix error timestamp setting on the decoder error path
tools/perf/builtin-inject.c | 2 +-
.../perf/util/intel-pt-decoder/intel-pt-decoder.c | 83 ++++++++++++++--------
tools/perf/util/intel-pt.c | 1 +
3 files changed, 56 insertions(+), 30 deletions(-)
commit c29d9792607e67ed8a3f6e9db0d96836d885a8c5 upstream.
The space allowed for new attributes can be too small if existing header
information is large. That can happen, for example, if there are very
many CPUs, due to having an event ID per CPU per event being stored in the
header information.
Fix by adding the existing header.data_offset. Also increase the extra
space allowed to 8KiB and align to a 4KiB boundary for neatness.
Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Link: http://lore.kernel.org/lkml/20211125071457.2066863-1-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[Adrian: Backport to v5.15]
Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com>
---
tools/perf/builtin-inject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 6ad191e731fc..d454f5a7af93 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -819,7 +819,7 @@ static int __cmd_inject(struct perf_inject *inject)
inject->tool.ordered_events = true;
inject->tool.ordering_requires_timestamps = true;
/* Allow space in the header for new attributes */
- output_data_offset = 4096;
+ output_data_offset = roundup(8192 + session->header.data_offset, 4096);
if (inject->strip)
strip_init(inject);
}
--
2.25.1
commit dde91ccfa25fd58f64c397d91b81a4b393100ffa upstream
There is a short period between a net device starts to be unregistered
and when it is actually gone. In that time frame ethtool operations
could still be performed, which might end up in unwanted or undefined
behaviours[1].
Do not allow ethtool operations after a net device starts its
unregistration. This patch targets the netlink part as the ioctl one
isn't affected: the reference to the net device is taken and the
operation is executed within an rtnl lock section and the net device
won't be found after unregister.
[1] For example adding Tx queues after unregister ends up in NULL
pointer exceptions and UaFs, such as:
BUG: KASAN: use-after-free in kobject_get+0x14/0x90
Read of size 1 at addr ffff88801961248c by task ethtool/755
CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014
Call Trace:
dump_stack_lvl+0x57/0x72
print_address_description.constprop.0+0x1f/0x140
kasan_report.cold+0x7f/0x11b
kobject_get+0x14/0x90
kobject_add_internal+0x3d1/0x450
kobject_init_and_add+0xba/0xf0
netdev_queue_update_kobjects+0xcf/0x200
netif_set_real_num_tx_queues+0xb4/0x310
veth_set_channels+0x1c3/0x550
ethnl_set_channels+0x524/0x610
[The patch differs from the upstream one as code was moved around by
commit 41107ac22fcf ("ethtool: move netif_device_present check from
ethnl_parse_header_dev_get to ethnl_ops_begin"). The check on the netdev
state is still done in ethnl_ops_begin as it must be done in an rtnl
section (the one which performs the op) to not race with
unregister_netdevice_many.
Also note the trace in [1] is not possible here as the channel ops for
veth were added later, but that was just one example.]
Fixes: 041b1c5d4a53 ("ethtool: helper functions for netlink interface")
Suggested-by: Jakub Kicinski <kuba(a)kernel.org>
Signed-off-by: Antoine Tenart <atenart(a)kernel.org>
---
Hello,
This patch is intended for the stable 5.10 tree.
As reported by Greg, patch dde91ccfa25f ("ethtool: do not perform
operations on net devices being unregistered") did not apply correctly
on the 5.10 tree. The explanation of this and the approach taken here is
explained in the above commit log, between [].
I removed the Link tag and Signed-off-by from Jakub from the original
patch as this one is slightly different in its implementation.
Thanks,
Antoine
net/ethtool/netlink.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index d8efec516d86..979dee6bb88c 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -249,6 +249,9 @@ struct ethnl_reply_data {
static inline int ethnl_ops_begin(struct net_device *dev)
{
+ if (dev && dev->reg_state == NETREG_UNREGISTERING)
+ return -ENODEV;
+
if (dev && dev->ethtool_ops->begin)
return dev->ethtool_ops->begin(dev);
else
--
2.33.1