[PATCH kernel v2] vfio/pci/nvlink2: Do not attempt NPU2 setup on POWER8NVL NPU
We execute certain NPU2 setup code (such as mapping an LPID to a device
in NPU2) unconditionally if an Nvlink bridge is detected. However this
cannot succeed on POWER8NVL machines as the init helpers return an error
other than ENODEV which means the device is there is and setup failed so
vfio_pci_enable() fails and pass through is not possible.
This changes the two NPU2 related init helpers to return -ENODEV if
there is no "memory-region" device tree property as this is
the distinction between NPU and NPU2.
Tested on
- POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
NVIDIA GV100 10de:1db1 driver 418.39
- POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
NVIDIA P100 10de:15f9 driver 396.47
Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
Cc: sta...@vger.kernel.org # 5.0
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v2:
* updated commit log with tested configs and replaced P8+ with POWER8NVL for
clarity
---
drivers/vfio/pci/vfio_pci_nvlink2.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_nvlink2.c
b/drivers/vfio/pci/vfio_pci_nvlink2.c
index 65c61710c0e9..9adcf6a8f888 100644
--- a/drivers/vfio/pci/vfio_pci_nvlink2.c
+++ b/drivers/vfio/pci/vfio_pci_nvlink2.c
@@ -231,7 +231,7 @@ int vfio_pci_nvdia_v100_nvlink2_init(struct vfio_pci_device
*vdev)
return -EINVAL;
if (of_property_read_u32(npu_node, "memory-region", &mem_phandle))
- return -EINVAL;
+ return -ENODEV;
mem_node = of_find_node_by_phandle(mem_phandle);
if (!mem_node)
@@ -393,7 +393,7 @@ int vfio_pci_ibm_npu2_init(struct vfio_pci_device *vdev)
int ret;
struct vfio_pci_npu2_data *data;
struct device_node *nvlink_dn;
- u32 nvlink_index = 0;
+ u32 nvlink_index = 0, mem_phandle = 0;
struct pci_dev *npdev = vdev->pdev;
struct device_node *npu_node = pci_device_to_OF_node(npdev);
struct pci_controller *hose = pci_bus_to_host(npdev->bus);
@@ -408,6 +408,9 @@ int vfio_pci_ibm_npu2_init(struct vfio_pci_device *vdev)
if (!pnv_pci_get_gpu_dev(vdev->pdev))
return -ENODEV;
+ if (of_property_read_u32(npu_node, "memory-region", &mem_phandle))
+ return -ENODEV;
+
/*
* NPU2 normally has 8 ATSD registers (for concurrency) and 6 links
* so we can allocate one register per link, using nvlink index as
--
2.17.1
[PATCH kernel v2] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
We execute certain NPU2 setup code (such as mapping an LPID to a device
in NPU2) unconditionally if an Nvlink bridge is detected. However this
cannot succeed on POWER8NVL machines and errors appear in dmesg. This is
harmless as skiboot returns an error and the only place we check it is
vfio-pci but that code does not get called on P8+ either.
This adds a check if pnv_npu2_xxx helpers are called on a machine with
NPU2 which initializes pnv_phb::npu in pnv_npu2_init();
pnv_phb::npu==NULL on POWER8/NVL (Naples).
While at this, fix NULL derefencing in pnv_npu_peers_take_ownership/
pnv_npu_peers_release_ownership which occurs when GPUs on mentioned P8s
cause EEH which happens if "vfio-pci" disables devices using
the D3 power state; the vfio-pci's disable_idle_d3 module parameter
controls this and must be set on Naples. The EEH handling clears
the entire pnv_ioda_pe struct in pnv_ioda_free_pe() hence
the NULL derefencing. We cannot recover from that but at least we stop
crashing.
Tested on
- POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
NVIDIA GV100 10de:1db1 driver 418.39
- POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
NVIDIA P100 10de:15f9 driver 396.47
Fixes: 1b785611e119 ("powerpc/powernv/npu: Add release_ownership hook")
Cc: sta...@vger.kernel.org # 5.0
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v2:
* added checks for !pe->table_group.ops and updated commit log
* added tested configurations
---
arch/powerpc/platforms/powernv/npu-dma.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index abeaa533b976..b711dc3262a3 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -385,7 +385,8 @@ static void pnv_npu_peers_take_ownership(struct
iommu_table_group *table_group)
for (i = 0; i < npucomp->pe_num; ++i) {
struct pnv_ioda_pe *pe = npucomp->pe[i];
- if (!pe->table_group.ops->take_ownership)
+ if (!pe->table_group.ops ||
+ !pe->table_group.ops->take_ownership)
continue;
pe->table_group.ops->take_ownership(&pe->table_group);
}
@@ -401,7 +402,8 @@ static void pnv_npu_peers_release_ownership(
for (i = 0; i < npucomp->pe_num; ++i) {
struct pnv_ioda_pe *pe = npucomp->pe[i];
- if (!pe->table_group.ops->release_ownership)
+ if (!pe->table_group.ops ||
+ !pe->table_group.ops->release_ownership)
continue;
pe->table_group.ops->release_ownership(&pe->table_group);
}
@@ -623,6 +625,11 @@ int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, unsigned
int lparid,
return -ENODEV;
hose = pci_bus_to_host(npdev->bus);
+ if (hose->npu == NULL) {
+ dev_info_once(&npdev->dev, "Nvlink1 does not support contexts");
+ return 0;
+ }
+
nphb = hose->private_data;
dev_dbg(&gpdev->dev, "Map LPAR opalid=%llu lparid=%u\n",
@@ -670,6 +677,11 @@ int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev)
return -ENODEV;
hose = pci_bus_to_host(npdev->bus);
+ if (hose->npu == NULL) {
+ dev_info_once(&npdev->dev, "Nvlink1 does not support contexts");
+ return 0;
+ }
+
nphb = hose->private_data;
dev_dbg(&gpdev->dev, "destroy context opalid=%llu\n",
--
2.17.1
[PATCH v2] m68k: Fix WARNING splat in pmac_zilog driver
Don't add platform resources that won't be used. This avoids a
recently-added warning from the driver core, that can show up on a
multi-platform kernel when !MACH_IS_MAC.
[ cut here ]
WARNING: CPU: 0 PID: 0 at drivers/base/platform.c:224
platform_get_irq_optional+0x8e/0xce
0 is an invalid IRQ number
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-multi #1
Stack from 004b3f04:
004b3f04 00462c2f 00462c2f 004b3f20 0002e128 004754db 004b6ad4 004b3f4c
0002e19c 004754f7 00e0 00285ba0 0009 004b3f44
004754db 004b3f64 004b3f74 00285ba0 004754f7 00e0 0009 004754db
004fdf0c 005269e2 004fdf0c 004b3f88 00285cae 004b6964
004fdf0c 004b3fac 0051cc68 004b6964 004b6964 0200
0051cc3e 0023c18a 004b3fc0 0051cd8a 004fdf0c 0002 0052b43c 004b3fc8
Call Trace: [<0002e128>] __warn+0xa6/0xd6
[<0002e19c>] warn_slowpath_fmt+0x44/0x76
[<00285ba0>] platform_get_irq_optional+0x8e/0xce
[<00285ba0>] platform_get_irq_optional+0x8e/0xce
[<00285cae>] platform_get_irq+0x12/0x4c
[<0051cc68>] pmz_init_port+0x2a/0xa6
[<0051cc3e>] pmz_init_port+0x0/0xa6
[<0023c18a>] strlen+0x0/0x22
[<0051cd8a>] pmz_probe+0x34/0x88
[<0051cde6>] pmz_console_init+0x8/0x28
[<00511776>] console_init+0x1e/0x28
[<0005a3bc>] printk+0x0/0x16
[<0050a8a6>] start_kernel+0x368/0x4ce
[<005094f8>] _sinittext+0x4f8/0xc48
random: get_random_bytes called from print_oops_end_marker+0x56/0x80 with
crng_init=0
---[ end trace 392d8e82eed68d6c ]---
Commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid"),
which introduced the WARNING, suggests that testing for irq == 0 is
undesirable. Instead of that comparison, just test for resource existence.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Joshua Thompson
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: sta...@vger.kernel.org # v5.8+
References: commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is
invalid")
Reported-by: Laurent Vivier
Signed-off-by: Finn Thain
---
Changed since v1:
- Add a comment to explain the need for the global structs.
- Expand the commit log to better explain the intention of the patch.
---
arch/m68k/mac/config.c | 17 +
drivers/tty/serial/pmac_zilog.c | 14 +-
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 0ac53d87493c..2bea1799b8de 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -777,16 +777,12 @@ static struct resource scc_b_rsrcs[] = {
struct platform_device scc_a_pdev = {
.name = "scc",
.id = 0,
- .num_resources = ARRAY_SIZE(scc_a_rsrcs),
- .resource = scc_a_rsrcs,
};
EXPORT_SYMBOL(scc_a_pdev);
struct platform_device scc_b_pdev = {
.name = "scc",
.id = 1,
- .num_resources = ARRAY_SIZE(scc_b_rsrcs),
- .resource = scc_b_rsrcs,
};
EXPORT_SYMBOL(scc_b_pdev);
@@ -813,10 +809,15 @@ static void __init mac_identify(void)
/* Set up serial port resources for the console initcall. */
- scc_a_rsrcs[0].start = (resource_size_t) mac_bi_data.sccbase + 2;
- scc_a_rsrcs[0].end = scc_a_rsrcs[0].start;
- scc_b_rsrcs[0].start = (resource_size_t) mac_bi_data.sccbase;
- scc_b_rsrcs[0].end = scc_b_rsrcs[0].start;
+ scc_a_rsrcs[0].start = (resource_size_t)mac_bi_data.sccbase + 2;
+ scc_a_rsrcs[0].end = scc_a_rsrcs[0].start;
+ scc_a_pdev.num_resources = ARRAY_SIZE(scc_a_rsrcs);
+ scc_a_pdev.resource = scc_a_rsrcs;
+
+ scc_b_rsrcs[0].start = (resource_size_t)mac_bi_data.sccbase;
+ scc_b_rsrcs[0].end = scc_b_rsrcs[0].start;
+ scc_b_pdev.num_resources = ARRAY_SIZE(scc_b_rsrcs);
+ scc_b_pdev.resource = scc_b_rsrcs;
switch (macintosh_config->scc_type) {
case MAC_SCC_PSC:
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index 96e7aa479961..216b75ef5048 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1693,22 +1693,26 @@ static int __init pmz_probe(void)
#else
+/* On PCI PowerMacs, pmz_probe() does an explicit search of the OpenFirmware
+ * tree to obtain the device_nodes needed to start the console before the
+ * macio driver. On Macs without OpenFirmware, global platform_devices take
+ * the place of those device_nodes.
+ */
extern struct platform_device scc_a_pdev, scc_b_pdev;
static int __init pmz_init_port(struct uart_pmac_port *uap)
{
- struct resource *r_ports;
- int irq;
+ struct resource *r_ports, *r_irq;
r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0);
- irq = platform_get_irq(uap->pdev, 0);
- if (!r_ports || irq <= 0)
+ r_irq = platform_get_resource(uap->pdev, IORESOUR
[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020
https://bugzilla.kernel.org/show_bug.cgi?id=209029 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #6 from Erhard F. (erhar...@mailbox.org) --- Current v5.9.x boots fine on this G5. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] powerpc: inline iomap accessors
ioreadXX()/ioreadXXbe() accessors are equivalent to ppc
in_leXX()/in_be16() accessors but they are not inlined.
Since commit 0eb573682872 ("powerpc/kerenl: Enable EEH for IO
accessors"), the 'le' versions are equivalent to the ones
defined in asm-generic/io.h, allthough the ones there are inlined.
Include asm-generic/io.h to get them. Keep ppc versions of the
'be' ones as they are optimised, but make them inline in ppc io.h.
This reduces the size of ppc64e_defconfig build by 3 kbytes:
textdata bss dec hex filename
101607334343422 562972 15067127 e5e7f7 vmlinux.before
101592394341590 562972 15063801 e5daf9 vmlinux.after
A typical function using ioread and iowrite before the change:
c066a3c4 <.ata_bmdma_stop>:
c066a3c4: 7c 08 02 a6 mflrr0
c066a3c8: fb c1 ff f0 std r30,-16(r1)
c066a3cc: f8 01 00 10 std r0,16(r1)
c066a3d0: fb e1 ff f8 std r31,-8(r1)
c066a3d4: f8 21 ff 81 stdur1,-128(r1)
c066a3d8: eb e3 00 00 ld r31,0(r3)
c066a3dc: eb df 00 98 ld r30,152(r31)
c066a3e0: 7f c3 f3 78 mr r3,r30
c066a3e4: 4b 9b 6f 7d bl c0021360 <.ioread8>
c066a3e8: 60 00 00 00 nop
c066a3ec: 7f c4 f3 78 mr r4,r30
c066a3f0: 54 63 06 3c rlwinm r3,r3,0,24,30
c066a3f4: 4b 9b 70 4d bl c0021440 <.iowrite8>
c066a3f8: 60 00 00 00 nop
c066a3fc: 7f e3 fb 78 mr r3,r31
c066a400: 38 21 00 80 addir1,r1,128
c066a404: e8 01 00 10 ld r0,16(r1)
c066a408: eb c1 ff f0 ld r30,-16(r1)
c066a40c: 7c 08 03 a6 mtlrr0
c066a410: eb e1 ff f8 ld r31,-8(r1)
c066a414: 4b ff ff 8c b c066a3a0
<.ata_sff_dma_pause>
The same function with this patch:
c0669cb4 <.ata_bmdma_stop>:
c0669cb4: e8 63 00 00 ld r3,0(r3)
c0669cb8: e9 43 00 98 ld r10,152(r3)
c0669cbc: 7c 00 04 ac hwsync
c0669cc0: 89 2a 00 00 lbz r9,0(r10)
c0669cc4: 0c 09 00 00 twi 0,r9,0
c0669cc8: 4c 00 01 2c isync
c0669ccc: 55 29 06 3c rlwinm r9,r9,0,24,30
c0669cd0: 7c 00 04 ac hwsync
c0669cd4: 99 2a 00 00 stb r9,0(r10)
c0669cd8: a1 4d 06 f0 lhz r10,1776(r13)
c0669cdc: 2c 2a 00 00 cmpdi r10,0
c0669ce0: 41 c2 00 08 beq-c0669ce8
<.ata_bmdma_stop+0x34>
c0669ce4: b1 4d 06 f2 sth r10,1778(r13)
c0669ce8: 4b ff ff a8 b c0669c90
<.ata_sff_dma_pause>
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/io.h | 154 ++-
arch/powerpc/kernel/iomap.c | 166 --
2 files changed, 153 insertions(+), 167 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 58635960403c..2469b46ac2c4 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -302,41 +302,56 @@ static inline unsigned char __raw_readb(const volatile
void __iomem *addr)
{
return *(volatile unsigned char __force *)PCI_FIX_ADDR(addr);
}
+#define __raw_readb __raw_readb
+
static inline unsigned short __raw_readw(const volatile void __iomem *addr)
{
return *(volatile unsigned short __force *)PCI_FIX_ADDR(addr);
}
+#define __raw_readw __raw_readw
+
static inline unsigned int __raw_readl(const volatile void __iomem *addr)
{
return *(volatile unsigned int __force *)PCI_FIX_ADDR(addr);
}
+#define __raw_readl __raw_readl
+
static inline void __raw_writeb(unsigned char v, volatile void __iomem *addr)
{
*(volatile unsigned char __force *)PCI_FIX_ADDR(addr) = v;
}
+#define __raw_writeb __raw_writeb
+
static inline void __raw_writew(unsigned short v, volatile void __iomem *addr)
{
*(volatile unsigned short __force *)PCI_FIX_ADDR(addr) = v;
}
+#define __raw_writew __raw_writew
+
static inline void __raw_writel(unsigned int v, volatile void __iomem *addr)
{
*(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v;
}
+#define __raw_writel __raw_writel
#ifdef __powerpc64__
static inline unsigned long __raw_readq(const volatile void __iomem *addr)
{
return *(volatile unsigned long __force *)PCI_FIX_ADDR(addr);
}
+#define __raw_readq __raw_readq
+
static inline void __raw_writeq(unsigned long v, volatile void __iomem *addr)
{
*(volatile unsigned long __force *)PCI_FIX_ADDR(addr) = v;
}
+#define __raw_writeq __raw_writeq
static inline void __raw_writeq_be(unsigned long v, volatile void __iomem
*add
Re: [PATCH v3] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
On Thu, Nov 12, 2020 at 03:32:54PM +0200, Laurentiu Tudor wrote: > From: Ionut-robert Aron > > Convert fsl,qoriq-mc to YAML in order to automate the verification > process of dts files. In addition, update MAINTAINERS accordingly > and, while at it, add some missing files. > > Signed-off-by: Ionut-robert Aron > [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] > Signed-off-by: Laurentiu Tudor > --- > Changes in v3: > - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with >reference to it > - fixed a dt_binding_check warning > Changes in v2: > - fixed errors reported by yamllint > - dropped multiple unnecessary quotes > - used schema instead of text in description > - added constraints on dpmac reg property > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 -- > .../bindings/misc/fsl,qoriq-mc.yaml | 187 + > .../ethernet/freescale/dpaa2/overview.rst | 5 +- > MAINTAINERS | 4 +- > 4 files changed, 194 insertions(+), 198 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > new file mode 100644 > index ..1dda2ad29717 > --- /dev/null > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > @@ -0,0 +1,187 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +# Copyright 2020 NXP > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/misc/fsl,qoriq-mc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +maintainers: > + - Laurentiu Tudor > + > +title: Freescale Management Complex > + > +description: | > + The Freescale Management Complex (fsl-mc) is a hardware resource > + manager that manages specialized hardware objects used in > + network-oriented packet processing applications. After the fsl-mc > + block is enabled, pools of hardware resources are available, such as > + queues, buffer pools, I/O interfaces. These resources are building > + blocks that can be used to create functional hardware objects/devices > + such as network interfaces, crypto accelerator instances, L2 switches, > + etc. > + > + For an overview of the DPAA2 architecture and fsl-mc bus see: > + Documentation/networking/device_drivers/freescale/dpaa2/overview.rst > + > + As described in the above overview, all DPAA2 objects in a DPRC share the > + same hardware "isolation context" and a 10-bit value called an ICID > + (isolation context id) is expressed by the hardware to identify > + the requester. > + > + The generic 'iommus' property is insufficient to describe the relationship > + between ICIDs and IOMMUs, so an iommu-map property is used to define > + the set of possible ICIDs under a root DPRC and how they map to > + an IOMMU. > + > + For generic IOMMU bindings, see: > + Documentation/devicetree/bindings/iommu/iommu.txt. > + > + For arm-smmu binding, see: > + Documentation/devicetree/bindings/iommu/arm,smmu.yaml. > + > + MC firmware binary images can be found here: > + https://github.com/NXP/qoriq-mc-binary > + > +properties: > + compatible: > +const: fsl,qoriq-mc > +description: > + A Freescale Management Complex compatible with this binding must have > + Block Revision Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in > + the MC control register region. > + > + reg: > +minItems: 1 > +items: > + - description: the command portal for this machine > + - description: > + MC control registers. This region may not be present in some > + scenarios, such as in the device tree presented to a virtual > + machine. > + > + ranges: > +description: | > + A standard property. Defines the mapping between the child MC address > + space and the parent system address space. > + > + The MC address space is defined by 3 components: > + > + > + Valid values for region type are: > + 0x0 - MC portals > + 0x1 - QBMAN portals > + > + '#address-cells': > +const: 3 > + > + '#size-cells': > +const: 1 > + > + dpmacs: > +type: object > +description: > + The fsl-mc node may optionally have dpmac sub-nodes that describe the > + relationship between the Ethernet MACs which belong to the MC and the > + Ethernet PHYs on the system board. > + > +properties: > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > +patternProperties: > + "^(dpmac@[0-9a-f]+)|(ethernet@[0-9a-f]+)$": > +type: object > + > +description: > + see Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml Use $ref here. > + > + iommu-map: > +description: |
Re: [PATCH v4 02/18] dt-bindings: usb: Convert generic USB properties to DT schemas
On Wed, 11 Nov 2020 12:08:37 +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 > > --- > > 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 > Reviewed-by: Rob Herring
Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote: > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote: > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote: > > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > > > Controller schema, but with additional vendor-specific properties, the > > > controller-specific reference clocks and PHYs. So let's convert the > > > currently available legacy text-based DWC USB3 bindings to the DT schema > > > and make sure the DWC USB3 nodes are also validated against the > > > usb-xhci.yaml schema. > > > > > > Note we have to discard the nodename restriction of being prefixed with > > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > > > are supposed to be named as "^usb(@.*)". > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Changelog v2: > > > - Discard '|' from the descriptions, since we don't need to preserve > > > the text formatting in any of them. > > > - Drop quotes from around the string constants. > > > - Fix the "clock-names" prop description to be referring the enumerated > > > clock-names instead of the ones from the Databook. > > > > > > Changelog v3: > > > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > > > as either host or otg. > > > > > > Changelog v4: > > > - Apply usb-drd.yaml schema first. If the controller is configured > > > to work in a gadget mode only, then apply the usb.yaml schema too, > > > otherwise apply the usb-xhci.yaml schema. > > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > > > time. > > > --- > > > .../devicetree/bindings/usb/dwc3.txt | 125 > > > .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++ > > > 2 files changed, 303 insertions(+), 125 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > > > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > new file mode 100644 > > > index ..079617891da6 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > @@ -0,0 +1,303 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Synopsys DesignWare USB3 Controller > > > + > > > +maintainers: > > > + - Felipe Balbi > > > + > > > +description: > > > + This is usually a subnode to DWC3 glue to which it is connected, but > > > can also > > > + be presented as a standalone DT node with an optional vendor-specific > > > + compatible string. > > > + > > > > +allOf: > > > + - $ref: usb-drd.yaml# > > > + - if: > > > + properties: > > > +dr_mode: > > > + const: peripheral Another thing, this evaluates to true if dr_mode is not present. You need to add 'required'? If dr_mode is otg, then don't you need to apply both usb.yaml and usb-xhci.yaml? > > > +then: > > > + $ref: usb.yaml# > > > > This part could be done in usb-drd.yaml? > > Originally I was thinking about that, but then in order to minimize > the properties validation I've decided to split the properties in > accordance with the USB controllers functionality: > > +- USB Gadget/Peripheral Controller. There is no > | specific schema for the gadgets since there is no > | common gadget properties (at least I failed to find > | ones). So the pure gadget controllers need to be > | validated just against usb.yaml schema. > | > usb.yaml <--+-- usb-hcd.yaml - Generic USB Host Controller. The schema > ^ turns out to include the OHCI/UHCI/EHCI > | properties, which AFAICS are also > | applicable for the other host controllers. > | So any USB host controller node needs to > | be validated against this schema. > | > +- usb-xhci.yaml - Generic xHCI Host controller. > > usb-drd.yaml -- USB Dual-Role/OTG Controllers. It describes the > DRD/OTG-specific properties and nothing else. So normally > it should be applied together with one of the > schemas described above. > > So the use-cases of the suggested schemas is following: > > 1) USB Controller is pure gadget? Then: >+ allOf: >+ - $ref: usb.yaml# > 2) USB Controller is pure USB host (including OHCI/UHCI/EHCI)? >+ allOf: >+ - $ref: usb-hcd.yaml# >Note this prevents us from fixing all the currently available USB DT >schemas, which already apply the usb-hcd.yaml s
Re: [PATCH] m68k: Fix WARNING splat in pmac_zilog driver
Hi Finn,
On Sat, Nov 21, 2020 at 12:47 AM Finn Thain wrote:
> On Fri, 20 Nov 2020, Geert Uytterhoeven wrote:
> > On Fri, Nov 20, 2020 at 5:51 AM Finn Thain
> > wrote:
> > > Don't add platform resources that won't be used. This avoids a
> > > recently-added warning from the driver core, that can show up on a
> > > multi-platform kernel when !MACH_IS_MAC.
> > >
> > > [ cut here ]
> > > WARNING: CPU: 0 PID: 0 at drivers/base/platform.c:224
> > > platform_get_irq_optional+0x8e/0xce
> > > 0 is an invalid IRQ number
> > > Modules linked in:
> > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-multi #1
> > > Stack from 004b3f04:
> > > 004b3f04 00462c2f 00462c2f 004b3f20 0002e128 004754db 004b6ad4
> > > 004b3f4c
> > > 0002e19c 004754f7 00e0 00285ba0 0009 004b3f44
> > >
> > > 004754db 004b3f64 004b3f74 00285ba0 004754f7 00e0 0009
> > > 004754db
> > > 004fdf0c 005269e2 004fdf0c 004b3f88 00285cae 004b6964
> > >
> > > 004fdf0c 004b3fac 0051cc68 004b6964 004b6964 0200
> > >
> > > 0051cc3e 0023c18a 004b3fc0 0051cd8a 004fdf0c 0002 0052b43c
> > > 004b3fc8
> > > Call Trace: [<0002e128>] __warn+0xa6/0xd6
> > > [<0002e19c>] warn_slowpath_fmt+0x44/0x76
> > > [<00285ba0>] platform_get_irq_optional+0x8e/0xce
> > > [<00285ba0>] platform_get_irq_optional+0x8e/0xce
> > > [<00285cae>] platform_get_irq+0x12/0x4c
> > > [<0051cc68>] pmz_init_port+0x2a/0xa6
> > > [<0051cc3e>] pmz_init_port+0x0/0xa6
> > > [<0023c18a>] strlen+0x0/0x22
> > > [<0051cd8a>] pmz_probe+0x34/0x88
> > > [<0051cde6>] pmz_console_init+0x8/0x28
> > > [<00511776>] console_init+0x1e/0x28
> > > [<0005a3bc>] printk+0x0/0x16
> > > [<0050a8a6>] start_kernel+0x368/0x4ce
> > > [<005094f8>] _sinittext+0x4f8/0xc48
> > > random: get_random_bytes called from print_oops_end_marker+0x56/0x80 with
> > > crng_init=0
> > > ---[ end trace 392d8e82eed68d6c ]---
> > >
> > > Cc: Michael Ellerman
> > > Cc: Benjamin Herrenschmidt
> > > Cc: Paul Mackerras
> > > Cc: Joshua Thompson
> > > Cc: Greg Kroah-Hartman
> > > Cc: Jiri Slaby
> > > Cc: sta...@vger.kernel.org # v5.8+
> > > References: commit a85a6c86c25b ("driver core: platform: Clarify that IRQ
> > > 0 is invalid")
> > > Reported-by: Laurent Vivier
> > > Signed-off-by: Finn Thain
> > > ---
> > > The global platform_device structs provide the equivalent of a direct
> > > search of the OpenFirmware tree, for platforms that don't have OF.
> > > The purpose of that search is discussed in the comments in pmac_zilog.c:
> > >
> > > * First, we need to do a direct OF-based probe pass. We
> > > * do that because we want serial console up before the
> > > * macio stuffs calls us back
> > >
> > > The actual platform bus matching takes place later, with a
> > > module_initcall,
> > > following the usual pattern.
> >
> > I think it would be good for this explanation to be part of the
> > actual patch description above.
> >
>
> Thanks for your review.
>
> I take that explanation as read because it was fundamental to the changes
> I made to pmac_zilog.c back in 2009 with commit ec9cbe09899e ("pmac-zilog:
> add platform driver").
That's a long time ago ;-)
I asked because to the casual reader, it's far from obvious why the platform
device use-time is different from the platform device's resources use-time.
> IMO, being that it isn't news, it doesn't belong in the changelog.
> However, I agree that it needs to be documented. How about I add a comment
> to pmac_zilog.c?
Fine for me.
> > > --- a/drivers/tty/serial/pmac_zilog.c
> > > +++ b/drivers/tty/serial/pmac_zilog.c
> > > @@ -1697,18 +1697,17 @@ extern struct platform_device scc_a_pdev,
> > > scc_b_pdev;
> > >
> > > static int __init pmz_init_port(struct uart_pmac_port *uap)
> > > {
> > > - struct resource *r_ports;
> > > - int irq;
> > > + struct resource *r_ports, *r_irq;
> > >
> > > r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0);
> > > - irq = platform_get_irq(uap->pdev, 0);
> > > - if (!r_ports || irq <= 0)
> > > + r_irq = platform_get_resource(uap->pdev, IORESOURCE_IRQ, 0);
> > > + if (!r_ports || !r_irq)
> > > return -ENODEV;
> > >
> > > uap->port.mapbase = r_ports->start;
> > > uap->port.membase = (unsigned char __iomem *) r_ports->start;
> > > uap->port.iotype = UPIO_MEM;
> > > - uap->port.irq = irq;
> > > + uap->port.irq = r_irq->start;
> > > uap->port.uartclk = ZS_CLOCK;
> > > uap->port.fifosize = 1;
> > > uap->port.ops = &pmz_pops;
> >
> > Given the resources are no longer present on !MAC, just doing
> >
> > r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0);
> > + if (!r_ports)
> > + return -ENODEV;
> > irq = platform_get_irq(uap->pdev, 0);
> >
> > shoul
