Re: [PATCH v5 02/19] dt-bindings: usb: Convert generic USB properties to DT schemas
On Sat, 2020-12-05 at 18:24 +0300, Serge Semin wrote:
> The generic USB properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert its content into the generic USB, USB HCD and USB DRD DT
> schemas. So the Generic USB schema will be applicable to all USB
> controllers, USB HCD - for the generic USB Host controllers and the USB
> DRD - for the USB Dual-role controllers.
>
> Note the USB DRD schema is supposed to work in conjunction with
> the USB peripheral/gadget and USB host controllers DT schemas.
>
> Signed-off-by: Serge Semin
> Reviewed-by: Rob Herring
>
> ---
>
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
> the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
> the multi-lined version of the list.
> - Drop quotes from around the string constants.
>
> Changelog v4:
> - Redistribute the properties between generic ones, USB HCD-specific and
> USB DRD-specific.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more time.
> ---
> .../devicetree/bindings/usb/generic.txt | 57 --
> .../devicetree/bindings/usb/usb-drd.yaml | 77 +++
> .../devicetree/bindings/usb/usb-hcd.yaml | 5 ++
> .../devicetree/bindings/usb/usb.yaml | 22 ++
> 4 files changed, 104 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> create mode 100644 Documentation/devicetree/bindings/usb/usb-drd.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> deleted file mode 100644
> index ba472e7aefc9..
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Generic USB Properties
> -
> -Optional properties:
> - - maximum-speed: tells USB controllers we want to work up to a certain
> - speed. Valid arguments are "super-speed-plus",
> - "super-speed", "high-speed", "full-speed" and
> - "low-speed". In case this isn't passed via DT, USB
> - controllers should default to their maximum HW
> - capability.
> - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> - particular mode. Valid arguments are "host",
> - "peripheral" and "otg". In case this attribute isn't
> - passed via DT, USB DRD controllers should default to
> - OTG.
> - - phy_type: tells USB controllers that we want to configure the core to
> support
> - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> - selected. Valid arguments are "utmi" and "utmi_wide".
> - In case this isn't passed via DT, USB controllers should
> - default to HW capability.
> - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> - with which the device and its descriptors are compliant,
> - in binary-coded decimal (i.e. 2.0 is 0200H). This
> - property is used if any real OTG features(HNP/SRP/ADP)
> - is enabled, if ADP is required, otg-rev should be
> - 0x0200 or above.
> - - companion: phandle of a companion
> - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> HNP
> - is the basic function of real OTG except you want it
> - to be a srp-capable only B device.
> - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> - optional for OTG device.
> - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> - optional for OTG device.
> - - usb-role-switch: boolean, indicates that the device is capable of
> assigning
> - the USB data role (USB host or USB device) for a given
> - USB connector, such as Type-C, Type-B(micro).
> - see connector/usb-connector.yaml.
> - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> - device default operation mode of controller while usb
> - role is USB_ROLE_NONE. Valid arguments are "host" and
> - "peripheral". Defaults to "peripheral" if not
> - specified.
> -
> -
> -This is an attribute to a USB controller such as:
> -
> -dwc3@4a03 {
> - compatible = "synopsys,dwc3";
> - reg = <0x4a03 0xcfff>;
> - interrupts = <0 92 4>
> - usb-phy = <&usb2_phy>, <&usb3,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git a/Doc
Re: [PATCH] MAINTAINERS: Update 68k Mac entry
Hi Finn,
On Sat, Dec 5, 2020 at 4:49 AM Finn Thain wrote:
> Two files under drivers/macintosh are actually m68k-only. I think that
> patches for these files should be reviewed in the appropriate forum and
> merged via the appropriate tree, rather than falling to the powerpc
> maintainers to deal with. Update the "M68K ON APPLE MACINTOSH" section
> accordingly.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Joshua Thompson
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-m...@lists.linux-m68k.org
> Signed-off-by: Finn Thain
Reviewed-by: Geert Uytterhoeven
i.e. will queue in the m68k for-v5.11 branch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[powerpc:next-test 42/193] arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: 8817aabb1bdd5811130f94ff6442bb19c9158a3a
commit: 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e [42/193] powerpc: inline iomap
accessors
config: powerpc64-randconfig-s032-20201207 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-179-ga00755aa-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
git remote add powerpc
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
arch/powerpc/platforms/44x/ppc476.c:236:17: sparse: sparse: cast removes
address space '__iomem' of expression
>> arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: sparse: incorrect type
>> in argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *addr @@ got unsigned char [usertype] * @@
arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: expected void const
volatile [noderef] __iomem *addr
arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: got unsigned char
[usertype] *
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: sparse: incorrect type
in argument 1 (different address spaces) @@ expected void volatile
[noderef] __iomem *addr @@ got unsigned char [usertype] *[assigned] fpga @@
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: expected void
volatile [noderef] __iomem *addr
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: got unsigned char
[usertype] *[assigned] fpga
vim +241 arch/powerpc/platforms/44x/ppc476.c
228d55053397e6d arch/powerpc/platforms/44x/currituck.c Tony Breeds
2011-11-30 217
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 218 static int board_rev = -1;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 219 static int __init ppc47x_get_board_rev(void)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 220 {
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 221 int reg;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 222 u8 *fpga;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 223 struct device_node *np = NULL;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 224
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 225 if (of_machine_is_compatible("ibm,currituck")) {
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 226 np = of_find_compatible_node(NULL, NULL,
"ibm,currituck-fpga");
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 227 reg = 0;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 228 } else if (of_machine_is_compatible("ibm,akebono")) {
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 229 np = of_find_compatible_node(NULL, NULL,
"ibm,akebono-fpga");
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 230 reg = 2;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 231 }
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 232
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 233 if (!np)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 234 goto fail;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 235
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.cAlistair Popple
2014-03-06 @236 fpga = (u8 *) of_iomap(np, 0);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 237 of_node_put(np);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 238 if (!fpga)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple
2013-05-09 239 goto fail;
ab9a4183fddf232 arch/powerpc/pl
[PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver
The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is
not user-selectable, and the last code that selected it was removed
with the C2K board support in 2018, see:
92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
That means the driver is now dead code, so remove it.
Suggested-by: Borislav Petkov
Signed-off-by: Michael Ellerman
---
drivers/edac/Kconfig| 7 -
drivers/edac/Makefile | 1 -
drivers/edac/mv64x60_edac.c | 883
drivers/edac/mv64x60_edac.h | 114 -
4 files changed, 1005 deletions(-)
delete mode 100644 drivers/edac/mv64x60_edac.c
delete mode 100644 drivers/edac/mv64x60_edac.h
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index fa0c3b5797e4..f3816f1131ed 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -292,13 +292,6 @@ config EDAC_LAYERSCAPE
Support for error detection and correction on Freescale memory
controllers on Layerscape SoCs.
-config EDAC_MV64X60
- tristate "Marvell MV64x60"
- depends on MV64X60
- help
- Support for error detection and correction on the Marvell
- MV64360 and MV64460 chipsets.
-
config EDAC_PASEMI
tristate "PA Semi PWRficient"
depends on PPC_PASEMI && PCI
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 3cd1aeb0a916..464d3d8d850a 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -65,7 +65,6 @@ obj-$(CONFIG_EDAC_SKX)+= skx_edac.o
i10nm_edac-y := skx_common.o i10nm_base.o
obj-$(CONFIG_EDAC_I10NM) += i10nm_edac.o
-obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
obj-$(CONFIG_EDAC_CELL)+= cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
obj-$(CONFIG_EDAC_AMD8111) += amd8111_edac.o
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
deleted file mode 100644
index 3c68bb525d5d..
--- a/drivers/edac/mv64x60_edac.c
+++ /dev/null
@@ -1,883 +0,0 @@
-/*
- * Marvell MV64x60 Memory Controller kernel module for PPC platforms
- *
- * Author: Dave Jiang
- *
- * 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "edac_module.h"
-#include "mv64x60_edac.h"
-
-static const char *mv64x60_ctl_name = "MV64x60";
-static int edac_dev_idx;
-static int edac_pci_idx;
-static int edac_mc_idx;
-
-/*** PCI err device **/
-#ifdef CONFIG_PCI
-static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
-{
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 cause;
-
- cause = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!cause)
- return;
-
- printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
- printk(KERN_ERR "Cause register: 0x%08x\n", cause);
- printk(KERN_ERR "Address Low: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
- printk(KERN_ERR "Address High: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
- printk(KERN_ERR "Attribute: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
- printk(KERN_ERR "Command: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
- writel(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
-
- if (cause & MV64X60_PCI_PE_MASK)
- edac_pci_handle_pe(pci, pci->ctl_name);
-
- if (!(cause & MV64X60_PCI_PE_MASK))
- edac_pci_handle_npe(pci, pci->ctl_name);
-}
-
-static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
-{
- struct edac_pci_ctl_info *pci = dev_id;
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 val;
-
- val = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!val)
- return IRQ_NONE;
-
- mv64x60_pci_check(pci);
-
- return IRQ_HANDLED;
-}
-
-/*
- * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
- * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
- * well. IOW, don't set bit 0.
- */
-
-/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
-static int __init mv64x60_pci_fixup(struct platform_device *pdev)
-{
- struct resource *r;
- void __iomem *pci_serr;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "PCI err regs\n", __func__);
- return -ENOENT;
- }
-
- pci_serr = ioremap(r->start, resource_size(r));
- if (!pci_serr
Re: [PATCH v6 1/5] PCI: Unify ECAM constants in native PCI Express drivers
+JimQ,
On 12/6/2020 12:16 PM, Krzysztof Wilczyński wrote:
> Hello Nicolas, Florian and Florian,
>
> [...]
>> -/* Configuration space read/write support */
>> -static inline int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
>> -{
>> -return ((PCI_SLOT(devfn) & 0x1f) << PCIE_EXT_SLOT_SHIFT)
>> -| ((PCI_FUNC(devfn) & 0x07) << PCIE_EXT_FUNC_SHIFT)
>> -| (busnr << PCIE_EXT_BUSNUM_SHIFT)
>> -| (reg & ~3);
>> -}
>> -
>> static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int
>> devfn,
>> int where)
>> {
>> @@ -716,7 +704,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus
>> *bus, unsigned int devfn,
>> return PCI_SLOT(devfn) ? NULL : base + where;
>>
>> /* For devices, write to the config space index register */
>> -idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
>> +idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0);
>> writel(idx, pcie->base + PCIE_EXT_CFG_INDEX);
>> return base + PCIE_EXT_CFG_DATA + where;
>> }
> [...]
>
> Passing the hard-coded 0 as the "reg" argument here never actually did
> anything, thus the 32 bit alignment was never correctly enforced.
>
> My question would be: should this be 32 bit aligned? It seems like the
> intention was to perhaps make the alignment? I am sadly not intimately
> familiar with his hardware, so I am not sure if there is something to
> fix here or not.
>
> Also, I wonder whether it would be safe to pass the offset (the "where"
> variable) rather than hard-coded 0?
>
> Thank you for help in advance!
>
> Bjorn also asked the same question:
>
> https://lore.kernel.org/linux-pci/20201120203428.GA272511@bjorn-Precision-5520/
>
> Krzysztof
>
--
Florian
[PATCH 2/2] powerpc/powernv/idle: Restore CIABR after idle for Power9
On Power9, CIABR is lost after idle. This means that instruction
breakpoints set by xmon which use CIABR do not work. Fix this by
restoring CIABR after idle.
Signed-off-by: Jordan Niethe
---
arch/powerpc/platforms/powernv/idle.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 1ed7c5286487..e6f461812856 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -589,6 +589,7 @@ struct p9_sprs {
u64 spurr;
u64 dscr;
u64 wort;
+ u64 ciabr;
u64 mmcra;
u32 mmcr0;
@@ -668,6 +669,7 @@ static unsigned long power9_idle_stop(unsigned long psscr,
bool mmu_on)
sprs.spurr = mfspr(SPRN_SPURR);
sprs.dscr = mfspr(SPRN_DSCR);
sprs.wort = mfspr(SPRN_WORT);
+ sprs.ciabr = mfspr(SPRN_CIABR);
sprs.mmcra = mfspr(SPRN_MMCRA);
sprs.mmcr0 = mfspr(SPRN_MMCR0);
@@ -785,6 +787,7 @@ static unsigned long power9_idle_stop(unsigned long psscr,
bool mmu_on)
mtspr(SPRN_SPURR, sprs.spurr);
mtspr(SPRN_DSCR,sprs.dscr);
mtspr(SPRN_WORT,sprs.wort);
+ mtspr(SPRN_CIABR, sprs.ciabr);
mtspr(SPRN_MMCRA, sprs.mmcra);
mtspr(SPRN_MMCR0, sprs.mmcr0);
--
2.17.1
[PATCH 1/2] powerpc/book3s64/kexec: Clear CIABR on kexec
The value in CIABR persists across kexec which can lead to unintended
results when the new kernel hits the old kernel's breakpoint. For
example:
0:mon> bi $loadavg_proc_show
0:mon> b
typeaddress
1 inst c0519060 loadavg_proc_show+0x0/0x130
0:mon> x
$ kexec -l /mnt/vmlinux --initrd=/mnt/rootfs.cpio.gz --append='xmon=off'
$ kexec -e
$ cat /proc/loadavg
Trace/breakpoint trap
Make sure CIABR is cleared so this does not happen.
Signed-off-by: Jordan Niethe
---
arch/powerpc/include/asm/book3s/64/kexec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/kexec.h
b/arch/powerpc/include/asm/book3s/64/kexec.h
index 6b5c3a248ba2..d4b9d476ecba 100644
--- a/arch/powerpc/include/asm/book3s/64/kexec.h
+++ b/arch/powerpc/include/asm/book3s/64/kexec.h
@@ -3,6 +3,7 @@
#ifndef _ASM_POWERPC_BOOK3S_64_KEXEC_H_
#define _ASM_POWERPC_BOOK3S_64_KEXEC_H_
+#include
#define reset_sprs reset_sprs
static inline void reset_sprs(void)
@@ -14,6 +15,10 @@ static inline void reset_sprs(void)
if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
mtspr(SPRN_IAMR, 0);
+ if (cpu_has_feature(CPU_FTR_HVMODE))
+ mtspr(SPRN_CIABR, 0);
+ else
+ plpar_set_ciabr(0);
}
/* Do we need isync()? We are going via a kexec reset */
--
2.17.1
Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
Christophe Leroy writes:
> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
> routines"), userspace access is not granted anymore when using
> copy_from_kernel_nofault()
>
> However, kthread_probe_data() uses copy_from_kernel_nofault()
> to check validity of pointers. When the pointer is NULL,
> it points to userspace, leading to a KUAP fault and triggering
> the following big hammer warning many times when you request
> a sysrq "show task":
>
> [ 1117.202054] [ cut here ]
> [ 1117.202102] Bug: fault blocked by AP register !
> [ 1117.202261] WARNING: CPU: 0 PID: 377 at
> arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
> [ 1117.202310] Modules linked in:
> [ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: GW
> 5.10.0-rc5-01340-g83f53be2de31-dirty #4175
> [ 1117.202499] NIP: c0012048 LR: c0012048 CTR:
> [ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.202625] MSR: 00021032 CR: 2408 XER: 2000
> [ 1117.202899]
> [ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 0023 c092e554 0001
> c09865e8 c092e640
> [ 1117.202899] GPR08: 1032 00014efc 28082224 100d166a
> 100a0920
> [ 1117.202899] GPR16: 100cac0c 100b 1080c3fc 1080d685 100d 100d
> 100a0900
> [ 1117.202899] GPR24: 100d c07892ec c0921510 c21f4440 005c
> c000 cacdbc80
> [ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204509] Call Trace:
> [ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
> [ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
> [ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 0001
> [ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.205104] MSR: 9032 CR: 28082224 XER:
> [ 1117.205416] DAR: 005c DSISR: c000
> [ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 0001 0017 0017
> 0027 000f
> [ 1117.205416] GPR08: c09926ec 3000 24082224
> [ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
> [ 1117.206258] --- interrupt: 301
> [ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
> [ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
> [ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
> [ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
> [ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
> [ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
> [ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
> [ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
> [ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
> [ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
> [ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
> [ 1117.207938] --- interrupt: c01 at 0xfd4e784
> [ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
> [ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.208134] MSR: d032 CR: 4400 XER:
> [ 1117.208470]
> [ 1117.208470] GPR00: 0004 7fc34090 77bfb4e0 0001 1080fa40 0002
> 740f fefefeff
> [ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0
> [ 1117.209104] NIP [0fd4e784] 0xfd4e784
> [ 1117.209180] LR [0fe0f244] 0xfe0f244
> [ 1117.209236] --- interrupt: c01
> [ 1117.209274] Instruction dump:
> [ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040
> 4082ff60
> [ 1117.209727] 0fe0 3c60c082 386399f4 48013b65 <0fe0> 80010034
> 386b 7c0803a6
> [ 1117.210102] ---[ end trace 1927c0323393af3e ]---
>
> To avoid that, copy_from_kernel_nofault_allowed() is used to check
> whether the address is a valid kernel address. But the default
> version of it returns true for any address.
>
> Provide a powerpc version of copy_from_kernel_nofault_allowed()
> that returns false when the address is below TASK_USER_MAX,
> so that copy_from_kernel_nofault() will return -ERANGE.
>
> Reported-by: Qian Cai
> Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
> Cc: Christoph Hellwig
> Cc: Al Viro
> Signed-off-by: Christophe Leroy
> ---
> This issue was introduced in 5.10. I didn't mark it for stable, hopping it
> will go into 5.10-rc7
> ---
> arch/powerpc/mm/Makefile | 2 +-
> arch/powerpc/mm/maccess.c | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/mm/maccess.c
>
> diff --git a/arch/powerpc/mm/maccess.c b/arch/powerpc/mm/maccess.c
Re: [PATCH] powerpc/book3s_hv_uvmem: Check for failed page migration
On Saturday, 5 December 2020 3:52:44 AM AEDT Ram Pai wrote: > On Fri, Dec 04, 2020 at 03:48:41PM +0530, Bharata B Rao wrote: > > On Thu, Dec 03, 2020 at 04:08:12PM +1100, Alistair Popple wrote: > This patch certainly looks like the problem, that has been hurting > us for a while. Let me run this patch through my SVM tests. Looks very > promising. > > BTW: The code does a similar thing while paging out. It pages out from the > UV, and then does the migration. Is there a bug there aswell? As specified the migrate_pages_vma() API can fail to migrate device private pages. However the fix was less obvious to me, and in practice I don't think it will ever fail for device private pages as you don't have the same races to establish the page and device private pages can't be pinned. It might be worth adding some kind of warning though in case this ever changes. - Alistair > RP >
Re: [PATCH] powerpc/book3s_hv_uvmem: Check for failed page migration
On Friday, 4 December 2020 9:18:41 PM AEDT Bharata B Rao wrote: > > Reviewed-by: Bharata B Rao > > Did you actually hit this scenario with secure VMs where a UV-paged-in > page was later found to be not migratable? No, this was found by inspection. I have no way of testing this but we had a similar issue in Nouveau and I think you would have a similar issue here although it might be hard to hit. migrate_vma_pages() will fail a page migration if a CPU thread has raced and established a non-zero page PTE for the address. See migrate_vma_insert_page() for the implementation. It will also fail if something else has taken a reference on the page after calling migrate_vma_setup(), but that is less likely as any existing pages will have been isolated. - Alistair > Regards, > Bharata. >
RE: [PATCH v5 09/19] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
Hi Serge, Thank you for the patch. > -Original Message- > From: Serge Semin > Sent: 05 December 2020 15:24 > To: Mathias Nyman ; Felipe Balbi ; > Krzysztof Kozlowski > ; Greg Kroah-Hartman ; Rob > Herring ; > Chunfeng Yun ; Prabhakar Mahadev Lad > lad...@bp.renesas.com>; Yoshihiro Shimoda > Cc: Serge Semin ; Serge Semin > ; Alexey > Malahov ; Pavel Parkhomenko > ; Andy Gross ; > Bjorn Andersson > ; Manu Gautam ; Roger > Quadros ; > Neil Armstrong ; Kevin Hilman > ; Martin Blumenstingl > ; Ahmad Zainie > ; linux- > arm-ker...@lists.infradead.org; linux-snps-...@lists.infradead.org; > linux-m...@vger.kernel.org; > linuxppc-dev@lists.ozlabs.org; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; Rob Herring > Subject: [PATCH v5 09/19] dt-bindings: usb: renesas-xhci: Refer to the > usb-xhci.yaml file > > With minor peculiarities (like uploading some vendor-specific firmware) > these are just Generic xHCI controllers fully compatible with its > properties. Make sure the Renesas USB xHCI DT nodes are also validated > against the Generic xHCI DT schema. > > Signed-off-by: Serge Semin > Reviewed-by: Rob Herring > Reviewed-by: Yoshihiro Shimoda > --- > Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Lad Prabhakar Cheers, Prabhakar > diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml > b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml > index 0f078bd0a3e5..7e5ed196b52c 100644 > --- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml > +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml > @@ -11,7 +11,7 @@ maintainers: >- Yoshihiro Shimoda > > allOf: > - - $ref: "usb-hcd.yaml" > + - $ref: "usb-xhci.yaml" > > properties: >compatible: > @@ -69,7 +69,7 @@ required: >- power-domains >- resets > > -additionalProperties: false > +unevaluatedProperties: false > > examples: >- | > -- > 2.29.2
Re: [PATCH v6 1/5] PCI: Unify ECAM constants in native PCI Express drivers
Hello Nicolas, Florian and Florian,
[...]
> -/* Configuration space read/write support */
> -static inline int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
> -{
> - return ((PCI_SLOT(devfn) & 0x1f) << PCIE_EXT_SLOT_SHIFT)
> - | ((PCI_FUNC(devfn) & 0x07) << PCIE_EXT_FUNC_SHIFT)
> - | (busnr << PCIE_EXT_BUSNUM_SHIFT)
> - | (reg & ~3);
> -}
> -
> static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int
> devfn,
> int where)
> {
> @@ -716,7 +704,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus
> *bus, unsigned int devfn,
> return PCI_SLOT(devfn) ? NULL : base + where;
>
> /* For devices, write to the config space index register */
> - idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
> + idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0);
> writel(idx, pcie->base + PCIE_EXT_CFG_INDEX);
> return base + PCIE_EXT_CFG_DATA + where;
> }
[...]
Passing the hard-coded 0 as the "reg" argument here never actually did
anything, thus the 32 bit alignment was never correctly enforced.
My question would be: should this be 32 bit aligned? It seems like the
intention was to perhaps make the alignment? I am sadly not intimately
familiar with his hardware, so I am not sure if there is something to
fix here or not.
Also, I wonder whether it would be safe to pass the offset (the "where"
variable) rather than hard-coded 0?
Thank you for help in advance!
Bjorn also asked the same question:
https://lore.kernel.org/linux-pci/20201120203428.GA272511@bjorn-Precision-5520/
Krzysztof
RE: [PATCH v5 19/19] dt-bindings: usb: intel,keembay-dwc3: Validate DWC3 sub-node
Hi Serge.
> -Original Message-
> From: Serge Semin
> Sent: Saturday, December 5, 2020 11:24 PM
> To: Nyman, Mathias ; Felipe Balbi
> ; Krzysztof Kozlowski ; Greg Kroah-
> Hartman ; Rob Herring
> ; Chunfeng Yun ;
> Wan Mohamad, Wan Ahmad Zainie
>
> Cc: Serge Semin ; Serge Semin
> ; Alexey Malahov
> ; Pavel Parkhomenko
> ; Andy Gross
> ; Bjorn Andersson ;
> Manu Gautam ; Roger Quadros
> ; Lad Prabhakar lad...@bp.renesas.com>; Yoshihiro Shimoda
> ; narmstrong
> ; Kevin Hilman ;
> Martin Blumenstingl ; linux-arm-
> ker...@lists.infradead.org; linux-snps-...@lists.infradead.org; linux-
> m...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> u...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v5 19/19] dt-bindings: usb: intel,keembay-dwc3: Validate
> DWC3 sub-node
>
> Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC
> USB3 compatible sub-node to describe a fully functioning USB interface. Let's
> use the available DWC USB3 DT schema to validate the Qualcomm DWC3 sub-
> nodes.
>
> Note since the generic DWC USB3 DT node is supposed to be named as
> generic USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-
> nodes name regexp and fix the DT node example.
>
> Signed-off-by: Serge Semin
LGTM. With minor change to fix the typo above, Qualcomm to Intel
Keem Bay,
Acked-by: Wan Ahmad Zainie
>
> ---
>
> Changelog v5:
> - This is a new patch created for the new Intel Keem Bay bindings file,
> which has been added just recently.
> ---
> .../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-
> dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-
> dwc3.yaml
> index dd32c10ce6c7..43b91ab62004 100644
> --- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
> @@ -34,11 +34,8 @@ properties:
> # Required child node:
>
> patternProperties:
> - "^dwc3@[0-9a-f]+$":
> -type: object
> -description:
> - A child node must exist to represent the core DWC3 IP block.
> - The content of the node is defined in dwc3.txt.
> + "^usb@[0-9a-f]+$":
> +$ref: snps,dwc3.yaml#
>
> required:
>- compatible
> @@ -68,7 +65,7 @@ examples:
>#address-cells = <1>;
>#size-cells = <1>;
>
> - dwc3@3400 {
> + usb@3400 {
> compatible = "snps,dwc3";
> reg = <0x3400 0x1>;
> interrupts = ;
> --
> 2.29.2
Best regards,
Zainie
Re: [PATCH v5 19/19] dt-bindings: usb: intel,keembay-dwc3: Validate DWC3 sub-node
Hi Wan,
On Sun, Dec 06, 2020 at 09:56:47AM +, Wan Mohamad, Wan Ahmad Zainie wrote:
> Hi Serge.
>
> > -Original Message-
> > From: Serge Semin
> > Sent: Saturday, December 5, 2020 11:24 PM
> > To: Nyman, Mathias ; Felipe Balbi
> > ; Krzysztof Kozlowski ; Greg Kroah-
> > Hartman ; Rob Herring
> > ; Chunfeng Yun ;
> > Wan Mohamad, Wan Ahmad Zainie
> >
> > Cc: Serge Semin ; Serge Semin
> > ; Alexey Malahov
> > ; Pavel Parkhomenko
> > ; Andy Gross
> > ; Bjorn Andersson ;
> > Manu Gautam ; Roger Quadros
> > ; Lad Prabhakar > lad...@bp.renesas.com>; Yoshihiro Shimoda
> > ; narmstrong
> > ; Kevin Hilman ;
> > Martin Blumenstingl ; linux-arm-
> > ker...@lists.infradead.org; linux-snps-...@lists.infradead.org; linux-
> > m...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > u...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH v5 19/19] dt-bindings: usb: intel,keembay-dwc3: Validate
> > DWC3 sub-node
> >
> > Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC
> > USB3 compatible sub-node to describe a fully functioning USB interface.
> > Let's
> > use the available DWC USB3 DT schema to validate the Qualcomm DWC3 sub-
> > nodes.
> >
> > Note since the generic DWC USB3 DT node is supposed to be named as
> > generic USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-
> > nodes name regexp and fix the DT node example.
> >
> > Signed-off-by: Serge Semin
>
> LGTM. With minor change to fix the typo above, Qualcomm to Intel
> Keem Bay,
> Acked-by: Wan Ahmad Zainie
Ah, right. Thanks for noticing that. A probability of copy-paste mistakes
increases proportionally to the number sleepless hours.)
-Sergey
>
> >
> > ---
> >
> > Changelog v5:
> > - This is a new patch created for the new Intel Keem Bay bindings file,
> > which has been added just recently.
> > ---
> > .../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++--
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-
> > dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-
> > dwc3.yaml
> > index dd32c10ce6c7..43b91ab62004 100644
> > --- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
> > +++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
> > @@ -34,11 +34,8 @@ properties:
> > # Required child node:
> >
> > patternProperties:
> > - "^dwc3@[0-9a-f]+$":
> > -type: object
> > -description:
> > - A child node must exist to represent the core DWC3 IP block.
> > - The content of the node is defined in dwc3.txt.
> > + "^usb@[0-9a-f]+$":
> > +$ref: snps,dwc3.yaml#
> >
> > required:
> >- compatible
> > @@ -68,7 +65,7 @@ examples:
> >#address-cells = <1>;
> >#size-cells = <1>;
> >
> > - dwc3@3400 {
> > + usb@3400 {
> > compatible = "snps,dwc3";
> > reg = <0x3400 0x1>;
> > interrupts = ;
> > --
> > 2.29.2
>
> Best regards,
> Zainie
Patch "powerpc: Stop exporting __clear_user which is now inlined." has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled
powerpc: Stop exporting __clear_user which is now inlined.
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-stop-exporting-__clear_user-which-is-now-inlined.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From msucha...@suse.de Sun Dec 6 10:49:43 2020
From: Michal Suchanek
Date: Sat, 5 Dec 2020 00:28:07 +0100
Subject: powerpc: Stop exporting __clear_user which is now inlined.
To: sta...@vger.kernel.org
Cc: Michal Suchanek , Benjamin Herrenschmidt
, Paul Mackerras , Michael Ellerman
, linuxppc-dev@lists.ozlabs.org,
linux-ker...@vger.kernel.org
Message-ID: <20201204232807.31887-1-msucha...@suse.de>
From: Michal Suchanek
Stable commit 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP
enabled") redefines __clear_user as inline function but does not remove
the export.
Fixes: 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP enabled")
Signed-off-by: Michal Suchanek
Acked-by: Michael Ellerman
---
arch/powerpc/lib/ppc_ksyms.c |1 -
1 file changed, 1 deletion(-)
--- a/arch/powerpc/lib/ppc_ksyms.c
+++ b/arch/powerpc/lib/ppc_ksyms.c
@@ -24,7 +24,6 @@ EXPORT_SYMBOL(csum_tcpudp_magic);
#endif
EXPORT_SYMBOL(__copy_tofrom_user);
-EXPORT_SYMBOL(__clear_user);
EXPORT_SYMBOL(copy_page);
#ifdef CONFIG_PPC64
Patches currently in stable-queue which might be from msucha...@suse.de are
queue-4.4/powerpc-stop-exporting-__clear_user-which-is-now-inlined.patch
Re: [PATCH] powerpc: Stop exporting __clear_user which is now inlined.
On Sat, Dec 05, 2020 at 09:58:23PM +1100, Michael Ellerman wrote:
> Michal Suchanek writes:
> > Stable commit 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP
> > enabled") redefines __clear_user as inline function but does not remove
> > the export.
> >
> > Fixes: 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP enabled")
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > arch/powerpc/lib/ppc_ksyms.c | 1 -
> > 1 file changed, 1 deletion(-)
>
> Acked-by: Michael Ellerman
Now applied, thanks.
greg k-h
