5.7.5-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 283/376 ext4: fix race between ext4_sync_parent() and rename()
In reply to Greg Kroah-HartmanFrom: Eric Biggers <[email protected]>
commit 08adf452e628b0e2ce9a01048cfbec52353703d7 upstream.
'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is broken because without d_lock, d_parent can be concurrently changed due to a rename(). Then if the old directory is immediately deleted, old d_parent->inode can be NULL. That causes a NULL dereference in igrab().
To fix this, use dget_parent() to safely grab a reference to the parent dentry, which pins the inode. This also eliminates the need to use d_find_any_alias() other than for the initial inode, as we no longer throw away the dentry at each step.
This is an extremely hard race to hit, but it is possible. Adding a udelay() in between the reads of ->d_parent and its ->d_inode makes it reproducible on a no-journal filesystem using the following program:
#include <fcntl.h>
#include <unistd.h>
int main()
{
if (fork()) {
for (;;) {
mkdir("dir1", 0700);
int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC);
write(fd, "X", 1);
close(fd);
}
} else {
mkdir("dir2", 0700);
for (;;) {
rename("dir1/file", "dir2/file");
rmdir("dir1");
}
}
}--- fs/ext4/fsync.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
fs/ext4/fsync.c +13 -15
@@ -44,30 +44,28 @@*/ static int ext4_sync_parent (struct inode *inode) { -struct dentry *dentry =NULL ; -struct inode *next; +struct dentry *dentry, *next;int ret =0 ;if (!ext4_test_inode_state (inode,EXT4_STATE_NEWENTRY ))return 0 ; - inode =igrab (inode); + dentry =d_find_any_alias (inode); +if (!dentry) +return 0 ;while (ext4_test_inode_state (inode,EXT4_STATE_NEWENTRY )) {ext4_clear_inode_state (inode,EXT4_STATE_NEWENTRY ); - dentry =d_find_any_alias (inode); -if (!dentry) -break ; - next =igrab (d_inode (dentry->d_parent)); + + next =dget_parent (dentry);dput (dentry); -if (!next) -break ; -iput (inode); - inode = next; + dentry = next; + inode = dentry->d_inode; +/* * The directory inode may have gone through rmdir by now. But * the inode itself and its blocks are still allocated (we hold -* a reference to the inode so it didn't go through -* ext4_evict_inode()) and so we are safe to flush metadata -* blocks and the inode. +* a reference to the inode via its dentry), so it didn't go +* through ext4_evict_inode()) and so we are safe to flush +* metadata blocks and the inode. */ ret =sync_mapping_buffers (inode->i_mapping);if (ret)
@@ -76,7 +74,7 @@ static int ext4_sync_parent(struct inodeif (ret)break ; } -iput (inode); +dput (dentry);return ret; }
Greg Kroah-Hartman
maintainerPATCH 284/376 PCI: Avoid Pericom USB controller OHCI/EHCI PME# defect
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
[ Upstream commit 68f5fc4ea9ddf9f77720d568144219c4e6452cde ]
Both Pericom OHCI and EHCI devices advertise PME# support from all power states:
06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI])
Subsystem: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e]
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
06:00.2 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] (rev 01) (prog-if 20 [EHCI])
Subsystem: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f]
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
But testing shows that it's unreliable: there is a 20% chance PME# won't be asserted when a USB device is plugged.
Remove PME support for both devices to make USB plugging work reliably.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205981
--- drivers/pci/quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/pci/quirks.c +13 -0
@@ -5568,6 +5568,19 @@ static void pci_fixup_no_d0_pme(struct pci_dev *dev) }DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_ASMEDIA ,0x2142 , pci_fixup_no_d0_pme); +/* +* Device [12d8:0x400e] and [12d8:0x400f] +* These devices advertise PME# support in all power states but don't +* reliably assert it. +*/ +static void pci_fixup_no_pme (struct pci_dev *dev) +{ +pci_info (dev,"PME# is unreliable, disabling it\n" ); + dev->pme_support =0 ; +} +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_PERICOM ,0x400e , pci_fixup_no_pme); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_PERICOM ,0x400f , pci_fixup_no_pme); +static void apex_pci_fixup_class (struct pci_dev *pdev) { pdev->class = (PCI_CLASS_SYSTEM_OTHER <<8 ) | pdev->class;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 285/376 PCI: Avoid FLR for AMD Matisse HD Audio & USB 3.0
In reply to Greg Kroah-HartmanFrom: Marcos Scriven <[email protected]>
[ Upstream commit 0d14f06cd6657ba3446a5eb780672da487b068e7 ]
The AMD Matisse HD Audio & USB 3.0 devices advertise Function Level Reset support, but hang when an FLR is triggered.
To reproduce the problem, attach the device to a VM, then detach and try to attach again.
Rename the existing quirk_intel_no_flr(), which was not Intel-specific, to quirk_no_flr(), and apply it to prevent the use of FLR on these AMD devices.
--- drivers/pci/quirks.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
drivers/pci/quirks.c +14 -4
@@ -5129,13 +5129,23 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev) }DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x443 , quirk_intel_qat_vf_cap); -/* FLR may cause some 82579 devices to hang */ -static void quirk_intel_no_flr (struct pci_dev *dev) +/* +* FLR may cause the following to devices to hang: +* +* AMD Starship/Matisse HD Audio Controller 0x1487 +* AMD Matisse USB 3.0 Host Controller 0x149c +* Intel 82579LM Gigabit Ethernet Controller 0x1502 +* Intel 82579V Gigabit Ethernet Controller 0x1503 +* +*/ +static void quirk_no_flr (struct pci_dev *dev) { dev->dev_flags |=PCI_DEV_FLAGS_NO_FLR_RESET ; } -DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1502 , quirk_intel_no_flr); -DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1503 , quirk_intel_no_flr); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_AMD ,0x1487 , quirk_no_flr); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_AMD ,0x149c , quirk_no_flr); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1502 , quirk_no_flr); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1503 , quirk_no_flr);static void quirk_no_ext_tags (struct pci_dev *pdev) {
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 286/376 PCI: Avoid FLR for AMD Starship USB 3.0
In reply to Greg Kroah-HartmanFrom: Kevin Buettner <[email protected]>
[ Upstream commit 5727043c73fdfe04597971b5f3f4850d879c1f4f ]
The AMD Starship USB 3.0 host controller advertises Function Level Reset support, but it apparently doesn't work. Add a quirk to prevent use of FLR on this device.
Without this quirk, when attempting to assign (pass through) an AMD Starship USB 3.0 host controller to a guest OS, the system becomes increasingly unresponsive over the course of several minutes, eventually requiring a hard reset. Shortly after attempting to start the guest, I see these messages:
vfio-pci 0000:05:00.3: not ready 1023ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 2047ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 4095ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 8191ms after FLR; waiting
And then eventually:
vfio-pci 0000:05:00.3: not ready 65535ms after FLR; giving up
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs
perf: interrupt took too long (642744 > 2500), lowering kernel.perf_event_max_sample_rate to 1000
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 82.270 msecs
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 680.608 msecs
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 100.952 msecs
...
watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [qemu-system-x86:7487]
Tested on a Micro-Star International Co., Ltd. MS-7C59/Creator TRX40 motherboard with an AMD Ryzen Threadripper 3970X.
--- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pci/quirks.c +2 -0
@@ -5133,6 +5133,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);* FLR may cause the following to devices to hang: * * AMD Starship/Matisse HD Audio Controller 0x1487 +* AMD Starship USB 3.0 Host Controller 0x148c * AMD Matisse USB 3.0 Host Controller 0x149c * Intel 82579LM Gigabit Ethernet Controller 0x1502 * Intel 82579V Gigabit Ethernet Controller 0x1503
@@ -5143,6 +5144,7 @@ static void quirk_no_flr(struct pci_dev *dev) dev->dev_flags |=PCI_DEV_FLAGS_NO_FLR_RESET ; }DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_AMD ,0x1487 , quirk_no_flr); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_AMD ,0x148c , quirk_no_flr);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_AMD ,0x149c , quirk_no_flr);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1502 , quirk_no_flr);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x1503 , quirk_no_flr);
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 287/376 PCI: Add ACS quirk for Intel Root Complex Integrated Endpoints
In reply to Greg Kroah-HartmanFrom: Ashok Raj <[email protected]>
[ Upstream commit 3247bd10a4502a3075ce8e1c3c7d31ef76f193ce ]
All Intel platforms guarantee that all root complex implementations must send transactions up to IOMMU for address translations. Hence for Intel RCiEP devices, we can assume some ACS-type isolation even without an ACS capability.
Quoted 1 line
From the Intel VT-d spec, r3.1, sec 3.16 ("Root-Complex Peer to Peer
Considerations"):
When DMA remapping is enabled, peer-to-peer requests through the Root-Complex must be handled as follows:
- The input address in the request is translated (through first-level, second-level or nested translation) to a host physical address (HPA). The address decoding for peer addresses must be done only on the translated HPA. Hardware implementations are free to further limit peer-to-peer accesses to specific host physical address regions (or to completely disallow peer-forwarding of translated requests).
- Since address translation changes the contents (address field) of the PCI Express Transaction Layer Packet (TLP), for PCI Express peer-to-peer requests with ECRC, the Root-Complex hardware must use the new ECRC (re-computed with the translated address) if it decides to forward the TLP as a peer request.
- Root-ports, and multi-function root-complex integrated endpoints, may support additional peer-to-peer control features by supporting PCI Express Access Control Services (ACS) capability. Refer to ACS capability in PCI Express specifications for details.
Since Linux didn't give special treatment to allow this exception, certain RCiEP MFD devices were grouped in a single IOMMU group. This doesn't permit a single device to be assigned to a guest for instance.
In one vendor system: Device 14.x were grouped in a single IOMMU group.
/sys/kernel/iommu_groups/5/devices/0000:00:14.0
/sys/kernel/iommu_groups/5/devices/0000:00:14.2
/sys/kernel/iommu_groups/5/devices/0000:00:14.3
After this patch:
/sys/kernel/iommu_groups/5/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:14.2 /sys/kernel/iommu_groups/6/devices/0000:00:14.3 <<< new group
14.0 and 14.2 are integrated devices, but legacy end points, whereas 14.3 was a PCIe-compliant RCiEP.
00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
This permits assigning this device to a guest VM.
--- drivers/pci/quirks.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
drivers/pci/quirks.c +15 -0
@@ -4682,6 +4682,20 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, u16 acs_flags) PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT); } +static int pci_quirk_rciep_acs (struct pci_dev *dev,u16 acs_flags) +{ +/* +* Intel RCiEP's are required to allow p2p only on translated +* addresses. Refer to Intel VT-d specification, r3.1, sec 3.16, +* "Root-Complex Peer to Peer Considerations". +*/ +if (pci_pcie_type (dev) !=PCI_EXP_TYPE_RC_END ) +return -ENOTTY ; + +return pci_acs_ctrl_enabled (acs_flags, +PCI_ACS_SV |PCI_ACS_RR |PCI_ACS_CR |PCI_ACS_UF ); +} +static int pci_quirk_brcm_acs (struct pci_dev *dev,u16 acs_flags) {/*
@@ -4764,6 +4778,7 @@ static const struct pci_dev_acs_enabled {/* I219 */ { PCI_VENDOR_ID_INTEL, 0x15b7, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_INTEL, 0x15b8, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_rciep_acs },/* QCOM QDF2xxx root ports */ { PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs }, { PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 288/376 serial: 8250_pci: Move Pericom IDs to pci_ids.h
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
[ Upstream commit 62a7f3009a460001eb46984395280dd900bc4ef4 ]
Move the IDs to pci_ids.h so it can be used by next patch.
--- drivers/tty/serial/8250/8250_pci.c | 6 ------ include/linux/pci_ids.h | 6 ++++++ 2 files changed, 6 insertions(+), 6 deletions(-)
drivers/tty/serial/8250/8250_pci.c +0 -6
@@ -1869,12 +1869,6 @@ pci_moxa_setup(struct serial_private *priv,#define PCIE_DEVICE_ID_WCH_CH384_4S 0x3470#define PCIE_DEVICE_ID_WCH_CH382_2S 0x3253 -#define PCI_VENDOR_ID_PERICOM 0x12D8 -#define PCI_DEVICE_ID_PERICOM_PI7C9X7951 0x7951 -#define PCI_DEVICE_ID_PERICOM_PI7C9X7952 0x7952 -#define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954 -#define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958 -#define PCI_VENDOR_ID_ACCESIO 0x494f#define PCI_DEVICE_ID_ACCESIO_PCIE_COM_2SDB 0x1051#define PCI_DEVICE_ID_ACCESIO_MPCIE_COM_2S 0x1053
include/linux/pci_ids.h +6 -0
@@ -1832,6 +1832,12 @@#define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2#define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018 +#define PCI_VENDOR_ID_PERICOM 0x12D8 +#define PCI_DEVICE_ID_PERICOM_PI7C9X7951 0x7951 +#define PCI_DEVICE_ID_PERICOM_PI7C9X7952 0x7952 +#define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954 +#define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958 +#define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0#define PCI_SUBDEVICE_ID_CHASE_PCIFAST4 0x0031#define PCI_SUBDEVICE_ID_CHASE_PCIFAST8 0x0021
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 289/376 x86/amd_nb: Add AMD family 17h model 60h PCI IDs
In reply to Greg Kroah-HartmanFrom: Alexander Monakov <[email protected]>
[ Upstream commit a4e91825d7e1252f7cba005f1451e5464b23c15d ]
Add PCI IDs for AMD Renoir (4000-series Ryzen CPUs). This is necessary to enable support for temperature sensors via the k10temp module.
--- arch/x86/kernel/amd_nb.c | 5 +++++ include/linux/pci_ids.h | 1 + 2 files changed, 6 insertions(+)
arch/x86/kernel/amd_nb.c +5 -0
@@ -18,9 +18,11 @@#define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450#define PCI_DEVICE_ID_AMD_17H_M10H_ROOT 0x15d0#define PCI_DEVICE_ID_AMD_17H_M30H_ROOT 0x1480 +#define PCI_DEVICE_ID_AMD_17H_M60H_ROOT 0x1630#define PCI_DEVICE_ID_AMD_17H_DF_F4 0x1464#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F4 0x15ec#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F4 0x1494 +#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F4 0x144c#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F4 0x1444#define PCI_DEVICE_ID_AMD_19H_DF_F4 0x1654
@@ -33,6 +35,7 @@ static const struct pci_device_id amd_root_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_ROOT) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_ROOT) }, {} };
@@ -50,6 +53,7 @@ static const struct pci_device_id amd_nb_misc_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F3) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F3) },
@@ -65,6 +69,7 @@ static const struct pci_device_id amd_nb_link_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
include/linux/pci_ids.h +1 -0
@@ -550,6 +550,7 @@#define PCI_DEVICE_ID_AMD_17H_DF_F3 0x1463#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F3 0x15eb#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F3 0x1493 +#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F3 0x144b#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F3 0x1443#define PCI_DEVICE_ID_AMD_19H_DF_F3 0x1653#define PCI_DEVICE_ID_AMD_CNB17H_F3 0x1703
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 290/376 ima: Remove redundant policy rule set in add_rules()
In reply to Greg Kroah-HartmanFrom: Krzysztof Struczynski <[email protected]>
[ Upstream commit 6ee28442a465ab4c4be45e3b15015af24b1ba906 ]
Function ima_appraise_flag() returns the flag to be set in temp_ima_appraise depending on the hook identifier passed as an argument. It is not necessary to set the flag again for the POLICY_CHECK hook.
--- security/integrity/ima/ima_policy.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
security/integrity/ima/ima_policy.c +1 -4
@@ -643,11 +643,8 @@ static void add_rules(struct ima_rule_entry *entries, int count,list_add_tail (&entry->list, &ima_policy_rules); } -if (entries[i].action ==APPRAISE ) { +if (entries[i].action ==APPRAISE ) temp_ima_appraise |=ima_appraise_flag (entries[i].func); -if (entries[i].func ==POLICY_CHECK ) - temp_ima_appraise |=IMA_APPRAISE_POLICY ; - } } }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 291/376 ima: Set again build_ima_appraise variable
In reply to Greg Kroah-HartmanFrom: Krzysztof Struczynski <[email protected]>
[ Upstream commit b59fda449cf07f2db3be3a67142e6c000f5e8d79 ]
After adding the new add_rule() function in commit c52657d93b05 ("ima: refactor ima_init_policy()"), all appraisal flags are added to the temp_ima_appraise variable. Revert to the previous behavior instead of removing build_ima_appraise, to benefit from the protection offered by __ro_after_init.
The mentioned commit introduced a bug, as it makes all the flags modifiable, while build_ima_appraise flags can be protected with __ro_after_init.
--- security/integrity/ima/ima_policy.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
security/integrity/ima/ima_policy.c +8 -2
@@ -643,8 +643,14 @@ static void add_rules(struct ima_rule_entry *entries, int count,list_add_tail (&entry->list, &ima_policy_rules); } -if (entries[i].action ==APPRAISE ) - temp_ima_appraise |=ima_appraise_flag (entries[i].func); +if (entries[i].action ==APPRAISE ) { +if (entries != build_appraise_rules) + temp_ima_appraise |= +ima_appraise_flag (entries[i].func); +else + build_ima_appraise |= +ima_appraise_flag (entries[i].func); + } } }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 292/376 PCI: Program MPS for RCiEP devices
In reply to Greg Kroah-HartmanFrom: Ashok Raj <[email protected]>
commit aa0ce96d72dd2e1b0dfd0fb868f82876e7790878 upstream.
Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge, so pci_configure_mps() previously ignored them, which may result in reduced performance.
Instead, program the Max_Payload_Size of RCiEPs to the maximum supported value (unless it is limited for the PCIE_BUS_PEER2PEER case). This also affects the subsequent programming of Max_Read_Request_Size because Linux programs MRRS based on the MPS value.
--- drivers/pci/probe.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
drivers/pci/probe.c +21 -1
@@ -1934,13 +1934,33 @@ static void pci_configure_mps(struct pcistruct pci_dev *bridge =pci_upstream_bridge (dev);int mps, mpss, p_mps, rc; -if (!pci_is_pcie (dev) || !bridge || !pci_is_pcie (bridge)) +if (!pci_is_pcie (dev))return ;/* MPS and MRRS fields are of type 'RsvdP' for VFs, short-circuit out */ if (dev->is_virtfn)return ; +/* +* For Root Complex Integrated Endpoints, program the maximum +* supported value unless limited by the PCIE_BUS_PEER2PEER case. +*/ +if (pci_pcie_type (dev) ==PCI_EXP_TYPE_RC_END ) { +if (pcie_bus_config ==PCIE_BUS_PEER2PEER ) + mps =128 ; +else + mps =128 << dev->pcie_mpss; + rc =pcie_set_mps (dev, mps); +if (rc) { +pci_warn (dev,"can't set Max Payload Size to %d; if necessary, use \"pci=pcie_bus_safe\" and report a bug\n" , + mps); + } +return ; + } + +if (!bridge || !pci_is_pcie (bridge)) +return ; + mps =pcie_get_mps (dev); p_mps =pcie_get_mps (bridge);
Greg Kroah-Hartman
maintainerPATCH 293/376 e1000e: Disable TSO for buffer overrun workaround
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit f29801030ac67bf98b7a65d3aea67b30769d4f7c upstream.
Commit b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") imposes roughly 30% performance penalty.
The commit log states that "Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance", so let's disable TSO by default to regain the loss.
--- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/intel/e1000e/netdev.c +4 -0
@@ -5294,6 +5294,10 @@ static void e1000_watchdog_task(struct w/* oops */ break ; } +if (hw->mac.type == e1000_pch_spt) { + netdev->features &= ~NETIF_F_TSO ; + netdev->features &= ~NETIF_F_TSO6 ; + } }/* enable transmits in the hardware, need to do this
Greg Kroah-Hartman
maintainerPATCH 294/376 e1000e: Relax condition to trigger reset for ME workaround
In reply to Greg Kroah-HartmanFrom: Punit Agrawal <[email protected]>
commit d601afcae2febc49665008e9a79e701248d56c50 upstream.
It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duration of the interference from ME. But the driver only performs the reset if E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have transpired. The extra condition can lead to inconsistency between the state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
While at it, also make __ew32_prepare() static as it's not used anywhere else.
--- drivers/net/ethernet/intel/e1000e/e1000.h | 1 - drivers/net/ethernet/intel/e1000e/netdev.c | 12 +++++------- 2 files changed, 5 insertions(+), 8 deletions(-)
drivers/net/ethernet/intel/e1000e/e1000.h +0 -1
@@ -576,7 +576,6 @@ static inline u32 __er32(struct e1000_hw#define er32 (reg) __er32(hw, E1000_##reg) -s32 __ew32_prepare (struct e1000_hw *hw);void __ew32 (struct e1000_hw *hw,unsigned long reg,u32 val);#define ew32 (reg, val) __ew32(hw, E1000_##reg, (val))
drivers/net/ethernet/intel/e1000e/netdev.c +5 -7
@@ -119,14 +119,12 @@ static const struct e1000_reg_info e1000* has bit 24 set while ME is accessing MAC CSR registers, wait if it is set * and try again a number of times. **/ -s32 __ew32_prepare (struct e1000_hw *hw) +static void __ew32_prepare (struct e1000_hw *hw) {s32 i =E1000_ICH_FWSM_PCIM2PCI_COUNT ;while ((er32 (FWSM ) &E1000_ICH_FWSM_PCIM2PCI ) && --i)udelay (50 ); - -return i; }void __ew32 (struct e1000_hw *hw,unsigned long reg,u32 val)
@@ -607,11 +605,11 @@ static void e1000e_update_rdt_wa(struct {struct e1000_adapter *adapter = rx_ring->adapter;struct e1000_hw *hw = &adapter->hw; -s32 ret_val =__ew32_prepare (hw); +__ew32_prepare (hw);writel (i, rx_ring->tail); -if (unlikely (!ret_val && (i !=readl (rx_ring->tail)))) { +if (unlikely (i !=readl (rx_ring->tail))) {u32 rctl =er32 (RCTL );ew32 (RCTL , rctl & ~E1000_RCTL_EN );
@@ -624,11 +622,11 @@ static void e1000e_update_tdt_wa(struct {struct e1000_adapter *adapter = tx_ring->adapter;struct e1000_hw *hw = &adapter->hw; -s32 ret_val =__ew32_prepare (hw); +__ew32_prepare (hw);writel (i, tx_ring->tail); -if (unlikely (!ret_val && (i !=readl (tx_ring->tail)))) { +if (unlikely (i !=readl (tx_ring->tail))) {u32 tctl =er32 (TCTL );ew32 (TCTL , tctl & ~E1000_TCTL_EN );
Greg Kroah-Hartman
maintainerPATCH 295/376 irqchip/sifive-plic: Set default irq affinity in plic_irqdomain_map()
In reply to Greg Kroah-HartmanFrom: Anup Patel <[email protected]>
commit 2458ed31e9b9ab40d78a452ab2650a0857556e85 upstream.
For multiple PLIC instances, each PLIC can only target a subset of CPUs which is represented by "lmask" in the "struct plic_priv".
Currently, the default irq affinity for each PLIC interrupt is all online CPUs which is illegal value for default irq affinity when we have multiple PLIC instances. To fix this, we now set "lmask" as the default irq affinity in for each interrupt in plic_irqdomain_map().
--- drivers/irqchip/irq-sifive-plic.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/irqchip/irq-sifive-plic.c +3 -0
@@ -176,9 +176,12 @@ static struct irq_chip plic_chip = {static int plic_irqdomain_map (struct irq_domain *d,unsigned int irq,irq_hw_number_t hwirq) { +struct plic_priv *priv = d->host_data; +irq_domain_set_info (d, irq, hwirq, &plic_chip, d->host_data, handle_fasteoi_irq,NULL ,NULL );irq_set_noprobe (irq); +irq_set_affinity (irq, &priv->lmask);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 296/376 irqchip/sifive-plic: Setup cpuhp once after boot CPU handler is present
In reply to Greg Kroah-HartmanFrom: Anup Patel <[email protected]>
commit 2234ae846ccb9ebdf4c391824cb79e73674dceda upstream.
For multiple PLIC instances, the plic_init() is called once for each PLIC instance. Due to this we have two issues:
1. cpuhp_setup_state() is called multiple times
2. plic_starting_cpu() can crash for boot CPU if cpuhp_setup_state() is called before boot CPU PLIC handler is available.
Address both issues by only initializing the HP notifiers when the boot CPU setup is complete.
--- drivers/irqchip/irq-sifive-plic.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/irqchip/irq-sifive-plic.c +12 -2
@@ -76,6 +76,7 @@ struct plic_handler {void __iomem *enable_base;struct plic_priv *priv; }; +static bool plic_cpuhp_setup_done; static DEFINE_PER_CPU(struct plic_handler, plic_handlers); static inline void plic_toggle(struct plic_handler *handler,
@@ -285,6 +286,7 @@ static int __init plic_init(struct devicint error =0 , nr_contexts, nr_handlers =0 , i;u32 nr_irqs;struct plic_priv *priv; +struct plic_handler *handler; priv =kzalloc (sizeof (*priv),GFP_KERNEL );if (!priv)
@@ -315,7 +317,6 @@ static int __init plic_init(struct devicfor (i =0 ; i < nr_contexts; i++) {struct of_phandle_args parent; -struct plic_handler *handler;irq_hw_number_t hwirq;int cpu, hartid;
@@ -369,9 +370,18 @@ done: nr_handlers++; } -cpuhp_setup_state (CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING , +/* +* We can have multiple PLIC instances so setup cpuhp state only +* when context handler for current/boot CPU is present. +*/ + handler =this_cpu_ptr (&plic_handlers); +if (handler->present && !plic_cpuhp_setup_done) { +cpuhp_setup_state (CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING ,"irqchip/sifive/plic:starting" , plic_starting_cpu, plic_dying_cpu); + plic_cpuhp_setup_done = true; + } +pr_info ("mapped %d interrupts with %d handlers for %d contexts.\n" , nr_irqs, nr_handlers, nr_contexts);set_handle_irq (plic_handle_irq);
Greg Kroah-Hartman
maintainerPATCH 297/376 carl9170: remove P2P_GO support
In reply to Greg Kroah-HartmanFrom: Christian Lamparter <[email protected]>
commit b14fba7ebd04082f7767a11daea7f12f3593de22 upstream.
This patch follows up on a bug-report by Frank Schäfer that discovered P2P GO wasn't working with wpa_supplicant. This patch removes part of the broken P2P GO support but keeps the vif switchover code in place.
--- drivers/net/wireless/ath/carl9170/fw.c | 4 +--- drivers/net/wireless/ath/carl9170/main.c | 21 ++++----------------- 2 files changed, 5 insertions(+), 20 deletions(-)
drivers/net/wireless/ath/carl9170/fw.c +1 -3
@@ -338,9 +338,7 @@ static int carl9170_fw(struct ar9170 *ar ar->hw->wiphy->interface_modes |=BIT (NL80211_IFTYPE_ADHOC );if (SUPP (CARL9170FW_WLANTX_CAB )) { - if_comb_types |= -BIT (NL80211_IFTYPE_AP ) | -BIT (NL80211_IFTYPE_P2P_GO ); + if_comb_types |=BIT (NL80211_IFTYPE_AP );#ifdef CONFIG_MAC80211_MESH if_comb_types |=
drivers/net/wireless/ath/carl9170/main.c +4 -17
@@ -582,11 +582,10 @@ static int carl9170_init_interface(struc ar->disable_offload |= ((vif->type !=NL80211_IFTYPE_STATION ) && (vif->type !=NL80211_IFTYPE_AP )); -/* While the driver supports HW offload in a single -* P2P client configuration, it doesn't support HW -* offload in the favourit, concurrent P2P GO+CLIENT -* configuration. Hence, HW offload will always be -* disabled for P2P. +/* The driver used to have P2P GO+CLIENT support, +* but since this was dropped and we don't know if +* there are any gremlins lurking in the shadows, +* so best we keep HW offload disabled for P2P. */ ar->disable_offload |= vif->p2p;
@@ -639,18 +638,6 @@ static int carl9170_op_add_interface(strif (vif->type ==NL80211_IFTYPE_STATION )break ; -/* P2P GO [master] use-case -* Because the P2P GO station is selected dynamically -* by all participating peers of a WIFI Direct network, -* the driver has be able to change the main interface -* operating mode on the fly. -*/ -if (main_vif->p2p && vif->p2p && - vif->type ==NL80211_IFTYPE_AP ) { - old_main = main_vif; -break ; - } - err = -EBUSY ;rcu_read_unlock ();
Greg Kroah-Hartman
maintainerPATCH 298/376 clocksource: Remove obsolete ifdef
In reply to Greg Kroah-HartmanFrom: Thomas Gleixner <[email protected]>
commit c7f3d43b629b598a2bb9ec3524e844eae7492e7e upstream.
CONFIG_GENERIC_VDSO_CLOCK_MODE was a transitional config switch which got removed after all architectures got converted to the new storage model.
But the removal forgot to remove the #ifdef which guards the vdso_clock_mode sanity check, which effectively disables the sanity check.
Remove it now.
--- kernel/time/clocksource.c | 2 -- 1 file changed, 2 deletions(-)
kernel/time/clocksource.c +0 -2
@@ -928,14 +928,12 @@ int __clocksource_register_scale(structclocksource_arch_init (cs); -#ifdef CONFIG_GENERIC_VDSO_CLOCK_MODE if (cs->vdso_clock_mode <0 || cs->vdso_clock_mode >=VDSO_CLOCKMODE_MAX ) {pr_warn ("clocksource %s registered with invalid VDSO mode %d. Disabling VDSO support.\n" , cs->name, cs->vdso_clock_mode); cs->vdso_clock_mode =VDSO_CLOCKMODE_NONE ; } -#endif /* Initialize mult/shift and max_idle_ns */ __clocksource_update_freq_scale (cs, scale, freq);
Greg Kroah-Hartman
maintainerPATCH 299/376 clocksource/drivers/timer-microchip-pit64b: Select CONFIG_TIMER_OF
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 25259f7a5de2de9d67793dc584b15c83a3134c93 upstream.
This driver is an OF driver, it depends on OF, and uses TIMER_OF_DECLARE, so it should select CONFIG_TIMER_OF.
Without CONFIG_TIMER_OF enabled this can lead to warnings such as:
powerpc-linux-ld: warning: orphan section __timer_of_table' from drivers/clocksource/timer-microchip-pit64b.o' being placed in section `__timer_of_table'.
Because TIMER_OF_TABLES in vmlinux.lds.h doesn't emit anything into the linker script when CONFIG_TIMER_OF is not enabled.
--- drivers/clocksource/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/clocksource/Kconfig +1 -0
@@ -709,6 +709,7 @@ config MICROCHIP_PIT64B bool "Microchip PIT64B support" depends on OF || COMPILE_TEST select CLKSRC_MMIO + select TIMER_OF help This option enables Microchip PIT64B timer for Atmel based system. It supports the oneshot, the periodic
Greg Kroah-Hartman
maintainerPATCH 300/376 media: cedrus: Program output format during each run
In reply to Greg Kroah-HartmanFrom: Samuel Holland <[email protected]>
commit a8876c22eab9a871834f85de83e98bbf7e6e264d upstream.
Previously, the output format was programmed as part of the ioctl() handler. However, this has two problems:
1) If there are multiple active streams with different output formats, the hardware will use whichever format was set last for both streams. Similarly, an ioctl() done in an inactive context will wrongly affect other active contexts.
2) The registers are written while the device is not actively streaming. To enable runtime PM tied to the streaming state, all hardware access needs to be moved inside cedrus_device_run().
The call to cedrus_dst_format_set() is now placed just before the codec-specific callback that programs the hardware.
--- drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ drivers/staging/media/sunxi/cedrus/cedrus_video.c | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-)
drivers/staging/media/sunxi/cedrus/cedrus_dec.c +2 -0
@@ -74,6 +74,8 @@ void cedrus_device_run(void *priv)v4l2_m2m_buf_copy_metadata (run.src, run.dst, true); +cedrus_dst_format_set (dev, &ctx->dst_fmt); + dev->dec_ops[ctx->current_codec]->setup (ctx, &run);/* Complete request(s) controls if needed. */
drivers/staging/media/sunxi/cedrus/cedrus_video.c +0 -3
@@ -273,7 +273,6 @@ static int cedrus_s_fmt_vid_cap(struct f struct v4l2_format *f) {struct cedrus_ctx *ctx =cedrus_file2ctx (file); -struct cedrus_dev *dev = ctx->dev;struct vb2_queue *vq;int ret;
@@ -287,8 +286,6 @@ static int cedrus_s_fmt_vid_cap(struct f ctx->dst_fmt = f->fmt.pix; -cedrus_dst_format_set (dev, &ctx->dst_fmt); -return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 301/376 serial: 8250: Avoid error message on reprobe
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit e0a851fe6b9b619527bd928aa93caaddd003f70c upstream.
If the call to uart_add_one_port() in serial8250_register_8250_port() fails, a half-initialized entry in the serial_8250ports[] array is left behind.
A subsequent reprobe of the same serial port causes that entry to be reused. Because uart->port.dev is set, uart_remove_one_port() is called for the half-initialized entry and bails out with an error message:
bcm2835-aux-uart 3f215040.serial: Removing wrong port: (null) != (ptrval)
The same happens on failure of mctrl_gpio_init() since commit 4a96895f74c9 ("tty/serial/8250: use mctrl_gpio helpers").
Fix by zeroing the uart->port.dev pointer in the probe error path.
The bug was introduced in v2.6.10 by historical commit befff6f5bf5f ("[SERIAL] Add new port registration/unregistration functions."):
https://git.kernel.org/tglx/history/c/befff6f5bf5f
The commit added an unconditional call to uart_remove_one_port() in serial8250_register_port(). In v3.7, commit 835d844d1a28 ("8250_pnp:
do pnp probe before legacy probe") made that call conditional on uart->port.dev which allows me to fix the issue by zeroing that pointer in the error path. Thus, the present commit will fix the problem as far back as v3.7 whereas still older versions need to also cherry-pick 835d844d1a28.
--- drivers/tty/serial/8250/8250_core.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
drivers/tty/serial/8250/8250_core.c +10 -4
@@ -1040,7 +1040,7 @@ int serial8250_register_8250_port(struct gpios =mctrl_gpio_init (&uart->port,0 );if (IS_ERR (gpios)) { ret =PTR_ERR (gpios); - goto out_unlock; + goto err; }else { uart->gpios = gpios; }
@@ -1089,8 +1089,10 @@ int serial8250_register_8250_port(structserial8250_apply_quirks (uart); ret =uart_add_one_port (&serial8250_reg, &uart->port); -if (ret ==0 ) - ret = uart->port.line; +if (ret) + goto err; + + ret = uart->port.line; }else { dev_info(uart->port.dev, "skipping CIR port at 0x%lx / 0x%llx, IRQ %d\n",
@@ -1112,10 +1114,14 @@ int serial8250_register_8250_port(struct } } -out_unlock:mutex_unlock (&serial_mutex);return ret; + +err: + uart->port.dev =NULL ; +mutex_unlock (&serial_mutex); +return ret; }EXPORT_SYMBOL (serial8250_register_8250_port);
Greg Kroah-Hartman
maintainerPATCH 302/376 Bluetooth: hci_bcm: respect IRQ polarity from DT
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit b25e4df4a83e516efbdeeefb5b2d3e259639a56e upstream.
The IRQ polarity is be configured in bcm_setup_sleep(). Make the configured value match what is in the DeviceTree.
--- drivers/bluetooth/hci_bcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/bluetooth/hci_bcm.c +2 -1
@@ -1153,7 +1153,8 @@ static int bcm_of_probe(struct bcm_devicdevice_property_read_u8_array (bdev->dev,"brcm,bt-pcm-int-params" , bdev->pcm_int_params,5 ); bdev->irq =of_irq_get_byname (bdev->dev->of_node,"host-wakeup" ); - + bdev->irq_active_low =irq_get_trigger_type (bdev->irq) + & (IRQ_TYPE_EDGE_FALLING |IRQ_TYPE_LEVEL_LOW );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 303/376 Bluetooth: hci_bcm: fix freeing not-requested IRQ
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit 81bd5d0c62437c02caac6b3f942fcda874063cb0 upstream.
When BT module can't be initialized, but it has an IRQ, unloading the driver WARNs when trying to free not-yet-requested IRQ. Fix it by noting whether the IRQ was requested.
WARNING: CPU: 2 PID: 214 at kernel/irq/devres.c:144 devm_free_irq+0x49/0x4ca [...] WARNING: CPU: 2 PID: 214 at kernel/irq/manage.c:1746 __free_irq+0x8b/0x27c Trying to free already-free IRQ 264 Modules linked in: hci_uart(-) btbcm bluetooth ecdh_generic ecc libaes CPU: 2 PID: 214 Comm: rmmod Tainted: G W 5.6.1mq-00044-ga5f9ea098318-dirty #928
[...]
[<b016aefb>] (devm_free_irq) from [<af8ba1ff>] (bcm_close+0x97/0x118 [hci_uart]) [<af8ba1ff>] (bcm_close [hci_uart]) from [<af8b736f>] (hci_uart_unregister_device+0x33/0x3c [hci_uart]) [<af8b736f>] (hci_uart_unregister_device [hci_uart]) from [<b035930b>] (serdev_drv_remove+0x13/0x20) [<b035930b>] (serdev_drv_remove) from [<b037093b>] (device_release_driver_internal+0x97/0x118) [<b037093b>] (device_release_driver_internal) from [<b0370a0b>] (driver_detach+0x2f/0x58) [<b0370a0b>] (driver_detach) from [<b036f855>] (bus_remove_driver+0x41/0x94) [<b036f855>] (bus_remove_driver) from [<af8ba8db>] (bcm_deinit+0x1b/0x740 [hci_uart]) [<af8ba8db>] (bcm_deinit [hci_uart]) from [<af8ba86f>] (hci_uart_exit+0x13/0x30 [hci_uart]) [<af8ba86f>] (hci_uart_exit [hci_uart]) from [<b01900bd>] (sys_delete_module+0x109/0x1d0) [<b01900bd>] (sys_delete_module) from [<b0101001>] (ret_fast_syscall+0x1/0x5a)
[...]
--- drivers/bluetooth/hci_bcm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/bluetooth/hci_bcm.c +4 -1
@@ -118,6 +118,7 @@ struct bcm_device {u32 oper_speed;int irq;bool irq_active_low; +bool irq_acquired;#ifdef CONFIG_PM struct hci_uart *hu;
@@ -333,6 +334,8 @@ static int bcm_request_irq(struct bcm_da goto unlock; } + bdev->irq_acquired = true; +device_init_wakeup (bdev->dev, true); pm_runtime_set_autosuspend_delay(bdev->dev,
@@ -514,7 +517,7 @@ static int bcm_close(struct hci_uart *hu }if (bdev) { -if (IS_ENABLED (CONFIG_PM ) && bdev->irq >0 ) { +if (IS_ENABLED (CONFIG_PM ) && bdev->irq_acquired) {devm_free_irq (bdev->dev, bdev->irq, bdev);device_init_wakeup (bdev->dev, false);pm_runtime_disable (bdev->dev);
Greg Kroah-Hartman
maintainerPATCH 304/376 b43legacy: Fix case where channel status is corrupted
In reply to Greg Kroah-HartmanFrom: Larry Finger <[email protected]>
commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream.
This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices")
In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in b43legacy is reported. Upon testing, thus problem exists on PPC and X86 platforms, is present in the oldest kernel tested (3.2), and has been present in the driver since it was first added to the kernel.
The problem is a corrupted channel status received from the device. Both the internal card in a PowerBook G4 and the PCMCIA version (Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2 (revision 4 of the 802.11 core) of the chip has been tested. No other devices using b43legacy are available for testing.
Various sources of the problem were considered. Buffer overrun and other sources of corruption within the driver were rejected because the faulty channel status is always the same, not a random value. It was concluded that the faulty data is coming from the device, probably due to a firmware bug. As that source is not available, the driver must take appropriate action to recover.
At present, the driver reports the error, and them continues to process the bad packet. This is believed that to be a mistake, and the correct action is to drop the correpted packet.
Reported-and-tested by: F. Erhard <[email protected]>
--- drivers/net/wireless/broadcom/b43legacy/xmit.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/broadcom/b43legacy/xmit.c +1 -0
@@ -558,6 +558,7 @@ void b43legacy_rx(struct b43legacy_wldevdefault :b43legacywarn (dev->wl,"Unexpected value for chanstat (0x%X)\n" , chanstat); + goto drop; }memcpy (IEEE80211_SKB_RXCB (skb), &status,sizeof (status));
Greg Kroah-Hartman
maintainerPATCH 305/376 b43: Fix connection problem with WPA3
In reply to Greg Kroah-HartmanFrom: Larry Finger <[email protected]>
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43 did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed.
With this change, b43 will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers.
--- drivers/net/wireless/broadcom/b43/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/broadcom/b43/main.c +1 -1
@@ -5569,7 +5569,7 @@ static struct b43_wl *b43_wireless_init(/* fill hw info */ ieee80211_hw_set (hw,RX_INCLUDES_FCS );ieee80211_hw_set (hw,SIGNAL_DBM ); - +ieee80211_hw_set (hw,MFP_CAPABLE ); hw->wiphy->interface_modes =BIT (NL80211_IFTYPE_AP ) | BIT(NL80211_IFTYPE_MESH_POINT) |
Greg Kroah-Hartman
maintainerPATCH 306/376 b43_legacy: Fix connection problem with WPA3
In reply to Greg Kroah-HartmanFrom: Larry Finger <[email protected]>
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43legacy did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed.
With this change, b43legacy will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers.
--- drivers/net/wireless/broadcom/b43legacy/main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/broadcom/b43legacy/main.c +1 -0
@@ -3801,6 +3801,7 @@ static int b43legacy_wireless_init(struc/* fill hw info */ ieee80211_hw_set (hw,RX_INCLUDES_FCS );ieee80211_hw_set (hw,SIGNAL_DBM ); +ieee80211_hw_set (hw,MFP_CAPABLE );/* Allow WPA3 in software */ hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_AP) |
Greg Kroah-Hartman
maintainerPATCH 307/376 media: ov5640: fix use of destroyed mutex
In reply to Greg Kroah-HartmanFrom: Tomi Valkeinen <[email protected]>
commit bfcba38d95a0aed146a958a84a2177af1459eddc upstream.
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting in the use of the destroyed mutex.
Fix this by calling moving the mutex_destroy() to the end of the cleanup sequence, as there's no need to destroy the mutex as early as possible.
--- drivers/media/i2c/ov5640.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/i2c/ov5640.c +2 -2
@@ -3093,8 +3093,8 @@ static int ov5640_probe(struct i2c_clien free_ctrls:v4l2_ctrl_handler_free (&sensor->ctrls.handler); entity_cleanup: -mutex_destroy (&sensor->lock);media_entity_cleanup (&sensor->sd.entity); +mutex_destroy (&sensor->lock);return ret; }
@@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_cliestruct ov5640_dev *sensor =to_ov5640_dev (sd);v4l2_async_unregister_subdev (&sensor->sd); -mutex_destroy (&sensor->lock);media_entity_cleanup (&sensor->sd.entity);v4l2_ctrl_handler_free (&sensor->ctrls.handler); +mutex_destroy (&sensor->lock);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 308/376 usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle
In reply to Greg Kroah-HartmanFrom: Macpaul Lin <[email protected]>
commit 402bcac4b25b520c89ba60db85eb6316f36e797f upstream.
When receiving reset interrupt, FADDR need to be reset to zero in peripheral mode. Otherwise ep0 cannot do enumeration when re-plugging USB cable.
--- drivers/usb/musb/mediatek.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/musb/mediatek.c +6 -0
@@ -208,6 +208,12 @@ static irqreturn_t generic_interrupt(int musb->int_rx =musb_clearw (musb->mregs,MUSB_INTRRX ); musb->int_tx =musb_clearw (musb->mregs,MUSB_INTRTX ); +if ((musb->int_usb &MUSB_INTR_RESET ) && !is_host_active (musb)) { +/* ep0 FADDR must be 0 when (re)entering peripheral mode */ +musb_ep_select (musb->mregs,0 ); +musb_writeb (musb->mregs,MUSB_FADDR ,0 ); + } +if (musb->int_usb || musb->int_tx || musb->int_rx) retval =musb_interrupt (musb);
Greg Kroah-Hartman
maintainerPATCH 309/376 clk: mediatek: assign the initial value to clk_init_data of mtk_mux
In reply to Greg Kroah-HartmanFrom: Weiyi Lu <[email protected]>
commit 571cfadcc628dd5591444f7289e27445ea732f4c upstream.
When some new clock supports are introduced, e.g. [1] it might lead to an error although it should be NULL because clk_init_data is on the stack and it might have random values if using without initialization.
Add the missing initial value to clk_init_data.
[1] https://android-review.googlesource.com/c/kernel/common/+/1278046
--- drivers/clk/mediatek/clk-mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/mediatek/clk-mux.c +1 -1
@@ -160,7 +160,7 @@ struct clk *mtk_clk_register_mux(const s spinlock_t *lock) {struct mtk_clk_mux *clk_mux; -struct clk_init_data init; +struct clk_init_data init = {};struct clk *clk; clk_mux =kzalloc (sizeof (*clk_mux),GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 310/376 igb: Report speed and duplex as unknown when device is runtime suspended
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit 165ae7a8feb53dc47fb041357e4b253bfc927cf9 upstream.
igb device gets runtime suspended when there's no link partner. We can't get correct speed under that state:
$ cat /sys/class/net/enp3s0/speed 1000
In addition to that, an error can also be spotted in dmesg:
[ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost
Since device can only be runtime suspended when there's no link partner, we can skip reading register and let the following logic set speed and duplex with correct status.
The more generic approach will be wrap get_link_ksettings() with begin() and complete() callbacks. However, for this particular issue, begin() calls igb_runtime_resume() , which tries to rtnl_lock() while the lock is already hold by upper ethtool layer.
So let's take this approach until the igb_runtime_resume() no longer needs to hold rtnl_lock.
--- drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/igb/igb_ethtool.c +2 -1
@@ -143,7 +143,8 @@ static int igb_get_link_ksettings(structu32 speed;u32 supported, advertising; - status =rd32 (E1000_STATUS ); + status =pm_runtime_suspended (&adapter->pdev->dev) ? +0 :rd32 (E1000_STATUS );if (hw->phy.media_type == e1000_media_type_copper) { supported = (SUPPORTED_10baseT_Half |
Greg Kroah-Hartman
maintainerPATCH 311/376 hwmon: (k10temp) Add AMD family 17h model 60h PCI match
In reply to Greg Kroah-HartmanFrom: Alexander Monakov <[email protected]>
commit 279f0b3a4b80660fba6faadc2ca2fa426bf3f7e9 upstream.
Add support for retrieving Tdie and Tctl on AMD Renoir (4000-series Ryzen CPUs).
It appears SMU offsets for reading current/voltage and CCD temperature have changed for this generation (reads from currently used offsets yield zeros), so those features cannot be enabled so trivially.
--- drivers/hwmon/k10temp.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/k10temp.c +1 -0
@@ -632,6 +632,7 @@ static const struct pci_device_id k10tem { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F3) }, + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F3) }, { PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) }, {}
Greg Kroah-Hartman
maintainerPATCH 312/376 EDAC/amd64: Add AMD family 17h model 60h PCI IDs
In reply to Greg Kroah-HartmanFrom: Alexander Monakov <[email protected]>
commit b6bea24d41519e8c31e4798f1c1a3f67e540c5d0 upstream.
Add support for AMD Renoir (4000-series Ryzen CPUs).
--- drivers/edac/amd64_edac.c | 14 ++++++++++++++ drivers/edac/amd64_edac.h | 3 +++ 2 files changed, 17 insertions(+)
drivers/edac/amd64_edac.c +14 -0
@@ -2319,6 +2319,16 @@ static struct amd64_family_type family_t .dbam_to_cs = f17_addr_mask_to_cs_size, } }, + [F17_M60H_CPUS] = { + .ctl_name = "F17h_M60h", + .f0_id = PCI_DEVICE_ID_AMD_17H_M60H_DF_F0, + .f6_id = PCI_DEVICE_ID_AMD_17H_M60H_DF_F6, + .max_mcs = 2, + .ops = { + .early_channel_count = f17_early_channel_count, + .dbam_to_cs = f17_addr_mask_to_cs_size, + } + }, [F17_M70H_CPUS] = { .ctl_name = "F17h_M70h", .f0_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F0,
@@ -3357,6 +3367,10 @@ static struct amd64_family_type *per_fam fam_type = &family_types[F17_M30H_CPUS ]; pvt->ops = &family_types[F17_M30H_CPUS ].ops;break ; + }else if (pvt->model >=0x60 && pvt->model <=0x6f ) { + fam_type = &family_types[F17_M60H_CPUS ]; + pvt->ops = &family_types[F17_M60H_CPUS ].ops; +break ; }else if (pvt->model >=0x70 && pvt->model <=0x7f ) { fam_type = &family_types[F17_M70H_CPUS ]; pvt->ops = &family_types[F17_M70H_CPUS ].ops;
drivers/edac/amd64_edac.h +3 -0
@@ -120,6 +120,8 @@#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F6 0x15ee#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F0 0x1490#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F6 0x1496 +#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F0 0x1448 +#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F6 0x144e#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F0 0x1440#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F6 0x1446#define PCI_DEVICE_ID_AMD_19H_DF_F0 0x1650
@@ -293,6 +295,7 @@ enum amd_families {F17_CPUS ,F17_M10H_CPUS ,F17_M30H_CPUS , +F17_M60H_CPUS ,F17_M70H_CPUS ,F19_CPUS , NUM_FAMILIES,
Greg Kroah-Hartman
maintainerPATCH 313/376 iommu/vt-d: Only clear real DMA devices context entries
In reply to Greg Kroah-HartmanFrom: Jon Derrick <[email protected]>
commit 8038bdb8553313ad53bfcffcf8294dd0ab44618f upstream.
Domain context mapping can encounter issues with sub-devices of a real DMA device. A sub-device cannot have a valid context entry due to it potentially aliasing another device's 16-bit ID. It's expected that sub-devices of the real DMA device uses the real DMA device's requester when context mapping.
This is an issue when a sub-device is removed where the context entry is cleared for all aliases. Other sub-devices are still valid, resulting in those sub-devices being stranded without valid context entries.
The correct approach is to use the real DMA device when programming the context entries. The insertion path is correct because device_to_iommu() will return the bus and devfn of the real DMA device. The removal path needs to only operate on the real DMA device, otherwise the entire context entry would be cleared for all sub-devices of the real DMA device.
This patch also adds a helper to determine if a struct device is a sub-device of a real DMA device.
--- drivers/iommu/intel-iommu.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/iommu/intel-iommu.c +8 -1
@@ -2582,6 +2582,12 @@ static int domain_setup_first_level(stru flags); } +static bool dev_is_real_dma_subdevice (struct device *dev) +{ +return dev &&dev_is_pci (dev) && +pci_real_dma_dev (to_pci_dev (dev)) !=to_pci_dev (dev); +} + static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, int bus, int devfn, struct device *dev,
@@ -5286,7 +5292,8 @@ static void __dmar_remove_one_dev_info(s PASID_RID2PASID);iommu_disable_dev_iotlb (info); -domain_context_clear (iommu, info->dev); +if (!dev_is_real_dma_subdevice (info->dev)) +domain_context_clear (iommu, info->dev);intel_pasid_free_table (info->dev); }
Greg Kroah-Hartman
maintainerPATCH 314/376 iommu/vt-d: Allocate domain info for real DMA sub-devices
In reply to Greg Kroah-HartmanFrom: Jon Derrick <[email protected]>
commit 4fda230ecddc2573ed88632e98b69b0b9b68c0ad upstream.
Sub-devices of a real DMA device might exist on a separate segment than the real DMA device and its IOMMU. These devices should still have a valid device_domain_info, but the current dma alias model won't allocate info for the subdevice.
This patch adds a segment member to struct device_domain_info and uses the sub-device's BDF so that these sub-devices won't alias to other devices.
--- drivers/iommu/intel-iommu.c | 19 +++++++++++++++---- include/linux/intel-iommu.h | 1 + 2 files changed, 16 insertions(+), 4 deletions(-)
drivers/iommu/intel-iommu.c +15 -4
@@ -2545,7 +2545,7 @@ dmar_search_domain_by_dev_info(int segmestruct device_domain_info *info;list_for_each_entry (info, &device_domain_list, global) -if (info->iommu->segment == segment && info->bus == bus && +if (info->segment == segment && info->bus == bus && info->devfn == devfn)return info;
@@ -2602,8 +2602,18 @@ static struct dmar_domain *dmar_insert_oif (!info)return NULL ; - info->bus = bus; - info->devfn = devfn; +if (!dev_is_real_dma_subdevice (dev)) { + info->bus = bus; + info->devfn = devfn; + info->segment = iommu->segment; + }else { +struct pci_dev *pdev =to_pci_dev (dev); + + info->bus = pdev->bus->number; + info->devfn = pdev->devfn; + info->segment =pci_domain_nr (pdev->bus); + } + info->ats_supported = info->pasid_supported = info->pri_supported =0 ; info->ats_enabled = info->pasid_enabled = info->pri_enabled =0 ; info->ats_qdep =0 ;
@@ -2643,7 +2653,8 @@ static struct dmar_domain *dmar_insert_oif (!found) {struct device_domain_info *info2; - info2 =dmar_search_domain_by_dev_info (iommu->segment, bus, devfn); + info2 =dmar_search_domain_by_dev_info (info->segment, info->bus, + info->devfn);if (info2) { found = info2->domain; info2->dev = dev;
include/linux/intel-iommu.h +1 -0
@@ -571,6 +571,7 @@ struct device_domain_info {struct list_head auxiliary_domains;/* auxiliary domains * attached to this device */ +u32 segment;/* PCI segment number */ u8 bus;/* PCI bus number */ u8 devfn;/* PCI devfn number */ u16 pfsid;/* SRIOV physical function source ID */
Greg Kroah-Hartman
maintainerPATCH 315/376 power: vexpress: add suppress_bind_attrs to true
In reply to Greg Kroah-HartmanFrom: Anders Roxell <[email protected]>
commit 73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream.
Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind attributes available via the sysfs, so lets be explicit here and use ".suppress_bind_attrs = true" to prevent userspace from doing something silly.
--- drivers/power/reset/vexpress-poweroff.c | 1 + 1 file changed, 1 insertion(+)
drivers/power/reset/vexpress-poweroff.c +1 -0
@@ -143,6 +143,7 @@ static struct platform_driver vexpress_r .driver = { .name = "vexpress-reset", .of_match_table = vexpress_reset_of_match, + .suppress_bind_attrs = true, }, };
Greg Kroah-Hartman
maintainerPATCH 316/376 power: supply: core: fix HWMON temperature labels
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit 6b20464ad9fb5fd76ef6f219ce62156aa9639dcc upstream.
tempX_label files are swapped compared to what power_supply_hwmon_temp_to_property() uses. Make them match.
--- drivers/power/supply/power_supply_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/supply/power_supply_hwmon.c +1 -1
@@ -144,7 +144,7 @@ static int power_supply_hwmon_read_strin u32 attr, int channel, const char **str) { - *str = channel ?"temp" :"temp ambient" ; + *str = channel ?"temp ambient" :"temp" ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 317/376 power: supply: core: fix memory leak in HWMON error path
In reply to Greg Kroah-HartmanFrom: Qiushi Wu <[email protected]>
commit 1d7a7128a2e9e1f137c99b0a44e94d70a77343e3 upstream.
In function power_supply_add_hwmon_sysfs(), psyhw->props is allocated by bitmap_zalloc(). But this pointer is not deallocated when devm_add_action fail, which lead to a memory leak bug. To fix this, we replace devm_add_action with devm_add_action_or_reset.
--- drivers/power/supply/power_supply_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/supply/power_supply_hwmon.c +1 -1
@@ -304,7 +304,7 @@ int power_supply_add_hwmon_sysfs(struct goto error; } - ret =devm_add_action (dev, power_supply_hwmon_bitmap_free, + ret =devm_add_action_or_reset (dev, power_supply_hwmon_bitmap_free, psyhw->props);if (ret) goto error;
Greg Kroah-Hartman
maintainerPATCH 318/376 pinctrl: samsung: Correct setting of eint wakeup mask on s5pv210
In reply to Greg Kroah-HartmanFrom: Jonathan Bakker <[email protected]>
commit b577a279914085c6b657c33e9f39ef56d96a3302 upstream.
Commit a8be2af0218c ("pinctrl: samsung: Write external wakeup interrupt mask") started writing the eint wakeup mask from the pinctrl driver. Unfortunately, it made the assumption that the private retention data was always a regmap while in the case of s5pv210 it is a raw pointer to the clock base (as the eint wakeup mask not in the PMU as with newer Exynos platforms).
--- drivers/pinctrl/samsung/pinctrl-exynos.c | 73 ++++++++++++++++++++----------- 1 file changed, 49 insertions(+), 24 deletions(-)
drivers/pinctrl/samsung/pinctrl-exynos.c +49 -24
@@ -40,6 +40,8 @@ struct exynos_irq_chip {u32 eint_pend;u32 eint_wake_mask_value;u32 eint_wake_mask_reg; +void (*set_eint_wakeup_mask)(struct samsung_pinctrl_drv_data *drvdata, +struct exynos_irq_chip *irq_chip); };static inline struct exynos_irq_chip *to_exynos_irq_chip (struct irq_chip *chip)
@@ -342,6 +344,47 @@ static int exynos_wkup_irq_set_wake(strureturn 0 ; } +static void +exynos_pinctrl_set_eint_wakeup_mask (struct samsung_pinctrl_drv_data *drvdata, +struct exynos_irq_chip *irq_chip) +{ +struct regmap *pmu_regs; + +if (!drvdata->retention_ctrl || !drvdata->retention_ctrl->priv) { +dev_warn (drvdata->dev, +"No retention data configured bank with external wakeup interrupt. Wake-up mask will not be set.\n" ); +return ; + } + + pmu_regs = drvdata->retention_ctrl->priv; +dev_info (drvdata->dev, +"Setting external wakeup interrupt mask: 0x%x\n" , + irq_chip->eint_wake_mask_value); + +regmap_write (pmu_regs, irq_chip->eint_wake_mask_reg, + irq_chip->eint_wake_mask_value); +} + +static void +s5pv210_pinctrl_set_eint_wakeup_mask (struct samsung_pinctrl_drv_data *drvdata, +struct exynos_irq_chip *irq_chip) + +{ +void __iomem *clk_base; + +if (!drvdata->retention_ctrl || !drvdata->retention_ctrl->priv) { +dev_warn (drvdata->dev, +"No retention data configured bank with external wakeup interrupt. Wake-up mask will not be set.\n" ); +return ; + } + + + clk_base = (void __iomem *) drvdata->retention_ctrl->priv; + +__raw_writel (irq_chip->eint_wake_mask_value, + clk_base + irq_chip->eint_wake_mask_reg); +} +/* * irq_chip for wakeup interrupts */
@@ -360,8 +403,9 @@ static const struct exynos_irq_chip s5pv .eint_mask = EXYNOS_WKUP_EMASK_OFFSET, .eint_pend = EXYNOS_WKUP_EPEND_OFFSET, .eint_wake_mask_value = EXYNOS_EINT_WAKEUP_MASK_DISABLED, - /* Only difference with exynos4210_wkup_irq_chip: */ + /* Only differences with exynos4210_wkup_irq_chip: */ .eint_wake_mask_reg = S5PV210_EINT_WAKEUP_MASK, + .set_eint_wakeup_mask = s5pv210_pinctrl_set_eint_wakeup_mask, };static const struct exynos_irq_chip exynos4210_wkup_irq_chip__initconst = {
@@ -380,6 +424,7 @@ static const struct exynos_irq_chip exyn .eint_pend = EXYNOS_WKUP_EPEND_OFFSET, .eint_wake_mask_value = EXYNOS_EINT_WAKEUP_MASK_DISABLED, .eint_wake_mask_reg = EXYNOS_EINT_WAKEUP_MASK, + .set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask, };static const struct exynos_irq_chip exynos7_wkup_irq_chip__initconst = {
@@ -398,6 +443,7 @@ static const struct exynos_irq_chip exyn .eint_pend = EXYNOS7_WKUP_EPEND_OFFSET, .eint_wake_mask_value = EXYNOS_EINT_WAKEUP_MASK_DISABLED, .eint_wake_mask_reg = EXYNOS5433_EINT_WAKEUP_MASK, + .set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask, };/* list of external wakeup controllers supported */
@@ -574,27 +620,6 @@ int exynos_eint_wkup_init(struct samsungreturn 0 ; } -static void -exynos_pinctrl_set_eint_wakeup_mask (struct samsung_pinctrl_drv_data *drvdata, -struct exynos_irq_chip *irq_chip) -{ -struct regmap *pmu_regs; - -if (!drvdata->retention_ctrl || !drvdata->retention_ctrl->priv) { -dev_warn (drvdata->dev, -"No retention data configured bank with external wakeup interrupt. Wake-up mask will not be set.\n" ); -return ; - } - - pmu_regs = drvdata->retention_ctrl->priv; -dev_info (drvdata->dev, -"Setting external wakeup interrupt mask: 0x%x\n" , - irq_chip->eint_wake_mask_value); - -regmap_write (pmu_regs, irq_chip->eint_wake_mask_reg, - irq_chip->eint_wake_mask_value); -} -static void exynos_pinctrl_suspend_bank (struct samsung_pinctrl_drv_data *drvdata,struct samsung_pin_bank *bank)
@@ -626,8 +651,8 @@ void exynos_pinctrl_suspend(struct samsuelse if (bank->eint_type ==EINT_TYPE_WKUP ) {if (!irq_chip) { irq_chip = bank->irq_chip; -exynos_pinctrl_set_eint_wakeup_mask (drvdata, - irq_chip); + irq_chip->set_eint_wakeup_mask (drvdata, + irq_chip); }else if (bank->irq_chip != irq_chip) { dev_warn(drvdata->dev, "More than one external wakeup interrupt chip configured (bank: %s). This is not supported by hardware nor by driver.\n",
Greg Kroah-Hartman
maintainerPATCH 319/376 pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs
In reply to Greg Kroah-HartmanFrom: Jonathan Bakker <[email protected]>
commit f354157a7d184db430c1a564c506434e33b1bec5 upstream.
Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers are saved and restored over a suspend/resume cycle. However, the EINT_MASK registers are not.
On S5PV210 at the very least, these registers are not retained over suspend, leading to the interrupts remaining masked upon resume and therefore no interrupts being triggered for the device. There should be no effect on any SoCs that do retain these registers as theoretically we would just be re-writing what was already there.
--- drivers/pinctrl/samsung/pinctrl-exynos.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/pinctrl/samsung/pinctrl-exynos.c +9 -0
@@ -267,6 +267,7 @@ struct exynos_eint_gpio_save {u32 eint_con;u32 eint_fltcon0;u32 eint_fltcon1; +u32 eint_mask; };/*
@@ -633,10 +634,13 @@ static void exynos_pinctrl_suspend_bank( + 2 * bank->eint_offset); save->eint_fltcon1 =readl (regs +EXYNOS_GPIO_EFLTCON_OFFSET +2 * bank->eint_offset +4 ); + save->eint_mask =readl (regs + bank->irq_chip->eint_mask + + bank->eint_offset);pr_debug ("%s: save con %#010x\n" , bank->name, save->eint_con);pr_debug ("%s: save fltcon0 %#010x\n" , bank->name, save->eint_fltcon0);pr_debug ("%s: save fltcon1 %#010x\n" , bank->name, save->eint_fltcon1); +pr_debug ("%s: save mask %#010x\n" , bank->name, save->eint_mask); }void exynos_pinctrl_suspend (struct samsung_pinctrl_drv_data *drvdata)
@@ -678,6 +682,9 @@ static void exynos_pinctrl_resume_bank(pr_debug ("%s: fltcon1 %#010x => %#010x\n" , bank->name,readl (regs +EXYNOS_GPIO_EFLTCON_OFFSET +2 * bank->eint_offset +4 ), save->eint_fltcon1); +pr_debug ("%s: mask %#010x => %#010x\n" , bank->name, +readl (regs + bank->irq_chip->eint_mask + + bank->eint_offset), save->eint_mask);writel (save->eint_con, regs +EXYNOS_GPIO_ECON_OFFSET + bank->eint_offset);
@@ -685,6 +692,8 @@ static void exynos_pinctrl_resume_bank( + 2 * bank->eint_offset);writel (save->eint_fltcon1, regs +EXYNOS_GPIO_EFLTCON_OFFSET +2 * bank->eint_offset +4 ); +writel (save->eint_mask, regs + bank->irq_chip->eint_mask + + bank->eint_offset); }void exynos_pinctrl_resume (struct samsung_pinctrl_drv_data *drvdata)
Greg Kroah-Hartman
maintainerPATCH 320/376 gnss: sirf: fix error return code in sirf_probe()
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
commit 43d7ce70ae43dd8523754b17f567417e0e75dbce upstream.
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function.
This avoids a use-after-free in case the driver is later unbound.
--- drivers/gnss/sirf.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gnss/sirf.c +6 -2
@@ -439,14 +439,18 @@ static int sirf_probe(struct serdev_devi data->on_off =devm_gpiod_get_optional (dev,"sirf,onoff" ,GPIOD_OUT_LOW ); -if (IS_ERR (data->on_off)) +if (IS_ERR (data->on_off)) { + ret =PTR_ERR (data->on_off); goto err_put_device; + }if (data->on_off) { data->wakeup =devm_gpiod_get_optional (dev,"sirf,wakeup" ,GPIOD_IN ); -if (IS_ERR (data->wakeup)) +if (IS_ERR (data->wakeup)) { + ret =PTR_ERR (data->wakeup); goto err_put_device; + } ret =regulator_enable (data->vcc);if (ret)
Greg Kroah-Hartman
maintainerPATCH 321/376 sparc32: fix register window handling in genregs32_[gs]et()
In reply to Greg Kroah-HartmanFrom: Al Viro <[email protected]>
commit cf51e129b96847f969bfb8af1ee1516a01a70b39 upstream.
It needs access_process_vm() if the traced process does not share mm with the caller. Solution is similar to what sparc64 does. Note that genregs32_set() is only ever called with pos being 0 or 32 * sizeof(u32) (the latter - as part of PTRACE_SETREGS handling).
--- arch/sparc/kernel/ptrace_32.c | 230 ++++++++++++++++++------------------------ 1 file changed, 99 insertions(+), 131 deletions(-)
arch/sparc/kernel/ptrace_32.c +99 -131
@@ -46,82 +46,79 @@ enum sparc_regset { REGSET_FP, }; +static int regwindow32_get (struct task_struct *target, +const struct pt_regs *regs, +u32 *uregs) +{ +unsigned long reg_window = regs->u_regs[UREG_I6 ]; +int size =16 *sizeof (u32); + +if (target == current) { +if (copy_from_user (uregs, (void __user *)reg_window, size)) +return -EFAULT ; + }else { +if (access_process_vm (target, reg_window, uregs, size, +FOLL_FORCE ) != size) +return -EFAULT ; + } +return 0 ; +} + +static int regwindow32_set (struct task_struct *target, +const struct pt_regs *regs, +u32 *uregs) +{ +unsigned long reg_window = regs->u_regs[UREG_I6 ]; +int size =16 *sizeof (u32); + +if (target == current) { +if (copy_to_user ((void __user *)reg_window, uregs, size)) +return -EFAULT ; + }else { +if (access_process_vm (target, reg_window, uregs, size, +FOLL_FORCE |FOLL_WRITE ) != size) +return -EFAULT ; + } +return 0 ; +} +static int genregs32_get (struct task_struct *target,const struct user_regset *regset,unsigned int pos,unsigned int count,void *kbuf,void __user *ubuf) {const struct pt_regs *regs = target->thread.kregs; -unsigned long __user *reg_window; -unsigned long *k = kbuf; -unsigned long __user *u = ubuf; -unsigned long reg; +u32 uregs[16 ]; +int ret;if (target == current)flush_user_windows (); - pos /=sizeof (reg); - count /=sizeof (reg); + ret =user_regset_copyout (&pos, &count, &kbuf, &ubuf, + regs->u_regs, +0 ,16 *sizeof (u32)); +if (ret || !count) +return ret; -if (kbuf) { -for (; count >0 && pos <16 ; count--) - *k++ = regs->u_regs[pos++]; - - reg_window = (unsigned long __user *) regs->u_regs[UREG_I6 ]; - reg_window -=16 ; -for (; count >0 && pos <32 ; count--) { -if (get_user (*k++, ®_window[pos++])) -return -EFAULT ; - } - }else { -for (; count >0 && pos <16 ; count--) { -if (put_user (regs->u_regs[pos++], u++)) -return -EFAULT ; - } - - reg_window = (unsigned long __user *) regs->u_regs[UREG_I6 ]; - reg_window -=16 ; -for (; count >0 && pos <32 ; count--) { -if (get_user (reg, ®_window[pos++]) || -put_user (reg, u++)) -return -EFAULT ; - } - } -while (count >0 ) { -switch (pos) { -case 32 :/* PSR */ - reg = regs->psr; -break ; -case 33 :/* PC */ - reg = regs->pc; -break ; -case 34 :/* NPC */ - reg = regs->npc; -break ; -case 35 :/* Y */ - reg = regs->y; -break ; -case 36 :/* WIM */ -case 37 :/* TBR */ - reg =0 ; -break ; -default : - goto finish; - } - -if (kbuf) - *k++ = reg; -else if (put_user (reg, u++)) +if (pos <32 *sizeof (u32)) { +if (regwindow32_get (target, regs, uregs))return -EFAULT ; - pos++; - count--; + ret =user_regset_copyout (&pos, &count, &kbuf, &ubuf, + uregs, +16 *sizeof (u32),32 *sizeof (u32)); +if (ret || !count) +return ret; } -finish: - pos *=sizeof (reg); - count *=sizeof (reg); -return user_regset_copyout_zero (&pos, &count, &kbuf, &ubuf, -38 *sizeof (reg),-1 ); + uregs[0 ] = regs->psr; + uregs[1 ] = regs->pc; + uregs[2 ] = regs->npc; + uregs[3 ] = regs->y; + uregs[4 ] =0 ;/* WIM */ + uregs[5 ] =0 ;/* TBR */ +return user_regset_copyout (&pos, &count, &kbuf, &ubuf, + uregs, +32 *sizeof (u32),38 *sizeof (u32)); } static int genregs32_set(struct task_struct *target,
@@ -130,82 +127,53 @@ static int genregs32_set(struct task_str const void *kbuf, const void __user *ubuf) { struct pt_regs *regs = target->thread.kregs; -unsigned long __user *reg_window; -const unsigned long *k = kbuf; -const unsigned long __user *u = ubuf; -unsigned long reg; +u32 uregs[16 ]; +u32 psr; +int ret;if (target == current)flush_user_windows (); - pos /=sizeof (reg); - count /=sizeof (reg); - -if (kbuf) { -for (; count >0 && pos <16 ; count--) - regs->u_regs[pos++] = *k++; - - reg_window = (unsigned long __user *) regs->u_regs[UREG_I6 ]; - reg_window -=16 ; -for (; count >0 && pos <32 ; count--) { -if (put_user (*k++, ®_window[pos++])) -return -EFAULT ; - } - }else { -for (; count >0 && pos <16 ; count--) { -if (get_user (reg, u++)) -return -EFAULT ; - regs->u_regs[pos++] = reg; - } - - reg_window = (unsigned long __user *) regs->u_regs[UREG_I6 ]; - reg_window -=16 ; -for (; count >0 && pos <32 ; count--) { -if (get_user (reg, u++) || -put_user (reg, ®_window[pos++])) -return -EFAULT ; - } - } -while (count >0 ) { -unsigned long psr; - -if (kbuf) - reg = *k++; -else if (get_user (reg, u++)) -return -EFAULT ; - -switch (pos) { -case 32 :/* PSR */ - psr = regs->psr; - psr &= ~(PSR_ICC |PSR_SYSCALL ); - psr |= (reg & (PSR_ICC |PSR_SYSCALL )); - regs->psr = psr; -break ; -case 33 :/* PC */ - regs->pc = reg; -break ; -case 34 :/* NPC */ - regs->npc = reg; -break ; -case 35 :/* Y */ - regs->y = reg; -break ; -case 36 :/* WIM */ -case 37 :/* TBR */ -break ; -default : - goto finish; - } + ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, + regs->u_regs, +0 ,16 *sizeof (u32)); +if (ret || !count) +return ret; - pos++; - count--; +if (pos <32 *sizeof (u32)) { +if (regwindow32_get (target, regs, uregs)) +return -EFAULT ; + ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, + uregs, +16 *sizeof (u32),32 *sizeof (u32)); +if (ret) +return ret; +if (regwindow32_set (target, regs, uregs)) +return -EFAULT ; +if (!count) +return 0 ; } -finish: - pos *=sizeof (reg); - count *=sizeof (reg); - + ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, + &psr, +32 *sizeof (u32),33 *sizeof (u32)); +if (ret) +return ret; + regs->psr = (regs->psr & ~(PSR_ICC |PSR_SYSCALL )) | + (psr & (PSR_ICC |PSR_SYSCALL )); +if (!count) +return 0 ; + ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, + ®s->pc, +33 *sizeof (u32),34 *sizeof (u32)); +if (ret || !count) +return ret; + ret =user_regset_copyin (&pos, &count, &kbuf, &ubuf, + ®s->y, +34 *sizeof (u32),35 *sizeof (u32)); +if (ret || !count) +return ret;return user_regset_copyin_ignore (&pos, &count, &kbuf, &ubuf, -38 *sizeof (reg),-1 ); +35 *sizeof (u32),38 *sizeof (u32)); } static int fpregs32_get(struct task_struct *target,
Greg Kroah-Hartman
maintainerPATCH 322/376 sparc64: fix misuses of access_process_vm() in genregs32_[sg]et()
In reply to Greg Kroah-HartmanFrom: Al Viro <[email protected]>
commit 142cd25293f6a7ecbdff4fb0af17de6438d46433 upstream.
We do need access_process_vm() to access the target's reg_window. However, access to caller's memory (storing the result in genregs32_get(), fetching the new values in case of genregs32_set()) should be done by normal uaccess primitives.
--- arch/sparc/kernel/ptrace_64.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-)
arch/sparc/kernel/ptrace_64.c +3 -14
@@ -572,19 +572,13 @@ static int genregs32_get(struct task_strfor (; count >0 && pos <32 ; count--) {if (access_process_vm (target, (unsigned long ) - ®_window[pos], + ®_window[pos++], ®,sizeof (reg),FOLL_FORCE ) !=sizeof (reg))return -EFAULT ; -if (access_process_vm (target, - (unsigned long ) u, - ®,sizeof (reg), -FOLL_FORCE |FOLL_WRITE ) - !=sizeof (reg)) +if (put_user (reg, u++))return -EFAULT ; - pos++; - u++; } } }
@@ -684,12 +678,7 @@ static int genregs32_set(struct task_str } }else {for (; count >0 && pos <32 ; count--) { -if (access_process_vm (target, - (unsigned long ) - u, - ®,sizeof (reg), -FOLL_FORCE ) - !=sizeof (reg)) +if (get_user (reg, u++))return -EFAULT ; if (access_process_vm(target, (unsigned long)
Greg Kroah-Hartman
maintainerPATCH 323/376 software node: implement software_node_unregister()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
commit 46d26819a5056f4831649c5887ad5c71a16d86f7 upstream.
Sometimes it is better to unregister individual nodes instead of trying to do them all at once with software_node_unregister_nodes(), so create software_node_unregister() so that you can unregister them one at a time.
This is especially important when creating nodes in a hierarchy, with parent -> children representations. Children always need to be removed before a parent is, as the swnode logic assumes this is going to be the case.
Fix up the lib/test_printf.c fwnode_pointer() test which to use this new function as it had the problem of tearing things down in the backwards order.
--- drivers/base/swnode.c | 27 +++++++++++++++++++++------ include/linux/property.h | 1 + lib/test_printf.c | 4 +++- 3 files changed, 25 insertions(+), 7 deletions(-)
drivers/base/swnode.c +21 -6
@@ -712,17 +712,18 @@ EXPORT_SYMBOL_GPL(software_node_register* @nodes: Zero terminated array of software nodes to be unregistered * * Unregister multiple software nodes at once. +* +* NOTE: Be careful using this call if the nodes had parent pointers set up in +* them before registering. If so, it is wiser to remove the nodes +* individually, in the correct order (child before parent) instead of relying +* on the sequential order of the list of nodes in the array. */ void software_node_unregister_nodes (const struct software_node *nodes) { -struct swnode *swnode;int i; -for (i =0 ; nodes[i].name; i++) { - swnode =software_node_to_swnode (&nodes[i]); -if (swnode) -fwnode_remove_software_node (&swnode->fwnode); - } +for (i =0 ; nodes[i].name; i++) +software_node_unregister (&nodes[i]); }EXPORT_SYMBOL_GPL (software_node_unregister_nodes);
@@ -741,6 +742,20 @@ int software_node_register(const struct }EXPORT_SYMBOL_GPL (software_node_register); +/** +* software_node_unregister - Unregister static software node +* @node: The software node to be unregistered +*/ +void software_node_unregister (const struct software_node *node) +{ +struct swnode *swnode; + + swnode =software_node_to_swnode (node); +if (swnode) +fwnode_remove_software_node (&swnode->fwnode); +} +EXPORT_SYMBOL_GPL (software_node_unregister); +struct fwnode_handle *fwnode_create_software_node (const struct property_entry *properties,const struct fwnode_handle *parent)
include/linux/property.h +1 -0
@@ -441,6 +441,7 @@ int software_node_register_nodes(const svoid software_node_unregister_nodes (const struct software_node *nodes);int software_node_register (const struct software_node *node); +void software_node_unregister (const struct software_node *node);int software_node_notify (struct device *dev,unsigned long action);
lib/test_printf.c +3 -1
@@ -637,7 +637,9 @@ static void __init fwnode_pointer(void)test (second_name,"%pfwP" ,software_node_fwnode (&softnodes[1 ]));test (third_name,"%pfwP" ,software_node_fwnode (&softnodes[2 ])); -software_node_unregister_nodes (softnodes); +software_node_unregister (&softnodes[2 ]); +software_node_unregister (&softnodes[1 ]); +software_node_unregister (&softnodes[0 ]); } static void __init
Greg Kroah-Hartman
maintainerPATCH 324/376 dm crypt: avoid truncating the logical block size
In reply to Greg Kroah-HartmanFrom: Eric Biggers <[email protected]>
commit 64611a15ca9da91ff532982429c44686f4593b5f upstream.
queue_limits::logical_block_size got changed from unsigned short to unsigned int, but it was forgotten to update crypt_io_hints() to use the new type. Fix it.
--- drivers/md/dm-crypt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-crypt.c +1 -1
@@ -3274,7 +3274,7 @@ static void crypt_io_hints(struct dm_tar limits->max_segment_size =PAGE_SIZE ; limits->logical_block_size = - max_t(unsigned short, limits->logical_block_size, cc->sector_size); +max_t (unsigned, limits->logical_block_size, cc->sector_size); limits->physical_block_size =max_t (unsigned, limits->physical_block_size, cc->sector_size); limits->io_min =max_t (unsigned, limits->io_min, cc->sector_size);
Greg Kroah-Hartman
maintainerPATCH 325/376 alpha: fix memory barriers so that they conform to the specification
In reply to Greg Kroah-HartmanFrom: Mikulas Patocka <[email protected]>
commit 54505a1e2083fc54cbe8779b97479f969cd30a00 upstream.
The commits cd0e00c10672 and 92d7223a7423 broke boot on the Alpha Avanti platform. The patches move memory barriers after a write before the write. The result is that if there's iowrite followed by ioread, there is no barrier between them.
The Alpha architecture allows reordering of the accesses to the I/O space, and the missing barrier between write and read causes hang with serial port and real time clock.
This patch makes barriers confiorm to the specification.
1. We add mb() before readX_relaxed and writeX_relaxed - memory-barriers.txt claims that these functions must be ordered w.r.t. each other. Alpha doesn't order them, so we need an explicit barrier.
2. We add mb() before reads from the I/O space - so that if there's a write followed by a read, there should be a barrier between them.
--- arch/alpha/include/asm/io.h | 74 +++++++++++++++++++++++++++++++++++--------- arch/alpha/kernel/io.c | 60 +++++++++++++++++++++++++++++++---- 2 files changed, 112 insertions(+), 22 deletions(-)
arch/alpha/include/asm/io.h +59 -15
@@ -310,14 +310,18 @@ static inline int __is_mmio(const volati#if IO_CONCAT (__IO_PREFIX,trivial_io_bw)extern inline unsigned int ioread8 (void __iomem *addr) { -unsigned int ret =IO_CONCAT (__IO_PREFIX,ioread8)(addr); +unsigned int ret; +mb (); + ret =IO_CONCAT (__IO_PREFIX,ioread8)(addr);mb ();return ret; }extern inline unsigned int ioread16 (void __iomem *addr) { -unsigned int ret =IO_CONCAT (__IO_PREFIX,ioread16)(addr); +unsigned int ret; +mb (); + ret =IO_CONCAT (__IO_PREFIX,ioread16)(addr);mb ();return ret; }
@@ -358,7 +362,9 @@ extern inline void outw(u16 b, unsigned#if IO_CONCAT (__IO_PREFIX,trivial_io_lq)extern inline unsigned int ioread32 (void __iomem *addr) { -unsigned int ret =IO_CONCAT (__IO_PREFIX,ioread32)(addr); +unsigned int ret; +mb (); + ret =IO_CONCAT (__IO_PREFIX,ioread32)(addr);mb ();return ret; }
@@ -403,14 +409,18 @@ extern inline void __raw_writew(u16 b, vextern inline u8 readb (const volatile void __iomem *addr) { -u8 ret =__raw_readb (addr); +u8 ret; +mb (); + ret =__raw_readb (addr);mb ();return ret; }extern inline u16 readw (const volatile void __iomem *addr) { -u16 ret =__raw_readw (addr); +u16 ret; +mb (); + ret =__raw_readw (addr);mb ();return ret; }
@@ -451,14 +461,18 @@ extern inline void __raw_writeq(u64 b, vextern inline u32 readl (const volatile void __iomem *addr) { -u32 ret =__raw_readl (addr); +u32 ret; +mb (); + ret =__raw_readl (addr);mb ();return ret; }extern inline u64 readq (const volatile void __iomem *addr) { -u64 ret =__raw_readq (addr); +u64 ret; +mb (); + ret =__raw_readq (addr);mb ();return ret; }
@@ -487,14 +501,44 @@ extern inline void writeq(u64 b, volatil#define outb_p outb#define outw_p outw#define outl_p outl -#define readb_relaxed (addr) __raw_readb(addr) -#define readw_relaxed (addr) __raw_readw(addr) -#define readl_relaxed (addr) __raw_readl(addr) -#define readq_relaxed (addr) __raw_readq(addr) -#define writeb_relaxed (b, addr) __raw_writeb(b, addr) -#define writew_relaxed (b, addr) __raw_writew(b, addr) -#define writel_relaxed (b, addr) __raw_writel(b, addr) -#define writeq_relaxed (b, addr) __raw_writeq(b, addr) + +extern u8 readb_relaxed (const volatile void __iomem *addr); +extern u16 readw_relaxed (const volatile void __iomem *addr); +extern u32 readl_relaxed (const volatile void __iomem *addr); +extern u64 readq_relaxed (const volatile void __iomem *addr); + +#if IO_CONCAT (__IO_PREFIX,trivial_io_bw) +extern inline u8 readb_relaxed (const volatile void __iomem *addr) +{ +mb (); +return __raw_readb (addr); +} + +extern inline u16 readw_relaxed (const volatile void __iomem *addr) +{ +mb (); +return __raw_readw (addr); +} +#endif + +#if IO_CONCAT (__IO_PREFIX,trivial_io_lq) +extern inline u32 readl_relaxed (const volatile void __iomem *addr) +{ +mb (); +return __raw_readl (addr); +} + +extern inline u64 readq_relaxed (const volatile void __iomem *addr) +{ +mb (); +return __raw_readq (addr); +} +#endif + +#define writeb_relaxed writeb +#define writew_relaxed writew +#define writel_relaxed writel +#define writeq_relaxed writeq/* * String version of IO memory access ops:
arch/alpha/kernel/io.c +53 -7
108 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 326/376 memory: samsung: exynos5422-dmc: Fix tFAW timings alignment
In reply to Greg Kroah-HartmanFrom: Bernard Zhao <[email protected]>
commit 4bff7214d263b5235263136cb53147a759b3f3ab upstream.
Aligning of tFAW timing with standard was using wrong argument as minimum acceptable value. This could lead to wrong timing if provided timings and clock period do not match the standard.
--- drivers/memory/samsung/exynos5422-dmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/memory/samsung/exynos5422-dmc.c +1 -1
@@ -1091,7 +1091,7 @@ static int create_timings_aligned(struct/* power related timings */ val = dmc->timings->tFAW / clk_period_ps; val += dmc->timings->tFAW % clk_period_ps ?1 :0 ; - val =max (val, dmc->min_tck->tXP); + val =max (val, dmc->min_tck->tFAW); reg = &timing_power[0 ]; *reg_timing_power |=TIMING_VAL2REG (reg, val);
Greg Kroah-Hartman
maintainerPATCH 327/376 powerpc/fadump: use static allocation for reserved memory ranges
In reply to Greg Kroah-HartmanFrom: Hari Bathini <[email protected]>
commit 02c04e374e176ae3a3f64a682f80702f8d2fb65d upstream.
At times, memory ranges have to be looked up during early boot, when kernel couldn't be initialized for dynamic memory allocation. In fact, reserved-ranges look up is needed during FADump memory reservation. Without accounting for reserved-ranges in reserving memory for FADump, MPIPL boot fails with memory corruption issues. So, extend memory ranges handling to support static allocation and populate reserved memory ranges during early boot.
--- arch/powerpc/include/asm/fadump-internal.h | 4 + arch/powerpc/kernel/fadump.c | 77 ++++++++++++++++------------- 2 files changed, 48 insertions(+), 33 deletions(-)
arch/powerpc/include/asm/fadump-internal.h +3 -1
@@ -64,12 +64,14 @@ struct fadump_memory_range { };/* fadump memory ranges info */ +#define RNG_NAME_SZ 16struct fadump_mrange_info { -char name[16 ]; +char name[RNG_NAME_SZ ];struct fadump_memory_range *mem_ranges;u32 mem_ranges_sz;u32 mem_range_cnt;u32 max_mem_ranges; +bool is_static; };/* Platform specific callback functions */
arch/powerpc/kernel/fadump.c +45 -32
134 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 328/376 powerpc/fadump: consider reserved ranges while reserving memory
In reply to Greg Kroah-HartmanFrom: Hari Bathini <[email protected]>
commit 140777a3d8dfdb3d3f20ea7707c0f1c0ce1b0aa5 upstream.
Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for memory reservations") enabled support to parse reserved-ranges DT node and reserve kernel memory falling in these ranges for F/W purposes. Memory reserved for FADump should not overlap with these ranges as it could corrupt memory meant for F/W or crash'ed kernel memory to be exported as vmcore.
But since commit 579ca1a27675 ("powerpc/fadump: make use of memblock's bottom up allocation mode"), memblock_find_in_range() is being used to find the appropriate area to reserve memory for FADump, which can't account for reserved-ranges as these ranges are reserved only after FADump memory reservation.
With reserved-ranges now being populated during early boot, look out for these memory ranges while reserving memory for FADump. Without this change, MPIPL on PowerNV systems aborts with hostboot failure, when memory reserved for FADump is less than 4096MB.
--- arch/powerpc/kernel/fadump.c | 76 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 67 insertions(+), 9 deletions(-)
arch/powerpc/kernel/fadump.c +67 -9
@@ -445,10 +445,72 @@ static int __init fadump_get_boot_mem_rereturn ret; } +/* +* Returns true, if the given range overlaps with reserved memory ranges +* starting at idx. Also, updates idx to index of overlapping memory range +* with the given memory range. +* False, otherwise. +*/ +static bool overlaps_reserved_ranges (u64 base,u64 end,int *idx) +{ +bool ret = false; +int i; + +for (i = *idx; i < reserved_mrange_info.mem_range_cnt; i++) { +u64 rbase = reserved_mrange_info.mem_ranges[i].base; +u64 rend = rbase + reserved_mrange_info.mem_ranges[i].size; + +if (end <= rbase) +break ; + +if ((end > rbase) && (base < rend)) { + *idx = i; + ret = true; +break ; + } + } + +return ret; +} + +/* +* Locate a suitable memory area to reserve memory for FADump. While at it, +* lookup reserved-ranges & avoid overlap with them, as they are used by F/W. +*/ +static u64 __init fadump_locate_reserve_mem (u64 base,u64 size) +{ +struct fadump_memory_range *mrngs; +phys_addr_t mstart, mend; +int idx =0 ; +u64 i, ret =0 ; + + mrngs = reserved_mrange_info.mem_ranges; +for_each_free_mem_range (i,NUMA_NO_NODE ,MEMBLOCK_NONE , + &mstart, &mend,NULL ) { +pr_debug ("%llu) mstart: %llx, mend: %llx, base: %llx\n" , + i, mstart, mend, base); + +if (mstart > base) + base =PAGE_ALIGN (mstart); + +while ((mend > base) && ((mend - base) >= size)) { +if (!overlaps_reserved_ranges (base, base+size, &idx)) { + ret = base; + goto out; + } + + base = mrngs[idx].base + mrngs[idx].size; + base =PAGE_ALIGN (base); + } + } + +out: +return ret; +} +int __init fadump_reserve_mem (void ) { -u64 base, size, mem_boundary, bootmem_min, align =PAGE_SIZE ; -bool is_memblock_bottom_up =memblock_bottom_up (); +u64 base, size, mem_boundary, bootmem_min;int ret =1 ;if (!fw_dump.fadump_enabled)
@@ -469,9 +531,9 @@ int __init fadump_reserve_mem(void)PAGE_ALIGN (fadump_calculate_reserve_size ());#ifdef CONFIG_CMA if (!fw_dump.nocma) { - align =FADUMP_CMA_ALIGNMENT ; fw_dump.boot_memory_size = -ALIGN (fw_dump.boot_memory_size, align); +ALIGN (fw_dump.boot_memory_size, +FADUMP_CMA_ALIGNMENT ); }#endif
@@ -539,11 +601,7 @@ int __init fadump_reserve_mem(void)* Reserve memory at an offset closer to bottom of the RAM to * minimize the impact of memory hot-remove operation. */ -memblock_set_bottom_up (true); - base =memblock_find_in_range (base, mem_boundary, size, align); - -/* Restore the previous allocation mode */ -memblock_set_bottom_up (is_memblock_bottom_up); + base =fadump_locate_reserve_mem (base, size);if (!base) {pr_err ("Failed to find memory chunk for reservation!\n" );
Greg Kroah-Hartman
maintainerPATCH 329/376 powerpc/fadump: Account for memory_limit while reserving memory
In reply to Greg Kroah-HartmanFrom: Hari Bathini <[email protected]>
commit 9a2921e5baca1d25eb8d21f21d1e90581a6d0f68 upstream.
If the memory chunk found for reserving memory overshoots the memory limit imposed, do not proceed with reserving memory. Default behavior was this until commit 140777a3d8df ("powerpc/fadump: consider reserved ranges while reserving memory") changed it unwittingly.
--- arch/powerpc/kernel/fadump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/fadump.c +1 -1
@@ -603,7 +603,7 @@ int __init fadump_reserve_mem(void)*/ base =fadump_locate_reserve_mem (base, size); -if (!base) { +if (!base || (base + size > mem_boundary)) {pr_err ("Failed to find memory chunk for reservation!\n" ); goto error_out; }
Greg Kroah-Hartman
maintainerPATCH 330/376 kernel/cpu_pm: Fix uninitted local in cpu_pm
In reply to Greg Kroah-HartmanFrom: Douglas Anderson <[email protected]>
commit b5945214b76a1f22929481724ffd448000ede914 upstream.
cpu_pm_notify() is basically a wrapper of notifier_call_chain(). notifier_call_chain() doesn't initialize *nr_calls to 0 before it starts incrementing it--presumably it's up to the callers to do this.
Unfortunately the callers of cpu_pm_notify() don't init *nr_calls. This potentially means you could get too many or two few calls to CPU_PM_ENTER_FAILED or CPU_CLUSTER_PM_ENTER_FAILED depending on the luck of the stack.
Let's fix this.
--- kernel/cpu_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/cpu_pm.c +2 -2
@@ -80,7 +80,7 @@ EXPORT_SYMBOL_GPL(cpu_pm_unregister_noti*/ int cpu_pm_enter (void ) { -int nr_calls; +int nr_calls =0 ;int ret =0 ; ret =cpu_pm_notify (CPU_PM_ENTER ,-1 , &nr_calls);
@@ -131,7 +131,7 @@ EXPORT_SYMBOL_GPL(cpu_pm_exit);*/ int cpu_cluster_pm_enter (void ) { -int nr_calls; +int nr_calls =0 ;int ret =0 ; ret =cpu_pm_notify (CPU_CLUSTER_PM_ENTER ,-1 , &nr_calls);
Greg Kroah-Hartman
maintainerPATCH 331/376 ARM: tegra: Correct PL310 Auxiliary Control Register initialization
In reply to Greg Kroah-HartmanFrom: Dmitry Osipenko <[email protected]>
commit 35509737c8f958944e059d501255a0bf18361ba0 upstream.
The PL310 Auxiliary Control Register shouldn't have the "Full line of zero" optimization bit being set before L2 cache is enabled. The L2X0 driver takes care of enabling the optimization by itself.
This patch fixes a noisy error message on Tegra20 and Tegra30 telling that cache optimization is erroneously enabled without enabling it for the CPU:
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
--- arch/arm/mach-tegra/tegra.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-tegra/tegra.c +2 -2
@@ -107,8 +107,8 @@ static const char * const tegra_dt_board };DT_MACHINE_START (TEGRA_DT ,"NVIDIA Tegra SoC (Flattened Device Tree)" ) - .l2c_aux_val = 0x3c400001, - .l2c_aux_mask = 0xc20fc3fe, + .l2c_aux_val = 0x3c400000, + .l2c_aux_mask = 0xc20fc3ff, .smp = smp_ops(tegra_smp_ops), .map_io = tegra_map_common_io, .init_early = tegra_init_early,
Greg Kroah-Hartman
maintainerPATCH 332/376 soc/tegra: pmc: Select GENERIC_PINCONF
In reply to Greg Kroah-HartmanFrom: Corentin Labbe <[email protected]>
commit 5098e2b95e8e6f56266c2d5c180c75917090082a upstream.
I have hit the following build error:
armv7a-hardfloat-linux-gnueabi-ld: drivers/soc/tegra/pmc.o: in function `pinconf_generic_dt_node_to_map_pin':
pmc.c:(.text+0x500): undefined reference to pinconf_generic_dt_node_to_map' armv7a-hardfloat-linux-gnueabi-ld: drivers/soc/tegra/pmc.o:(.rodata+0x1f88): undefined reference to pinconf_generic_dt_free_map'
So SOC_TEGRA_PMC should select GENERIC_PINCONF.
--- drivers/soc/tegra/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/soc/tegra/Kconfig +1 -0
@@ -133,6 +133,7 @@ config SOC_TEGRA_FLOWCTRL config SOC_TEGRA_PMC bool + select GENERIC_PINCONF config SOC_TEGRA_POWERGATE_BPMP def_bool y
Greg Kroah-Hartman
maintainerPATCH 333/376 jbd2: avoid leaking transaction credits when unreserving handle
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 14ff6286309e2853aed50083c9a83328423fdd8c upstream.
When reserved transaction handle is unused, we subtract its reserved credits in __jbd2_journal_unreserve_handle() called from jbd2_journal_stop(). However this function forgets to remove reserved credits from transaction->t_outstanding_credits and thus the transaction space that was reserved remains effectively leaked. The leaked transaction space can be quite significant in some cases and leads to unnecessarily small transactions and thus reducing throughput of the journalling machinery. E.g. fsmark workload creating lots of 4k files was observed to have about 20% lower throughput due to this when ext4 is mounted with dioread_nolock mount option.
Subtract reserved credits from t_outstanding_credits as well.
--- fs/jbd2/transaction.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
fs/jbd2/transaction.c +11 -3
@@ -541,17 +541,24 @@ handle_t *jbd2_journal_start(journal_t * }EXPORT_SYMBOL (jbd2_journal_start); -static void __jbd2_journal_unreserve_handle (handle_t *handle) +static void __jbd2_journal_unreserve_handle (handle_t *handle,transaction_t *t) {journal_t *journal = handle->h_journal;WARN_ON (!handle->h_reserved);sub_reserved_credits (journal, handle->h_total_credits); +if (t) +atomic_sub (handle->h_total_credits, &t->t_outstanding_credits); }void jbd2_journal_free_reserved (handle_t *handle) { -__jbd2_journal_unreserve_handle (handle); +journal_t *journal = handle->h_journal; + +/* Get j_state_lock to pin running transaction if it exists */ +read_lock (&journal->j_state_lock); +__jbd2_journal_unreserve_handle (handle, journal->j_running_transaction); +read_unlock (&journal->j_state_lock);jbd2_free_handle (handle); }EXPORT_SYMBOL (jbd2_journal_free_reserved);
@@ -722,7 +729,8 @@ static void stop_this_handle(handle_t *hatomic_sub (handle->h_total_credits, &transaction->t_outstanding_credits);if (handle->h_rsv_handle) -__jbd2_journal_unreserve_handle (handle->h_rsv_handle); +__jbd2_journal_unreserve_handle (handle->h_rsv_handle, + transaction);if (atomic_dec_and_test (&transaction->t_updates))wake_up (&journal->j_wait_updates);
Greg Kroah-Hartman
maintainerPATCH 334/376 ARM: dts: exynos: Fix GPIO polarity for thr GalaxyS3 CM36651 sensors bus
In reply to Greg Kroah-HartmanFrom: Marek Szyprowski <[email protected]>
commit 8807d356bfea92b0a8f04ce421800ed83400cd22 upstream.
GPIO lines for the CM36651 sensor I2C bus use the normal not the inverted polarity. This bug has been there since adding the CM36651 sensor by commit 85cb4e0bd229 ("ARM: dts: add cm36651 light/proximity sensor node for exynos4412-trats2"), but went unnoticed because the "i2c-gpio" driver ignored the GPIO polarity specified in the device-tree.
The recent conversion of "i2c-gpio" driver to the new, descriptor based GPIO API, automatically made it the DT-specified polarity aware, what broke the CM36651 sensor operation.
--- arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi +1 -1
@@ -68,7 +68,7 @@ i2c_cm36651: i2c-gpio-2 { compatible = "i2c-gpio"; - gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>; + gpios = <&gpf0 0 GPIO_ACTIVE_HIGH>, <&gpf0 1 GPIO_ACTIVE_HIGH>; i2c-gpio,delay-us = <2>; #address-cells = <1>; #size-cells = <0>;
Greg Kroah-Hartman
maintainerPATCH 335/376 ARM: dts: at91: sama5d2_ptc_ek: fix vbus pin
In reply to Greg Kroah-HartmanFrom: Ludovic Desroches <[email protected]>
commit baa998aecb75c04d62be0a4ab6b724af6d73a0f9 upstream.
The gpio property for the vbus pin doesn't match the pinctrl and is not correct.
--- arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts +1 -1
@@ -40,7 +40,7 @@ ahb { usb0: gadget@300000 { - atmel,vbus-gpio = <&pioA PIN_PA27 GPIO_ACTIVE_HIGH>; + atmel,vbus-gpio = <&pioA PIN_PB11 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usba_vbus>; status = "okay";
Greg Kroah-Hartman
maintainerPATCH 336/376 ARM: dts: s5pv210: Set keep-power-in-suspend for SDHCI1 on Aries
In reply to Greg Kroah-HartmanFrom: Jonathan Bakker <[email protected]>
commit 869d42e6eba821905e1a0950623aadafe1a6e6d3 upstream.
SDHCI1 is connected to a BCM4329 WiFi/BT chip which requires power to be kept over suspend. As the surrounding hardware supports this, mark it as such. This fixes WiFi after a suspend/resume cycle.
--- arch/arm/boot/dts/s5pv210-aries.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/s5pv210-aries.dtsi +1 -0
@@ -454,6 +454,7 @@ pinctrl-names = "default"; cap-sd-highspeed; cap-mmc-highspeed; + keep-power-in-suspend; mmc-pwrseq = <&wifi_pwrseq>; non-removable;
Greg Kroah-Hartman
maintainerPATCH 337/376 drivers/macintosh: Fix memleak in windfarm_pm112 driver
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 93900337b9ac2f4eca427eff6d187be2dc3b5551 upstream.
create_cpu_loop() calls smu_sat_get_sdb_partition() which does kmalloc() and returns the allocated buffer. In fact it's called twice, and neither buffer is freed.
This results in a memory leak as reported by Erhard:
unreferenced object 0xc00000047081f840 (size 32):
comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s)
hex dump (first 32 bytes):
c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. ..
00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............
backtrace:
[<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112]
[<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<000000000d54838d>] .kthread+0x13c/0x190
[<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
unreferenced object 0xc0000004737089f0 (size 16):
comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s)
hex dump (first 16 bytes):
c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{.....
backtrace:
[<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112]
[<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<000000000d54838d>] .kthread+0x13c/0x190
[<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64Fix it by rearranging the logic so we deal with each buffer separately, which then makes it easy to free the buffer once we're done with it.
--- drivers/macintosh/windfarm_pm112.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)
drivers/macintosh/windfarm_pm112.c +13 -8
@@ -132,14 +132,6 @@ static int create_cpu_loop(int cpu)s32 tmax;int fmin; -/* Get PID params from the appropriate SAT */ - hdr =smu_sat_get_sdb_partition (chip,0xC8 + core,NULL ); -if (hdr ==NULL ) { -printk (KERN_WARNING "windfarm: can't get CPU PID fan config\n" ); -return -EINVAL ; - } - piddata = (struct smu_sdbp_cpupiddata *)&hdr[1 ]; -/* Get FVT params to get Tmax; if not found, assume default */ hdr =smu_sat_get_sdb_partition (chip,0xC4 + core,NULL );if (hdr) {
@@ -152,6 +144,16 @@ static int create_cpu_loop(int cpu)if (tmax < cpu_all_tmax) cpu_all_tmax = tmax; +kfree (hdr); + +/* Get PID params from the appropriate SAT */ + hdr =smu_sat_get_sdb_partition (chip,0xC8 + core,NULL ); +if (hdr ==NULL ) { +printk (KERN_WARNING "windfarm: can't get CPU PID fan config\n" ); +return -EINVAL ; + } + piddata = (struct smu_sdbp_cpupiddata *)&hdr[1 ]; +/* * Darwin has a minimum fan speed of 1000 rpm for the 4-way and * 515 for the 2-way. That appears to be overkill, so for now,
@@ -174,6 +176,9 @@ static int create_cpu_loop(int cpu) pid.min = fmin;wf_cpu_pid_init (&cpu_pid[cpu], &pid); + +kfree (hdr); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 338/376 powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit 74016701fe5f873ae23bf02835407227138d874d upstream.
'thread' doesn't exist in kuap_check() macro.
Use 'current' instead.
--- arch/powerpc/include/asm/book3s/32/kup.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/include/asm/book3s/32/kup.h +2 -1
@@ -2,6 +2,7 @@#ifndef _ASM_POWERPC_BOOK3S_32_KUP_H#define _ASM_POWERPC_BOOK3S_32_KUP_H +#include <asm/bug.h> #include <asm/book3s/32/mmu-hash.h> #ifdef __ASSEMBLY__
@@ -75,7 +76,7 @@ .macro kuap_check current, gpr#ifdef CONFIG_PPC_KUAP_DEBUG - lwz \gpr, KUAP(thread) + lwz \gpr, THREAD + KUAP(\current) 999: twnei \gpr, 0 EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE) #endif
Greg Kroah-Hartman
maintainerPATCH 339/376 powerpc/kasan: Fix issues by lowering KASAN_SHADOW_END
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit 3a66a24f6060e6775f8c02ac52329ea0152d7e58 upstream.
At the time being, KASAN_SHADOW_END is 0x100000000, which is 0 in 32 bits representation.
This leads to a couple of issues:
- kasan_remap_early_shadow_ro() does nothing because the comparison k_cur < k_end is always false.
- In ptdump, address comparison for markers display fails and the marker's name is printed at the start of the KASAN area instead of being printed at the end.
However, there is no need to shadow the KASAN shadow area itself, so the KASAN shadow area can stop shadowing memory at the start of itself.
With a PAGE_OFFSET set to 0xc0000000, KASAN shadow area is then going from 0xf8000000 to 0xff000000.
--- arch/powerpc/include/asm/kasan.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/powerpc/include/asm/kasan.h +1 -3
@@ -23,9 +23,7 @@#define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET) -#define KASAN_SHADOW_END 0UL - -#define KASAN_SHADOW_SIZE (KASAN_SHADOW_END - KASAN_SHADOW_START) +#define KASAN_SHADOW_END (-(-KASAN_SHADOW_START >> KASAN_SHADOW_SCALE_SHIFT))#ifdef CONFIG_KASAN void kasan_early_init (void );
Greg Kroah-Hartman
maintainerPATCH 340/376 powerpc/kasan: Fix shadow pages allocation failure
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit d2a91cef9bbdeb87b7449fdab1a6be6000930210 upstream.
Doing kasan pages allocation in MMU_init is too early, kernel doesn't have access yet to the entire memory space and memblock_alloc() fails when the kernel is a bit big.
Do it from kasan_init() instead.
--- arch/powerpc/include/asm/kasan.h | 2 -- arch/powerpc/mm/init_32.c | 2 -- arch/powerpc/mm/kasan/kasan_init_32.c | 4 +++- 3 files changed, 3 insertions(+), 5 deletions(-)
arch/powerpc/include/asm/kasan.h +0 -2
@@ -27,12 +27,10 @@#ifdef CONFIG_KASAN void kasan_early_init (void ); -void kasan_mmu_init (void );void kasan_init (void );void kasan_late_init (void );#else static inline void kasan_init (void ) { } -static inline void kasan_mmu_init (void ) { }static inline void kasan_late_init (void ) { }#endif
arch/powerpc/mm/init_32.c +0 -2
@@ -170,8 +170,6 @@ void __init MMU_init(void)btext_unmap ();#endif -kasan_mmu_init (); -setup_kup ();/* Shortly after that, the entire linear mapping will be available */
arch/powerpc/mm/kasan/kasan_init_32.c +3 -1
@@ -132,7 +132,7 @@ static void __init kasan_unmap_early_shaflush_tlb_kernel_range (k_start, k_end); } -void __init kasan_mmu_init (void ) +static void __init kasan_mmu_init (void ) {int ret;struct memblock_region *reg;
@@ -160,6 +160,8 @@ void __init kasan_mmu_init(void)void __init kasan_init (void ) { +kasan_mmu_init (); +kasan_remap_early_shadow_ro ();clear_page (kasan_early_shadow_page);
Greg Kroah-Hartman
maintainerPATCH 341/376 powerpc/32: Disable KASAN with pages bigger than 16k
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit 888468ce725a4cd56d72dc7e5096078f7a9251a0 upstream.
Mapping of early shadow area is implemented by using a single static page table having all entries pointing to the same early shadow page. The shadow area must therefore occupy full PGD entries.
The shadow area has a size of 128MB starting at 0xf8000000. With 4k pages, a PGD entry is 4MB
With 16k pages, a PGD entry is 64MB
With 64k pages, a PGD entry is 1GB which is too big.
Until we rework the early shadow mapping, disable KASAN when the page size is too big.
--- arch/powerpc/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/Kconfig +2 -2
@@ -170,8 +170,8 @@ config PPC select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU select HAVE_ARCH_JUMP_LABEL - select HAVE_ARCH_KASAN if PPC32 - select HAVE_ARCH_KASAN_VMALLOC if PPC32 + select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14 + select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14 select HAVE_ARCH_KGDB select HAVE_ARCH_MMAP_RND_BITS select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
Greg Kroah-Hartman
maintainerPATCH 342/376 powerpc/64s: Dont let DT CPU features set FSCR_DSCR
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 993e3d96fd08c3ebf7566e43be9b8cd622063e6d upstream.
The device tree CPU features binding includes FSCR bit numbers which Linux is instructed to set by firmware.
Whether that's a good idea or not, in the case of the DSCR the Linux implementation has a hard requirement that the FSCR_DSCR bit not be set by default. We use it to track when a process reads/writes to DSCR, so it must be clear to begin with.
So if firmware tells us to set FSCR_DSCR we must ignore it.
Currently this does not cause a bug in our DSCR handling because the value of FSCR that the device tree CPU features code establishes is only used by swapper. All other tasks use the value hard coded in init_task.thread.fscr.
However we'd like to fix that in a future commit, at which point this will become necessary.
--- arch/powerpc/kernel/dt_cpu_ftrs.c | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/powerpc/kernel/dt_cpu_ftrs.c +8 -0
@@ -346,6 +346,14 @@ static int __init feat_enable_dscr(struc {u64 lpcr; +/* +* Linux relies on FSCR[DSCR] being clear, so that we can take the +* facility unavailable interrupt and track the task's usage of DSCR. +* See facility_unavailable_exception(). +* Clear the bit here so that feat_enable() doesn't set it. +*/ + f->fscr_bit_nr =-1 ; +feat_enable (f); lpcr =mfspr (SPRN_LPCR );
Greg Kroah-Hartman
maintainerPATCH 343/376 powerpc/64s: Save FSCR to init_task.thread.fscr after feature init
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 912c0a7f2b5daa3cbb2bc10f303981e493de73bd upstream.
At boot the FSCR is initialised via one of two paths. On most systems it's set to a hard coded value in __init_FSCR().
On newer skiboot systems we use the device tree CPU features binding, where firmware can tell Linux what bits to set in FSCR (and HFSCR).
In both cases the value that's configured at boot is not propagated into the init_task.thread.fscr value prior to the initial fork of init (pid 1), which means the value is not used by any processes other than swapper (the idle task).
For the __init_FSCR() case this is OK, because the value in init_task.thread.fscr is initialised to something sensible. However it does mean that the value set in __init_FSCR() is not used other than for swapper, which is odd and confusing.
The bigger problem is for the device tree CPU features case it prevents firmware from setting (or clearing) FSCR bits for use by user space. This means all existing kernels can not have features enabled/disabled by firmware if those features require setting/clearing FSCR bits.
We can handle both cases by saving the FSCR value into init_task.thread.fscr after we have initialised it at boot. This fixes the bug for device tree CPU features, and will allow us to simplify the initialisation for the __init_FSCR() case in a future patch.
--- arch/powerpc/kernel/prom.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/powerpc/kernel/prom.c +19 -0
@@ -685,6 +685,23 @@ static void __init tm_init(void)static void tm_init (void ) { }#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */ +#ifdef CONFIG_PPC64 +static void __init save_fscr_to_task (void ) +{ +/* +* Ensure the init_task (pid 0, aka swapper) uses the value of FSCR we +* have configured via the device tree features or via __init_FSCR(). +* That value will then be propagated to pid 1 (init) and all future +* processes. +*/ +if (early_cpu_has_feature (CPU_FTR_ARCH_207S )) + init_task.thread.fscr =mfspr (SPRN_FSCR ); +} +#else +static inline void save_fscr_to_task (void ) {}; +#endif + +void __init early_init_devtree (void *params) {phys_addr_t limit;
@@ -773,6 +790,8 @@ void __init early_init_devtree(void *parBUG (); } +save_fscr_to_task (); +#if defined(CONFIG_SMP ) && defined(CONFIG_PPC64 )/* We'll later wait for secondaries to check in; there are * NCPUS-1 non-boot CPUs :-)
Greg Kroah-Hartman
maintainerPATCH 344/376 kbuild: force to build vmlinux if CONFIG_MODVERSION=y
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream.
This code does not work as stated in the comment.
$(CONFIG_MODVERSIONS) is always empty because it is expanded before include/config/auto.conf is included. Hence, 'make modules' with CONFIG_MODVERSION=y cannot record the version CRCs.
This has been broken since 2003, commit ("kbuild: Enable modules to be build using the "make dir/" syntax"). [1]
--- Makefile | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
Makefile +8 -5
@@ -608,12 +608,8 @@ KBUILD_MODULES := KBUILD_BUILTIN := 1 # If we have only "make modules", don't compile built-in objects. -# When we're building modules with modversions, we need to consider -# the built-in objects during the descend as well, in order to -# make sure the checksums are up to date before we record them. - ifeq ($(MAKECMDGOALS),modules) - KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS),1) + KBUILD_BUILTIN := endif # If we have "make <whatever> modules", compile modules
@@ -1315,6 +1311,13 @@ ifdef CONFIG_MODULES all: modules +# When we're building modules with modversions, we need to consider +# the built-in objects during the descend as well, in order to +# make sure the checksums are up to date before we record them. +ifdef CONFIG_MODVERSIONS + KBUILD_BUILTIN := 1 +endif + # Build modules # # A module can be listed more than once in obj-m resulting in
Greg Kroah-Hartman
maintainerPATCH 345/376 virtio-balloon: Disable free page reporting if page poison reporting is not enabled
In reply to Greg Kroah-HartmanFrom: Alexander Duyck <[email protected]>
commit fb69c2c896fc8289b0d9e2c0791472e7cd398bca upstream.
We should disable free page reporting if page poisoning is enabled but we cannot report it via the balloon interface. This way we can avoid the possibility of corrupting guest memory. Normally the page poisoning feature should always be present when free page reporting is enabled on the hypervisor, however this allows us to correctly handle a case of the virtio-balloon device being possibly misconfigured.
--- drivers/virtio/virtio_balloon.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/virtio/virtio_balloon.c +8 -1
@@ -1107,11 +1107,18 @@ static int virtballoon_restore(struct vistatic int virtballoon_validate (struct virtio_device *vdev) { -/* Tell the host whether we care about poisoned pages. */ +/* +* Inform the hypervisor that our pages are poisoned or +* initialized. If we cannot do that then we should disable +* page reporting as it could potentially change the contents +* of our free pages. +*/ if (!want_init_on_free () && (IS_ENABLED (CONFIG_PAGE_POISONING_NO_SANITY ) || !page_poisoning_enabled ()))__virtio_clear_bit (vdev,VIRTIO_BALLOON_F_PAGE_POISON ); +else if (!virtio_has_feature (vdev,VIRTIO_BALLOON_F_PAGE_POISON )) +__virtio_clear_bit (vdev,VIRTIO_BALLOON_F_REPORTING );__virtio_clear_bit (vdev,VIRTIO_F_IOMMU_PLATFORM );return 0 ;
Greg Kroah-Hartman
maintainerPATCH 346/376 sunrpc: svcauth_gss_register_pseudoflavor must reject duplicate registrations.
In reply to Greg Kroah-HartmanFrom: NeilBrown <[email protected]>
commit d47a5dc2888fd1b94adf1553068b8dad76cec96c upstream.
There is no valid case for supporting duplicate pseudoflavor registrations.
Currently the silent acceptance of such registrations is hiding a bug. The rpcsec_gss_krb5 module registers 2 flavours but does not unregister them, so if you load, unload, reload the module, it will happily continue to use the old registration which now has pointers to the memory were the module was originally loaded. This could lead to unexpected results.
So disallow duplicate registrations.
--- net/sunrpc/auth_gss/svcauth_gss.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/sunrpc/auth_gss/svcauth_gss.c +4 -2
@@ -826,9 +826,11 @@ svcauth_gss_register_pseudoflavor(u32 ps new->h.flavour = &svcauthops_gss; new->pseudoflavor = pseudoflavor; - stat =0 ; test =auth_domain_lookup (name, &new->h); -if (test != &new->h) {/* Duplicate registration */ +if (test != &new->h) { +pr_warn ("svc: duplicate registration of gss pseudo flavour %s.\n" , + name); + stat = -EADDRINUSE ;auth_domain_put (test);kfree (new->h.name); goto out_free_dom;
Greg Kroah-Hartman
maintainerPATCH 347/376 sunrpc: clean up properly in gss_mech_unregister()
In reply to Greg Kroah-HartmanFrom: NeilBrown <[email protected]>
commit 24c5efe41c29ee3e55bcf5a1c9f61ca8709622e8 upstream.
gss_mech_register() calls svcauth_gss_register_pseudoflavor() for each flavour, but gss_mech_unregister() does not call auth_domain_put(). This is unbalanced and makes it impossible to reload the module.
Change svcauth_gss_register_pseudoflavor() to return the registered auth_domain, and save it for later release.
--- include/linux/sunrpc/gss_api.h | 1 + include/linux/sunrpc/svcauth_gss.h | 3 ++- net/sunrpc/auth_gss/gss_mech_switch.c | 12 +++++++++--- net/sunrpc/auth_gss/svcauth_gss.c | 12 ++++++------ 4 files changed, 18 insertions(+), 10 deletions(-)
include/linux/sunrpc/gss_api.h +1 -0
@@ -84,6 +84,7 @@ struct pf_desc {u32 service;char *name;char *auth_domain_name; +struct auth_domain *domain;bool datatouch; };
include/linux/sunrpc/svcauth_gss.h +2 -1
@@ -20,7 +20,8 @@ int gss_svc_init(void);void gss_svc_shutdown (void );int gss_svc_init_net (struct net *net);void gss_svc_shutdown_net (struct net *net); -int svcauth_gss_register_pseudoflavor (u32 pseudoflavor,char * name); +struct auth_domain *svcauth_gss_register_pseudoflavor (u32 pseudoflavor, +char *name);u32 svcauth_gss_flavor (struct auth_domain *dom);#endif /* _LINUX_SUNRPC_SVCAUTH_GSS_H */
net/sunrpc/auth_gss/gss_mech_switch.c +9 -3
@@ -37,6 +37,8 @@ gss_mech_free(struct gss_api_mech *gm)for (i =0 ; i < gm->gm_pf_num; i++) { pf = &gm->gm_pfs[i]; +if (pf->domain) +auth_domain_put (pf->domain);kfree (pf->auth_domain_name); pf->auth_domain_name =NULL ; }
@@ -59,6 +61,7 @@ make_auth_domain_name(char *name)static int gss_mech_svc_setup (struct gss_api_mech *gm) { +struct auth_domain *dom;struct pf_desc *pf;int i, status;
@@ -68,10 +71,13 @@ gss_mech_svc_setup(struct gss_api_mech * status = -ENOMEM ;if (pf->auth_domain_name ==NULL ) goto out; - status =svcauth_gss_register_pseudoflavor (pf->pseudoflavor, - pf->auth_domain_name); -if (status) + dom =svcauth_gss_register_pseudoflavor ( + pf->pseudoflavor, pf->auth_domain_name); +if (IS_ERR (dom)) { + status =PTR_ERR (dom); goto out; + } + pf->domain = dom; }return 0 ; out:
net/sunrpc/auth_gss/svcauth_gss.c +6 -6
@@ -809,7 +809,7 @@ u32 svcauth_gss_flavor(struct auth_domaiEXPORT_SYMBOL_GPL (svcauth_gss_flavor); -int +struct auth_domain *svcauth_gss_register_pseudoflavor (u32 pseudoflavor,char * name) {struct gss_domain *new;
@@ -832,17 +832,17 @@ svcauth_gss_register_pseudoflavor(u32 ps name); stat = -EADDRINUSE ;auth_domain_put (test); -kfree (new->h.name); - goto out_free_dom; + goto out_free_name; } -return 0 ; +return test; +out_free_name: +kfree (new->h.name); out_free_dom:kfree (new); out: -return stat; +return ERR_PTR (stat); } -EXPORT_SYMBOL_GPL (svcauth_gss_register_pseudoflavor); static inline int
Greg Kroah-Hartman
maintainerPATCH 348/376 block: nr_sects_write(): Disable preemption on seqcount write
In reply to Greg Kroah-HartmanFrom: Ahmed S. Darwish <[email protected]>
commit 15b81ce5abdc4b502aa31dff2d415b79d2349d2f upstream.
For optimized block readers not holding a mutex, the "number of sectors" 64-bit value is protected from tearing on 32-bit architectures by a sequence counter.
Disable preemption before entering that sequence counter's write side critical section. Otherwise, the read side can preempt the write side section and spin for the entire scheduler tick. If the reader belongs to a real-time scheduling class, it can spin forever and the kernel will livelock.
--- block/blk.h | 2 ++ 1 file changed, 2 insertions(+)
block/blk.h +2 -0
@@ -470,9 +470,11 @@ static inline sector_t part_nr_sects_reastatic inline void part_nr_sects_write (struct hd_struct *part,sector_t size) {#if BITS_PER_LONG ==32 && defined(CONFIG_SMP ) +preempt_disable ();write_seqcount_begin (&part->nr_sects_seq); part->nr_sects = size;write_seqcount_end (&part->nr_sects_seq); +preempt_enable ();#elif BITS_PER_LONG ==32 && defined(CONFIG_PREEMPTION )preempt_disable (); part->nr_sects = size;
Greg Kroah-Hartman
maintainerPATCH 349/376 RISC-V: Dont mark init section as non-executable
In reply to Greg Kroah-HartmanFrom: Anup Patel <[email protected]>
commit 4e0f9e3a6104261f25b16fcab02fc96f5666ba11 upstream.
The head text section (i.e. _start, secondary_start_sbi, etc) and the init section fall under same page table level-1 mapping.
Currently, the runtime CPU hotplug is broken because we are marking init section as non-executable which in-turn marks head text section as non-executable.
Further investigating other architectures, it seems marking the init section as non-executable is redundant because the init section pages are anyway poisoned and freed.
To fix broken runtime CPU hotplug, we simply remove the code marking the init section as non-executable.
--- arch/riscv/mm/init.c | 11 ----------- 1 file changed, 11 deletions(-)
arch/riscv/mm/init.c +0 -11
@@ -479,17 +479,6 @@ static void __init setup_vm_final(void)csr_write (CSR_SATP ,PFN_DOWN (__pa_symbol (swapper_pg_dir)) |SATP_MODE );local_flush_tlb_all (); } - -void free_initmem (void ) -{ -unsigned long init_begin = (unsigned long )__init_begin; -unsigned long init_end = (unsigned long )__init_end; - -/* Make the region as non-execuatble. */ -set_memory_nx (init_begin, (init_end - init_begin) >>PAGE_SHIFT ); -free_initmem_default (POISON_FREE_INITMEM ); -} -#else asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
Greg Kroah-Hartman
maintainerPATCH 350/376 pwm: lpss: Fix get_state runtime-pm reference handling
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 01aa905d4791da7d3630f6030ff99d58105cca00 upstream.
Before commit cfc4c189bc70 ("pwm: Read initial hardware state at request time"), a driver's get_state callback would get called once per PWM from pwmchip_add().
pwm-lpss' runtime-pm code was relying on this, getting a runtime-pm ref for PWMs which are enabled at probe time from within its get_state callback, before enabling runtime-pm.
The change to calling get_state at request time causes a number of problems:
1. PWMs enabled at probe time may get runtime suspended before they are requested, causing e.g. a LCD backlight controlled by the PWM to turn off.
2. When the request happens when the PWM has been runtime suspended, the ctrl register will read all 1 / 0xffffffff, causing get_state to store bogus values in the pwm_state.
3. get_state was using an async pm_runtime_get() call, because it assumed that runtime-pm has not been enabled yet. If shortly after the request an apply call is made, then the pwm_lpss_is_updating() check may trigger because the resume triggered by the pm_runtime_get() call is not complete yet, so the ctrl register still reads all 1 / 0xffffffff.
This commit fixes these issues by moving the initial pm_runtime_get() call for PWMs which are enabled at probe time to the pwm_lpss_probe() function; and by making get_state take a runtime-pm ref before reading the ctrl reg.
--- drivers/pwm/pwm-lpss.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/pwm/pwm-lpss.c +11 -4
@@ -158,7 +158,6 @@ static int pwm_lpss_apply(struct pwm_chireturn 0 ; } -/* This function gets called once from pwmchip_add to get the initial state */ static void pwm_lpss_get_state (struct pwm_chip *chip,struct pwm_device *pwm,struct pwm_state *state) {
@@ -167,6 +166,8 @@ static void pwm_lpss_get_state(struct pwunsigned long long base_unit, freq, on_time_div;u32 ctrl; +pm_runtime_get_sync (chip->dev); + base_unit_range =BIT (lpwm->info->base_unit_bits); ctrl =pwm_lpss_read (pwm);
@@ -187,8 +188,7 @@ static void pwm_lpss_get_state(struct pw state->polarity =PWM_POLARITY_NORMAL ; state->enabled = !!(ctrl &PWM_ENABLE ); -if (state->enabled) -pm_runtime_get (chip->dev); +pm_runtime_put (chip->dev); }static const struct pwm_ops pwm_lpss_ops = {
@@ -202,7 +202,8 @@ struct pwm_lpss_chip *pwm_lpss_probe(str {struct pwm_lpss_chip *lpwm;unsigned long c; -int ret; +int i, ret; +u32 ctrl;if (WARN_ON (info->npwm >MAX_PWMS ))return ERR_PTR (-ENODEV );
@@ -232,6 +233,12 @@ struct pwm_lpss_chip *pwm_lpss_probe(strreturn ERR_PTR (ret); } +for (i =0 ; i < lpwm->info->npwm; i++) { + ctrl =pwm_lpss_read (&lpwm->chip.pwms[i]); +if (ctrl &PWM_ENABLE ) +pm_runtime_get (dev); + } +return lpwm; }EXPORT_SYMBOL_GPL (pwm_lpss_probe);
Greg Kroah-Hartman
maintainerPATCH 351/376 pwm: jz4740: Enhance precision in calculation of duty cycle
In reply to Greg Kroah-HartmanFrom: Paul Cercueil <[email protected]>
commit 9017dc4fbd59c09463019ce494cfe36d654495a8 upstream.
Calculating the hardware value for the duty from the hardware value of the period resulted in a precision loss versus calculating it from the clock rate directly.
(Also remove a cast that doesn't really need to be here)
--- drivers/pwm/pwm-jz4740.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/pwm/pwm-jz4740.c +3 -3
@@ -158,11 +158,11 @@ static int jz4740_pwm_apply(struct pwm_c/* Calculate period value */ tmp = (unsigned long long )rate * state->period;do_div (tmp,NSEC_PER_SEC ); - period = (unsigned long )tmp; + period = tmp;/* Calculate duty value */ - tmp = (unsigned long long )period * state->duty_cycle; -do_div (tmp, state->period); + tmp = (unsigned long long )rate * state->duty_cycle; +do_div (tmp,NSEC_PER_SEC ); duty = period - tmp;if (duty >= period)
Greg Kroah-Hartman
maintainerPATCH 352/376 mtd: rawnand: Fix nand_gpio_waitrdy()
In reply to Greg Kroah-HartmanFrom: Boris Brezillon <[email protected]>
commit e45a4b652dbd2f8b5a3b8e97e89f602a58cb28aa upstream.
Mimic what's done in nand_soft_waitrdy() and add one to the jiffies timeout so we don't end up waiting less than actually required.
--- drivers/mtd/nand/raw/nand_base.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/nand_base.c +8 -2
@@ -736,8 +736,14 @@ EXPORT_SYMBOL_GPL(nand_soft_waitrdy);int nand_gpio_waitrdy (struct nand_chip *chip,struct gpio_desc *gpiod,unsigned long timeout_ms) { -/* Wait until R/B pin indicates chip is ready or timeout occurs */ - timeout_ms = jiffies +msecs_to_jiffies (timeout_ms); + +/* +* Wait until R/B pin indicates chip is ready or timeout occurs. +* +1 below is necessary because if we are now in the last fraction +* of jiffy and msecs_to_jiffies is 1 then we will wait only that +* small jiffy fraction - possibly leading to false timeout. +*/ + timeout_ms = jiffies +msecs_to_jiffies (timeout_ms) +1 ; do { if (gpiod_get_value_cansleep(gpiod)) return 0;
Greg Kroah-Hartman
maintainerPATCH 353/376 mtd: rawnand: onfi: Fix redundancy detection check
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 1d5d08ee9b28cff907326b4ad5a2463fd2808be1 upstream.
During ONFI detection, the CRC derived from the parameter page and the CRC supposed to be at the end of the parameter page are compared. If they do not match, the second then the third copies of the page are tried.
The current implementation compares the newly derived CRC with the CRC contained in the first page only. So if this particular CRC area has been corrupted, then the detection will fail for a wrong reason.
Fix this issue by checking the derived CRC against the right one.
--- drivers/mtd/nand/raw/nand_onfi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/nand_onfi.c +1 -1
@@ -173,7 +173,7 @@ int nand_onfi_detect(struct nand_chip *c }if (onfi_crc16 (ONFI_CRC_BASE , (u8 *)&p[i],254 ) == -le16_to_cpu (p->crc)) { +le16_to_cpu (p[i].crc)) {if (i)memcpy (p, &p[i],sizeof (*p));break ;
Greg Kroah-Hartman
maintainerPATCH 354/376 mtd: rawnand: brcmnand: fix hamming oob layout
In reply to Greg Kroah-HartmanFrom: Álvaro Fernández Rojas <[email protected]>
commit 130bbde4809b011faf64f99dddc14b4b01f440c3 upstream.
First 2 bytes are used in large-page nand.
--- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/mtd/nand/raw/brcmnand/brcmnand.c +7 -4
@@ -1116,11 +1116,14 @@ static int brcmnand_hamming_ooblayout_frif (!section) {/* * Small-page NAND use byte 6 for BBI while large-page -* NAND use byte 0. +* NAND use bytes 0 and 1. */ -if (cfg->page_size >512 ) - oobregion->offset++; - oobregion->length--; +if (cfg->page_size >512 ) { + oobregion->offset +=2 ; + oobregion->length -=2 ; + }else { + oobregion->length--; + } } }
Greg Kroah-Hartman
maintainerPATCH 355/376 mtd: rawnand: diskonchip: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit c5be12e45940f1aa1b5dfa04db5d15ad24f7c896 upstream.
Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment.
There is no Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if it did not intruce
any bug.
--- drivers/mtd/nand/raw/diskonchip.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
drivers/mtd/nand/raw/diskonchip.c +2 -5
@@ -1609,13 +1609,10 @@ static int __init doc_probe(unsigned lon numchips =doc2001_init (mtd);if ((ret =nand_scan (nand, numchips)) || (ret = doc->late_init (mtd))) { -/* DBB note: i believe nand_release is necessary here, as +/* DBB note: i believe nand_cleanup is necessary here, as buffers may have been allocated in nand_base. Check with Thomas. FIX ME! */ -/* nand_release will call mtd_device_unregister, but we -haven't yet added it. This is handled without incident by -mtd_device_unregister, as far as I can tell. */ -nand_release (nand); +nand_cleanup (nand); goto fail; }
Greg Kroah-Hartman
maintainerPATCH 356/376 mtd: rawnand: sharpsl: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 0f44b3275b3798ccb97a2f51ac85871c30d6fbbc upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense.
--- drivers/mtd/nand/raw/sharpsl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/sharpsl.c +1 -1
@@ -183,7 +183,7 @@ static int sharpsl_nand_probe(struct plareturn 0 ; err_add: -nand_release (this); +nand_cleanup (this); err_scan:iounmap (sharpsl->io);
Greg Kroah-Hartman
maintainerPATCH 357/376 mtd: rawnand: ingenic: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit de17cade0e034e9b721a6db9b488014effac1e5a upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. Hence, pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug makes sense.
--- drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c +1 -1
@@ -376,7 +376,7 @@ static int ingenic_nand_init_chip(struct ret =mtd_device_register (mtd,NULL ,0 );if (ret) { -nand_release (chip); +nand_cleanup (chip);return ret; }
Greg Kroah-Hartman
maintainerPATCH 358/376 mtd: rawnand: xway: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 34531be5e804a8e1abf314a6c3a19fe342e4a154 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not introducing any bug.
--- drivers/mtd/nand/raw/xway_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/xway_nand.c +1 -1
@@ -210,7 +210,7 @@ static int xway_nand_probe(struct platfo err =mtd_device_register (mtd,NULL ,0 );if (err) -nand_release (&data->chip); +nand_cleanup (&data->chip);return err; }
Greg Kroah-Hartman
maintainerPATCH 359/376 mtd: rawnand: orion: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit be238fbf78e4c7c586dac235ab967d3e565a4d1a upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not introducing any bug.
--- drivers/mtd/nand/raw/orion_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/orion_nand.c +1 -1
@@ -180,7 +180,7 @@ static int __init orion_nand_probe(struc mtd->name ="orion_nand" ; ret =mtd_device_register (mtd, board->parts, board->nr_parts);if (ret) { -nand_release (nc); +nand_cleanup (nc); goto no_dev; }
Greg Kroah-Hartman
maintainerPATCH 360/376 mtd: rawnand: socrates: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 9c6c2e5cc77119ce0dacb4f9feedb73ce0354421 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not introducing any bug.
--- drivers/mtd/nand/raw/socrates_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/socrates_nand.c +1 -1
@@ -169,7 +169,7 @@ static int socrates_nand_probe(struct plif (!res)return res; -nand_release (nand_chip); +nand_cleanup (nand_chip); out:iounmap (host->io_base);
Greg Kroah-Hartman
maintainerPATCH 361/376 mtd: rawnand: oxnas: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 154298e2a3f6c9ce1d76cdb48d89fd5b107ea1a3 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
While at it, be consistent and move the function call in the error path thanks to a goto statement.
--- drivers/mtd/nand/raw/oxnas_nand.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mtd/nand/raw/oxnas_nand.c +4 -4
@@ -140,10 +140,8 @@ static int oxnas_nand_probe(struct platf goto err_release_child; err =mtd_device_register (mtd,NULL ,0 ); -if (err) { -nand_release (chip); - goto err_release_child; - } +if (err) + goto err_cleanup_nand; oxnas->chips[nchips] = chip; ++nchips;
@@ -159,6 +157,8 @@ static int oxnas_nand_probe(struct platfreturn 0 ; +err_cleanup_nand: +nand_cleanup (chip); err_release_child:of_node_put (nand_np); err_clk_unprepare:
Greg Kroah-Hartman
maintainerPATCH 362/376 mtd: rawnand: sunxi: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 3d84515ffd8fb657e10fa5b1215e9f095fa7efca upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
--- drivers/mtd/nand/raw/sunxi_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/sunxi_nand.c +1 -1
@@ -2003,7 +2003,7 @@ static int sunxi_nand_chip_init(struct d ret =mtd_device_register (mtd,NULL ,0 );if (ret) {dev_err (dev,"failed to register mtd device: %d\n" , ret); -nand_release (nand); +nand_cleanup (nand);return ret; }
Greg Kroah-Hartman
maintainerPATCH 363/376 mtd: rawnand: plat_nand: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
--- drivers/mtd/nand/raw/plat_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/plat_nand.c +1 -1
@@ -92,7 +92,7 @@ static int plat_nand_probe(struct platfoif (!err)return err; -nand_release (&data->chip); +nand_cleanup (&data->chip); out:if (pdata->ctrl.remove) pdata->ctrl.remove (pdev);
Greg Kroah-Hartman
maintainerPATCH 364/376 mtd: rawnand: pasemi: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit f51466901c07e6930435d30b02a21f0841174f61 upstream.
nand_cleanup() is supposed to be called on error after a successful call to nand_scan() to free all NAND resources.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
--- drivers/mtd/nand/raw/pasemi_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/nand/raw/pasemi_nand.c +3 -1
@@ -146,7 +146,7 @@ static int pasemi_nand_probe(struct platif (mtd_device_register (pasemi_nand_mtd,NULL ,0 )) {dev_err (dev,"Unable to register MTD device\n" ); err = -ENODEV ; - goto out_lpc; + goto out_cleanup_nand; } dev_info(dev, "PA Semi NAND flash at %pR, control at I/O %x\n", &res,
@@ -154,6 +154,8 @@ static int pasemi_nand_probe(struct platreturn 0 ; + out_cleanup_nand: +nand_cleanup (chip); out_lpc:release_region (lpcctl,4 ); out_ior:
Greg Kroah-Hartman
maintainerPATCH 365/376 mtd: rawnand: mtk: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 8a82bbcadec877f5f938c54026278dfc1f05a332 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not introducing any bug.
--- drivers/mtd/nand/raw/mtk_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/mtk_nand.c +1 -1
@@ -1419,7 +1419,7 @@ static int mtk_nfc_nand_chip_init(struct ret =mtd_device_register (mtd,NULL ,0 );if (ret) {dev_err (dev,"mtd parse partition error\n" ); -nand_release (nand); +nand_cleanup (nand);return ret; }
Greg Kroah-Hartman
maintainerPATCH 366/376 mtd: rawnand: tmio: Fix the probe error path
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 75e9a330a9bd48f97a55a08000236084fe3dae56 upstream.
nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not introducing any bug.
--- drivers/mtd/nand/raw/tmio_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/raw/tmio_nand.c +1 -1
@@ -448,7 +448,7 @@ static int tmio_probe(struct platform_deif (!retval)return retval; -nand_release (nand_chip); +nand_cleanup (nand_chip); err_irq:tmio_hw_stop (dev, tmio);
Greg Kroah-Hartman
maintainerPATCH 367/376 w1: omap-hdq: cleanup to add missing newline for some dev_dbg
In reply to Greg Kroah-HartmanFrom: H. Nikolaus Schaller <[email protected]>
commit 5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream.
Otherwise it will corrupt the console log during debugging.
--- drivers/w1/masters/omap_hdq.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/w1/masters/omap_hdq.c +5 -5
@@ -155,7 +155,7 @@ static int hdq_write_byte(struct hdq_dat/* check irqstatus */ if (!(*status &OMAP_HDQ_INT_STATUS_TXCOMPLETE )) {dev_dbg (hdq_data->dev,"timeout waiting for" -" TXCOMPLETE/RXCOMPLETE, %x" , *status); +" TXCOMPLETE/RXCOMPLETE, %x\n" , *status); ret = -ETIMEDOUT ; goto out; }
@@ -166,7 +166,7 @@ static int hdq_write_byte(struct hdq_dat OMAP_HDQ_FLAG_CLEAR, &tmp_status);if (ret) {dev_dbg (hdq_data->dev,"timeout waiting GO bit" -" return to zero, %x" , tmp_status); +" return to zero, %x\n" , tmp_status); } out:
@@ -183,7 +183,7 @@ static irqreturn_t hdq_isr(int irq, voidspin_lock_irqsave (&hdq_data->hdq_spinlock, irqflags); hdq_data->hdq_irqstatus =hdq_reg_in (hdq_data,OMAP_HDQ_INT_STATUS );spin_unlock_irqrestore (&hdq_data->hdq_spinlock, irqflags); -dev_dbg (hdq_data->dev,"hdq_isr: %x" , hdq_data->hdq_irqstatus); +dev_dbg (hdq_data->dev,"hdq_isr: %x\n" , hdq_data->hdq_irqstatus); if (hdq_data->hdq_irqstatus & (OMAP_HDQ_INT_STATUS_TXCOMPLETE | OMAP_HDQ_INT_STATUS_RXCOMPLETE
@@ -248,7 +248,7 @@ static int omap_hdq_break(struct hdq_dat tmp_status = hdq_data->hdq_irqstatus;/* check irqstatus */ if (!(tmp_status &OMAP_HDQ_INT_STATUS_TIMEOUT )) { -dev_dbg (hdq_data->dev,"timeout waiting for TIMEOUT, %x" , +dev_dbg (hdq_data->dev,"timeout waiting for TIMEOUT, %x\n" , tmp_status); ret = -ETIMEDOUT ; goto out;
@@ -275,7 +275,7 @@ static int omap_hdq_break(struct hdq_dat &tmp_status);if (ret)dev_dbg (hdq_data->dev,"timeout waiting INIT&GO bits" -" return to zero, %x" , tmp_status); +" return to zero, %x\n" , tmp_status); out:hdq_reset_irqstatus (hdq_data);
Greg Kroah-Hartman
maintainerPATCH 368/376 w1: omap-hdq: fix return value to be -1 if there is a timeout
In reply to Greg Kroah-HartmanFrom: H. Nikolaus Schaller <[email protected]>
commit 2d4100632fa1947bf3e8d7a091e94e2cf21923af upstream.
omap_w1_read_byte() should return -1 (or 0xff) in case of error (e.g. missing battery).
The code accidentially overwrites the variable ret and not val, which is returned. So it will return the initial value 0 instead of -1.
--- drivers/w1/masters/omap_hdq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/w1/masters/omap_hdq.c +1 -1
@@ -464,7 +464,7 @@ static u8 omap_w1_read_byte(void *_hdq) ret =hdq_read_byte (hdq_data, &val);if (ret) - ret =-1 ; + val =-1 ;pm_runtime_mark_last_busy (hdq_data->dev);pm_runtime_put_autosuspend (hdq_data->dev);
Greg Kroah-Hartman
maintainerPATCH 369/376 w1: omap-hdq: fix interrupt handling which did show spurious timeouts
In reply to Greg Kroah-HartmanFrom: H. Nikolaus Schaller <[email protected]>
commit 13db4c40fe0b20b80c7d1c91a9da8411e26b5c27 upstream.
Since
commit 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")
was applied,
I did see timeouts and wrong values when reading a bq27000 connected to hdq of the omap3. This occurred mainly after boot but remained and only sometimes settled down after several reads.
root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=0 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CAPACITY=0 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=-2731 POWER_SUPPLY_TIME_TO_EMPTY_NOW=0 POWER_SUPPLY_TIME_TO_EMPTY_AVG=0 POWER_SUPPLY_TIME_TO_FULL_NOW=0 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=0 POWER_SUPPLY_CHARGE_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=0 POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_ENERGY_NOW=0 POWER_SUPPLY_POWER_AVG=0 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments
real 0m15.761s
user 0m0.001s
sys 0m0.025s
root@letux:~#
Sometimes the effect did disappear after accessing the device multiple times, speed went up and results became correct.
All this indicates that some interrupts from the hdq controller are lost by the driver.
Enabling debugging revealed that there were spurious tx and rx timeouts, i.e. the driver does not always recognise interrupts. The main problem is that rx and tx interrupts share a single variable which was sometimes reset to 0 wiping out other interrupts. And it was overwritten by a second interrupt, independent of whether the previous interrupt was already processed or not.
This patch improves interrupt handling to avoid such races and loss of interrupt flags.
The ideas are:
* only the hdq_isr() sets bits in hdq_status
* it does not reset any bits
* it does wake_up() if any interrupt is pending
* bits are only reset by the read/write/break functions if they were waited for
* this makes sure that no interrupts can be lost
* rx/tx/timeout bits are completely decoupled from each other (and not reset all after waiting for any of them)
* which bits to reset is now specified by a new parameter to hdq_reset_irqstatus()
* hdq_reset_irqstatus() also returns the state before resetting so that we can encapsulate the spinlock
* this should now handle the case that the write and read are both already finished quickly before the hdq_write_byte() ends.
* Or that two interrupts occur in succession before they are processed by the driver.
Old code may have reset all status bits making the next hdq_read_byte() timeout.
* the spinlock now always protects changing of bits in function hdq_reset_irqstatus() which could become a read-write-modify problem if the interrupt handler tries to read-modify-write exactly at the same moment
* we add mutex protection also for hdq_write_byte() just to be safe to not to disturb a hdq_read_byte() triggered by some other thread/process.
This patch was tested on a GTA04 and results in no boot problems any more. And first read after boot is now ok:
root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=3970000 POWER_SUPPLY_CURRENT_NOW=354144 POWER_SUPPLY_CAPACITY=82 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=266 POWER_SUPPLY_TIME_TO_EMPTY_NOW=7680 POWER_SUPPLY_TIME_TO_EMPTY_AVG=7380 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=934856 POWER_SUPPLY_CHARGE_NOW=763976 POWER_SUPPLY_CHARGE_FULL_DESIGN=1233792 POWER_SUPPLY_CYCLE_COUNT=82 POWER_SUPPLY_ENERGY_NOW=2852840 POWER_SUPPLY_POWER_AVG=1392840 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments
real 0m0.233s user 0m0.000s sys 0m0.025s
root@letux:~#
It was also tested with dev_dbg enabled and more printk that all activities behave correctly, especially hdq_write_byte(), hdq_read_byte(), omap_hdq_break().
Not tested is omap_w1_triplet().
--- drivers/w1/masters/omap_hdq.c | 62 ++++++++++++++++++++++++++++-------------- 1 file changed, 42 insertions(+), 20 deletions(-)
drivers/w1/masters/omap_hdq.c +42 -20
@@ -54,10 +54,10 @@ MODULE_PARM_DESC(w1_id, "1-wire id for tstruct hdq_data {struct device *dev;void __iomem *hdq_base; -/* lock status update */ +/* lock read/write/break operations */ struct mutex hdq_mutex; +/* interrupt status and a lock for it */ u8 hdq_irqstatus; -/* device lock */ spinlock_t hdq_spinlock;/* mode: 0-HDQ 1-W1 */ int mode;
@@ -120,13 +120,18 @@ static int hdq_wait_for_flag(struct hdq_ }/* Clear saved irqstatus after using an interrupt */ -static void hdq_reset_irqstatus (struct hdq_data *hdq_data) +static u8 hdq_reset_irqstatus (struct hdq_data *hdq_data,u8 bits) {unsigned long irqflags; +u8 status;spin_lock_irqsave (&hdq_data->hdq_spinlock, irqflags); - hdq_data->hdq_irqstatus =0 ; + status = hdq_data->hdq_irqstatus; +/* this is a read-modify-write */ + hdq_data->hdq_irqstatus &= ~bits;spin_unlock_irqrestore (&hdq_data->hdq_spinlock, irqflags); + +return status; }/* write out a byte and fill *status with HDQ_INT_STATUS */
@@ -135,6 +140,12 @@ static int hdq_write_byte(struct hdq_datint ret;u8 tmp_status; + ret =mutex_lock_interruptible (&hdq_data->hdq_mutex); +if (ret <0 ) { + ret = -EINTR ; + goto rtn; + } + *status =0 ;hdq_reg_out (hdq_data,OMAP_HDQ_TX_DATA , val);
@@ -144,14 +155,15 @@ static int hdq_write_byte(struct hdq_dat OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO);/* wait for the TXCOMPLETE bit */ ret =wait_event_timeout (hdq_wait_queue, - hdq_data->hdq_irqstatus,OMAP_HDQ_TIMEOUT ); + (hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_TXCOMPLETE ), +OMAP_HDQ_TIMEOUT ); + *status =hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_TXCOMPLETE );if (ret ==0 ) {dev_dbg (hdq_data->dev,"TX wait elapsed\n" ); ret = -ETIMEDOUT ; goto out; } - *status = hdq_data->hdq_irqstatus;/* check irqstatus */ if (!(*status &OMAP_HDQ_INT_STATUS_TXCOMPLETE )) { dev_dbg(hdq_data->dev, "timeout waiting for"
@@ -170,7 +182,8 @@ static int hdq_write_byte(struct hdq_dat } out: -hdq_reset_irqstatus (hdq_data); +mutex_unlock (&hdq_data->hdq_mutex); +rtn:return ret; }
@@ -181,7 +194,7 @@ static irqreturn_t hdq_isr(int irq, voidunsigned long irqflags;spin_lock_irqsave (&hdq_data->hdq_spinlock, irqflags); - hdq_data->hdq_irqstatus =hdq_reg_in (hdq_data,OMAP_HDQ_INT_STATUS ); + hdq_data->hdq_irqstatus |=hdq_reg_in (hdq_data,OMAP_HDQ_INT_STATUS );spin_unlock_irqrestore (&hdq_data->hdq_spinlock, irqflags);dev_dbg (hdq_data->dev,"hdq_isr: %x\n" , hdq_data->hdq_irqstatus);
@@ -238,18 +251,19 @@ static int omap_hdq_break(struct hdq_dat/* wait for the TIMEOUT bit */ ret =wait_event_timeout (hdq_wait_queue, - hdq_data->hdq_irqstatus,OMAP_HDQ_TIMEOUT ); + (hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_TIMEOUT ), +OMAP_HDQ_TIMEOUT ); + tmp_status =hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_TIMEOUT );if (ret ==0 ) {dev_dbg (hdq_data->dev,"break wait elapsed\n" ); ret = -EINTR ; goto out; } - tmp_status = hdq_data->hdq_irqstatus;/* check irqstatus */ if (!(tmp_status &OMAP_HDQ_INT_STATUS_TIMEOUT )) {dev_dbg (hdq_data->dev,"timeout waiting for TIMEOUT, %x\n" , - tmp_status); + tmp_status); ret = -ETIMEDOUT ; goto out; }
@@ -278,7 +292,6 @@ static int omap_hdq_break(struct hdq_dat " return to zero, %x\n", tmp_status); out: -hdq_reset_irqstatus (hdq_data);mutex_unlock (&hdq_data->hdq_mutex); rtn:return ret;
@@ -309,12 +322,15 @@ static int hdq_read_byte(struct hdq_data*/ wait_event_timeout (hdq_wait_queue, (hdq_data->hdq_irqstatus - &OMAP_HDQ_INT_STATUS_RXCOMPLETE ), + & (OMAP_HDQ_INT_STATUS_RXCOMPLETE | +OMAP_HDQ_INT_STATUS_TIMEOUT )),OMAP_HDQ_TIMEOUT ); - + status =hdq_reset_irqstatus (hdq_data, +OMAP_HDQ_INT_STATUS_RXCOMPLETE | +OMAP_HDQ_INT_STATUS_TIMEOUT );hdq_reg_merge (hdq_data,OMAP_HDQ_CTRL_STATUS ,0 ,OMAP_HDQ_CTRL_STATUS_DIR ); - status = hdq_data->hdq_irqstatus; +/* check irqstatus */ if (!(status &OMAP_HDQ_INT_STATUS_RXCOMPLETE )) { dev_dbg(hdq_data->dev, "timeout waiting for"
@@ -322,11 +338,12 @@ static int hdq_read_byte(struct hdq_data ret = -ETIMEDOUT ; goto out; } + }else {/* interrupt had occurred before hdq_read_byte was called */ +hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_RXCOMPLETE ); }/* the data is ready. Read it in! */ *val =hdq_reg_in (hdq_data,OMAP_HDQ_RX_DATA ); out: -hdq_reset_irqstatus (hdq_data);mutex_unlock (&hdq_data->hdq_mutex); rtn:return ret;
@@ -367,15 +384,15 @@ static u8 omap_w1_triplet(void *_hdq, u8 (hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_RXCOMPLETE ), OMAP_HDQ_TIMEOUT); +/* Must clear irqstatus for another RXCOMPLETE interrupt */ +hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_RXCOMPLETE ); +if (err ==0 ) {dev_dbg (hdq_data->dev,"RX wait elapsed\n" ); goto out; } id_bit = (hdq_reg_in (_hdq,OMAP_HDQ_RX_DATA ) &0x01 ); -/* Must clear irqstatus for another RXCOMPLETE interrupt */ -hdq_reset_irqstatus (hdq_data); -/* read comp_bit */ hdq_reg_merge (_hdq,OMAP_HDQ_CTRL_STATUS , ctrl |OMAP_HDQ_CTRL_STATUS_DIR , mask);
@@ -383,6 +400,9 @@ static u8 omap_w1_triplet(void *_hdq, u8 (hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_RXCOMPLETE ), OMAP_HDQ_TIMEOUT); +/* Must clear irqstatus for another RXCOMPLETE interrupt */ +hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_RXCOMPLETE ); +if (err ==0 ) {dev_dbg (hdq_data->dev,"RX wait elapsed\n" ); goto out;
@@ -409,6 +429,9 @@ static u8 omap_w1_triplet(void *_hdq, u8 (hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_TXCOMPLETE ), OMAP_HDQ_TIMEOUT); +/* Must clear irqstatus for another TXCOMPLETE interrupt */ +hdq_reset_irqstatus (hdq_data,OMAP_HDQ_INT_STATUS_TXCOMPLETE ); +if (err ==0 ) {dev_dbg (hdq_data->dev,"TX wait elapsed\n" ); goto out;
@@ -418,7 +441,6 @@ static u8 omap_w1_triplet(void *_hdq, u8 OMAP_HDQ_CTRL_STATUS_SINGLE); out: -hdq_reset_irqstatus (hdq_data);mutex_unlock (&hdq_data->hdq_mutex); rtn:pm_runtime_mark_last_busy (hdq_data->dev);
Greg Kroah-Hartman
maintainerPATCH 370/376 f2fs: dont leak filename in f2fs_try_convert_inline_dir()
In reply to Greg Kroah-HartmanFrom: Eric Biggers <[email protected]>
commit ff5f85c8d62a487bde415ef4c9e2d0be718021df upstream.
We need to call fscrypt_free_filename() to free the memory allocated by fscrypt_setup_filename().
--- fs/f2fs/inline.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/f2fs/inline.c +4 -2
@@ -559,12 +559,12 @@ int f2fs_try_convert_inline_dir(struct i ipage =f2fs_get_node_page (sbi, dir->i_ino);if (IS_ERR (ipage)) { err =PTR_ERR (ipage); - goto out; + goto out_fname; }if (f2fs_has_enough_room (dir, ipage, &fname)) {f2fs_put_page (ipage,1 ); - goto out; + goto out_fname; } inline_dentry =inline_data_addr (dir, ipage);
@@ -572,6 +572,8 @@ int f2fs_try_convert_inline_dir(struct i err =do_convert_inline_dir (dir, ipage, inline_dentry);if (!err)f2fs_put_page (ipage,1 ); +out_fname: +fscrypt_free_filename (&fname); out:f2fs_unlock_op (sbi);return err;
Greg Kroah-Hartman
maintainerPATCH 371/376 f2fs: fix checkpoint=disable:%u%%
In reply to Greg Kroah-HartmanFrom: Jaegeuk Kim <[email protected]>
commit 1ae18f71cb522684bac1718f5c188fb5e30eb23d upstream.
When parsing the mount option, we don't have sbi->user_block_count. Should do it after getting it.
--- fs/f2fs/f2fs.h | 1 + fs/f2fs/super.c | 25 +++++++++++++++++++------ 2 files changed, 20 insertions(+), 6 deletions(-)
fs/f2fs/f2fs.h +1 -0
@@ -139,6 +139,7 @@ struct f2fs_mount_info {int fs_mode;/* fs mode: LFS or ADAPTIVE */ int bggc_mode;/* bggc mode: off, on or sync */ bool test_dummy_encryption;/* test dummy encryption */ +block_t unusable_cap_perc;/* percentage for cap */ block_t unusable_cap;/* Amount of space allowed to be * unusable when disabling checkpoint */
fs/f2fs/super.c +19 -6
@@ -284,6 +284,22 @@ static inline void limit_reserve_root(st F2FS_OPTION(sbi).s_resgid)); } +static inline void adjust_unusable_cap_perc (struct f2fs_sb_info *sbi) +{ +if (!F2FS_OPTION (sbi).unusable_cap_perc) +return ; + +if (F2FS_OPTION (sbi).unusable_cap_perc ==100 ) +F2FS_OPTION (sbi).unusable_cap = sbi->user_block_count; +else +F2FS_OPTION (sbi).unusable_cap = (sbi->user_block_count /100 ) * +F2FS_OPTION (sbi).unusable_cap_perc; + +f2fs_info (sbi,"Adjust unusable cap for checkpoint=disable = %u / %u%%" , +F2FS_OPTION (sbi).unusable_cap, +F2FS_OPTION (sbi).unusable_cap_perc); +} +static void init_once (void *foo) {struct f2fs_inode_info *fi = (struct f2fs_inode_info *) foo;
@@ -795,12 +811,7 @@ static int parse_options(struct super_blreturn -EINVAL ;if (arg <0 || arg >100 )return -EINVAL ; -if (arg ==100 ) -F2FS_OPTION (sbi).unusable_cap = - sbi->user_block_count; -else -F2FS_OPTION (sbi).unusable_cap = - (sbi->user_block_count /100 ) * arg; +F2FS_OPTION (sbi).unusable_cap_perc = arg;set_opt (sbi,DISABLE_CHECKPOINT );break ;case Opt_checkpoint_disable_cap:
@@ -1845,6 +1856,7 @@ skip: (test_opt (sbi,POSIX_ACL ) ?SB_POSIXACL :0 );limit_reserve_root (sbi); +adjust_unusable_cap_perc (sbi); *flags = (*flags & ~SB_LAZYTIME ) | (sb->s_flags &SB_LAZYTIME );return 0 ; restore_gc:
@@ -3521,6 +3533,7 @@ try_onemore: sbi->reserved_blocks =0 ; sbi->current_reserved_blocks =0 ;limit_reserve_root (sbi); +adjust_unusable_cap_perc (sbi);for (i =0 ; i <NR_INODE_TYPE ; i++) {INIT_LIST_HEAD (&sbi->inode_list[i]);
Greg Kroah-Hartman
maintainerPATCH 372/376 perf probe: Do not show the skipped events
In reply to Greg Kroah-HartmanFrom: Masami Hiramatsu <[email protected]>
commit f41ebe9defacddeae96a872a33f0f22ced0bfcef upstream.
When a probe point is expanded to several places (like inlined) and if some of them are skipped because of blacklisted or __init function, those trace_events has no event name. It must be skipped while showing results.
Without this fix, you can see "(null):(null)" on the list,
# ./perf probe request_resource
reserve_setup is out of .text, skip it.
Added new events:
(null):(null) (on request_resource)
probe:request_resource (on request_resource)You can now use it in all perf tools, such as:
perf record -e probe:request_resource -aR sleep 1
#
With this fix, it is ignored:
# ./perf probe request_resource
reserve_setup is out of .text, skip it.
Added new events:
probe:request_resource (on request_resource)You can now use it in all perf tools, such as:
perf record -e probe:request_resource -aR sleep 1
#
--- tools/perf/builtin-probe.c | 3 +++ 1 file changed, 3 insertions(+)
tools/perf/builtin-probe.c +3 -0
@@ -364,6 +364,9 @@ static int perf_add_probe_events(structfor (k =0 ; k < pev->ntevs; k++) {struct probe_trace_event *tev = &pev->tevs[k]; +/* Skipped events have no event name */ +if (!tev->event) +continue ;/* We use tev's name for showing new events */ show_perf_probe_event(tev->group, tev->event, pev,
Greg Kroah-Hartman
maintainerPATCH 373/376 perf probe: Fix to check blacklist address correctly
In reply to Greg Kroah-HartmanFrom: Masami Hiramatsu <[email protected]>
commit 80526491c2ca6abc028c0f0dbb0707a1f35fb18a upstream.
Fix to check kprobe blacklist address correctly with relocated address by adjusting debuginfo address.
Since the address in the debuginfo is same as objdump, it is different from relocated kernel address with KASLR. Thus, 'perf probe' always misses to catch the blacklisted addresses.
Without this patch, 'perf probe' can not detect the blacklist addresses on a KASLR enabled kernel.
# perf probe kprobe_dispatcher
Failed to write event: Invalid argument
Error: Failed to add events.
#With this patch, it correctly shows the error message.
# perf probe kprobe_dispatcher
kprobe_dispatcher is blacklisted function, skip it.
Probe point 'kprobe_dispatcher' not found.
Error: Failed to add events.
#--- tools/perf/util/probe-event.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
tools/perf/util/probe-event.c +15 -6
@@ -102,7 +102,7 @@ void exit_probe_symbol_maps(void)symbol__exit (); } -static struct ref_reloc_sym *kernel_get_ref_reloc_sym (void ) +static struct ref_reloc_sym *kernel_get_ref_reloc_sym (struct map **pmap) {/* kmap->ref_reloc_sym should be set if host_machine is initialized */ struct kmap *kmap;
@@ -114,6 +114,10 @@ static struct ref_reloc_sym *kernel_get_ kmap =map__kmap (map);if (!kmap)return NULL ; + +if (pmap) + *pmap = map; +return kmap->ref_reloc_sym; }
@@ -125,7 +129,7 @@ static int kernel_get_symbol_address_by_struct map *map;/* ref_reloc_sym is just a label. Need a special fix*/ - reloc_sym =kernel_get_ref_reloc_sym (); + reloc_sym =kernel_get_ref_reloc_sym (NULL );if (reloc_sym &&strcmp (name, reloc_sym->name) ==0 ) *addr = (reloc) ? reloc_sym->addr : reloc_sym->unrelocated_addr;else {
@@ -745,6 +749,7 @@ post_process_kernel_probe_trace_events(s int ntevs) {struct ref_reloc_sym *reloc_sym; +struct map *map;char *tmp;int i, skipped =0 ;
@@ -753,7 +758,7 @@ post_process_kernel_probe_trace_events(sreturn post_process_offline_probe_trace_events (tevs, ntevs, symbol_conf.vmlinux_name); - reloc_sym =kernel_get_ref_reloc_sym (); + reloc_sym =kernel_get_ref_reloc_sym (&map);if (!reloc_sym) {pr_warning ("Relocated base symbol is not found!\n" );return -EINVAL ;
@@ -764,9 +769,13 @@ post_process_kernel_probe_trace_events(scontinue ;if (tevs[i].point.retprobe && !kretprobe_offset_is_supported ())continue ; -/* If we found a wrong one, mark it by NULL symbol */ +/* +* If we found a wrong one, mark it by NULL symbol. +* Since addresses in debuginfo is same as objdump, we need +* to convert it to addresses on memory. +*/ if (kprobe_warn_out_range (tevs[i].point.symbol, - tevs[i].point.address)) { +map__objdump_2mem (map, tevs[i].point.address))) { tmp =NULL ; skipped++; }else {
@@ -2935,7 +2944,7 @@ static int find_probe_trace_events_from_/* Note that the symbols in the kmodule are not relocated */ if (!pev->uprobes && !pev->target && (!pp->retprobe ||kretprobe_offset_is_supported ())) { - reloc_sym =kernel_get_ref_reloc_sym (); + reloc_sym =kernel_get_ref_reloc_sym (NULL );if (!reloc_sym) {pr_warning ("Relocated base symbol is not found!\n" ); ret = -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 374/376 perf probe: Check address correctness by map instead of _etext
In reply to Greg Kroah-HartmanFrom: Masami Hiramatsu <[email protected]>
commit 2ae5d0d7d8868df7c05c2013c0b9cddd4d40610e upstream.
Since commit 03db8b583d1c ("perf tools: Fix maps__find_symbol_by_name()") introduced map address range check in maps__find_symbol_by_name(), we can not get "_etext" from kernel map because _etext is placed on the edge of the kernel .text section (= kernel map in perf.)
To fix this issue, this checks the address correctness by map address range information (map->start and map->end) instead of using _etext address.
This can cause an error if the target inlined function is embedded in both __init function and normal function.
For exaample, request_resource() is a normal function but also embedded in __init reserve_setup(). In this case, the probe point in reserve_setup() must be skipped.
However, without this fix, it failes to setup all probe points:
# ./perf probe -v request_resource
probe-definition(0): request_resource
symbol:request_resource file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux for symbols
Open Debuginfo file: /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux
Try to find probe point from debuginfo.
Matched function: request_resource [15e29ad]
found inline addr: 0xffffffff82fbf892
Probe point found: reserve_setup+204
found inline addr: 0xffffffff810e9790
Probe point found: request_resource+0
Found 2 probe_trace_events.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Opening /sys/kernel/debug/tracing//README write=0
Writing event: p:probe/request_resource _text+33290386
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Invalid argument (Code: -22)
#With this fix,
# ./perf probe request_resource
reserve_setup is out of .text, skip it.
Added new events:
(null):(null) (on request_resource)
probe:request_resource (on request_resource)You can now use it in all perf tools, such as:
perf record -e probe:request_resource -aR sleep 1
#
--- tools/perf/util/probe-event.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
tools/perf/util/probe-event.c +13 -12
@@ -236,21 +236,22 @@ static void clear_probe_trace_events(strstatic bool kprobe_blacklist__listed (unsigned long address);static bool kprobe_warn_out_range (const char *symbol,unsigned long address) { -u64 etext_addr =0 ; -int ret; +struct map *map; +bool ret = false; -/* Get the address of _etext for checking non-probable text symbol */ - ret =kernel_get_symbol_address_by_name ("_etext" , &etext_addr, - false, false); - -if (ret ==0 && etext_addr < address) -pr_warning ("%s is out of .text, skip it.\n" , symbol); -else if (kprobe_blacklist__listed (address)) + map =kernel_get_module_map (NULL ); +if (map) { + ret = address <= map->start || map->end < address; +if (ret) +pr_warning ("%s is out of .text, skip it.\n" , symbol); +map__put (map); + } +if (!ret &&kprobe_blacklist__listed (address)) {pr_warning ("%s is blacklisted function, skip it.\n" , symbol); -else -return false; + ret = true; + } -return true; +return ret; }/*
Greg Kroah-Hartman
maintainerPATCH 375/376 perf symbols: Fix debuginfo search for Ubuntu
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 85afd35575a3c1a3a905722dde5ee70b49282e70 upstream.
Reportedly, from 19.10 Ubuntu has begun mixing up the location of some debug symbol files, putting files expected to be in /usr/lib/debug/usr/lib into /usr/lib/debug/lib instead. Fix by adding another dso_binary_type.
Example on Ubuntu 20.04
Before:
$ perf record -e intel_pt//u uname
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.030 MB perf.data ]
$ perf script --call-trace | head -5
uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%)
uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4100
uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4df0
uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4e18
uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc5128After:
$ perf script --call-trace | head -5
uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%)
uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _start
uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start
uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start
uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start--- tools/perf/util/dso.c | 16 ++++++++++++++++ tools/perf/util/dso.h | 1 + tools/perf/util/probe-finder.c | 1 + tools/perf/util/symbol.c | 2 ++ 4 files changed, 20 insertions(+)
tools/perf/util/dso.c +16 -0
@@ -47,6 +47,7 @@ char dso__symtab_origin(const struct dso [DSO_BINARY_TYPE__BUILD_ID_CACHE_DEBUGINFO] = 'D', [DSO_BINARY_TYPE__FEDORA_DEBUGINFO] = 'f', [DSO_BINARY_TYPE__UBUNTU_DEBUGINFO] = 'u', + [DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO] = 'x', [DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO] = 'o', [DSO_BINARY_TYPE__BUILDID_DEBUGINFO] = 'b', [DSO_BINARY_TYPE__SYSTEM_PATH_DSO] = 'd',
@@ -129,6 +130,21 @@ int dso__read_binary_type_filename(constsnprintf (filename + len, size - len,"%s" , dso->long_name);break ; +case DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO : +/* +* Ubuntu can mixup /usr/lib with /lib, putting debuginfo in +* /usr/lib/debug/lib when it is expected to be in +* /usr/lib/debug/usr/lib +*/ +if (strlen (dso->long_name) <9 || +strncmp (dso->long_name,"/usr/lib/" ,9 )) { + ret =-1 ; +break ; + } + len =__symbol__join_symfs (filename, size,"/usr/lib/debug" ); +snprintf (filename + len, size - len,"%s" , dso->long_name +4 ); +break ; +case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO : {const char *last_slash;
tools/perf/util/dso.h +1 -0
@@ -30,6 +30,7 @@ enum dso_binary_type {DSO_BINARY_TYPE__BUILD_ID_CACHE_DEBUGINFO ,DSO_BINARY_TYPE__FEDORA_DEBUGINFO ,DSO_BINARY_TYPE__UBUNTU_DEBUGINFO , +DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO ,DSO_BINARY_TYPE__BUILDID_DEBUGINFO ,DSO_BINARY_TYPE__SYSTEM_PATH_DSO , DSO_BINARY_TYPE__GUEST_KMODULE,
tools/perf/util/probe-finder.c +1 -0
@@ -101,6 +101,7 @@ enum dso_binary_type distro_dwarf_types[DSO_BINARY_TYPE__UBUNTU_DEBUGINFO ,DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO ,DSO_BINARY_TYPE__BUILDID_DEBUGINFO , +DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO , DSO_BINARY_TYPE__NOT_FOUND, };
tools/perf/util/symbol.c +2 -0
@@ -79,6 +79,7 @@ static enum dso_binary_type binary_type_DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ,DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP ,DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO , +DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO , DSO_BINARY_TYPE__NOT_FOUND, };
@@ -1515,6 +1516,7 @@ static bool dso__is_compatible_symtab_tycase DSO_BINARY_TYPE__SYSTEM_PATH_DSO :case DSO_BINARY_TYPE__FEDORA_DEBUGINFO :case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO : +case DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO :case DSO_BINARY_TYPE__BUILDID_DEBUGINFO :case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO :return !kmod && dso->kernel ==DSO_TYPE_USER ;
Greg Kroah-Hartman
maintainerPATCH 376/376 perf symbols: Fix kernel maps for kcore and eBPF
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 0affd0e5262b6d40f5f63466d88933e99698e240 upstream.
Adjust 'map->pgoff' also when moving a map's start address.
Example with v5.4.34 based kernel:
Before:
$ sudo tools/perf/perf record -a --kcore -e intel_pt//k sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.958 MB perf.data ]
$ sudo tools/perf/perf script --itrace=e >/dev/null
Warning:
961 instruction trace errorsAfter:
$ sudo tools/perf/perf script --itrace=e >/dev/null
$Committer testing:
# uname -a Linux seventh 5.6.10-100.fc30.x86_64 #1 SMP Mon May 4 15:36:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux #
Before:
# perf record -a --kcore -e intel_pt//k sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.923 MB perf.data ] # perf script --itrace=e >/dev/null Warning: 295 instruction trace errors #
After:
# perf record -a --kcore -e intel_pt//k sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.919 MB perf.data ] # perf script --itrace=e >/dev/null #
--- tools/perf/util/symbol.c | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/util/symbol.c +2 -0
@@ -1210,6 +1210,7 @@ int maps__merge_in(struct maps *kmaps, s m->end = old_map->start;list_add_tail (&m->node, &merged); + new_map->pgoff += old_map->end - new_map->start; new_map->start = old_map->end; } }else {
@@ -1230,6 +1231,7 @@ int maps__merge_in(struct maps *kmaps, s* |new......| -> |new...| * |old....| -> |old....| */ + new_map->pgoff += old_map->end - new_map->start; new_map->start = old_map->end; } }
Holger Hoffstätte
AppliedQuoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Thanks!
Holger
Quoted 8 lines · Holger Hoffstätte
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Uh-oh: I have to take the above back. This release no longer suspends to RAM; display and NIC shut down (box is no longer remotely accessible) but the power stays on and I have to power-cycle.
Will try to revert a bunch of things tomorrow..
-h
Greg Kroah-Hartman
maintainerQuoted 7 lines · Holger Hoffstätte
Quoted 6 lines · Holger Hoffstätte
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Quoted 7 lines
Quoted 2 lines
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Uh-oh: I have to take the above back. This release no longer suspends to RAM; display and NIC shut down (box is no longer remotely accessible) but the power stays on and I have to power-cycle.
Will try to revert a bunch of things tomorrow..
Is this a new problem? Or is it a regression?
thanks,
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
Quoted 10 lines · Holger Hoffstätte
Quoted 8 lines · Holger Hoffstätte
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Quoted 6 lines
Quoted 4 lines
Uh-oh: I have to take the above back. This release no longer suspends to RAM; display and NIC shut down (box is no longer remotely accessible) but the power stays on and I have to power-cycle.
Will try to revert a bunch of things tomorrow..Is this a new problem? Or is it a regression?
5.7.(0,1,2,3,4) all suspended & woke up without problem, every night. Just a moment ago I also got a GPU lockup out of the blue, probably caused by something else (looks like mm/THP/memory mapping/userfault related):
--snip--
Jun 20 08:57:06 ragnarok kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000008fa last fence id 0x000000000000091d on ring 0) Jun 20 08:57:06 ragnarok kernel: BUG: unable to handle page fault for address: ffffc904009ecffc Jun 20 08:57:06 ragnarok kernel: #PF: supervisor read access in kernel mode Jun 20 08:57:06 ragnarok kernel: #PF: error_code(0x0000) - not-present page Jun 20 08:57:06 ragnarok kernel: PGD 604128067 P4D 604128067 PUD 0 Jun 20 08:57:06 ragnarok kernel: Oops: 0000 [#1] SMP Jun 20 08:57:06 ragnarok kernel: CPU: 0 PID: 4994 Comm: compton Not tainted 5.7.5 #1 Jun 20 08:57:06 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Jun 20 08:57:06 ragnarok kernel: RIP: 0010:radeon_ring_backup+0xc3/0x140 [radeon] Jun 20 08:57:06 ragnarok kernel: Code: 89 45 00 48 85 c0 74 6a 41 8d 7c 24 ff 31 d2 48 c1 e7 02 eb 08 49 8b 45 00 48 83 c2 04 48 8b 75 08 8d 4b 01 89 db 48 8d 34 9e <8b> 36 89 34 10 23 4d 54 89 cb 48 39 d7 75 dc 4c 89 f7 e8 26 8c 19 Jun 20 08:57:06 ragnarok kernel: RSP: 0018:ffffc90000df3c00 EFLAGS: 00010202 Jun 20 08:57:06 ragnarok kernel: RAX: ffff888585f80000 RBX: 00000000ffffffff RCX: 0000000000000000 Jun 20 08:57:06 ragnarok kernel: RDX: 0000000000000000 RSI: ffffc904009ecffc RDI: 0000000000049380 Jun 20 08:57:06 ragnarok kernel: RBP: ffff8885fc7413d8 R08: 0000000000000080 R09: ffff88861f7e6000 Jun 20 08:57:06 ragnarok kernel: R10: 000000000002f100 R11: 0000000000000006 R12: 00000000000124e1 Jun 20 08:57:06 ragnarok kernel: R13: ffffc90000df3c68 R14: ffff8885fc7413b8 R15: ffff8885fc740000 Jun 20 08:57:06 ragnarok kernel: FS: 00007f9cb8edb7c0(0000) GS:ffff888607400000(0000) knlGS:0000000000000000 Jun 20 08:57:06 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 20 08:57:06 ragnarok kernel: CR2: ffffc904009ecffc CR3: 0000000592e24003 CR4: 00000000000606f0 Jun 20 08:57:06 ragnarok kernel: Call Trace: Jun 20 08:57:06 ragnarok kernel: radeon_gpu_reset+0x98/0x280 [radeon] Jun 20 08:57:06 ragnarok kernel: ? dma_fence_wait_timeout+0x3f/0xf0 Jun 20 08:57:06 ragnarok kernel: ? dma_resv_wait_timeout_rcu+0x15a/0x3e0 Jun 20 08:57:06 ragnarok kernel: ? radeon_gem_busy_ioctl+0x70/0x70 [radeon] Jun 20 08:57:06 ragnarok kernel: radeon_gem_wait_idle_ioctl+0xcb/0x100 [radeon] Jun 20 08:57:06 ragnarok kernel: ? radeon_gem_busy_ioctl+0x70/0x70 [radeon] Jun 20 08:57:06 ragnarok kernel: drm_ioctl_kernel+0x84/0xd0 [drm] Jun 20 08:57:06 ragnarok kernel: drm_ioctl+0x1e1/0x370 [drm] Jun 20 08:57:06 ragnarok kernel: ? radeon_gem_busy_ioctl+0x70/0x70 [radeon] Jun 20 08:57:06 ragnarok kernel: ? do_iter_write+0xdf/0x190 Jun 20 08:57:06 ragnarok kernel: radeon_drm_ioctl+0x49/0x80 [radeon] Jun 20 08:57:06 ragnarok kernel: ksys_ioctl+0x33a/0x770 Jun 20 08:57:06 ragnarok kernel: __x64_sys_ioctl+0x16/0x19 Jun 20 08:57:06 ragnarok kernel: do_syscall_64+0x4e/0x310 Jun 20 08:57:06 ragnarok kernel: ? do_user_addr_fault+0x1df/0x460 Jun 20 08:57:06 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 20 08:57:06 ragnarok kernel: RIP: 0033:0x7f9cb91bd317 Jun 20 08:57:06 ragnarok kernel: Code: 00 00 00 48 8b 05 69 9b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 9b 0c 00 f7 d8 64 89 01 48 Jun 20 08:57:06 ragnarok kernel: RSP: 002b:00007ffc69dcf778 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 20 08:57:06 ragnarok kernel: RAX: ffffffffffffffda RBX: 00007ffc69dcf7c0 RCX: 00007f9cb91bd317 Jun 20 08:57:06 ragnarok kernel: RDX: 00007ffc69dcf7c0 RSI: 0000000040086464 RDI: 0000000000000007 Jun 20 08:57:06 ragnarok kernel: RBP: 0000000040086464 R08: 00005654ee7d4900 R09: 0000000000000011 Jun 20 08:57:06 ragnarok kernel: R10: 00005654ee7834e0 R11: 0000000000000246 R12: 0000000000000001 Jun 20 08:57:06 ragnarok kernel: R13: 0000000000000007 R14: 0000000000000000 R15: 00005654ee911c00 Jun 20 08:57:06 ragnarok kernel: Modules linked in: autofs4 nfs lockd grace sunrpc tcp_bbr2 sch_fq_codel it87 hwmon_vid drivetemp radeon snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi x86_pkg_temp_thermal i2c_algo_bit bfq mq_deadline snd_usb_audio drm_kms_helper snd_hda_intel uvcvideo coretemp syscopyarea snd_hwdep snd_intel_dspcfg sysfillrect videobuf2_vmalloc snd_usbmidi_lib sysimgblt videobuf2_memops crc32_pclmul snd_hda_codec fb_sys_fops videobuf2_v4l2 snd_rawmidi ttm aesni_intel snd_hda_core snd_seq_device snd_pcm crypto_simd videodev cryptd drm snd_timer glue_helper i2c_i801 videobuf2_common usbhid drm_panel_orientation_quirks snd atlantic backlight i2c_core soundcore parport_pc parport Jun 20 08:57:06 ragnarok kernel: CR2: ffffc904009ecffc Jun 20 08:57:06 ragnarok kernel: ---[ end trace 882fcc4b8349558d ]--- Jun 20 08:57:06 ragnarok kernel: RIP: 0010:radeon_ring_backup+0xc3/0x140 [radeon] Jun 20 08:57:06 ragnarok kernel: Code: 89 45 00 48 85 c0 74 6a 41 8d 7c 24 ff 31 d2 48 c1 e7 02 eb 08 49 8b 45 00 48 83 c2 04 48 8b 75 08 8d 4b 01 89 db 48 8d 34 9e <8b> 36 89 34 10 23 4d 54 89 cb 48 39 d7 75 dc 4c 89 f7 e8 26 8c 19 Jun 20 08:57:06 ragnarok kernel: RSP: 0018:ffffc90000df3c00 EFLAGS: 00010202 Jun 20 08:57:06 ragnarok kernel: RAX: ffff888585f80000 RBX: 00000000ffffffff RCX: 0000000000000000 Jun 20 08:57:06 ragnarok kernel: RDX: 0000000000000000 RSI: ffffc904009ecffc RDI: 0000000000049380 Jun 20 08:57:06 ragnarok kernel: RBP: ffff8885fc7413d8 R08: 0000000000000080 R09: ffff88861f7e6000 Jun 20 08:57:06 ragnarok kernel: R10: 000000000002f100 R11: 0000000000000006 R12: 00000000000124e1 Jun 20 08:57:06 ragnarok kernel: R13: ffffc90000df3c68 R14: ffff8885fc7413b8 R15: ffff8885fc740000 Jun 20 08:57:06 ragnarok kernel: FS: 00007f9cb8edb7c0(0000) GS:ffff888607400000(0000) knlGS:0000000000000000 Jun 20 08:57:06 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 20 08:57:06 ragnarok kernel: CR2: ffffc904009ecffc CR3: 0000000592e24003 CR4: 00000000000606f0
--snip--
Since this is my primary machine I'll have to revert to stable working conditions first and then see whether that was a one-off or caused by 5.7.5-rc1.
Quoted 17 lines · Holger Hoffstätte
Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Holger Hoffstätte
Quoted 8 lines · Holger Hoffstätte
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Uh-oh: I have to take the above back. This release no longer suspends to RAM; display and NIC shut down (box is no longer remotely accessible) but the power stays on and I have to power-cycle.
Will try to revert a bunch of things tomorrow..
Quoted 5 lines
Quoted 1 line
Is this a new problem? Or is it a regression?
5.7.(0,1,2,3,4) all suspended & woke up without problem, every night. Just a moment ago I also got a GPU lockup out of the blue, probably caused by something else (looks like
mm/THP/memorymapping/userfault related)
OK, nevermind - my bad, just noticed that I had a bunch of custom patches in that tree that should not have been in there for testing (yet). Extra-virgin 5.7.4 + 5.7.5-rc1 on top works & suspends/resumes fine, and so far no new GPU lockups either.
-h
Greg Kroah-Hartman
maintainerQuoted 20 lines · Holger Hoffstätte
Quoted 19 lines · Holger Hoffstätte
Quoted 17 lines · Greg Kroah-Hartman
Quoted 7 lines · Holger Hoffstätte
Quoted 6 lines · Holger Hoffstätte
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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.
Quoted 7 lines
Quoted 2 lines
Applied to 5.7.4 and running fine on two different systems (server, desktop) without problems.
Uh-oh: I have to take the above back. This release no longer suspends to RAM; display and NIC shut down (box is no longer remotely accessible) but the power stays on and I have to power-cycle.
Will try to revert a bunch of things tomorrow..Is this a new problem? Or is it a regression?
Quoted 8 lines
Quoted 3 lines
5.7.(0,1,2,3,4) all suspended & woke up without problem, every night. Just a moment ago I also got a GPU lockup out of the blue, probably caused by something else (looks like
mm/THP/memorymapping/userfault related)OK, nevermind - my bad, just noticed that I had a bunch of custom patches in that tree that should not have been in there for testing (yet). Extra-virgin 5.7.4 + 5.7.5-rc1 on top works & suspends/resumes fine, and so far no new GPU lockups either.
Wonderful, thanks for testing and letting me know it is good :)
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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, 21 Jun 2020 14:15:50 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 431 pass: 431 fail: 0
Guenter
Hello!
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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, 21 Jun 2020 14:15:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.7.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.7.5-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.7.y
git commit: 19411dc6b06179bc55c542f1be520764cdcd3aac
git describe: v5.7.2-542-g19411dc6b061
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.2-542-g19411dc6b061
No regressions (compared to build v5.7.3)
No fixes (compared to build v5.7.3)
Ran 37628 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* network-basic-tests
* perf
* v4l2-compliance
Greetings!
Daniel Díaz
[email protected]
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Daniel Díaz
Hello!
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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, 21 Jun 2020 14:15:50 +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.7.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.7.y
and the diffstat can be found below.
Quoted 7 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
THanks for testing all of these and letting me know.
greg k-h
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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, 21 Jun 2020 14:15:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.7.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.7:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 failLinux version: 5.7.5-rc1-g19411dc6b061
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 27 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.7.5 release. There are 376 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, 21 Jun 2020 14:15:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.7.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.7:
11 builds: 11 pass, 0 fail 26 boots: 26 pass, 0 fail 56 tests: 56 pass, 0 fail
Quoted 5 lines
Linux version: 5.7.5-rc1-g19411dc6b061
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Thanks for testing all of these and letting me know.
greg k-h