This is the start of the stable review cycle for the 5.4.214 release.
There are 14 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 18 Sep 2022 10:04:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.214-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.214-rc1
Brian Norris <briannorris(a)chromium.org>
tracefs: Only clobber mode/uid/gid on remount if asked
Mathew McBride <matt(a)traverse.com.au>
soc: fsl: select FSL_GUTS driver for DPIO
Enguerrand de Ribaucourt <enguerrand.de-ribaucourt(a)savoirfairelinux.com>
net: dp83822: disable rx error interrupt
Jann Horn <jannh(a)google.com>
mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
Hu Xiaoying <huxiaoying(a)kylinos.cn>
usb: storage: Add ASUS <0x0b05:0x1932> to IGNORE_UAS
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
Yu Zhe <yuzhe(a)nfschina.com>
perf/arm_pmu_platform: fix tests for platform_get_irq() failure
Maurizio Lombardi <mlombard(a)redhat.com>
nvmet-tcp: fix unhandled tcp states in nvmet_tcp_state_change()
Greg Tulli <greg.iforce(a)gmail.com>
Input: iforce - add support for Boeder Force Feedback Wheel
Li Qiong <liqiong(a)nfschina.com>
ieee802154: cc2520: add rc code in cc2520_tx()
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
tg3: Disable tg3 device on system reboot to avoid triggering AER
Even Xu <even.xu(a)intel.com>
hid: intel-ish-hid: ishtp: Fix ishtp client sending disordered message
Jason Wang <wangborong(a)cdjrlc.com>
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
Rob Clark <robdclark(a)chromium.org>
drm/msm/rd: Fix FIFO-full deadlock
-------------
Diffstat:
Documentation/input/joydev/joystick.rst | 1 +
Makefile | 4 +-
drivers/gpu/drm/msm/msm_rd.c | 3 ++
drivers/hid/intel-ish-hid/ishtp-hid.h | 2 +-
drivers/hid/intel-ish-hid/ishtp/client.c | 68 +++++++++++++++++------------
drivers/input/joystick/iforce/iforce-main.c | 1 +
drivers/net/ethernet/broadcom/tg3.c | 8 +++-
drivers/net/ieee802154/cc2520.c | 1 +
drivers/net/phy/dp83822.c | 3 +-
drivers/nvme/target/tcp.c | 3 ++
drivers/perf/arm_pmu_platform.c | 2 +-
drivers/platform/x86/acer-wmi.c | 9 +++-
drivers/soc/fsl/Kconfig | 1 +
drivers/usb/storage/unusual_uas.h | 7 +++
fs/tracefs/inode.c | 31 +++++++++----
mm/mmap.c | 9 +++-
16 files changed, 105 insertions(+), 48 deletions(-)
Currently, the non-x86 stub code calls get_memory_map() redundantly,
given that the data it returns is never used anywhere. So drop the call.
Cc: <stable(a)vger.kernel.org> # v4.14+
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
drivers/firmware/efi/libstub/fdt.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index fe567be0f118..804f542be3f2 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -280,14 +280,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
goto fail;
}
- /*
- * Now that we have done our final memory allocation (and free)
- * we can get the memory map key needed for exit_boot_services().
- */
- status = efi_get_memory_map(&map);
- if (status != EFI_SUCCESS)
- goto fail_free_new_fdt;
-
status = update_fdt((void *)fdt_addr, fdt_size,
(void *)*new_fdt_addr, MAX_FDT_SIZE, cmdline_ptr,
initrd_addr, initrd_size);
--
2.35.1
Hello Dear ,
I am Hassan Said Bin Hassan a financial consultant and a registered
agent with Top loan and investment companies in Asia, Africa, Europe
and America . I am consulting for them on commission bases and also
have agreement to source for clients that need funds to finance their
business or need partners or joint venture business relationship.
I am sourcing for companies, individual that need investors or loan to
finance their business. With my position, you can have access to a
soft loan for funding your business. Soft loan usually allows time
enough for repayment and also at relatively low interest rate.
Kindly indicate your interest to enable me to introduce you to the
company for processing of your loan within a few days with my support.
More details will be sent to you as soon as you indicate your interest
in your next response.
Thanks,
Hassan Said Bin Hassan
binhassanhassansaid(a)gmail.com
I am Mrs Yu. Ging Yunnan, and i have Covid-19 and the doctor said I
will not survive it because all vaccines has been given to me but to
no avian, am a China woman but I base here in France because am
married here and I have no child for my late husband and now am a
widow.
My reason of communicating you is that i have $9.2million USD which
was deposited in BNP Paribas Bank here in France by my late husband
which am the next of kin to and I want you to stand as the
beneficiary for the claim now that am about to end my race according
to my doctor.I will want you to use the fund to build an orphanage
home in my name there in country, please kindly reply to this message
urgently if willing to handle this project. God bless you and i wait
your swift response asap.
Mrs.Yunnan Ging.
The DPS310 chip has been observed to get "stuck" such that pressure
and temperature measurements are never indicated as "ready" in the
MEAS_CFG register. The only solution is to reset the device and try
again. In order to avoid continual failures, use a boolean flag to
only try the reset after timeout once if errors persist. Include a
patch to move the startup procedure into a function.
Changes since v7:
- Condense the code a bit by dropping rc2
Changes since v6:
- Use helper instead of the lengthy regmap_read_poll_timeout twice
- Just return dps310_startup in dps310_reset_reinit
Changes since v5:
- Completely rework the second patch to reset and reinit in any
timeout condition, if there haven't been previous timeouts that
failed to recover the chip.
Changes since v4:
- Just check for rc rather than rc < 0 in some cases
- Split declaration and init of rc
Changes since v3:
- Don't check regmap* return codes for < 0
- Fix comment spelling
Changes since v2:
- Add some comments
- Fix the clunky control flow
Changes since v1:
- Separate into two patches
- Rename 'dps310_verify_meas_cfg' to 'dps310_check_reset_meas_cfg'
Eddie James (2):
iio: pressure: dps310: Refactor startup procedure
iio: pressure: dps310: Reset chip after timeout
drivers/iio/pressure/dps310.c | 262 +++++++++++++++++++++-------------
1 file changed, 163 insertions(+), 99 deletions(-)
--
2.31.1
I hope that you are at your best and doing well. The purpose of this letter is seeking for a pen pal like friendship and I'd love to and be honored to be friends with you if you do not mind.. If the Idea sounds OK with you, just say yes and we can take it on from there. I look forward to hear hearing from you.. My name is Emerald From Sweden 36 years , this will mean a lot to me to hear back from you.
Warm Regards.
Emerald
*
***
*****
]+[ << Please consider the environment before printing this email >>
UCHI OPTOELECTRONIC (M) SDN. BHD.
Website : www.uchi.net
This e-mail and any files transmitted with it contain confidential and/or
privileged information and intended solely for the use of the individual
or entity to whom they are addressed. If you are not the intended recipient
(or have received this e-mail in error),please notify the sender immediately
and destroy this e-mail. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Please note that any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of the organization. Finally, the
recipient should check this email and any attachments for the presence of
viruses. The organization accepts no liability for any damage caused by
any virus transmitted by this email.
Fix an issue with the Tyan Tomcat IV S1564D system, the BIOS of which
does not assign PCI buses beyond #2, where our resource reallocation
code preserves the reset default of an I/O BAR assignment outside its
upstream PCI-to-PCI bridge's I/O forwarding range for device 06:08.0 in
this log:
pci_bus 0000:00: max bus depth: 4 pci_try_num: 5
[...]
pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: failed to assign [io size 0x0020]
pci 0000:05:00.0: PCI bridge to [bus 06]
pci 0000:05:00.0: bridge window [mem 0xd8000000-0xd85fffff]
[...]
pci 0000:00:11.0: PCI bridge to [bus 01-06]
pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
pci 0000:00:11.0: bridge window [mem 0xd8000000-0xdfffffff]
pci 0000:00:11.0: bridge window [mem 0xa8000000-0xafffffff 64bit pref]
pci_bus 0000:00: No. 2 try to assign unassigned res
[...]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: failed to assign [io size 0x0020]
pci 0000:05:00.0: PCI bridge to [bus 06]
pci 0000:05:00.0: bridge window [mem 0xd8000000-0xd85fffff]
[...]
pci 0000:00:11.0: PCI bridge to [bus 01-06]
pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
pci 0000:00:11.0: bridge window [mem 0xd8000000-0xdfffffff]
pci 0000:00:11.0: bridge window [mem 0xa8000000-0xafffffff 64bit pref]
pci_bus 0000:00: No. 3 try to assign unassigned res
pci 0000:00:11.0: resource 7 [io 0xe000-0xefff] released
[...]
pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f]
pci 0000:05:00.0: PCI bridge to [bus 06]
pci 0000:05:00.0: bridge window [io 0x2000-0x2fff]
pci 0000:05:00.0: bridge window [mem 0xd8000000-0xd85fffff]
[...]
pci 0000:00:11.0: PCI bridge to [bus 01-06]
pci 0000:00:11.0: bridge window [io 0x1000-0x2fff]
pci 0000:00:11.0: bridge window [mem 0xd8000000-0xdfffffff]
pci 0000:00:11.0: bridge window [mem 0xa8000000-0xafffffff 64bit pref]
pci_bus 0000:00: resource 4 [io 0x0000-0xffff]
pci_bus 0000:00: resource 5 [mem 0x00000000-0xffffffff]
pci_bus 0000:01: resource 0 [io 0x1000-0x2fff]
pci_bus 0000:01: resource 1 [mem 0xd8000000-0xdfffffff]
pci_bus 0000:01: resource 2 [mem 0xa8000000-0xafffffff 64bit pref]
pci_bus 0000:02: resource 0 [io 0x1000-0x2fff]
pci_bus 0000:02: resource 1 [mem 0xd8000000-0xd8bfffff]
pci_bus 0000:04: resource 0 [io 0x1000-0x1fff]
pci_bus 0000:04: resource 1 [mem 0xd8600000-0xd8afffff]
pci_bus 0000:05: resource 0 [io 0x2000-0x2fff]
pci_bus 0000:05: resource 1 [mem 0xd8000000-0xd85fffff]
pci_bus 0000:06: resource 0 [io 0x2000-0x2fff]
pci_bus 0000:06: resource 1 [mem 0xd8000000-0xd85fffff]
-- note that the assignment of 0xfce0-0xfcff is outside the range of
0x2000-0x2fff assigned to bus #6:
05:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=05, secondary=06, subordinate=06, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: d8000000-d85fffff
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/4 Enable-
Capabilities: [80] #0d [0000]
Capabilities: [90] Express PCI/PCI-X Bridge IRQ 0
06:08.0 USB controller: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 22, IRQ 5
I/O ports at fce0 [size=32]
Capabilities: [80] Power Management version 2
06:08.1 USB controller: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 22, IRQ 5
I/O ports at 2000 [size=32]
Capabilities: [80] Power Management version 2
Since both 06:08.0 and 06:08.1 have the same reset defaults the latter
device escapes its fate and gets a good assignment owing to an address
conflict with the former device.
Consequently when the device driver tries to access 06:08.0 according to
its designated address range it pokes at an unassigned I/O location,
likely subtractively decoded by the southbridge and forwarded to ISA,
causing the driver to become confused and bail out:
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
uhci_hcd 0000:06:08.0: host controller halted, very bad!
uhci_hcd 0000:06:08.0: HCRESET not completed yet!
uhci_hcd 0000:06:08.0: HC died; cleaning up
if good luck happens or if bad luck does, an infinite flood of messages:
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
[...]
making the system virtually unusuable.
This is because we have code to deal with a situation from PR #16263,
where broken ACPI firmware reports the wrong address range for the host
bridge's decoding window and trying to adjust to the window causes more
breakage than leaving the BIOS assignments intact.
This may work for a device directly on the root bus decoded by the host
bridge only, but for a device behind one or more PCI-to-PCI (or CardBus)
bridges those bridges' forwarding windows have been standardised and
need to be respected, or leaving whatever has been there in a downstream
device's BAR will have no effect as cycles for the addresses recorded
there will have no chance to appear on the bus the device has been
immediately attached to.
Make sure then for a device behind a PCI-to-PCI bridge that any firmware
assignment is within the bridge's relevant forwarding window or do not
restore the assignment, fixing the system concerned as follows:
pci_bus 0000:00: max bus depth: 4 pci_try_num: 5
[...]
pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.0: BAR 4: failed to assign [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: failed to assign [io 0xfce0-0xfcff]
[...]
pci_bus 0000:00: No. 2 try to assign unassigned res
[...]
pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.0: BAR 4: failed to assign [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: failed to assign [io 0xfce0-0xfcff]
[...]
pci_bus 0000:00: No. 3 try to assign unassigned res
[...]
pci 0000:06:08.0: BAR 4: assigned [io 0x2000-0x201f]
pci 0000:06:08.1: BAR 4: assigned [io 0x2020-0x203f]
and making device 06:08.0 work correctly.
Cf. <https://bugzilla.kernel.org/show_bug.cgi?id=16263>
Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk>
Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses")
Cc: stable(a)vger.kernel.org # v2.6.35+
---
Hi,
Resending this patch as it has gone into void. Patch re-verified against
5.17-rc2.
For the record the system's bus topology is as follows:
-[0000:00]-+-00.0
+-07.0
+-07.1
+-07.2
+-11.0-[0000:01-06]----00.0-[0000:02-06]--+-00.0-[0000:03]--
| +-01.0-[0000:04]--+-00.0
| | \-00.3
| \-02.0-[0000:05-06]----00.0-[0000:06]--+-05.0
| +-08.0
| +-08.1
| \-08.2
+-12.0
+-13.0
\-14.0
Maciej
Changes from v1:
- Do restore firmware BAR assignments behind a PCI-PCI bridge, but only if
within the bridge's forwarding window.
- Update the change description and heading accordingly (was: PCI: Do not
restore firmware BAR assignments behind a PCI-PCI bridge).
---
drivers/pci/setup-res.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
linux-pci-setup-res-fw-address-nobridge.diff
Index: linux-macro/drivers/pci/setup-res.c
===================================================================
--- linux-macro.orig/drivers/pci/setup-res.c
+++ linux-macro/drivers/pci/setup-res.c
@@ -212,9 +212,19 @@ static int pci_revert_fw_address(struct
res->end = res->start + size - 1;
res->flags &= ~IORESOURCE_UNSET;
+ /*
+ * If we're behind a P2P or CardBus bridge, make sure we're
+ * inside the relevant forwarding window, or otherwise the
+ * assignment must have been bogus and accesses intended for
+ * the range assigned would not reach the device anyway.
+ * On the root bus accept anything under the assumption the
+ * host bridge will let it through.
+ */
root = pci_find_parent_resource(dev, res);
if (!root) {
- if (res->flags & IORESOURCE_IO)
+ if (dev->bus->parent)
+ return -ENXIO;
+ else if (res->flags & IORESOURCE_IO)
root = &ioport_resource;
else
root = &iomem_resource;
This is the start of the stable review cycle for the 4.9.329 release.
There are 7 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 18 Sep 2022 10:04:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.329-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.329-rc1
Brian Norris <briannorris(a)chromium.org>
tracefs: Only clobber mode/uid/gid on remount if asked
Jann Horn <jannh(a)google.com>
mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
Li Qiong <liqiong(a)nfschina.com>
ieee802154: cc2520: add rc code in cc2520_tx()
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
tg3: Disable tg3 device on system reboot to avoid triggering AER
Jason Wang <wangborong(a)cdjrlc.com>
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
Rob Clark <robdclark(a)chromium.org>
drm/msm/rd: Fix FIFO-full deadlock
-------------
Diffstat:
Makefile | 4 ++--
drivers/gpu/drm/msm/msm_rd.c | 3 +++
drivers/hid/intel-ish-hid/ishtp-hid.h | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 8 ++++++--
drivers/net/ieee802154/cc2520.c | 1 +
drivers/platform/x86/acer-wmi.c | 9 ++++++++-
fs/tracefs/inode.c | 31 +++++++++++++++++++++++--------
mm/mmap.c | 9 +++++++--
8 files changed, 51 insertions(+), 16 deletions(-)