[powerpc:merge] BUILD SUCCESS 598b738031de83cadbcf745ad0ad2bd69a0ee012
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 598b738031de83cadbcf745ad0ad2bd69a0ee012 Automatic merge of 'master' into merge (2020-10-20 23:14) elapsed time: 928m configs tested: 128 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm colibri_pxa300_defconfig sh kfr2r09_defconfig mips maltasmvp_eva_defconfig m68k apollo_defconfig arm aspeed_g5_defconfig sh se7722_defconfig alphaalldefconfig m68k amcore_defconfig mipse55_defconfig shsh7757lcr_defconfig ia64 allmodconfig m68kmvme16x_defconfig shecovec24-romimage_defconfig mips loongson3_defconfig mipsmalta_kvm_guest_defconfig mipsworkpad_defconfig powerpcklondike_defconfig sh ecovec24_defconfig xtensa nommu_kc705_defconfig nios2 defconfig arm ebsa110_defconfig powerpc pcm030_defconfig cskydefconfig powerpc64alldefconfig mips lemote2f_defconfig powerpc mpc836x_rdk_defconfig s390 debug_defconfig powerpc ppc64_defconfig shshmin_defconfig arm viper_defconfig powerpc iss476-smp_defconfig powerpc bluestone_defconfig sh ap325rxa_defconfig arm at91_dt_defconfig arm milbeaut_m10v_defconfig mips mpc30x_defconfig mips ath79_defconfig armvt8500_v6_v7_defconfig powerpc mpc832x_rdb_defconfig mips rm200_defconfig pariscgeneric-64bit_defconfig armmps2_defconfig sh urquell_defconfig arm stm32_defconfig powerpc canyonlands_defconfig openrisc simple_smp_defconfig h8300 edosk2674_defconfig x86_64 defconfig powerpc mpc836x_mds_defconfig arc axs103_defconfig sh sh7724_generic_defconfig openriscdefconfig mips malta_defconfig powerpc stx_gp3_defconfig powerpc mpc866_ads_defconfig arm pxa3xx_defconfig nios2alldefconfig powerpc mpc8560_ads_defconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20201020 i386 randconfig-a005-20201020 i386 randconfig-a003-20201020 i386 randconfig-a001-20201020 i386 randconfig-a006-20201020 i386 randconfig-a004-20201020 x86_64 randconfig-a011-20201020 x86_64 randconfig-a013-20201020 x86_64
[powerpc:fixes-test] BUILD SUCCESS d1781f23704707d350b8c9006e2bdf5394bf91b2
tqm8540_defconfig powerpc pmac32_defconfig powerpc mpc834x_itx_defconfig sparc64 defconfig powerpc taishan_defconfig sh sh7785lcr_32bit_defconfig umkunit_defconfig x86_64 allyesconfig powerpc mpc832x_rdb_defconfig mips rm200_defconfig pariscgeneric-64bit_defconfig armmps2_defconfig sh urquell_defconfig arm stm32_defconfig powerpc canyonlands_defconfig arm omap2plus_defconfig powerpc acadia_defconfig h8300 edosk2674_defconfig x86_64 defconfig powerpc mpc836x_mds_defconfig arc axs103_defconfig xtensa virt_defconfig arm eseries_pxa_defconfig arm assabet_defconfig shmigor_defconfig ia64 alldefconfig openriscdefconfig mips malta_defconfig xtensaxip_kc705_defconfig m68k amiga_defconfig arc nsimosci_hs_defconfig arm aspeed_g4_defconfig arm moxart_defconfig powerpc rainier_defconfig arm badge4_defconfig m68k multi_defconfig arm corgi_defconfig parisc defconfig ia64generic_defconfig powerpcmpc7448_hpc2_defconfig mips maltaaprp_defconfig mips rt305x_defconfig m68k m5249evb_defconfig xtensa iss_defconfig mipsnlm_xlr_defconfig sh polaris_defconfig powerpc mpc8313_rdb_defconfig arm imx_v6_v7_defconfig riscv defconfig powerpc mpc866_ads_defconfig arm pxa3xx_defconfig nios2alldefconfig powerpc mpc8560_ads_defconfig armzeus_defconfig xtensa cadence_csp_defconfig arc allyesconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig sh allmodconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20201020 i386 randconfig-a005-20201020 i386 randconfig-a003-20201020 i386 randconfig-a001-20201020 i386 randconfig-a006-20201020 i386 randconfig-a004-20201020 x86_64 randconfig-a011-20201020 x86_64 randconfig-a013-20201020 x86_64 randconfig-a016-20201020 x86_64 randconfig-a015-20201020 x86_64 randconfig-a012-20201020 x86_64 randconfig-a014-20201020 i386 randconfig-a016-20201020 i386 randconfig-a014-20201020 i386 randconfig-a015-20201020 i386 randconfig-a013-20201020 i386 randconfig-a012-20201020 i386 randconfig-a011-20201020 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a001-20201020 x86_64 randconfig-a002
[PATCH kernel 1/2] Revert "dma-mapping: move large parts of to kernel/dma"
This reverts commit 19c65c3d30bb5a97170e425979d2e44ab2096c7d which
was a right move but sadly there is a POWERPC/pseries hardware config
which uses a mixture of direct and IOMMU DMA but bringing this
logic to the generic code won't benefit anybody else. The user of
this revert comes in the next patch.
Signed-off-by: Alexey Kardashevskiy
---
include/linux/dma-direct.h | 106 +
kernel/dma/direct.h| 119 -
kernel/dma/direct.c| 2 +-
kernel/dma/mapping.c | 2 +-
4 files changed, 108 insertions(+), 121 deletions(-)
delete mode 100644 kernel/dma/direct.h
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 18aade195884..e388b77e0048 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -120,8 +120,114 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir);
+int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
+bool dma_direct_can_mmap(struct device *dev);
+int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
int dma_direct_supported(struct device *dev, u64 mask);
+bool dma_direct_need_sync(struct device *dev, dma_addr_t dma_addr);
+int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, unsigned long attrs);
dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir, unsigned long attrs);
+size_t dma_direct_max_mapping_size(struct device *dev);
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir);
+#else
+static inline void dma_direct_sync_sg_for_device(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
+defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir, unsigned long attrs);
+void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction
dir);
+#else
+static inline void dma_direct_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+}
+static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+static inline void dma_direct_sync_single_for_device(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
+
+ if (!dev_is_dma_coherent(dev))
+ arch_sync_dma_for_device(paddr, size, dir);
+}
+
+static inline void dma_direct_sync_single_for_cpu(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (!dev_is_dma_coherent(dev)) {
+ arch_sync_dma_for_cpu(paddr, size, dir);
+ arch_sync_dma_for_cpu_all();
+ }
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
+
+ if (dir == DMA_FROM_DEVICE)
+ arch_dma_mark_clean(paddr, size);
+}
+
+static inline dma_addr_t dma_direct_map_page(struct device *dev,
+ struct page *page, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ phys_addr_t phys = page_to_phys(page) + offset;
+ dma_addr_t dma_addr = phys_to_dma(dev, phys);
+
+ if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
+ if (swiotlb_force != SWIOTLB_NO_FORCE)
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ dev_WARN_ONCE(dev, 1,
+"DMA addr %pad+%zu overflow (mask %llx, bus limit
%llx).\n",
+_addr, size, *dev->dma_mask,
dev->bus_dma_limit);
+
[PATCH kernel 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present
So far we have been using huge DMA windows to map all the RAM available.
The RAM is normally mapped to the VM address space contiguously, and
there is always a reasonable upper limit for possible future hot plugged
RAM which makes it easy to map all RAM via IOMMU.
Now there is persistent memory ("ibm,pmemory" in the FDT) which (unlike
normal RAM) can map anywhere in the VM space beyond the maximum RAM size
and since it can be used for DMA, it requires extending the huge window
up to MAX_PHYSMEM_BITS which requires hypervisor support for:
1. huge TCE tables;
2. multilevel TCE tables;
3. huge IOMMU pages.
Certain hypervisors cannot do either so the only option left is
restricting the huge DMA window to include only RAM and fallback to
the default DMA window for persistent memory.
This checks if the system has persistent memory. If it does not,
the DMA bypass mode is selected, i.e.
* dev->bus_dma_limit = 0
* dev->dma_ops_bypass = true <- this avoid calling dma_ops for mapping.
If there is such memory, this creates identity mapping only for RAM and
disables the DMA bypass mode which makes generic DMA code use indirect
dma_ops which may have performance impact:
* dev->bus_dma_limit = bus_offset + max_ram_size
for example 0x0800..8000. for a 2GB VM
* dev->dma_ops_bypass = false <- this forces indirect calls to dma_ops for
every mapping which then directs these to small or huge window.
This should not change the existing behaviour when no persistent memory.
Signed-off-by: Alexey Kardashevskiy
---
Without reverting 19c65c3d30bb5a97170, I could have added
I can repost if this is preferrable. Thanks.
---
Changelog:
v2:
* rebased on current upstream with the device::bypass added and DMA
direct code movement reverted
---
arch/powerpc/kernel/dma-iommu.c| 68 +-
arch/powerpc/platforms/pseries/iommu.c | 41 +---
2 files changed, 99 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a1c744194018..9a2a3b95f72d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -10,6 +10,16 @@
#include
#include
+static inline bool can_map_direct(struct device *dev, phys_addr_t addr)
+{
+ return dev->bus_dma_limit >= phys_to_dma(dev, addr);
+}
+
+static inline bool dma_handle_direct(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle >= dev->archdata.dma_offset;
+}
+
/*
* Generic iommu implementation
*/
@@ -44,6 +54,12 @@ static dma_addr_t dma_iommu_map_page(struct device *dev,
struct page *page,
enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ can_map_direct(dev, (phys_addr_t) page_to_phys(page) +
+ offset + size))
+ return dma_direct_map_page(dev, page, offset, size, direction,
+ attrs);
+
return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
size, dma_get_mask(dev), direction, attrs);
}
@@ -53,6 +69,12 @@ static void dma_iommu_unmap_page(struct device *dev,
dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ dma_handle_direct(dev, dma_handle + size)) {
+ dma_direct_unmap_page(dev, dma_handle, size, direction, attrs);
+ return;
+ }
+
iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
attrs);
}
@@ -62,6 +84,22 @@ static int dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct = true;
+ int i;
+
+ for_each_sg(sglist, s, nelems, i) {
+ direct = can_map_direct(dev,
+ sg_phys(s) + s->offset + s->length);
+ if (!direct)
+ break;
+ }
+ if (direct)
+ return dma_direct_map_sg(dev, sglist, nelems, direction,
+attrs);
+ }
+
return ppc_iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
dma_get_mask(dev), direction, attrs);
}
@@ -70,6 +108,24 @@ static void dma_iommu_unmap_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct
Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote:
> The generic USB HCD properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert it' content into the USB HCD DT schema properties so all USB DT
^ its?
> nodes would be validated to have them properly utilized.
>
> 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.
> ---
> .../devicetree/bindings/usb/generic.txt | 57
> .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++
Do we need change the file name or modify it's title?
the title is "Generic USB Host Controller Device Tree Bindings", but
some generic properties, such as, dr_mode, usb-role-switch, otg related
ones, are usually used by DRD controller, this may cause some confusion.
> 2 files changed, 88 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
>
> 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 = <_phy>, <,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> index 7263b7f2b510..ee7ea205c71d 100644
> --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> @@ -22,9 +22,97 @@ properties:
> description:
>Name specifier for the USB PHY
>
[PATCH kernel 0/2] powerpc/dma: Fallback to dma_ops when persistent memory present
This allows mixing direct DMA (to/from RAM) and IOMMU (to/from apersistent memory) on the PPC64/pseries platform. This was supposed to be a single patch but unexpected move of direct DMA functions happened. This is based on sha1 7cf726a59435 Linus Torvalds "Merge tag 'linux-kselftest-kunit-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest". Please comment. Thanks. Alexey Kardashevskiy (2): Revert "dma-mapping: move large parts of to kernel/dma" powerpc/dma: Fallback to dma_ops when persistent memory present include/linux/dma-direct.h | 106 ++ kernel/dma/direct.h| 119 - arch/powerpc/kernel/dma-iommu.c| 68 +- arch/powerpc/platforms/pseries/iommu.c | 41 +++-- kernel/dma/direct.c| 2 +- kernel/dma/mapping.c | 2 +- 6 files changed, 207 insertions(+), 131 deletions(-) delete mode 100644 kernel/dma/direct.h -- 2.17.1
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, 20 Oct 2020, Brad Boyer wrote: > > Wouldn't it be better to rearrange this code to only run if the devices > are present? This is a macio driver on pmac and a platform driver on > mac, so shouldn't it be possible to only run this code when the > appropriate entries are present in the right data structures? > > I didn't look at a lot of the other serial drivers, but some other mac > drivers have recently been updated to no longer have MACH_IS_MAC checks > due to being converted to platform drivers. > Actually, it's not simply a platform driver or macio driver. I think the console is supposed to be registered before the normal bus matching takes place. Hence this comment 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, and since that makes it * easier to pass the proper number of channels to * uart_register_driver() */ Laurent, can we avoid the irq == 0 warning splat like this? diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c index 96e7aa479961..7db600cd8cc7 100644 --- a/drivers/tty/serial/pmac_zilog.c +++ b/drivers/tty/serial/pmac_zilog.c @@ -1701,8 +1701,10 @@ static int __init pmz_init_port(struct uart_pmac_port *uap) int irq; r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0); + if (!r_ports) + return -ENODEV; irq = platform_get_irq(uap->pdev, 0); - if (!r_ports || irq <= 0) + if (irq <= 0) return -ENODEV; uap->port.mapbase = r_ports->start;
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, Oct 20, 2020 at 08:42:53PM +0200, Laurent Vivier wrote: > Le 20/10/2020 ?? 20:32, Greg KH a ??crit??: > > On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote: > >> Le 20/10/2020 ?? 19:37, Greg KH a ??crit??: > >>> Why not fix it to work properly like other arch checks are done > >> I would be happy to do the same. > >> > >>> Put it in a .h file and do the #ifdef there. Why is this "special"? > >> > >> I don't know. > >> > > > > Yup, that would be a good start, but why is the pmac_zilog.h file > > responsible for this? Shouldn't this be in some arch-specific file > > somewhere? > > For m68k, MACH_IS_MAC is defined in arch/m68k/include/asm/setup.h > > If I want to define it for any other archs I don't know in which file we > can put it. > > But as m68k mac is only sharing drivers with pmac perhaps we can put > this in arch/powerpc/include/asm/setup.h? Wouldn't it be better to rearrange this code to only run if the devices are present? This is a macio driver on pmac and a platform driver on mac, so shouldn't it be possible to only run this code when the appropriate entries are present in the right data structures? I didn't look at a lot of the other serial drivers, but some other mac drivers have recently been updated to no longer have MACH_IS_MAC checks due to being converted to platform drivers. Brad Boyer b...@allandria.com
Re: [PATCH v3 05/16] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
On Tue, Oct 20, 2020 at 1:21 PM Serge Semin wrote: > > Even though the Generic PHY framework is the more preferable way of > setting the USB PHY up, there are still many dts-files and DT bindings > which rely on having the legacy "usb-phy" specified to attach particular > USB PHYs to USB cores. Let's have the "usb-phy" property described in > the generic USB HCD binding file so it would be validated against the > nodes in which it's specified. Mark the property as deprecated to > discourage the developers from using it. > > Signed-off-by: Serge Semin > Reviewed-by: Rob Herring Acked-by: Martin Blumenstingl
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
Le 20/10/2020 à 20:32, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 19:37, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
Le 20/10/2020 à 18:28, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>> We can avoid to probe for the Zilog device (and generate ugly kernel
>> warning)
>> if kernel is built for Mac but not on a Mac.
>>
>> Signed-off-by: Laurent Vivier
>> ---
>> drivers/tty/serial/pmac_zilog.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/tty/serial/pmac_zilog.c
>> b/drivers/tty/serial/pmac_zilog.c
>> index 063484b22523..d1d2e55983c3 100644
>> --- a/drivers/tty/serial/pmac_zilog.c
>> +++ b/drivers/tty/serial/pmac_zilog.c
>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>> static int __init init_pmz(void)
>> {
>> int rc, i;
>> +
>> +#ifdef CONFIG_MAC
>> +if (!MACH_IS_MAC)
>> +return -ENODEV;
>> +#endif
>
> Why is the #ifdef needed?
>
> We don't like putting #ifdef in .c files for good reasons. Can you make
> the api check for this work with and without that #ifdef needed?
The #ifdef is needed because this file can be compiled for PowerMac and
m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
#ifdef.
We need the MAC_IS_MAC because the same kernel can be used with several
m68k machines, so the init_pmz can be called on a m68k machine without
the zilog device (it's a multi-targets kernel).
You can check it's the good way to do by looking inside:
drivers/video/fbdev/valkyriefb.c +317
drivers/macintosh/adb.c +316
That are two files used by both, mac and pmac.
>>>
>>> Why not fix it to work properly like other arch checks are done
>> I would be happy to do the same.
>>
>>> Put it in a .h file and do the #ifdef there. Why is this "special"?
>>
>> I don't know.
>>
>> Do you mean something like:
>>
>> drivers/tty/serial/pmac_zilog.h
>> ...
>> #ifndef MACH_IS_MAC
>> #define MACH_IS_MAC (0)
>> #endif
>> ...
>>
>> drivers/tty/serial/pmac_zilog.c
>> ...
>> static int __init pmz_console_init(void)
>> {
>> if (!MACH_IS_MAC)
>> return -ENODEV;
>> ...
>
> Yup, that would be a good start, but why is the pmac_zilog.h file
> responsible for this? Shouldn't this be in some arch-specific file
> somewhere?
For m68k, MACH_IS_MAC is defined in arch/m68k/include/asm/setup.h
If I want to define it for any other archs I don't know in which file we
can put it.
But as m68k mac is only sharing drivers with pmac perhaps we can put
this in arch/powerpc/include/asm/setup.h?
Thanks,
Laurent
Re: mm: Question about the use of 'accessed' flags and pte_young() helper
On Tue, Oct 20, 2020 at 05:52:07PM +0200, Vlastimil Babka wrote: > On 10/8/20 11:49 AM, Christophe Leroy wrote: > > In a 10 years old commit > > (https://github.com/linuxppc/linux/commit/d069cb4373fe0d451357c4d3769623a7564dfa9f), > > powerpc 8xx has > > made the handling of PTE accessed bit conditional to CONFIG_SWAP. > > Since then, this has been extended to some other powerpc variants. > > > > That commit means that when CONFIG_SWAP is not selected, the accessed bit > > is not set by SW TLB miss > > handlers, leading to pte_young() returning garbage, or should I say > > possibly returning false > > allthough a page has been accessed since its access flag was reset. > > > > Looking at various mm/ places, pte_young() is used independent of > > CONFIG_SWAP > > > > Is it still valid the not manage accessed flags when CONFIG_SWAP is not > > selected ? > > AFAIK it's wrong, reclaim needs it to detect accessed pages on inactive > list, via page_referenced(), including file pages (page cache) where > CONFIG_SWAP plays no role. Maybe it was different 10 years ago. Yes, we require this bit for properly aging mmapped file pages. The underlying assumption in the referenced commit is incorrect. > > If yes, should pte_young() always return true in that case ? > > It should best work as intended. If not possible, true is maybe better, as > false will lead to inactive file list thrashing. An unconditional true will cause mmapped file pages to be permanently mlocked / unevictable. Either way will break some workloads. The only good answer is the truth :-)
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
> Le 20/10/2020 à 19:37, Greg KH a écrit :
> > On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
> >> Le 20/10/2020 à 18:28, Greg KH a écrit :
> >>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> We can avoid to probe for the Zilog device (and generate ugly kernel
> warning)
> if kernel is built for Mac but not on a Mac.
>
> Signed-off-by: Laurent Vivier
> ---
> drivers/tty/serial/pmac_zilog.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/tty/serial/pmac_zilog.c
> b/drivers/tty/serial/pmac_zilog.c
> index 063484b22523..d1d2e55983c3 100644
> --- a/drivers/tty/serial/pmac_zilog.c
> +++ b/drivers/tty/serial/pmac_zilog.c
> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
> static int __init init_pmz(void)
> {
> int rc, i;
> +
> +#ifdef CONFIG_MAC
> +if (!MACH_IS_MAC)
> +return -ENODEV;
> +#endif
> >>>
> >>> Why is the #ifdef needed?
> >>>
> >>> We don't like putting #ifdef in .c files for good reasons. Can you make
> >>> the api check for this work with and without that #ifdef needed?
> >>
> >> The #ifdef is needed because this file can be compiled for PowerMac and
> >> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
> >> #ifdef.
> >>
> >> We need the MAC_IS_MAC because the same kernel can be used with several
> >> m68k machines, so the init_pmz can be called on a m68k machine without
> >> the zilog device (it's a multi-targets kernel).
> >>
> >> You can check it's the good way to do by looking inside:
> >>
> >> drivers/video/fbdev/valkyriefb.c +317
> >> drivers/macintosh/adb.c +316
> >>
> >> That are two files used by both, mac and pmac.
> >
> > Why not fix it to work properly like other arch checks are done
> I would be happy to do the same.
>
> > Put it in a .h file and do the #ifdef there. Why is this "special"?
>
> I don't know.
>
> Do you mean something like:
>
> drivers/tty/serial/pmac_zilog.h
> ...
> #ifndef MACH_IS_MAC
> #define MACH_IS_MAC (0)
> #endif
> ...
>
> drivers/tty/serial/pmac_zilog.c
> ...
> static int __init pmz_console_init(void)
> {
> if (!MACH_IS_MAC)
> return -ENODEV;
> ...
Yup, that would be a good start, but why is the pmac_zilog.h file
responsible for this? Shouldn't this be in some arch-specific file
somewhere?
thanks,
greg k-h
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
Le 20/10/2020 à 19:37, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 18:28, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
We can avoid to probe for the Zilog device (and generate ugly kernel
warning)
if kernel is built for Mac but not on a Mac.
Signed-off-by: Laurent Vivier
---
drivers/tty/serial/pmac_zilog.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/pmac_zilog.c
b/drivers/tty/serial/pmac_zilog.c
index 063484b22523..d1d2e55983c3 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
static int __init init_pmz(void)
{
int rc, i;
+
+#ifdef CONFIG_MAC
+ if (!MACH_IS_MAC)
+ return -ENODEV;
+#endif
>>>
>>> Why is the #ifdef needed?
>>>
>>> We don't like putting #ifdef in .c files for good reasons. Can you make
>>> the api check for this work with and without that #ifdef needed?
>>
>> The #ifdef is needed because this file can be compiled for PowerMac and
>> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
>> #ifdef.
>>
>> We need the MAC_IS_MAC because the same kernel can be used with several
>> m68k machines, so the init_pmz can be called on a m68k machine without
>> the zilog device (it's a multi-targets kernel).
>>
>> You can check it's the good way to do by looking inside:
>>
>> drivers/video/fbdev/valkyriefb.c +317
>> drivers/macintosh/adb.c +316
>>
>> That are two files used by both, mac and pmac.
>
> Why not fix it to work properly like other arch checks are done
I would be happy to do the same.
> Put it in a .h file and do the #ifdef there. Why is this "special"?
I don't know.
Do you mean something like:
drivers/tty/serial/pmac_zilog.h
...
#ifndef MACH_IS_MAC
#define MACH_IS_MAC (0)
#endif
...
drivers/tty/serial/pmac_zilog.c
...
static int __init pmz_console_init(void)
{
if (!MACH_IS_MAC)
return -ENODEV;
...
Thanks,
Laurent
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
> Le 20/10/2020 à 18:28, Greg KH a écrit :
> > On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> >> We can avoid to probe for the Zilog device (and generate ugly kernel
> >> warning)
> >> if kernel is built for Mac but not on a Mac.
> >>
> >> Signed-off-by: Laurent Vivier
> >> ---
> >> drivers/tty/serial/pmac_zilog.c | 11 +++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/tty/serial/pmac_zilog.c
> >> b/drivers/tty/serial/pmac_zilog.c
> >> index 063484b22523..d1d2e55983c3 100644
> >> --- a/drivers/tty/serial/pmac_zilog.c
> >> +++ b/drivers/tty/serial/pmac_zilog.c
> >> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
> >> static int __init init_pmz(void)
> >> {
> >>int rc, i;
> >> +
> >> +#ifdef CONFIG_MAC
> >> + if (!MACH_IS_MAC)
> >> + return -ENODEV;
> >> +#endif
> >
> > Why is the #ifdef needed?
> >
> > We don't like putting #ifdef in .c files for good reasons. Can you make
> > the api check for this work with and without that #ifdef needed?
>
> The #ifdef is needed because this file can be compiled for PowerMac and
> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
> #ifdef.
>
> We need the MAC_IS_MAC because the same kernel can be used with several
> m68k machines, so the init_pmz can be called on a m68k machine without
> the zilog device (it's a multi-targets kernel).
>
> You can check it's the good way to do by looking inside:
>
> drivers/video/fbdev/valkyriefb.c +317
> drivers/macintosh/adb.c +316
>
> That are two files used by both, mac and pmac.
Why not fix it to work properly like other arch checks are done?
Put it in a .h file and do the #ifdef there. Why is this "special"?
thanks,
greg k-h
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
Le 20/10/2020 à 18:28, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
>> if kernel is built for Mac but not on a Mac.
>>
>> Signed-off-by: Laurent Vivier
>> ---
>> drivers/tty/serial/pmac_zilog.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/tty/serial/pmac_zilog.c
>> b/drivers/tty/serial/pmac_zilog.c
>> index 063484b22523..d1d2e55983c3 100644
>> --- a/drivers/tty/serial/pmac_zilog.c
>> +++ b/drivers/tty/serial/pmac_zilog.c
>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>> static int __init init_pmz(void)
>> {
>> int rc, i;
>> +
>> +#ifdef CONFIG_MAC
>> +if (!MACH_IS_MAC)
>> +return -ENODEV;
>> +#endif
>
> Why is the #ifdef needed?
>
> We don't like putting #ifdef in .c files for good reasons. Can you make
> the api check for this work with and without that #ifdef needed?
The #ifdef is needed because this file can be compiled for PowerMac and
m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
#ifdef.
We need the MAC_IS_MAC because the same kernel can be used with several
m68k machines, so the init_pmz can be called on a m68k machine without
the zilog device (it's a multi-targets kernel).
You can check it's the good way to do by looking inside:
drivers/video/fbdev/valkyriefb.c +317
drivers/macintosh/adb.c +316
That are two files used by both, mac and pmac.
Thanks,
Laurent
[PATCH] serial: pmac_zilog: don't init if zilog is not available
We can avoid to probe for the Zilog device (and generate ugly kernel warning)
if kernel is built for Mac but not on a Mac.
Signed-off-by: Laurent Vivier
---
drivers/tty/serial/pmac_zilog.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index 063484b22523..d1d2e55983c3 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
static int __init init_pmz(void)
{
int rc, i;
+
+#ifdef CONFIG_MAC
+ if (!MACH_IS_MAC)
+ return -ENODEV;
+#endif
+
printk(KERN_INFO "%s\n", version);
/*
@@ -2034,6 +2040,11 @@ static int __init pmz_console_setup(struct console *co,
char *options)
static int __init pmz_console_init(void)
{
+#ifdef CONFIG_MAC
+ if (!MACH_IS_MAC)
+ return -ENODEV;
+#endif
+
/* Probe ports */
pmz_probe();
--
2.26.2
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
> if kernel is built for Mac but not on a Mac.
>
> Signed-off-by: Laurent Vivier
> ---
> drivers/tty/serial/pmac_zilog.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> index 063484b22523..d1d2e55983c3 100644
> --- a/drivers/tty/serial/pmac_zilog.c
> +++ b/drivers/tty/serial/pmac_zilog.c
> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
> static int __init init_pmz(void)
> {
> int rc, i;
> +
> +#ifdef CONFIG_MAC
> + if (!MACH_IS_MAC)
> + return -ENODEV;
> +#endif
Why is the #ifdef needed?
We don't like putting #ifdef in .c files for good reasons. Can you make
the api check for this work with and without that #ifdef needed?
thanks,
greg k-h
Re: mm: Question about the use of 'accessed' flags and pte_young() helper
On 10/8/20 11:49 AM, Christophe Leroy wrote: In a 10 years old commit (https://github.com/linuxppc/linux/commit/d069cb4373fe0d451357c4d3769623a7564dfa9f), powerpc 8xx has made the handling of PTE accessed bit conditional to CONFIG_SWAP. Since then, this has been extended to some other powerpc variants. That commit means that when CONFIG_SWAP is not selected, the accessed bit is not set by SW TLB miss handlers, leading to pte_young() returning garbage, or should I say possibly returning false allthough a page has been accessed since its access flag was reset. Looking at various mm/ places, pte_young() is used independent of CONFIG_SWAP Is it still valid the not manage accessed flags when CONFIG_SWAP is not selected ? AFAIK it's wrong, reclaim needs it to detect accessed pages on inactive list, via page_referenced(), including file pages (page cache) where CONFIG_SWAP plays no role. Maybe it was different 10 years ago. If yes, should pte_young() always return true in that case ? It should best work as intended. If not possible, true is maybe better, as false will lead to inactive file list thrashing. While we are at it, I'm wondering whether powerpc should redefine arch_faults_on_old_pte() On some variants of powerpc, accessed flag is managed by HW. On others, it is managed by SW TLB miss handlers via page fault handling. Thanks Christophe
Re: [PATCH v3 09/16] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Tue, 20 Oct 2020 14:20:54 +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. > --- > .../devicetree/bindings/usb/dwc3.txt | 125 > .../devicetree/bindings/usb/snps,dwc3.yaml| 302 ++ > 2 files changed, 302 insertions(+), 125 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > Reviewed-by: Rob Herring
Re: [PATCH 15/29] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
On Tue, Oct 20, 2020 at 02:59:45PM +0300, Serge Semin wrote: > In accordance with the Generic EHCI/OHCI bindings the corresponding node > name is suppose to comply with the Generic USB HCD DT schema, which > requires the USB nodes to have the name acceptable by the regexp: > "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible > nodes are correctly named. > > Signed-off-by: Serge Semin > --- > arch/powerpc/boot/dts/akebono.dts | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 0/2] Fixes for coregroup
On Mon, 19 Oct 2020 09:57:14 +0530, Srikar Dronamraju wrote: > These patches fixes problems introduced by the coregroup patches. > The first patch we remove a redundant variable. > Second patch allows to boot with CONFIG_CPUMASK_OFFSTACK enabled. > > Changelog v1->v2: > https://lore.kernel.org/linuxppc-dev/20201008034240.34059-1-sri...@linux.vnet.ibm.com/t/#u > 1. 1st patch was not part of previous posting. > 2. Updated 2nd patch based on comments from Michael Ellerman > > [...] Applied to powerpc/fixes. [1/2] powerpc/smp: Remove unnecessary variable https://git.kernel.org/powerpc/c/966730a6e8524c1b5fe64358e5884605cab6ccb3 [2/2] powerpc/smp: Use GFP_ATOMIC while allocating tmp mask https://git.kernel.org/powerpc/c/84dbf66c63472069e5eb40b810731367618cd8b5 cheers
Re: [PATCH 1/2] powerpc: Fix user data corruption with P9N DD2.1 VSX CI load workaround emulation
On Tue, 13 Oct 2020 15:37:40 +1100, Michael Neuling wrote: > __get_user_atomic_128_aligned() stores to kaddr using stvx which is a > VMX store instruction, hence kaddr must be 16 byte aligned otherwise > the store won't occur as expected. > > Unfortunately when we call __get_user_atomic_128_aligned() in > p9_hmi_special_emu(), the buffer we pass as kaddr (ie. vbuf) isn't > guaranteed to be 16B aligned. This means that the write to vbuf in > __get_user_atomic_128_aligned() has the bottom bits of the address > truncated. This results in other local variables being > overwritten. Also vbuf will not contain the correct data which results > in the userspace emulation being wrong and hence user data corruption. > > [...] Applied to powerpc/fixes. [1/2] powerpc: Fix undetected data corruption with P9N DD2.1 VSX CI load emulation https://git.kernel.org/powerpc/c/1da4a0272c5469169f78cd76cf175ff984f52f06 [2/2] selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load workaround https://git.kernel.org/powerpc/c/d1781f23704707d350b8c9006e2bdf5394bf91b2 cheers
Re: [PATCH v2] powerpc/powernv/dump: Fix race while processing OPAL dump
On Sat, 17 Oct 2020 22:12:10 +0530, Vasant Hegde wrote: > Every dump reported by OPAL is exported to userspace through a sysfs > interface and notified using kobject_uevent(). The userspace daemon > (opal_errd) then reads the dump and acknowledges that the dump is > saved safely to disk. Once acknowledged the kernel removes the > respective sysfs file entry causing respective resources to be > released including kobject. > > [...] Applied to powerpc/fixes. [1/1] powerpc/powernv/dump: Fix race while processing OPAL dump https://git.kernel.org/powerpc/c/0a43ae3e2beb77e3481d812834d33abe270768ab cheers
Re: [PATCH] powerpc/powernv/dump: Handle multiple writes to ack attribute
On Sat, 17 Oct 2020 22:12:36 +0530, Vasant Hegde wrote: > Even though we use self removing sysfs helper, we still need > to make sure we do the final kobject delete conditionally. > sysfs_remove_file_self() will handle parallel calls to remove > the sysfs attribute file and returns true only in the caller > that removed the attribute file. The other parallel callers > are returned false. Do the final kobject delete checking > the return value of sysfs_remove_file_self(). Applied to powerpc/fixes. [1/1] powerpc/powernv/dump: Handle multiple writes to ack attribute https://git.kernel.org/powerpc/c/358ab796ce78ba271a6ff82834183ffb2cb68c4c cheers
Re: [PATCH v2 3/3] powerpc: Fix update form addressing in inline assembly
Hi! On Tue, Oct 20, 2020 at 07:40:09AM +, Christophe Leroy wrote: > In several places, inline assembly uses the "%Un" modifier > to enable the use of instruction with update form addressing, > but the associated "<>" constraint is missing. > > As mentioned in previous patch, this fails with gcc 4.9, so > "<>" can't be used directly. > > Use UPD_CONSTR macro everywhere %Un modifier is used. > > Signed-off-by: Christophe Leroy Oh well, it will be easy enough to remove this wart later, so Reviewed-by: Segher Boessenkool > --- a/arch/powerpc/include/asm/book3s/32/pgtable.h > +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h > @@ -525,7 +525,7 @@ static inline void __set_pte_at(struct mm_struct *mm, > unsigned long addr, > stw%U0%X0 %2,%0\n\ > eieio\n\ > stw%U1%X1 %L2,%1" > - : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4)) > + : "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char *)ptep+4)) > : "r" (pte) : "memory"); Here it would pre-increment ptep+4. That can never be something useful afaics? The order the two operands are (either or not) pre-modified in the asm is not specified (GCC does not parse the asm template, by design), so I fail to see how this could ever work. > --- a/arch/powerpc/include/asm/nohash/pgtable.h > +++ b/arch/powerpc/include/asm/nohash/pgtable.h > @@ -200,7 +200,7 @@ static inline void __set_pte_at(struct mm_struct *mm, > unsigned long addr, > stw%U0%X0 %2,%0\n\ > eieio\n\ > stw%U1%X1 %L2,%1" > - : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4)) > + : "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char > *)ptep+4)) > : "r" (pte) : "memory"); Same here. The rest looks fine. Segher
[PATCH 15/29] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
- EHCI0: ehci@3001000 {
+ EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
- OHCI0: ohci@3001001 {
+ OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
- OHCI1: ohci@3001002 {
+ OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
--
2.27.0
[PATCH 00/29] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've removed a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in the controller driver and
in all the DTS files, which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link:
https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
Changelog v0:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Cc: Vineet Gupta
Cc: Rafal Milecki
Cc: Wei Xu
Cc: Thomas Bogendoerfer
Cc: Michael Ellerman
Cc: Jason Cooper
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Benoit Cousson
Cc: Patrice Chotard
Cc: Maxime Ripard
Cc: Khuong Dinh
Cc: Andy Gross
Cc: Alexey Brodkin
Cc: Hauke Mehrtens
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: Amelie Delaunay
Cc: Vladimir Zapolskiy
Cc: Paul Cercueil
Cc: Matthias Brugger
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Sebastian Hesselbarth
Cc: Kukjin Kim
Cc: Li Yang
Cc: Tony Lindgren
Cc: Chen-Yu Tsai
Cc: Bjorn Andersson
Cc: linux-snps-...@lists.infradead.org
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Serge Semin (29):
usb: dwc3: Discard synopsys,dwc3 compatibility string
arm: dts: keystone: Correct DWC USB3 compatible string
arm: dts: am437x: Correct DWC USB3 compatible string
arm: dts: exynos: Correct DWC USB3 compatible string
arm64: dts: amlogic: meson-g12: Set FL-adj property value
arc: dts: Harmonize EHCI/OHCI DT nodes name
arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
arm: dts: bcm5301x: Harmonize xHCI DT nodes name
arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
arm: dts: exynos: Harmonize DWC USB3 DT nodes name
arm: dts: keystone: Harmonize DWC USB3 DT nodes name
arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
arm: dts: omap5: Harmonize DWC USB3 DT nodes name
arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
arm64: dts: apm: Harmonize DWC USB3 DT nodes name
arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
arch/arc/boot/dts/axc003.dtsi | 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi | 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts
Re: [PATCH 3/3] powerpc: Fix pre-update addressing in inline assembly
On Tue, Oct 20, 2020 at 09:44:33AM +0200, Christophe Leroy wrote: > Le 19/10/2020 à 22:24, Segher Boessenkool a écrit : > >>but the associated "<>" constraint is missing. > > > >But that is just fine. Pointless, sure, but not a bug. > > Most of those are from prehistoric code. So at some point in time it was > effective. Then one day GCC changed it's way and they became pointless. So, > not a software bug, but still a regression at some point. > > >>Use UPD_CONSTR macro everywhere %Un modifier is used. > > > >Eww. My poor stomach. > > There are not that many :) Heh, your pain threshold is much higher than mine I guess :-) > >Have you verified that update form is *correct* in all these, and that > >we even *want* this there? > > I can't see anything that would militate against it, do you ? > > I guess if the elders have put %Us there, it was wanted. On old CPUs, update form load/stores actually executed faster than a "normal" memory access and an addi (or plain add). But on more recent stuff it mostly saves code size. Which is nice of course, and can speed up your code a bit, in theory at least. It is quite hard to trigger the compiler to generate update form insns in asm, sigh. So testing will probably not show anything either way. Oh well :-) Segher
Re: [PATCH v4] powerpc/pseries: Avoid using addr_to_pfn in real mode
On 7/24/20 12:09 PM, Ganesh Goudar wrote:
When an UE or memory error exception is encountered the MCE handler
tries to find the pfn using addr_to_pfn() which takes effective
address as an argument, later pfn is used to poison the page where
memory error occurred, recent rework in this area made addr_to_pfn
to run in real mode, which can be fatal as it may try to access
memory outside RMO region.
Have two helper functions to separate things to be done in real mode
and virtual mode without changing any functionality. This also fixes
the following error as the use of addr_to_pfn is now moved to virtual
mode.
Without this change following kernel crash is seen on hitting UE.
[ 485.128036] Oops: Kernel access of bad area, sig: 11 [#1]
[ 485.128040] LE SMP NR_CPUS=2048 NUMA pSeries
[ 485.128047] Modules linked in:
[ 485.128067] CPU: 15 PID: 6536 Comm: insmod Kdump: loaded Tainted: G OE 5.7.0
#22
[ 485.128074] NIP: c009b24c LR: c00398d8 CTR: c0cd57c0
[ 485.128078] REGS: c3f1f970 TRAP: 0300 Tainted: G OE (5.7.0)
[ 485.128082] MSR: 80001003 CR: 28008284 XER: 0001
[ 485.128088] CFAR: c009b190 DAR: c001fab0 DSISR: 4000
IRQMASK: 1
[ 485.128088] GPR00: 0001 c3f1fbf0 c1634300
b0fa0100
[ 485.128088] GPR04: d222 fab0
0022
[ 485.128088] GPR08: c001fab0 c001fab0
c3f1fc14
[ 485.128088] GPR12: 0008 c3ff5880 d218
[ 485.128088] GPR16: ff20 fff1 fff2
d21a1100
[ 485.128088] GPR20: d220 c0015c893c50 c0d49b28
c0015c893c50
[ 485.128088] GPR24: d21a0d08 c14e5da8 d21a0818
000a
[ 485.128088] GPR28: 0008 000a c17e2970
000a
[ 485.128125] NIP [c009b24c] __find_linux_pte+0x11c/0x310
[ 485.128130] LR [c00398d8] addr_to_pfn+0x138/0x170
[ 485.128133] Call Trace:
[ 485.128135] Instruction dump:
[ 485.128138] 3929 7d4a3378 7c883c36 7d2907b4 794a1564 7d294038 794af082
3900
[ 485.128144] 79291f24 790af00e 78e70020 7d095214 <7c69502a> 2fa3 419e011c
70690040
[ 485.128152] ---[ end trace d34b27e29ae0e340 ]---
Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event
code")
Signed-off-by: Ganesh Goudar
---
V2: Leave bare metal code and save_mce_event as is.
V3: Have separate functions for realmode and virtual mode handling.
V4: Fix build warning, rephrase commit message.
---
arch/powerpc/platforms/pseries/ras.c | 118 ---
1 file changed, 69 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index f3736fcd98fc..c509e43bac23 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -522,18 +522,55 @@ int pSeries_system_reset_exception(struct pt_regs *regs)
return 0; /* need to perform reset */
}
+static int mce_handle_err_realmode(int disposition, u8 error_type)
+{
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (disposition == RTAS_DISP_NOT_RECOVERED) {
+ switch (error_type) {
+ caseMC_ERROR_TYPE_SLB:
+ caseMC_ERROR_TYPE_ERAT:
+ /*
+* Store the old slb content in paca before flushing.
+* Print this when we go to virtual mode.
+* There are chances that we may hit MCE again if there
+* is a parity error on the SLB entry we trying to read
+* for saving. Hence limit the slb saving to single
+* level of recursion.
+*/
+ if (local_paca->in_mce == 1)
+ slb_save_contents(local_paca->mce_faulty_slbs);
+ flush_and_reload_slb();
+ disposition = RTAS_DISP_FULLY_RECOVERED;
+ break;
+ default:
+ break;
+ }
+ } else if (disposition == RTAS_DISP_LIMITED_RECOVERY) {
+ /* Platform corrected itself but could be degraded */
+ pr_err("MCE: limited recovery, system may be degraded\n");
+ disposition = RTAS_DISP_FULLY_RECOVERED;
+ }
+#endif
+ return disposition;
+}
-static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
+static int mce_handle_err_virtmode(struct pt_regs *regs,
+ struct rtas_error_log *errp,
+ struct pseries_mc_errorlog *mce_log,
+ int disposition)
{
struct mce_error_info mce_err = { 0 };
- unsigned long eaddr = 0, paddr = 0;
[PATCH v3 13/16] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
An empty snps,quirk-frame-length-adjustment won't cause any change performed by the driver. Moreover the DT schema validation will fail, since it expects the property being assigned with some value. So set fix the example by setting a valid FL-adj value in accordance with Neil Armstrong comment. Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/ Signed-off-by: Serge Semin Acked-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Note the same problem is in the DT source file arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index 5b04a7dfa018..a4b44a16aaef 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -209,6 +209,6 @@ examples: interrupts = <30>; dr_mode = "host"; snps,dis_u2_susphy_quirk; - snps,quirk-frame-length-adjustment; + snps,quirk-frame-length-adjustment = <0x20>; }; }; -- 2.27.0
[PATCH v3 16/16] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
Qualcomm msm8996/sc7180/sdm845 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
Reviewed-by: Rob Herring
---
Changelog v2:
- Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index dac10848dd7f..8f8d781e73a0 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,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
@@ -160,7 +157,7 @@ examples:
resets = < GCC_USB30_PRIM_BCR>;
-dwc3@a60 {
+usb@a60 {
compatible = "snps,dwc3";
reg = <0 0x0a60 0 0xcd00>;
interrupts = ;
--
2.27.0
[PATCH v3 06/16] dt-bindings: usb: Convert xHCI bindings to DT schema
Currently the DT bindings of Generic xHCI Controllers are described by means
of the legacy text file. Since such format is deprecated in favor of the
DT schema, let's convert the Generic xHCI Controllers bindings file to the
corresponding yaml files. There will be two of them: a DT schema for the
xHCI controllers on a generic platform and a DT schema validating a generic
xHCI controllers properties. The later will be used to validate the xHCI
controllers, which aside from some vendor-specific features support the
basic xHCI functionality.
An xHCI-compatible DT node shall support the standard USB HCD properties
and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
controller is being validated against the DT schema it is also supposed to
be equipped with mandatory compatible string, single registers range,
single interrupts source, and is supposed to optionally contain up to two
reference clocks for the controller core and CSRs.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Add explicit "additionalProperties: true" to the usb-xhci.yaml schema,
since additionalProperties/unevaluatedProperties are going to be mandary
for each binding.
---
.../devicetree/bindings/usb/generic-xhci.yaml | 63 +++
.../devicetree/bindings/usb/usb-xhci.txt | 41
.../devicetree/bindings/usb/usb-xhci.yaml | 42 +
3 files changed, 105 insertions(+), 41 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
new file mode 100644
index ..1ea1d49a8175
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB xHCI Controller Device Tree Bindings
+
+maintainers:
+ - Mathias Nyman
+
+allOf:
+ - $ref: "usb-xhci.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - description: Generic xHCI device
+const: generic-xhci
+ - description: Armada 37xx/375/38x/8k SoCs
+items:
+ - enum:
+ - marvell,armada3700-xhci
+ - marvell,armada-375-xhci
+ - marvell,armada-380-xhci
+ - marvell,armada-8k-xhci
+ - const: generic-xhci
+ - description: Broadcom STB SoCs with xHCI
+const: brcm,bcm7445-xhci
+ - description: Generic xHCI device
+const: xhci-platform
+deprecated: true
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 2
+
+ clock-names:
+minItems: 1
+items:
+ - const: core
+ - const: reg
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+usb@f0931000 {
+ compatible = "generic-xhci";
+ reg = <0xf0931000 0x8c8>;
+ interrupts = <0x0 0x4e 0x0>;
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
deleted file mode 100644
index 0c5cff84a969..
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-USB xHCI controllers
-
-Required properties:
- - compatible: should be one or more of
-
-- "generic-xhci" for generic XHCI device
-- "marvell,armada3700-xhci" for Armada 37xx SoCs
-- "marvell,armada-375-xhci" for Armada 375 SoCs
-- "marvell,armada-380-xhci" for Armada 38x SoCs
-- "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
-- "xhci-platform" (deprecated)
-
-When compatible with the generic version, nodes must list the
-SoC-specific version corresponding to the platform first
-followed by the generic version.
-
- - reg: should contain address and length of the standard XHCI
-register set for the device.
- - interrupts: one XHCI interrupt should be described here.
-
-Optional properties:
- - clocks: reference to the clocks
- - clock-names: mandatory if there is a second clock, in this case
-the name must be "core" for the first clock and "reg" for the
-second one
- - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- - usb3-lpm-capable: determines if platform is USB3 LPM capable
- - quirk-broken-port-ped: set if the controller has broken port disable
mechanism
- - imod-interval-ns: default interrupt moderation interval is 5000ns
- - phys : see usb-hcd.yaml in the current directory
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-
-Example:
- usb@f0931000 {
[PATCH v3 10/16] dt-bindings: usb: dwc3: Add interrupt-names property support
The controller driver supports two types of DWC USB3 devices: with a common interrupt lane and with individual interrupts for each mode. Add support for both these cases to the DWC USB3 DT schema. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/both of these cases support/support for both these cases" - Drop quotes from around the string constants. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 65bc66ec67d0..23f07222d3d7 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -30,9 +30,20 @@ properties: const: snps,dwc3 interrupts: +description: | + It's either a single common DWC3 interrupt (dwc_usb3) or individual + interrupts for the host, gadget and DRD modes. minItems: 1 maxItems: 3 + interrupt-names: +minItems: 1 +maxItems: 3 +oneOf: + - const: dwc_usb3 + - items: + enum: [host, peripheral, otg] + clocks: description: In general the core supports three types of clocks. bus_early is a -- 2.27.0
[PATCH v3 08/16] 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(-) diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml index add9f7b66da0..4491567152a1 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: @@ -68,7 +68,7 @@ required: - power-domains - resets -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.27.0
[PATCH v3 05/16] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
Even though the Generic PHY framework is the more preferable way of setting the USB PHY up, there are still many dts-files and DT bindings which rely on having the legacy "usb-phy" specified to attach particular USB PHYs to USB cores. Let's have the "usb-phy" property described in the generic USB HCD binding file so it would be validated against the nodes in which it's specified. Mark the property as deprecated to discourage the developers from using it. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Discard '|' from the property description, since we don't need to preserve the text formatting. --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index 1f9b40fdea70..264a660dc6ea 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -22,6 +22,13 @@ properties: description: Name specifier for the USB PHY + usb-phy: +$ref: /schemas/types.yaml#/definitions/phandle-array +description: + List of all the USB PHYs on this HCD to be accepted by the legacy USB + Physical Layer subsystem. +deprecated: true + maximum-speed: description: Tells USB controllers we want to work up to a certain speed. In case this -- 2.27.0
[PATCH v3 15/16] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3 compatible sub-node to describe a fully functioning USB interface. Since DWC USB3 has now got a DT schema describing its DT node, let's make sure the TI Keystone DWC3 sub-node passes validation against it. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/it'/its" --- Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index c1b19fc5d0a2..ca7fbe3ed22e 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -64,9 +64,7 @@ properties: patternProperties: "usb@[a-f0-9]+$": -type: object -description: This is the node representing the DWC3 controller instance - Documentation/devicetree/bindings/usb/dwc3.txt +$ref: snps,dwc3.yaml# required: - compatible -- 2.27.0
[PATCH v3 09/16] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
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. --- .../devicetree/bindings/usb/dwc3.txt | 125 .../devicetree/bindings/usb/snps,dwc3.yaml| 302 ++ 2 files changed, 302 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/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt deleted file mode 100644 index d03edf9d3935.. --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ /dev/null @@ -1,125 +0,0 @@ -synopsys DWC3 CORE - -DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties - as described in 'usb/generic.txt' - -Required properties: - - compatible: must be "snps,dwc3" - - reg : Address and length of the register set for the device - - interrupts: Interrupts used by the dwc3 controller. - - clock-names: list of clock names. Ideally should be "ref", -"bus_early", "suspend" but may be less or more. - - clocks: list of phandle and clock specifier pairs corresponding to - entries in the clock-names property. - -Exception for clocks: - clocks are optional if the parent node (i.e. glue-layer) is compatible to - one of the following: -"cavium,octeon-7130-usb-uctl" -"qcom,dwc3" -"samsung,exynos5250-dwusb3" -"samsung,exynos5433-dwusb3" -"samsung,exynos7-dwusb3" -"sprd,sc9860-dwc3" -"st,stih407-dwc3" -"ti,am437x-dwc3" -"ti,dwc3" -"ti,keystone-dwc3" -"rockchip,rk3399-dwc3" -"xlnx,zynqmp-dwc3" - -Optional properties: - - usb-phy : array of phandle for the PHY device. The first element - in the array is expected to be a handle to the USB2/HS PHY and - the second element is expected to be a handle to the USB3/SS PHY - - phys: from the *Generic PHY* bindings - - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" - or "usb3-phy". - - resets: set of phandle and reset specifier pairs - - snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM - - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable - - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER command - failure SW work-around for DWC_usb31 version 1.70a-ea06 - and prior. - - snps,disable_scramble_quirk: true when SW should disable data scrambling. - Only really useful for FPGA builds. - - snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum enabled - - snps,lpm-nyet-threshold: LPM NYET threshold - - snps,u2exit_lfps_quirk: set if we want to enable u2exit lfps quirk - - snps,u2ss_inp3_quirk: set if we enable P3 OK for U2/SS Inactive quirk - - snps,req_p1p2p3_quirk: when set, the core will always request for - P1/P2/P3 transition sequence. - - snps,del_p1p2p3_quirk: when set core will delay P1/P2/P3 until a certain - amount of 8B10B errors occur. - - snps,del_phy_power_chg_quirk: when set core will delay PHY power change - from P0 to P1/P2/P3. - - snps,lfps_filter_quirk: when set core will filter LFPS reception. - - snps,rx_detect_poll_quirk: when set core will disable a 400us delay to start - Polling LFPS after RX.Detect. - - snps,tx_de_emphasis_quirk: when set core will set Tx de-emphasis value. - - snps,tx_de_emphasis: the value driven to the PHY is controlled by the - LTSSM during USB3 Compliance mode. - - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy. - - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy. - - snps,dis_enblslpm_quirk: when set clears the enblslpm in GUSB2PHYCFG, - disabling the suspend signal to the PHY. - - snps,dis-u1-entry-quirk: set if link entering into U1 needs to be disabled. - - snps,dis-u2-entry-quirk: set if link entering into U2 needs to be disabled. - -
[PATCH v3 14/16] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the generic DWC USB2 and USB3 devices. Since now we've got DT schemas for both of the later IP cores let's make sure that the Amlogic G12A USB DT nodes are fully evaluated including the DWC sub-nodes. Signed-off-by: Serge Semin Reviewed-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Changelog v2: - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: properties: compatibe: ..." statement. --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index a4b44a16aaef..7b2dc905c8ce 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -78,7 +78,9 @@ properties: patternProperties: "^usb@[0-9a-f]+$": -type: object +oneOf: + - $ref: dwc2.yaml# + - $ref: snps,dwc3.yaml# additionalProperties: false -- 2.27.0
[PATCH v3 11/16] dt-bindings: usb: dwc3: Add Tx De-emphasis constraints
In accordance with the driver comments the PIPE3 de-emphasis can be tuned to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis property constraints so the DT schema would make sure the controller DT node is equipped with correct value. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/tunned/tuned" - Grammar fix: remove redundant "or" conjunction. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 23f07222d3d7..6ab7cba56059 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -149,6 +149,10 @@ properties: The value driven to the PHY is controlled by the LTSSM during USB3 Compliance mode. $ref: /schemas/types.yaml#/definitions/uint8 +enum: + - 0 # -6dB de-emphasis + - 1 # -3.5dB de-emphasis + - 2 # No de-emphasis snps,dis_u3_susphy_quirk: description: When set core will disable USB3 suspend phy -- 2.27.0
[PATCH v3 12/16] dt-bindings: usb: dwc3: Add Frame Length Adj constraints
In accordance with the IP core databook the snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. Let's make sure the DT schema applies a correct constraints on the property. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 6ab7cba56059..2a269624983a 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -230,6 +230,8 @@ properties: length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. $ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0 +maximum: 0x3f snps,rx-thr-num-pkt-prd: description: -- 2.27.0
[PATCH v3 07/16] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device
For some reason the "brcm,xhci-brcm-v2" compatible string has been missing in the original bindings file. Add it to the Generic xHCI Controllers DT schema since the controller driver expects it to be supported. Signed-off-by: Serge Semin Acked-by: Florian Fainelli Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml index 1ea1d49a8175..23d73df96ea3 100644 --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml @@ -26,7 +26,9 @@ properties: - marvell,armada-8k-xhci - const: generic-xhci - description: Broadcom STB SoCs with xHCI -const: brcm,bcm7445-xhci +enum: + - brcm,xhci-brcm-v2 + - brcm,bcm7445-xhci - description: Generic xHCI device const: xhci-platform deprecated: true -- 2.27.0
[PATCH v3 00/16] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
We've performed some work on the Generic USB HCD, xHCI and DWC USB3 DT bindings in the framework of the Baikal-T1 SoC support integration into the kernel. This patchset is a result of that work. First of all we moved the generic USB properties from the legacy text bindings into the USB HCD DT schema. So now the generic USB HCD-compatible DT nodes are validated taking into account the optional properties like: maximum-speed, dr_mode, otg-rev, usb-role-switch, etc. We've fixed these properties a bit so they would correspond to what functionality kernel currently supports. Secondly we converted generic USB xHCI text bindings file into the DT schema. It had to be split up into two bindings: DT schema with generic xHCI properties and a generic xHCI device DT schema. The later will be used to validate the pure xHCI-based nodes, while the former can be utilized by some vendor-specific versions of xHCI. Thirdly, what was primarily intended to be done for Baikal-T1 SoC USB we converted the legacy text-based DWC USB3 bindings to DT schema and altered the result a bit so it would be more coherent with what actually controller and its driver support. Since we've now got the DWC USB3 DT schema, we made it used to validate the sub-nodes of the Qualcom, TI and Amlogic DWC3 DT nodes. Finally we've also fixed all the OHCI/EHCI, xHCI and DW USB3 compatible DT nodes so they would comply with the nodes naming scema declared in the USB HCD DT bindings file. Link: https://lore.kernel.org/linux-usb/20201010224121.12672-1-sergey.se...@baikalelectronics.ru/ Changelog v2: - Thanks to Sergei Shtylyov for suggesting the commit logs grammar fixes: [PATCH 04/18] dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types [PATCH 05/18] dt-bindings: usb: usb-hcd: Add "tpl-support" property [PATCH 11/18] dt-bindings: usb: dwc3: Add interrupt-names property support [PATCH 13/18] dt-bindings: usb: dwc3: Add Tx De-emphasis restrictions [PATCH 17/18] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node - Set FL-adj of the amlogiv,meson-g12a-usb controller with value 0x20 instead of completely removing the property. - Drop the patch: [PATCH 02/18] dt-bindings: usb: usb-hcd: Add "wireless" maximum-speed property value since "wireless" speed type is depracated due to lack of the device supporting it. - Drop quotes from around the compat string constant. - Discard '|' from the property descriptions, since we don't need to preserve the text formatting. - Convert abbreviated form of the "maximum-speed" enum constraint into the multi-lined version of the list. - Fix the DW USB3 "clock-names" prop description to be refererring to the enumerated clock-names instead of the ones from the Databook. - Add explicit "additionalProperties: true" to the usb-xhci.yaml schema, since additionalProperties/unevaluatedProperties are going to be mandary for each binding. - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: properties: compatibe: ..." statement. - Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes of the Qualcomm DWC3 DT nodes. - Add new patches: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name [PATCH 19/20] arch: dts: Fix xHCI DT nodes name [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru Changelog v3: - Drop the patches: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name [PATCH 19/20] arch: dts: Fix xHCI DT nodes name [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name as they are going to be submitted in the framework of a dedicated patchset. - Drop the patch: [PATCH 11/20] dt-bindings: usb: dwc3: Add synopsys,dwc3 compatible string since it's going to be replaced with the driver/dts fixup and moved to a dedicated patchset. - Apply usb-xhci.yaml# schema for the DWC USB3 node only if the controller is supposed to work as either host or otg. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Pavel Parkhomenko Cc: Andy Gross Cc: Bjorn Andersson Cc: Manu Gautam Cc: Roger Quadros Cc: Lad Prabhakar Cc: Yoshihiro Shimoda Cc: Neil Armstrong Cc: Kevin Hilman Cc: Martin Blumenstingl Cc: linux-arm-ker...@lists.infradead.org Cc: linux-snps-...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Serge Semin (16): dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema dt-bindings: usb: usb-hcd: Add "otg-rev" property restriction dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types dt-bindings: usb: usb-hcd: Add "tpl-support" property dt-bindings: usb: usb-hcd: Add generic "usb-phy" property dt-bindings: usb: Convert xHCI bindings to DT schema dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml
[PATCH v3 04/16] dt-bindings: usb: usb-hcd: Add "tpl-support" property
The host controller device might be designed to work for the particular
products or applications. In that case its DT node is supposed to be
equipped with the tpl-support property.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Grammar fix: "s/it'/its"
- Discard '|' from the property description, since we don't need to preserve
the text formatting.
---
Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
index a1a6cde7327d..1f9b40fdea70 100644
--- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
@@ -101,6 +101,12 @@ properties:
enum: [host, peripheral]
default: peripheral
+ tpl-support:
+description:
+ Indicates if the Targeted Peripheral List is supported for given
+ targeted hosts (non-PC hosts).
+type: boolean
+
examples:
- |
usb {
--
2.27.0
[PATCH v3 03/16] dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types
Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types that can be specified in the phy_type HCD property. Add them to the enumeration of the acceptable values. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/PHY types can be/PHY types that can be" - Drop quotes from around the string constants. --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index e01d8a54971e..a1a6cde7327d 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -46,11 +46,13 @@ properties: phy_type: description: 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. In case - this isn't passed via DT, USB controllers should default to HW - capability. + UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected, UTMI+ low + pin interface if ULPI is specified, Serial core/PHY interconnect if + serial is specified and High-Speed Inter-Chip feature if HSIC is + selected. In case this isn't passed via DT, USB controllers should + default to HW capability. $ref: /schemas/types.yaml#/definitions/string -enum: [utmi, utmi_wide] +enum: [utmi, utmi_wide, ulpi, serial, hsic] otg-rev: description: -- 2.27.0
[PATCH v3 02/16] dt-bindings: usb: usb-hcd: Add "otg-rev" property restriction
There are only four OTG revisions are currently supported by the kernel: 0x0100, 0x0120, 0x0130, 0x0200. Any another value is considered as invalid. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index ee7ea205c71d..e01d8a54971e 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -60,6 +60,7 @@ properties: features (HNP/SRP/ADP) is enabled. If ADP is required, otg-rev should be 0x0200 or above. $ref: /schemas/types.yaml#/definitions/uint32 +enum: [0x0100, 0x0120, 0x0130, 0x0200] companion: description: Phandle of a companion device -- 2.27.0
[PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
The generic USB HCD properties have been described in the legacy bindings
text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
convert it' content into the USB HCD DT schema properties so all USB DT
nodes would be validated to have them properly utilized.
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.
---
.../devicetree/bindings/usb/generic.txt | 57
.../devicetree/bindings/usb/usb-hcd.yaml | 88 +++
2 files changed, 88 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
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 = <_phy>, <,phy>;
- maximum-speed = "super-speed";
- dr_mode = "otg";
- phy_type = "utmi_wide";
- otg-rev = <0x0200>;
- adp-disable;
-};
diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
index 7263b7f2b510..ee7ea205c71d 100644
--- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
@@ -22,9 +22,97 @@ properties:
description:
Name specifier for the USB PHY
+ maximum-speed:
+ description:
+ Tells USB controllers we want to work up to a certain speed. In case this
+ isn't passed via DT, USB controllers should default to their maximum HW
+ capability.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - low-speed
+ - full-speed
+ - high-speed
+ - super-speed
+ - super-speed-plus
+
+ dr_mode:
+description:
+ Tells Dual-Role USB controllers that we want to
RE: [PATCH 08/20] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
Hi, > From: Serge Semin, Sent: Wednesday, October 14, 2020 7:14 PM > > 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 > --- Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
Re: [PATCH 2/2] powerpc/watchpoint: Workaround P10 DD1 issue with VSX-32 byte instructions
Hi Ravi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.9 next-20201016]
[cannot apply to mpe/next scottwood/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Ravi-Bangoria/powerpc-Introduce-POWER10_DD1-feature/20201020-134813
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/a873a50e35b4c881b6bb53f48ae8ef7bb3e576eb
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Ravi-Bangoria/powerpc-Introduce-POWER10_DD1-feature/20201020-134813
git checkout a873a50e35b4c881b6bb53f48ae8ef7bb3e576eb
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/powerpc/kernel/hw_breakpoint.c: In function
'handle_p10dd1_spurious_exception':
>> arch/powerpc/kernel/hw_breakpoint.c:561:16: warning: variable
>> 'hw_start_addr' set but not used [-Wunused-but-set-variable]
561 | unsigned long hw_start_addr;
|^
vim +/hw_start_addr +561 arch/powerpc/kernel/hw_breakpoint.c
556
557 static void handle_p10dd1_spurious_exception(struct arch_hw_breakpoint
**info,
558 int *hit, unsigned long ea)
559 {
560 int i;
> 561 unsigned long hw_start_addr;
562 unsigned long hw_end_addr;
563
564 /*
565 * Handle spurious exception only when any bp_per_reg is set.
566 * Otherwise this might be created by xmon and not actually a
567 * spurious exception.
568 */
569 for (i = 0; i < nr_wp_slots(); i++) {
570 if (!info[i])
571 continue;
572
573 hw_start_addr = ALIGN_DOWN(info[i]->address,
HW_BREAKPOINT_SIZE);
574 hw_end_addr = ALIGN(info[i]->address + info[i]->len,
HW_BREAKPOINT_SIZE);
575
576 /*
577 * Ending address of DAWR range is less than starting
578 * address of op.
579 */
580 if ((hw_end_addr - 1) >= ea)
581 continue;
582
583 /*
584 * Those addresses need to be in the same or in two
585 * consecutive 512B blocks;
586 */
587 if (((hw_end_addr - 1) >> 10) != (ea >> 10))
588 continue;
589
590 /*
591 * 'op address + 64B' generates an address that has a
592 * carry into bit 52 (crosses 2K boundary).
593 */
594 if ((ea & 0x800) == ((ea + 64) & 0x800))
595 continue;
596
597 break;
598 }
599
600 if (i == nr_wp_slots())
601 return;
602
603 for (i = 0; i < nr_wp_slots(); i++) {
604 if (info[i]) {
605 hit[i] = 1;
606 info[i]->type |= HW_BRK_TYPE_EXTRANEOUS_IRQ;
607 }
608 }
609 }
610
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 3/3] powerpc: Fix pre-update addressing in inline assembly
Le 19/10/2020 à 22:24, Segher Boessenkool a écrit : On Mon, Oct 19, 2020 at 12:12:48PM +, Christophe Leroy wrote: In several places, inline assembly uses the "%Un" modifier to enable the use of instruction with pre-update addressing, Calling this "pre-update" is misleading: the register is not updated before the address is generated (or the memory access done!), and the addressing is exactly the same as the "non-u" insn would use. It is called an "update form" instruction, because (at the same time as doing the memory access, logically anyway) it writes back the address used to the base register. but the associated "<>" constraint is missing. But that is just fine. Pointless, sure, but not a bug. Most of those are from prehistoric code. So at some point in time it was effective. Then one day GCC changed it's way and they became pointless. So, not a software bug, but still a regression at some point. Use UPD_CONSTR macro everywhere %Un modifier is used. Eww. My poor stomach. There are not that many :) Have you verified that update form is *correct* in all these, and that we even *want* this there? I can't see anything that would militate against it, do you ? I guess if the elders have put %Us there, it was wanted. Christophe
[PATCH v2 3/3] powerpc: Fix update form addressing in inline assembly
In several places, inline assembly uses the "%Un" modifier
to enable the use of instruction with update form addressing,
but the associated "<>" constraint is missing.
As mentioned in previous patch, this fails with gcc 4.9, so
"<>" can't be used directly.
Use UPD_CONSTR macro everywhere %Un modifier is used.
Signed-off-by: Christophe Leroy
---
v2: Build failure (circular inclusion) fixed by change in patch 1
---
arch/powerpc/include/asm/atomic.h| 9 +
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/include/asm/io.h| 4 ++--
arch/powerpc/include/asm/nohash/pgtable.h| 2 +-
arch/powerpc/kvm/powerpc.c | 4 ++--
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 8a55eb8cc97b..61c6e8b200e8 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/*
* Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
@@ -26,14 +27,14 @@ static __inline__ int atomic_read(const atomic_t *v)
{
int t;
- __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
+ __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) :
"m"UPD_CONSTR(v->counter));
return t;
}
static __inline__ void atomic_set(atomic_t *v, int i)
{
- __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m"(v->counter) : "r"(i));
+ __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m"UPD_CONSTR(v->counter) :
"r"(i));
}
#define ATOMIC_OP(op, asm_op) \
@@ -316,14 +317,14 @@ static __inline__ s64 atomic64_read(const atomic64_t *v)
{
s64 t;
- __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
+ __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
"m"UPD_CONSTR(v->counter));
return t;
}
static __inline__ void atomic64_set(atomic64_t *v, s64 i)
{
- __asm__ __volatile__("std%U0%X0 %1,%0" : "=m"(v->counter) : "r"(i));
+ __asm__ __volatile__("std%U0%X0 %1,%0" : "=m"UPD_CONSTR(v->counter) :
"r"(i));
}
#define ATOMIC64_OP(op, asm_op)
\
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 34f5ca391f0c..0e1b6e020cef 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -525,7 +525,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
stw%U0%X0 %2,%0\n\
eieio\n\
stw%U1%X1 %L2,%1"
- : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
+ : "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
#else
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 58635960403c..87964dfb838e 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -122,7 +122,7 @@ static inline u##size name(const volatile u##size __iomem
*addr)\
{ \
u##size ret;\
__asm__ __volatile__("sync;"#insn"%U1%X1 %0,%1;twi 0,%0,0;isync"\
- : "=r" (ret) : "m" (*addr) : "memory"); \
+ : "=r" (ret) : "m"UPD_CONSTR (*addr) : "memory"); \
return ret; \
}
@@ -130,7 +130,7 @@ static inline u##size name(const volatile u##size __iomem
*addr)\
static inline void name(volatile u##size __iomem *addr, u##size val) \
{ \
__asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \
- : "=m" (*addr) : "r" (val) : "memory"); \
+ : "=m"UPD_CONSTR (*addr) : "r" (val) : "memory"); \
mmiowb_set_pending(); \
}
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index a00e4c1746d6..55ef2112ed00 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -200,7 +200,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
stw%U0%X0 %2,%0\n\
eieio\n\
stw%U1%X1 %L2,%1"
- : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
+ : "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char
*)ptep+4))
: "r" (pte) : "memory");
return;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 13999123b735..cf52d26f49cd 100644
--- a/arch/powerpc/kvm/powerpc.c
+++
[PATCH v2 2/3] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
From: Mathieu Desnoyers
The placeholder for instruction selection should use the second
argument's operand, which is %1, not %0. This could generate incorrect
assembly code if the memory addressing of operand %0 is a different
form from that of operand %1.
Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
Signed-off-by: Mathieu Desnoyers
Cc: Christophe Leroy
Cc: Kumar Gala
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: # v2.6.28+
Acked-by: Segher Boessenkool
[chleroy: revised commit log iaw segher's comment]
Signed-off-by: Christophe Leroy
---
v2: Changed commit log.
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/include/asm/nohash/pgtable.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 36443cda8dcf..34f5ca391f0c 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -524,7 +524,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
__asm__ __volatile__("\
stw%U0%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%U1%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 4b7c3472eab1..a00e4c1746d6 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -199,7 +199,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
__asm__ __volatile__("\
stw%U0%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%U1%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
return;
--
2.25.0
[PATCH v2 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
GCC 4.9 sometimes fails to build with "m<>" constraint in
inline assembly.
CC lib/iov_iter.o
In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
from ./arch/powerpc/include/asm/atomic.h:11,
from ./include/linux/atomic.h:7,
from ./include/linux/crypto.h:15,
from ./include/crypto/hash.h:11,
from lib/iov_iter.c:2:
lib/iov_iter.c: In function 'iovec_from_user.part.30':
./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has impossible
constraints
__asm__ __volatile__(\
^
./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro
'unsafe_op_wrap'
#define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
^
./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro
'__get_user_asm'
case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
^
./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro
'__get_user_size_allowed'
__get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
^
./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro
'__get_user_nocheck'
__get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
^
./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro
'__get_user_allowed'
#define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
^
lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
unsafe_get_user(len, [i].iov_len, uaccess_end);
^
make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
Define a UPD_CONSTR macro that is "<>" by default and
only "" with GCC prior to GCC 5.
Fixes: fcf1f26895a4 ("powerpc/uaccess: Add pre-update addressing to
__put_user_asm_goto()")
Fixes: 2f279eeb68b8 ("powerpc/uaccess: Add pre-update addressing to
__get_user_asm() and __put_user_asm()")
Signed-off-by: Christophe Leroy
Acked-by: Segher Boessenkool
---
v2: Moved UPD_CONSTR to asm-const.h to avoid circular inclusion issues with
patch 3.
---
arch/powerpc/include/asm/asm-const.h | 13 +
arch/powerpc/include/asm/uaccess.h | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/asm-const.h
b/arch/powerpc/include/asm/asm-const.h
index 082c1538c562..0ce2368bd20f 100644
--- a/arch/powerpc/include/asm/asm-const.h
+++ b/arch/powerpc/include/asm/asm-const.h
@@ -11,4 +11,17 @@
# define __ASM_CONST(x) x##UL
# define ASM_CONST(x) __ASM_CONST(x)
#endif
+
+/*
+ * Inline assembly memory constraint
+ *
+ * GCC 4.9 doesn't properly handle pre update memory constraint "m<>"
+ *
+ */
+#if defined(GCC_VERSION) && GCC_VERSION < 5
+#define UPD_CONSTR ""
+#else
+#define UPD_CONSTR "<>"
+#endif
+
#endif /* _ASM_POWERPC_ASM_CONST_H */
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 604d705f1bb8..8f27ea48fadb 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -223,7 +223,7 @@ do {
\
"1: " op "%U1%X1 %0,%1 # put_user\n" \
EX_TABLE(1b, %l2) \
: \
- : "r" (x), "m<>" (*addr)\
+ : "r" (x), "m"UPD_CONSTR (*addr)\
: \
: label)
@@ -294,7 +294,7 @@ extern long __get_user_bad(void);
".previous\n" \
EX_TABLE(1b, 3b)\
: "=r" (err), "=r" (x) \
- : "m<>" (*addr), "i" (-EFAULT), "0" (err))
+ : "m"UPD_CONSTR (*addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __get_user_asm2(x, addr, err) \
--
2.25.0
Re: [PATCH 3/8] powerpc: Mark functions called inside uaccess blocks w/ 'notrace'
Peter Zijlstra writes: > On Fri, Oct 16, 2020 at 07:56:16AM +0100, Christoph Hellwig wrote: >> On Thu, Oct 15, 2020 at 10:01:54AM -0500, Christopher M. Riedl wrote: >> > Functions called between user_*_access_begin() and user_*_access_end() >> > should be either inlined or marked 'notrace' to prevent leaving >> > userspace access exposed. Mark any such functions relevant to signal >> > handling so that subsequent patches can call them inside uaccess blocks. >> >> I don't think running this much code with uaccess enabled is a good >> idea. Please refactor the code to reduce the criticial sections with >> uaccess enabled. >> >> Btw, does powerpc already have the objtool validation that we don't >> accidentally jump out of unsafe uaccess critical sections? > > It does not, there was some effort on that a while ago, but I suspect > they're waiting for the ARM64 effort to land and build on that. Right, we don't have objtool support. We would definitely like objtool support at least for this uaccess checking, I'm sure we have some escapes. There was someone working on it in their own-time but last I heard that was still WIP. I didn't realise the ARM64 support was still not merged, so yeah having that land first would probably simplify things, but we still need someone who has time to work on it. cheers
