Re: [PATCH] printk: handle blank console arguments passed in.
On (20/10/05 20:35), Guenter Roeck wrote: > On a side note, I don't see the problem presumably fixed with this > patch in any of my tests. Hmm. This is rather interesting. Empty console= certainly oops-es my laptop, but not the cros board I just tested this on. Do we carry around any chromeos patches that may affect the parsing of the kernel boot command line? -ss
Re: [PATCH 2/4] dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties'
On Mon, 05 Oct 2020, Rob Herring wrote: > In cases where we don't reference another schema, 'additionalProperties' > can be used instead. This is preferred for now as 'unevaluatedProperties' > support isn't implemented yet. > > In a few cases, this means adding some missing property definitions of > which most are for SPI bus properties. 'unevaluatedProperties' is not going > to work for the SPI bus properties anyways as they are evaluated from the > parent node, not the SPI child node. Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On Fri, 02 Oct 2020, Rob Herring wrote: > Another round of wack-a-mole. The json-schema default is additional > unknown properties are allowed, but for DT all properties should be > defined. Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v11 4/5] dt-bindings: serial: document LiteUART bindings
Hi Geert,
On Fri, Sep 25, 2020 at 3:16 PM Geert Uytterhoeven wrote:
>
> Hi Mateusz,
>
> On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> wrote:
> > From: Filip Kokosinski
> >
> > Add documentation for LiteUART devicetree bindings.
> >
> > Signed-off-by: Filip Kokosinski
> > Signed-off-by: Mateusz Holenko
> > Reviewed-by: Rob Herring
>
> Thanks for your patch!
Thanks for your review!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
> > @@ -0,0 +1,38 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: LiteUART serial controller
> > +
> > +maintainers:
> > + - Karol Gugala
> > + - Mateusz Holenko
> > +
> > +description: |
> > + LiteUART serial controller is a part of LiteX FPGA SoC builder. It
> > supports
>
> part of the
Right, will fix that.
> > + multiple CPU architectures, currently including e.g. OpenRISC and RISC-V.
> > +
> > +properties:
> > + compatible:
> > +const: litex,liteuart
>
> Have you already decided how to handle future LiteUART variants that add
> new features (e.g. CTS/RTS, DMA)?
We were thinking of adding KConfig options, like
[ ] LiteUART serial port support
< > LiteUART DMA support
and using ifdefs in the code.
The other option could be to extend LiteX itself so that the UART core
provides information about its configuration via the capabilities register.
That way the driver could configure itself automatically at runtime.
This is, however, not decided yet.
>
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + - |
> > +uart0: serial@e0001800 {
> > + compatible = "litex,liteuart";
> > + reg = <0xe0001800 0x100>;
> > + interrupts = <2>;
> > +};
> > --
> > 2.25.1
> >
>
>
> --
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Best regards,
Mateusz
--
Mateusz Holenko
Antmicro Ltd | www.antmicro.com
Roosevelta 22, 60-829 Poznan, Poland
Re: [PATCH 2/2] usb: serial: option: add Cellient MPL200 card
On Mon, Oct 05, 2020 at 02:07:23PM +0200, Wilken Gottwalt wrote: > On Mon, 5 Oct 2020 18:36:36 +0700 Lars Melin wrote: > > On 10/5/2020 18:06, Johan Hovold wrote: > > > Do you remember the interface layout and why you blacklisted interface > > > 1? > > It is very likely that Cellient has replaced the VID with their own and > > kept the PID, it is something other mfgrs has done when buying modules > > from Qualcomm's series of devices with predefined composition. > > > > The MS Windows driver for 05c6:9025 describes the interfaces as: > > > > MI_00 Qualcomm HS-USB Diagnostics 9025 > > MI_01 Android Composite ADB Interface > > MI_02 Qualcomm HS-USB Android Modem 9025 > > MI_03 Qualcomm HS-USB NMEA 9025 > > MI_04 Qualcomm Wireless HS-USB Ethernet Adapter 9025 > > MI_05 USB Mass Storage Device > > > > where the net interface is for QMI/RMNET. > > It fully matches the blacklisting Wilken has done for 2692:9025 > > Does your device have a GPS connector? Mine had not and I'm not sure > if the description of MI_01 is actually correct. I remember looking at > this port and seeing bogus NMEA data. Well if it's NMEA then the interface shouldn't be blacklisted (even if the values are bogus on your device), but if it's ADB it should be as that is handled by userspace. Here's some lsusb output from a Cellient MPL200 that still uses the Qualcomm VID: https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg04523.html which gives some support to Lars's hypothesis. I guess we'll just keep the first interface reserved. Johan
Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On Thu, 1 Oct 2020 21:07:51 -0700
Guenter Roeck wrote:
> On 10/1/20 3:22 PM, Andreas Kemnade wrote:
> > On Wed, 30 Sep 2020 22:00:09 +0200
> > Arnd Bergmann wrote:
> >
> >> On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck wrote:
> >>>
> >>> On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:
> Hi,
>
> after the $subject patch I get lots of errors like this:
> >>>
> >>> For reference, this refers to commit fff2d0f701e6 ("hwmon: (applesmc)
> >>> avoid overlong udelay()").
> >>>
> [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.378621] applesmc: LKSB: write data fail
> [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.512787] applesmc: LKSB: write data fail
>
> CPU sticks at low speed and no fan is turning on.
> Reverting this patch on top of 5.9-rc6 solves this problem.
>
> Some information from dmidecode:
>
> Base Board Information
> Manufacturer: Apple Inc.
> Product Name: Mac-7DF21CB3ED6977E5
> Version: MacBookAir6,2
>
> Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple
> ROM Version. Model: …,
> Handle 0x0020, DMI type 11, 5 bytes
> OEM Strings
> String 1: Apple ROM Version. Model:MBA61. EFI Version:
> 122.0.0
> String 2: .0.0. Built by: root@saumon. Date: Wed
> Jun 10 18:
> String 3: 10:36 PDT 2020. Revision: 122 (B&I). ROM
> Version: F000_B
> String 4: 00. Build Type: Official Build, Release. Compiler:
> Appl
> String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based
> on LLVM
> String 6: 3.0svn).
>
> Writing to things in /sys/devices/platform/applesmc.768 gives also the
> said errors.
> But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on
> despite error messages.
>
> >>> Not really sure what to do here. I could revert the patch, but then we'd
> >>> gain
> >>> clang compile failures. Arnd, any idea ?
> >>
> >> It seems that either I made a mistake in the conversion and it sleeps for
> >> less time than before, or my assumption was wrong that converting a delay
> >> to
> >> a sleep is safe here.
> >>
> >> The error message indicates that the write fails, not the read, so that
> >> is what I'd look at first. Right away I can see that the maximum time to
> >> retry is only half of what it used to be, as we used to wait for
> >> 0x10, 0x20, 0x40, 0x80, ..., 0x2 microseconds for a total of
> >> 0x3fff0 microseconds (262ms), while my patch went with the 131ms
> >> total delay based on the comment saying "/* wait up to 128 ms for a
> >> status change. */".
> >>
> > Yes, that is also what I read from the code. I just thought there must
> > be something simple, which just needs a short look from another pair of
> > eyes.
> >
> >> Since there is sleeping wait, I see no reason the timeout couldn't
> >> be extended a lot, e.g. to a second, as in
> >>
> >> #define APPLESMC_MAX_WAIT 0x10
> >>
> >> If that doesn't work, I'd try using mdelay() in place of
> >> usleep_range(), such as
> >>
> >>mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC)));
> >>
> >> This adds back a really nasty latency, but it should avoid the
> >> compile-time problem.
> >>
> >> Andreas, can you try those two things? (one at a time,
> >> not both)
> >
> > Ok, I tried. None of them works. I rechecked my work and created real
> > git commits out of them and CONFIG_LOCALVERSION_AUTO is also set so
> > the usual stupid things are rules out.
> > In detail:
> > On top of 5.9-rc6 + *reverted* patch:
> > diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> > index fd99c9df8a00..2a9bd7f2b71b 100644
> > --- a/drivers/hwmon/applesmc.c
> > +++ b/drivers/hwmon/applesmc.c
> > @@ -45,7 +45,7 @@
> > /* wait up to 128 ms for a status change. */
> > #define APPLESMC_MIN_WAIT 0x0010
> > #define APPLESMC_RETRY_WAIT0x0100
> > -#define APPLESMC_MAX_WAIT 0x2
> > +#define APPLESMC_MAX_WAIT 0x8000
> >
> > #define APPLESMC_READ_CMD 0x10
> > #define APPLESMC_WRITE_CMD 0x11
> >
>
> Oh man, that code is so badlys broken.
>
> send_byte() repeats sending the data if it was not immediately successful.
> That is done for both data and commands. Effectively that happens if
> the command is not immediately accepted. However, send_argument()
> clearly assumes that each data byte is sent exactly once. Sending
> it more than once will mess up the key that is supposed to be sent.
> The Apple SMC emulation code in qemu confirms that data bytes can not
> be written more than once.
>
> Of course, theoretically it may be that the first data byte was not
> accepted (after all, the ACK bit is not set), but the ACK bit is
> not checked again after udelay(APPLESMC_RETRY_WAIT), so it may
> we
Re: [Question] rtc wake behavior and sysfs
On 05/10/2020 21:47:01-0400, Peter Geis wrote: > On Mon, Oct 5, 2020 at 6:29 PM Alexandre Belloni > wrote: > > > > On 05/10/2020 09:13:08-0400, Peter Geis wrote: > > > Good Morning, > > > > > > While testing suspend to ram on the Ouya, I encountered an interesting > > > issue with the rtc-tps65910 driver. > > > Attempting to use rtc-wake on the default configuration returned: > > > rtcwake: /dev/rtc0 not enabled for wakeup events > > > This is due to: > > > eb5eba4ef722 drivers/rtc/rtc-tps65910.c: enable/disable wake in > > > suspend/resume > > > This commit changed this driver's behavior to not enable wakeup by > > > default, but enables it when entering sleep mode. > > > This seems to be odd behavior to me. > > > Looking at a few other rtc drivers show they simply enable themselves > > > as wakeup sources by default. > > > > > > I also found the sysfs entries are at /sys/devices/ .. > > > /tps65910-rtc/power but are missing at /sys/class/rtc/rtc0/power/ > > > > > > I have two questions. > > > - Should the sysfs wakeup entries be missing at > > > /sys/class/rtc/rtc0/power/ ? > > > > I would be in /sys/class/rtc/rtc0/device/power > > > > > - Shouldn't a rtc be enabled as a wakeup source by default? > > > > > > > The short answer is no, the reason being that not all RTCs are connected > > to an IRQ or a pin that can wakeup or start the platform. What should be > > done is enabling wakeup only when interrupts are available or the > > wakeup-source property is in the rtc device tree node. > > Thank you for your explanation. > > So it would seem we have two issues. > - The sysfs wakeup entries are not populating in > /sys/class/rtc/rtc0/power when they are populating in > /sys/devices/<..>/tps65910-rtc/power. I think the rationale here is that the rtc device is not the wakeup device but the underlying one is hence why it is in /sys/class/rtc/rtc0/device/power and not in /sys/class/rtc/rtc0/power/. > - The wakeup-source property is not being applied to the tps65910-rtc > sub-device when it is applied in the tps65910 devicetree node. > > Should wakeup-source handling be the tps65910-rtc driver's > responsibility, or is that a limitation of the driver core that needs > to be fixed? For now, parsing this property is left to the individual drivers. You'll have to implement it for the tps65910 and so you can get it from the parent node if necessary. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 1/2] cpufreq,arm,arm64: restructure definitions of arch_set_freq_scale()
On 24-09-20, 13:30, Ionela Voinescu wrote:
> Compared to other arch_* functions, arch_set_freq_scale() has an atypical
> weak definition that can be replaced by a strong architecture specific
> implementation.
>
> The more typical support for architectural functions involves defining
> an empty stub in a header file if the symbol is not already defined in
> architecture code. Some examples involve:
> - #define arch_scale_freq_capacity topology_get_freq_scale
> - #define arch_scale_freq_invariant topology_scale_freq_invariant
> - #define arch_scale_cpu_capacitytopology_get_cpu_scale
> - #define arch_update_cpu_topology topology_update_cpu_topology
> - #define arch_scale_thermal_pressuretopology_get_thermal_pressure
> - #define arch_set_thermal_pressure topology_set_thermal_pressure
>
> Bring arch_set_freq_scale() in line with these functions by renaming it to
> topology_set_freq_scale() in the arch topology driver, and by defining the
> arch_set_freq_scale symbol to point to the new function for arm and arm64.
>
> While there are other users of the arch_topology driver, this patch defines
> arch_set_freq_scale for arm and arm64 only, due to their existing
> definitions of arch_scale_freq_capacity. This is the getter function of the
> frequency invariance scale factor and without a getter function, the
> setter function - arch_set_freq_scale() has not purpose.
>
> Signed-off-by: Ionela Voinescu
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm/include/asm/topology.h | 1 +
> arch/arm64/include/asm/topology.h | 1 +
> drivers/base/arch_topology.c | 4 ++--
> drivers/cpufreq/cpufreq.c | 7 ---
> include/linux/arch_topology.h | 2 ++
> include/linux/cpufreq.h | 11 ---
> 6 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index 9219e67befbe..e5e3d5ce4d55 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -8,6 +8,7 @@
> #include
>
> /* Replace task scheduler's default frequency-invariant accounting */
> +#define arch_set_freq_scale topology_set_freq_scale
> #define arch_scale_freq_capacity topology_get_freq_scale
> #define arch_scale_freq_invariant topology_scale_freq_invariant
>
> diff --git a/arch/arm64/include/asm/topology.h
> b/arch/arm64/include/asm/topology.h
> index 7cb519473fbd..11a465243f66 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -26,6 +26,7 @@ void topology_scale_freq_tick(void);
> #endif /* CONFIG_ARM64_AMU_EXTN */
>
> /* Replace task scheduler's default frequency-invariant accounting */
> +#define arch_set_freq_scale topology_set_freq_scale
> #define arch_scale_freq_capacity topology_get_freq_scale
> #define arch_scale_freq_invariant topology_scale_freq_invariant
>
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index 1705c772c273..ae5a596bcf86 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -33,8 +33,8 @@ __weak bool arch_freq_counters_available(const struct
> cpumask *cpus)
> }
> DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE;
>
> -void arch_set_freq_scale(const struct cpumask *cpus, unsigned long cur_freq,
> - unsigned long max_freq)
> +void topology_set_freq_scale(const struct cpumask *cpus, unsigned long
> cur_freq,
> + unsigned long max_freq)
> {
> unsigned long scale;
> int i;
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2ea245a6c0c0..f34d3a3d5ba6 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -160,13 +160,6 @@ u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int
> io_busy)
> }
> EXPORT_SYMBOL_GPL(get_cpu_idle_time);
>
> -__weak void arch_set_freq_scale(const struct cpumask *cpus,
> - unsigned long cur_freq,
> - unsigned long max_freq)
> -{
> -}
> -EXPORT_SYMBOL_GPL(arch_set_freq_scale);
> -
Why can't we have this anymore ? Because it is a macro now instead of a routine
for ARM ?
> /*
> * This is a generic cpufreq init() routine which can be used by cpufreq
> * drivers of SMP systems. It will do following:
> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index 083df331a3c9..0f6cd6b73a61 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -30,6 +30,8 @@ static inline unsigned long topology_get_freq_scale(int cpu)
> return per_cpu(freq_scale, cpu);
> }
>
> +void topology_set_freq_scale(const struct cpumask *cpus, unsigned long
> cur_freq,
> + unsigned long max_freq);
> bool topology_scale_freq_invariant(void);
>
> bool arch_freq_counters_available(const struct cpumask *cpus);
> diff --git a/include/linux/cpufreq.h
Re: [PATCH v11 4/5] dt-bindings: serial: document LiteUART bindings
Hi Mateusz,
On Tue, Oct 6, 2020 at 9:01 AM Mateusz Holenko wrote:
> On Fri, Sep 25, 2020 at 3:16 PM Geert Uytterhoeven
> wrote:
> > On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> > wrote:
> > > From: Filip Kokosinski
> > >
> > > Add documentation for LiteUART devicetree bindings.
> > >
> > > Signed-off-by: Filip Kokosinski
> > > Signed-off-by: Mateusz Holenko
> > > Reviewed-by: Rob Herring
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
> > > +properties:
> > > + compatible:
> > > +const: litex,liteuart
> >
> > Have you already decided how to handle future LiteUART variants that add
> > new features (e.g. CTS/RTS, DMA)?
>
> We were thinking of adding KConfig options, like
>
> [ ] LiteUART serial port support
> < > LiteUART DMA support
>
> and using ifdefs in the code.
That is the driver part, not the DT part.
If enabled, the driver still needs to know if the feature is present and
to be used, or not.
> The other option could be to extend LiteX itself so that the UART core
> provides information about its configuration via the capabilities register.
> That way the driver could configure itself automatically at runtime.
>
> This is, however, not decided yet.
A capabilities register sounds good to me.
That means everything is handled automatically by the driver
However, it does mean the DT schema checker cannot validate the
use of optional DT properties related to optional features, if any.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] arm: use DEBUG_UART_PHYS and DEBUG_UART_VIRT for sti LL_UART
Hi Alain On 8/30/20 9:57 PM, Alain Volmat wrote: > Update the sti platform LL_UART support to rely on > CONFIG_DEBUG_UART_PHYS and CONFIG_DEBUG_UART_VIRT from Kconfig > > Signed-off-by: Alain Volmat > --- > arch/arm/Kconfig.debug | 23 --- > arch/arm/include/debug/sti.S | 26 ++ > 2 files changed, 14 insertions(+), 35 deletions(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index 8a66a4e3..e97d6e5c8898 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1184,10 +1184,9 @@ choice > Say Y here if you want kernel low-level debugging support > on ST SPEAr13xx based platforms. > > - config STIH41X_DEBUG_ASC2 > + config DEBUG_STIH41X_ASC2 > bool "Use StiH415/416 ASC2 UART for low-level debug" > depends on ARCH_STI > - select DEBUG_STI_UART > help > Say Y here if you want kernel low-level debugging support > on STiH415/416 based platforms like b2000, which has > @@ -1195,10 +1194,9 @@ choice > > If unsure, say N. > > - config STIH41X_DEBUG_SBC_ASC1 > + config DEBUG_STIH41X_SBC_ASC1 > bool "Use StiH415/416 SBC ASC1 UART for low-level debug" > depends on ARCH_STI > - select DEBUG_STI_UART > help > Say Y here if you want kernel low-level debugging support > on STiH415/416 based platforms like b2020. which has > @@ -1534,10 +1532,6 @@ config DEBUG_TEGRA_UART > bool > depends on ARCH_TEGRA > > -config DEBUG_STI_UART > - bool > - depends on ARCH_STI > - > config DEBUG_STM32_UART > bool > depends on ARCH_STM32 > @@ -1591,7 +1585,8 @@ config DEBUG_LL_INCLUDE > default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART || DEBUG_S3C64XX_UART > default "debug/s5pv210.S" if DEBUG_S5PV210_UART > default "debug/sirf.S" if DEBUG_SIRFSOC_UART > - default "debug/sti.S" if DEBUG_STI_UART > + default "debug/sti.S" if DEBUG_STIH41X_ASC2 > + default "debug/sti.S" if DEBUG_STIH41X_SBC_ASC1 > default "debug/stm32.S" if DEBUG_STM32_UART > default "debug/tegra.S" if DEBUG_TEGRA_UART > default "debug/ux500.S" if DEBUG_UX500_UART > @@ -1723,7 +1718,9 @@ config DEBUG_UART_PHYS > default 0xfc00c000 if DEBUG_AT91_SAMA5D4_USART3 > default 0xfcb0 if DEBUG_HI3620_UART > default 0xfd883000 if DEBUG_ALPINE_UART0 > + default 0xfe531000 if DEBUG_STIH41X_SBC_ASC1 > default 0xfe80 if ARCH_IOP32X > + default 0xfed32000 if DEBUG_STIH41X_ASC2 > default 0xff69 if DEBUG_RK32_UART2 > default 0xffc02000 if DEBUG_SOCFPGA_UART0 > default 0xffc02100 if DEBUG_SOCFPGA_ARRIA10_UART1 > @@ -1752,7 +1749,8 @@ config DEBUG_UART_PHYS > DEBUG_S3C64XX_UART || \ > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \ > DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \ > - DEBUG_AT91_UART || DEBUG_STM32_UART > + DEBUG_AT91_UART || DEBUG_STM32_UART || \ > + DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 > > config DEBUG_UART_VIRT > hex "Virtual base address of debug UART" > @@ -1817,7 +1815,9 @@ config DEBUG_UART_VIRT > default 0xfc705000 if DEBUG_ZTE_ZX > default 0xfcfe8600 if DEBUG_BCM63XX_UART > default 0xfd00 if DEBUG_SPEAR3XX || DEBUG_SPEAR13XX > + default 0xfd531000 if DEBUG_STIH41X_SBC_ASC1 > default 0xfd883000 if DEBUG_ALPINE_UART0 > + default 0xfdd32000 if DEBUG_STIH41X_ASC2 > default 0xfe01 if STM32MP1_DEBUG_UART > default 0xfe017000 if DEBUG_MMP_UART2 > default 0xfe018000 if DEBUG_MMP_UART3 > @@ -1863,7 +1863,8 @@ config DEBUG_UART_VIRT > DEBUG_S3C64XX_UART || \ > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \ > DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \ > - DEBUG_AT91_UART || DEBUG_STM32_UART > + DEBUG_AT91_UART || DEBUG_STM32_UART || \ > + DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 > > config DEBUG_UART_8250_SHIFT > int "Register offset shift for the 8250 debug UART" > diff --git a/arch/arm/include/debug/sti.S b/arch/arm/include/debug/sti.S > index 6b42c91f217d..a903a60b81c6 100644 > --- a/arch/arm/include/debug/sti.S > +++ b/arch/arm/include/debug/sti.S > @@ -6,28 +6,6 @@ > * Copyright (C) 2013 STMicroelectronics (R&D) Limited. > */ > > -#define STIH41X_COMMS_BASE 0xfed0 > -#define STIH41X_ASC2_BASE (STIH41X_COMMS_BASE+0x32000) > - > -#define STIH41X_SBC_LPM_BASE0xfe40 > -#define STIH41X_SBC_COMMS_BASE (STIH41X_SBC_LPM_BASE + 0x10) > -#define STIH41X_SBC_ASC1_BASE (STIH41X_SBC_COMMS_BASE + 0x31000) > - > - > -#define VIRT_ADDRESS(x) (x - 0x100) > - > -#if IS_ENABLED(CONFIG_STIH41
Re: [PATCH] fs: remove ->sendpage
On Mon, Sep 28, 2020 at 03:17:34PM -0700, David Miller wrote: > From: Christoph Hellwig > Date: Sat, 26 Sep 2020 09:00:49 +0200 > > > ->sendpage is only called from generic_splice_sendpage. The only user of > > generic_splice_sendpage is socket_file_ops, which is also the only > > instance that actually implements ->sendpage. Remove the ->sendpage file > > operation and just open code the logic in the socket code. > > > > Signed-off-by: Christoph Hellwig > > Acked-by: David S. Miller Al, can you pick this up? Or give your ACK so that Dave can pick it up?
Re: [PATCH v2] iio: adc: exynos: do not rely on 'users' counter in ISR
On Tue, 6 Oct 2020 at 06:12, wrote: > > The order in which 'users' counter is decremented vs calling drivers' > close() method is implementation specific, and we should not rely on > it. Let's introduce driver private flag and use it to signal ISR > to exit when device is being closed. > > This has a side-effect of fixing issue of accessing inut->users > outside of input->mutex protection. > > Reported-by: Andrzej Pietrasiewicz > Signed-off-by: Dmitry Torokhov > --- > > v2: switched from ordinary read/write to READ_ONCE/WRITE_ONCE per Michał > Mirosław > > drivers/iio/adc/exynos_adc.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 2/2] arm: sti LL_UART: add STiH418 SBC UART0 support
Hi Alain On 8/30/20 9:57 PM, Alain Volmat wrote: > Add the entry for the STiH418 SBC UART0 low level uart. > > Signed-off-by: Alain Volmat > --- > arch/arm/Kconfig.debug | 19 +-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index e97d6e5c8898..447d177fcf8d 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1204,6 +1204,16 @@ choice > > If unsure, say N. > > + config DEBUG_STIH418_SBC_ASC0 > + bool "Use StiH418 SBC ASC0 UART for low-level debug" > + depends on ARCH_STI > + help > + Say Y here if you want kernel low-level debugging support > + on STiH418 based platforms which has default UART wired > + up to SBC ASC0. > + > + If unsure, say N. > + > config STM32F4_DEBUG_UART > bool "Use STM32F4 UART for low-level debug" > depends on MACH_STM32F429 || MACH_STM32F469 > @@ -1587,6 +1597,7 @@ config DEBUG_LL_INCLUDE > default "debug/sirf.S" if DEBUG_SIRFSOC_UART > default "debug/sti.S" if DEBUG_STIH41X_ASC2 > default "debug/sti.S" if DEBUG_STIH41X_SBC_ASC1 > + default "debug/sti.S" if DEBUG_STIH418_SBC_ASC0 > default "debug/stm32.S" if DEBUG_STM32_UART > default "debug/tegra.S" if DEBUG_TEGRA_UART > default "debug/ux500.S" if DEBUG_UX500_UART > @@ -1620,6 +1631,7 @@ config DEBUG_UART_PHYS > default 0x03010fe0 if ARCH_RPC > default 0x0700 if DEBUG_SUN9I_UART0 > default 0x09405000 if DEBUG_ZTE_ZX > + default 0x0953 if DEBUG_STIH418_SBC_ASC0 > default 0x10009000 if DEBUG_REALVIEW_STD_PORT || \ > DEBUG_VEXPRESS_UART0_CA9 > default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT > @@ -1750,7 +1762,8 @@ config DEBUG_UART_PHYS > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \ > DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \ > DEBUG_AT91_UART || DEBUG_STM32_UART || \ > - DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 > + DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \ > + DEBUG_STIH418_SBC_ASC0 > > config DEBUG_UART_VIRT > hex "Virtual base address of debug UART" > @@ -1796,6 +1809,7 @@ config DEBUG_UART_VIRT > default 0xf809 if DEBUG_VEXPRESS_UART0_RS1 > default 0xf8ffee00 if DEBUG_AT91_SAM9263_DBGU > default 0xf8fff200 if DEBUG_AT91_RM9200_DBGU > + default 0xf953 if DEBUG_STIH418_SBC_ASC0 > default 0xf9e09000 if DEBUG_AM33XXUART1 > default 0xfa02 if DEBUG_OMAP4UART3 || DEBUG_TI81XXUART1 > default 0xfa022000 if DEBUG_TI81XXUART2 > @@ -1864,7 +1878,8 @@ config DEBUG_UART_VIRT > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \ > DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \ > DEBUG_AT91_UART || DEBUG_STM32_UART || \ > - DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 > + DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \ > + DEBUG_STIH418_SBC_ASC0 > > config DEBUG_UART_8250_SHIFT > int "Register offset shift for the 8250 debug UART" Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH v2 00/29] [Set 1,2,3] Rid W=1 warnings in Wireless
Lee Jones writes:
> On Tue, 06 Oct 2020, Kalle Valo wrote:
>
>> Lee Jones writes:
>>
>> > On Thu, 10 Sep 2020, Lee Jones wrote:
>> >
>> >> This is a rebased/re-worked set of patches which have been
>> >> previously posted to the mailing list(s).
>> >>
>> >> This set is part of a larger effort attempting to clean-up W=1
>> >> kernel builds, which are currently overwhelmingly riddled with
>> >> niggly little warnings.
>> >>
>> >> There are quite a few W=1 warnings in the Wireless. My plan
>> >> is to work through all of them over the next few weeks.
>> >> Hopefully it won't be too long before drivers/net/wireless
>> >> builds clean with W=1 enabled.
>> >>
>> >> Lee Jones (29):
>> >> iwlwifi: dvm: Demote non-compliant kernel-doc headers
>> >> iwlwifi: rs: Demote non-compliant kernel-doc headers
>> >> iwlwifi: dvm: tx: Demote non-compliant kernel-doc headers
>> >> iwlwifi: dvm: lib: Demote non-compliant kernel-doc headers
>> >> iwlwifi: calib: Demote seemingly unintentional kerneldoc header
>> >> wil6210: Fix a couple of formatting issues in 'wil6210_debugfs_init'
>> >> iwlwifi: dvm: sta: Demote a bunch of nonconformant kernel-doc headers
>> >> iwlwifi: mvm: ops: Remove unused static struct 'iwl_mvm_debug_names'
>> >> iwlwifi: dvm: Demote a couple of nonconformant kernel-doc headers
>> >> iwlwifi: mvm: utils: Fix some doc-rot
>> >> iwlwifi: dvm: scan: Demote a few nonconformant kernel-doc headers
>> >> iwlwifi: dvm: rxon: Demote non-conformant kernel-doc headers
>> >> iwlwifi: mvm: tx: Demote misuse of kernel-doc headers
>> >> iwlwifi: dvm: devices: Fix function documentation formatting issues
>> >> iwlwifi: iwl-drv: Provide descriptions debugfs dentries
>> >> wil6210: wmi: Fix formatting and demote non-conforming function
>> >> headers
>> >> wil6210: interrupt: Demote comment header which is clearly not
>> >> kernel-doc
>> >> wil6210: txrx: Demote obvious abuse of kernel-doc
>> >> wil6210: txrx_edma: Demote comments which are clearly not kernel-doc
>> >> wil6210: pmc: Demote a few nonconformant kernel-doc function headers
>> >> wil6210: wil_platform: Demote kernel-doc header to standard comment
>> >> block
>> >> wil6210: wmi: Correct misnamed function parameter 'ptr_'
>> >> ath6kl: wmi: Remove unused variable 'rate'
>> >> ath9k: ar9002_initvals: Remove unused array
>> >> 'ar9280PciePhy_clkreq_off_L1_9280'
>> >> ath9k: ar9001_initvals: Remove unused array 'ar5416Bank6_9100'
>> >> ath9k: ar5008_initvals: Remove unused table entirely
>> >> ath9k: ar5008_initvals: Move ar5416Bank{0,1,2,3,7} to where they are
>> >> used
>> >> brcmsmac: phytbl_lcn: Remove unused array 'dot11lcn_gain_tbl_rev1'
>> >> brcmsmac: phy_lcn: Remove unused variable
>> >> 'lcnphy_rx_iqcomp_table_rev0'
>> >
>> > What's happening with all of these iwlwifi patches?
>> >
>> > Looks like they are still not applied.
>>
>> Luca (CCed) takes iwlwifi patches to his iwlwifi tree.
>
> Thanks Kalle.
>
> Luca,
>
> Do you know why these patches have not been applied yet? Do you
> plan on applying them this week? -rc1 is not due for release for
> nearly 3 weeks now that Linus tagged an -rc8.
I can also take Lee's patches directly to wireless-drivers-next, if
that's easier for Luca.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] arm: disable frequency invariance for CONFIG_BL_SWITCHER
On 24-09-20, 13:30, Ionela Voinescu wrote: > big.LITTLE switching complicates the setting of a correct cpufreq-based > frequency invariance scale factor due to (as observed in > drivers/cpufreq/vexpress-spc-cpufreq.c): > - Incorrect current and maximum frequencies as a result of the >exposure of a virtual frequency table to the cpufreq core, > - Missed updates as a result of asynchronous frequency adjustments >caused by frequency changes in other CPU pairs. > > Given that its functionality is atypical in regards to frequency > invariance and this is an old technology, disable frequency > invariance for when big.LITTLE switching is configured in to prevent > incorrect scale setting. > > Signed-off-by: Ionela Voinescu > Suggested-by: Dietmar Eggemann > Cc: Russell King > Cc: Catalin Marinas > --- > arch/arm/include/asm/topology.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h > index e5e3d5ce4d55..470299ee2fba 100644 > --- a/arch/arm/include/asm/topology.h > +++ b/arch/arm/include/asm/topology.h > @@ -7,10 +7,13 @@ > #include > #include > > +/* big.LITTLE switcher is incompatible with frequency invariance */ > +#ifndef CONFIG_BL_SWITCHER > /* Replace task scheduler's default frequency-invariant accounting */ > #define arch_set_freq_scale topology_set_freq_scale > #define arch_scale_freq_capacity topology_get_freq_scale > #define arch_scale_freq_invariant topology_scale_freq_invariant > +#endif > > /* Replace task scheduler's default cpu-invariant accounting */ > #define arch_scale_cpu_capacity topology_get_cpu_scale Acked-by: Viresh Kumar -- viresh
[PATCH v6 03/11] device-dax/kmem: move resource tracking to drvdata
Towards removing the mode specific @dax_kmem_res attribute from the
generic 'struct dev_dax', and preparing for multi-range support, move
resource tracking to driver data. The memory for the resource name
needs to have its own lifetime separate from the device bind lifetime
for cases where the driver is unbound, but the kmem range could not be
unplugged from the page allocator.
The resource reservation also needs to be released manually via
release_resource() given the awkward manipulation of the
IORESOURCE_BUSY flag.
Cc: David Hildenbrand
Cc: Vishal Verma
Cc: Dave Hansen
Cc: Pavel Tatashin
Cc: Brice Goglin
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/dax/dax-private.h |3 --
drivers/dax/kmem.c| 55 +
2 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
index fbaea36938ae..0668b58c64aa 100644
--- a/drivers/dax/dax-private.h
+++ b/drivers/dax/dax-private.h
@@ -42,8 +42,6 @@ struct dax_region {
* @dev - device core
* @pgmap - pgmap for memmap setup / lifetime (driver owned)
* @range: resource range for the instance
- * @dax_mem_res: physical address range of hotadded DAX memory
- * @dax_mem_name: name for hotadded DAX memory via add_memory_driver_managed()
*/
struct dev_dax {
struct dax_region *region;
@@ -52,7 +50,6 @@ struct dev_dax {
struct device dev;
struct dev_pagemap *pgmap;
struct range range;
- struct resource *dax_kmem_res;
};
static inline struct dev_dax *to_dev_dax(struct device *dev)
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index b0d6a99cf12d..a415bc239db4 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -29,14 +29,19 @@ static struct range dax_kmem_range(struct dev_dax *dev_dax)
return range;
}
+struct dax_kmem_data {
+ const char *res_name;
+ struct resource *res;
+};
+
int dev_dax_kmem_probe(struct device *dev)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
struct range range = dax_kmem_range(dev_dax);
+ struct dax_kmem_data *data;
struct resource *new_res;
- const char *new_res_name;
+ int rc = -ENOMEM;
int numa_node;
- int rc;
/*
* Ensure good NUMA information for the persistent memory.
@@ -51,17 +56,22 @@ int dev_dax_kmem_probe(struct device *dev)
return -EINVAL;
}
- new_res_name = kstrdup(dev_name(dev), GFP_KERNEL);
- if (!new_res_name)
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
return -ENOMEM;
+ data->res_name = kstrdup(dev_name(dev), GFP_KERNEL);
+ if (!data->res_name)
+ goto err_res_name;
+
/* Region is permanently reserved if hotremove fails. */
- new_res = request_mem_region(range.start, range_len(&range),
new_res_name);
+ new_res = request_mem_region(range.start, range_len(&range),
data->res_name);
if (!new_res) {
dev_warn(dev, "could not reserve region [%#llx-%#llx]\n",
range.start, range.end);
- kfree(new_res_name);
- return -EBUSY;
+ rc = -EBUSY;
+ goto err_request_mem;
}
+ data->res = new_res;
/*
* Set flags appropriate for System RAM. Leave ..._BUSY clear
@@ -77,15 +87,21 @@ int dev_dax_kmem_probe(struct device *dev)
*/
rc = add_memory_driver_managed(numa_node, new_res->start,
resource_size(new_res), kmem_name);
- if (rc) {
- release_resource(new_res);
- kfree(new_res);
- kfree(new_res_name);
- return rc;
- }
- dev_dax->dax_kmem_res = new_res;
+ if (rc)
+ goto err_add_memory;
+
+ dev_set_drvdata(dev, data);
return 0;
+
+err_add_memory:
+ release_resource(data->res);
+ kfree(data->res);
+err_request_mem:
+ kfree(data->res_name);
+err_res_name:
+ kfree(data);
+ return rc;
}
#ifdef CONFIG_MEMORY_HOTREMOVE
@@ -93,8 +109,7 @@ static int dev_dax_kmem_remove(struct device *dev)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
struct range range = dax_kmem_range(dev_dax);
- struct resource *res = dev_dax->dax_kmem_res;
- const char *res_name = res->name;
+ struct dax_kmem_data *data = dev_get_drvdata(dev);
int rc;
/*
@@ -112,10 +127,10 @@ static int dev_dax_kmem_remove(struct device *dev)
}
/* Release and free dax resources */
- release_resource(res);
- kfree(res);
- kfree(res_name);
- dev_dax->dax_kmem_res = NULL;
+ release_resource(data->res);
+ kfree(data->res);
+ kfree(data->res_name);
+ kfree(data);
return 0;
}
[PATCH v6 08/11] device-dax: add resize support
Make the device-dax 'size' attribute writable to allow capacity to be
split between multiple instances in a region. The intended consumers of
this capability are users that want to split a scarce memory resource
between device-dax and System-RAM access, or users that want to have
multiple security domains for a large region.
By default the hmem instance provider allocates an entire region to the
first instance. The process of creating a new instance (assuming a
region-id of 0) is find the region and trigger the 'create' attribute
which yields an empty instance to configure. For example:
cd /sys/bus/dax/devices
echo dax0.0 > dax0.0/driver/unbind
echo $new_size > dax0.0/size
echo 1 > $(readlink -f dax0.0)../dax_region/create
seed=$(cat $(readlink -f dax0.0)../dax_region/seed)
echo $new_size > $seed/size
echo dax0.0 > ../drivers/{device_dax,kmem}/bind
echo dax0.1 > ../drivers/{device_dax,kmem}/bind
Instances can be destroyed by:
echo $device > $(readlink -f $device)../dax_region/delete
Link:
https://lkml.kernel.org/r/159643102625.4062302.7431838945566033852.st...@dwillia2-desk3.amr.corp.intel.com
Cc: Vishal Verma
Cc: Brice Goglin
Cc: Dave Hansen
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 161 ++---
1 file changed, 152 insertions(+), 9 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index dce9413a4394..53d07f2f1285 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "dax-private.h"
#include "bus.h"
@@ -562,7 +563,8 @@ struct dax_region *alloc_dax_region(struct device *parent,
int region_id,
}
EXPORT_SYMBOL_GPL(alloc_dax_region);
-static int alloc_dev_dax_range(struct dev_dax *dev_dax, resource_size_t size)
+static int alloc_dev_dax_range(struct dev_dax *dev_dax, u64 start,
+ resource_size_t size)
{
struct dax_region *dax_region = dev_dax->region;
struct resource *res = &dax_region->res;
@@ -580,12 +582,7 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax,
resource_size_t size)
return 0;
}
- /* TODO: handle multiple allocations per region */
- if (res->child)
- return -ENOMEM;
-
- alloc = __request_region(res, res->start, size, dev_name(dev), 0);
-
+ alloc = __request_region(res, start, size, dev_name(dev), 0);
if (!alloc)
return -ENOMEM;
@@ -597,6 +594,29 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax,
resource_size_t size)
return 0;
}
+static int adjust_dev_dax_range(struct dev_dax *dev_dax, struct resource *res,
resource_size_t size)
+{
+ struct dax_region *dax_region = dev_dax->region;
+ struct range *range = &dev_dax->range;
+ int rc = 0;
+
+ device_lock_assert(dax_region->dev);
+
+ if (size)
+ rc = adjust_resource(res, range->start, size);
+ else
+ __release_region(&dax_region->res, range->start,
range_len(range));
+ if (rc)
+ return rc;
+
+ dev_dax->range = (struct range) {
+ .start = range->start,
+ .end = range->start + size - 1,
+ };
+
+ return 0;
+}
+
static ssize_t size_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -605,7 +625,127 @@ static ssize_t size_show(struct device *dev,
return sprintf(buf, "%llu\n", size);
}
-static DEVICE_ATTR_RO(size);
+
+static bool alloc_is_aligned(struct dax_region *dax_region,
+ resource_size_t size)
+{
+ /*
+* The minimum mapping granularity for a device instance is a
+* single subsection, unless the arch says otherwise.
+*/
+ return IS_ALIGNED(size, max_t(unsigned long, dax_region->align,
+ memremap_compat_align()));
+}
+
+static int dev_dax_shrink(struct dev_dax *dev_dax, resource_size_t size)
+{
+ struct dax_region *dax_region = dev_dax->region;
+ struct range *range = &dev_dax->range;
+ struct resource *res, *adjust = NULL;
+ struct device *dev = &dev_dax->dev;
+
+ for_each_dax_region_resource(dax_region, res)
+ if (strcmp(res->name, dev_name(dev)) == 0
+ && res->start == range->start) {
+ adjust = res;
+ break;
+ }
+
+ if (dev_WARN_ONCE(dev, !adjust, "failed to find matching resource\n"))
+ return -ENXIO;
+ return adjust_dev_dax_range(dev_dax, adjust, size);
+}
+
+static ssize_t dev_dax_resize(struct dax_region *dax_region,
+ struct dev_dax *dev_dax, resource_size_t size)
+{
+ resource_size_t avail = dax_region_avail_size(dax_region), to_alloc;
+ resource_size_t dev
[PATCH v6 07/11] drivers/base: make device_find_child_by_name() compatible with sysfs inputs
Use sysfs_streq() in device_find_child_by_name() to allow it to use a
sysfs input string that might contain a trailing newline.
The other "device by name" interfaces,
{bus,driver,class}_find_device_by_name(), already account for sysfs
strings.
Link:
https://lkml.kernel.org/r/159643102106.4062302.12229802117645312104.st...@dwillia2-desk3.amr.corp.intel.com
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Dan Williams
---
drivers/base/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bb5806a2bd4c..8dd753539c06 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3324,7 +3324,7 @@ struct device *device_find_child_by_name(struct device
*parent,
klist_iter_init(&parent->p->klist_children, &i);
while ((child = next_device(&i)))
- if (!strcmp(dev_name(child), name) && get_device(child))
+ if (sysfs_streq(dev_name(child), name) && get_device(child))
break;
klist_iter_exit(&i);
return child;
[PATCH v6 05/11] device-dax: introduce 'struct dev_dax' typed-driver operations
In preparation for introducing seed devices the dax-bus core needs to be
able to intercept ->probe() and ->remove() operations. Towards that end
arrange for the bus and drivers to switch from raw 'struct device'
driver operations to 'struct dev_dax' typed operations.
Cc: Jason Yan
Cc: Vishal Verma
Cc: Brice Goglin
Cc: Dave Hansen
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Reported-by: Hulk Robot
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 18 ++
drivers/dax/bus.h |4 +++-
drivers/dax/device.c | 12 +---
drivers/dax/kmem.c| 18 --
drivers/dax/pmem/compat.c |2 +-
5 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 0a48ce378686..9549f11ebed0 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -135,10 +135,28 @@ static bool is_static(struct dax_region *dax_region)
return (dax_region->res.flags & IORESOURCE_DAX_STATIC) != 0;
}
+static int dax_bus_probe(struct device *dev)
+{
+ struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return dax_drv->probe(dev_dax);
+}
+
+static int dax_bus_remove(struct device *dev)
+{
+ struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return dax_drv->remove(dev_dax);
+}
+
static struct bus_type dax_bus_type = {
.name = "dax",
.uevent = dax_bus_uevent,
.match = dax_bus_match,
+ .probe = dax_bus_probe,
+ .remove = dax_bus_remove,
.drv_groups = dax_drv_groups,
};
diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
index 44592a8cac0f..da27ea70a19a 100644
--- a/drivers/dax/bus.h
+++ b/drivers/dax/bus.h
@@ -38,6 +38,8 @@ struct dax_device_driver {
struct device_driver drv;
struct list_head ids;
int match_always;
+ int (*probe)(struct dev_dax *dev);
+ int (*remove)(struct dev_dax *dev);
};
int __dax_driver_register(struct dax_device_driver *dax_drv,
@@ -48,7 +50,7 @@ void dax_driver_unregister(struct dax_device_driver *dax_drv);
void kill_dev_dax(struct dev_dax *dev_dax);
#if IS_ENABLED(CONFIG_DEV_DAX_PMEM_COMPAT)
-int dev_dax_probe(struct device *dev);
+int dev_dax_probe(struct dev_dax *dev_dax);
#endif
/*
diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index 287cf0a3db23..9833fa83b537 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -392,11 +392,11 @@ static void dev_dax_kill(void *dev_dax)
kill_dev_dax(dev_dax);
}
-int dev_dax_probe(struct device *dev)
+int dev_dax_probe(struct dev_dax *dev_dax)
{
- struct dev_dax *dev_dax = to_dev_dax(dev);
struct dax_device *dax_dev = dev_dax->dax_dev;
struct range *range = &dev_dax->range;
+ struct device *dev = &dev_dax->dev;
struct dev_pagemap *pgmap;
struct inode *inode;
struct cdev *cdev;
@@ -446,17 +446,15 @@ int dev_dax_probe(struct device *dev)
}
EXPORT_SYMBOL_GPL(dev_dax_probe);
-static int dev_dax_remove(struct device *dev)
+static int dev_dax_remove(struct dev_dax *dev_dax)
{
/* all probe actions are unwound by devm */
return 0;
}
static struct dax_device_driver device_dax_driver = {
- .drv = {
- .probe = dev_dax_probe,
- .remove = dev_dax_remove,
- },
+ .probe = dev_dax_probe,
+ .remove = dev_dax_remove,
.match_always = 1,
};
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index a415bc239db4..5fb27fd3eb61 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -34,10 +34,10 @@ struct dax_kmem_data {
struct resource *res;
};
-int dev_dax_kmem_probe(struct device *dev)
+static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
{
- struct dev_dax *dev_dax = to_dev_dax(dev);
struct range range = dax_kmem_range(dev_dax);
+ struct device *dev = &dev_dax->dev;
struct dax_kmem_data *data;
struct resource *new_res;
int rc = -ENOMEM;
@@ -105,12 +105,12 @@ int dev_dax_kmem_probe(struct device *dev)
}
#ifdef CONFIG_MEMORY_HOTREMOVE
-static int dev_dax_kmem_remove(struct device *dev)
+static int dev_dax_kmem_remove(struct dev_dax *dev_dax)
{
- struct dev_dax *dev_dax = to_dev_dax(dev);
+ int rc;
+ struct device *dev = &dev_dax->dev;
struct range range = dax_kmem_range(dev_dax);
struct dax_kmem_data *data = dev_get_drvdata(dev);
- int rc;
/*
* We have one shot for removing memory, if some memory blocks were not
@@ -135,7 +135,7 @@ static int dev_dax_kmem_remove(struct device *dev)
return 0;
}
#else
-static int dev_dax_kmem_remove(struct device *dev)
+static int dev_dax_kmem_remove(struct dev_dax *dev_dax)
{
/*
* Without hotremove purposely leak the req
[PATCH v6 09/11] mm/memremap_pages: convert to 'struct range'
The 'struct resource' in 'struct dev_pagemap' is only used for holding
resource span information. The other fields, 'name', 'flags', 'desc',
'parent', 'sibling', and 'child' are all unused wasted space.
This is in preparation for introducing a multi-range extension of
devm_memremap_pages().
The bulk of this change is unwinding all the places internal to libnvdimm
that used 'struct resource' unnecessarily, and replacing instances of
'struct dev_pagemap'.res with 'struct dev_pagemap'.range.
P2PDMA had a minor usage of the resource flags field, but only to report
failures with "%pR". That is replaced with an open coded print of the
range.
Link:
https://lkml.kernel.org/r/159643103173.4062302.768998885691711532.st...@dwillia2-desk3.amr.corp.intel.com
Link: https://lkml.kernel.org/r/20200926121402.GA7467@kadam
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Vishal Verma
Cc: Vivek Goyal
Cc: Dave Jiang
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ira Weiny
Cc: Bjorn Helgaas
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Reported-by: Dan Carpenter
Signed-off-by: Dan Williams
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 13 +++--
drivers/dax/bus.c | 10 ++--
drivers/dax/bus.h |2 -
drivers/dax/device.c |3 -
drivers/dax/hmem/hmem.c|5 ++
drivers/dax/pmem/core.c| 12 ++---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 14 +++---
drivers/nvdimm/badrange.c | 26 +--
drivers/nvdimm/claim.c | 13 +++--
drivers/nvdimm/nd.h|3 +
drivers/nvdimm/pfn_devs.c | 12 ++---
drivers/nvdimm/pmem.c | 26 ++-
drivers/nvdimm/region.c| 21 +
drivers/pci/p2pdma.c | 11 ++---
drivers/xen/unpopulated-alloc.c| 48 +---
include/linux/memremap.h |5 +-
include/linux/range.h |1
lib/test_hmm.c | 50 ++---
mm/memremap.c | 77
tools/testing/nvdimm/test/iomap.c |2 -
20 files changed, 192 insertions(+), 162 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 7705d5557239..29ec555055c2 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -687,9 +687,9 @@ static struct page *kvmppc_uvmem_get_page(unsigned long
gpa, struct kvm *kvm)
struct kvmppc_uvmem_page_pvt *pvt;
unsigned long pfn_last, pfn_first;
- pfn_first = kvmppc_uvmem_pgmap.res.start >> PAGE_SHIFT;
+ pfn_first = kvmppc_uvmem_pgmap.range.start >> PAGE_SHIFT;
pfn_last = pfn_first +
- (resource_size(&kvmppc_uvmem_pgmap.res) >> PAGE_SHIFT);
+ (range_len(&kvmppc_uvmem_pgmap.range) >> PAGE_SHIFT);
spin_lock(&kvmppc_uvmem_bitmap_lock);
bit = find_first_zero_bit(kvmppc_uvmem_bitmap,
@@ -1007,7 +1007,7 @@ static vm_fault_t kvmppc_uvmem_migrate_to_ram(struct
vm_fault *vmf)
static void kvmppc_uvmem_page_free(struct page *page)
{
unsigned long pfn = page_to_pfn(page) -
- (kvmppc_uvmem_pgmap.res.start >> PAGE_SHIFT);
+ (kvmppc_uvmem_pgmap.range.start >> PAGE_SHIFT);
struct kvmppc_uvmem_page_pvt *pvt;
spin_lock(&kvmppc_uvmem_bitmap_lock);
@@ -1170,7 +1170,8 @@ int kvmppc_uvmem_init(void)
}
kvmppc_uvmem_pgmap.type = MEMORY_DEVICE_PRIVATE;
- kvmppc_uvmem_pgmap.res = *res;
+ kvmppc_uvmem_pgmap.range.start = res->start;
+ kvmppc_uvmem_pgmap.range.end = res->end;
kvmppc_uvmem_pgmap.ops = &kvmppc_uvmem_ops;
/* just one global instance: */
kvmppc_uvmem_pgmap.owner = &kvmppc_uvmem_pgmap;
@@ -1205,7 +1206,7 @@ void kvmppc_uvmem_free(void)
return;
memunmap_pages(&kvmppc_uvmem_pgmap);
- release_mem_region(kvmppc_uvmem_pgmap.res.start,
- resource_size(&kvmppc_uvmem_pgmap.res));
+ release_mem_region(kvmppc_uvmem_pgmap.range.start,
+ range_len(&kvmppc_uvmem_pgmap.range));
kfree(kvmppc_uvmem_bitmap);
}
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 53d07f2f1285..00fa73a8dfb4 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -515,7 +515,7 @@ static void dax_region_unregister(void *region)
}
struct dax_region *alloc_dax_region(struct device *parent, int region_id,
- struct resource *res, int target_node, unsigned int align,
+ struct range *range, int target_node, unsigned int align,
unsigned long flags)
{
struct dax_region *dax_region;
@@ -530,8 +530,8 @@ struct dax_region *alloc_dax_region(struct device
[PATCH v6 02/11] device-dax/kmem: introduce dax_kmem_range()
Towards removing the mode specific @dax_kmem_res attribute from the
generic 'struct dev_dax', and preparing for multi-range support, teach
the driver to calculate the hotplug range from the device range. The
hotplug range is the trivially calculated memory-block-size aligned
version of the device range.
Cc: David Hildenbrand
Cc: Vishal Verma
Cc: Dave Hansen
Cc: Pavel Tatashin
Cc: Brice Goglin
Cc: Dave Jiang
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Reviewed-by: David Hildenbrand
Signed-off-by: Dan Williams
---
drivers/dax/kmem.c | 40 +---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 5bb133df147d..b0d6a99cf12d 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -19,13 +19,20 @@ static const char *kmem_name;
/* Set if any memory will remain added when the driver will be unloaded. */
static bool any_hotremove_failed;
+static struct range dax_kmem_range(struct dev_dax *dev_dax)
+{
+ struct range range;
+
+ /* memory-block align the hotplug range */
+ range.start = ALIGN(dev_dax->range.start, memory_block_size_bytes());
+ range.end = ALIGN_DOWN(dev_dax->range.end + 1,
memory_block_size_bytes()) - 1;
+ return range;
+}
+
int dev_dax_kmem_probe(struct device *dev)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
- struct range *range = &dev_dax->range;
- resource_size_t kmem_start;
- resource_size_t kmem_size;
- resource_size_t kmem_end;
+ struct range range = dax_kmem_range(dev_dax);
struct resource *new_res;
const char *new_res_name;
int numa_node;
@@ -44,25 +51,14 @@ int dev_dax_kmem_probe(struct device *dev)
return -EINVAL;
}
- /* Hotplug starting at the beginning of the next block: */
- kmem_start = ALIGN(range->start, memory_block_size_bytes());
-
- kmem_size = range_len(range);
- /* Adjust the size down to compensate for moving up kmem_start: */
- kmem_size -= kmem_start - range->start;
- /* Align the size down to cover only complete blocks: */
- kmem_size &= ~(memory_block_size_bytes() - 1);
- kmem_end = kmem_start + kmem_size;
-
new_res_name = kstrdup(dev_name(dev), GFP_KERNEL);
if (!new_res_name)
return -ENOMEM;
/* Region is permanently reserved if hotremove fails. */
- new_res = request_mem_region(kmem_start, kmem_size, new_res_name);
+ new_res = request_mem_region(range.start, range_len(&range),
new_res_name);
if (!new_res) {
- dev_warn(dev, "could not reserve region [%pa-%pa]\n",
-&kmem_start, &kmem_end);
+ dev_warn(dev, "could not reserve region [%#llx-%#llx]\n",
range.start, range.end);
kfree(new_res_name);
return -EBUSY;
}
@@ -96,9 +92,8 @@ int dev_dax_kmem_probe(struct device *dev)
static int dev_dax_kmem_remove(struct device *dev)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct range range = dax_kmem_range(dev_dax);
struct resource *res = dev_dax->dax_kmem_res;
- resource_size_t kmem_start = res->start;
- resource_size_t kmem_size = resource_size(res);
const char *res_name = res->name;
int rc;
@@ -108,12 +103,11 @@ static int dev_dax_kmem_remove(struct device *dev)
* there is no way to hotremove this memory until reboot because device
* unbind will succeed even if we return failure.
*/
- rc = remove_memory(dev_dax->target_node, kmem_start, kmem_size);
+ rc = remove_memory(dev_dax->target_node, range.start,
range_len(&range));
if (rc) {
any_hotremove_failed = true;
- dev_err(dev,
- "DAX region %pR cannot be hotremoved until the next
reboot\n",
- res);
+ dev_err(dev, "%#llx-%#llx cannot be hotremoved until the next
reboot\n",
+ range.start, range.end);
return rc;
}
[PATCH v6 00/11] device-dax: support sub-dividing soft-reserved ranges
Changes since v5 [1]:
- (David) Introduce range_len() to include/linux/range.h immediately in
"device-dax: make pgmap optional for instance creation" rather than
wait until "mm/memremap_pages: convert to 'struct range'" to move it.
- (David) David points out that release_mem_region() can not be used in
the kmem driver since it depends on the resource range being busy at
free. The dance the driver does to hand-off busy/free management to
add_memory_driver_managed() breaks request_mem_region()'s assumptions
and requires the driver to continue to use a open-coded
release_resource() + kfree() sequence. For the new multi-range case,
expand the driver-data to hold all the resulting 'struct resource'
instances from mapping the ranges.
- (Boris) consolidate pgmap manipulation code in the
xen_alloc_unpopulated_pages() path. Since this touched
"mm/memremap_pages: convert to 'struct range'" with the pending fix from
Dan, I folded in that fix and gave him a Reported-by credit.
[1]:
http://lore.kernel.org/r/160106109960.30709.7379926726669669398.st...@dwillia2-desk3.amr.corp.intel.com
---
Hi Andrew,
As before patches that are in your tree and did not change as a result
of these updates are not re-sent. This set replaces:
device-dax-make-pgmap-optional-for-instance-creation.patch
...through...
device-dax-add-dis-contiguous-resource-support.patch
...in your stack.
I let this soak over the weekend in kbuild-robot visible tree and it
received a build success notification over 160 configs, and no other
regression notices.
---
The device-dax facility allows an address range to be directly mapped
through a chardev, or optionally hotplugged to the core kernel page
allocator as System-RAM. It is the mechanism for converting persistent
memory (pmem) to be used as another volatile memory pool i.e. the
current Memory Tiering hot topic on linux-mm.
In the case of pmem the nvdimm-namespace-label mechanism can sub-divide
it, but that labeling mechanism is not available / applicable to
soft-reserved ("EFI specific purpose") memory [2]. This series provides
a sysfs-mechanism for the daxctl utility to enable provisioning of
volatile-soft-reserved memory ranges.
The motivations for this facility are:
1/ Allow performance differentiated memory ranges to be split between
kernel-managed and directly-accessed use cases.
2/ Allow physical memory to be provisioned along performance relevant
address boundaries. For example, divide a memory-side cache [3] along
cache-color boundaries.
3/ Parcel out soft-reserved memory to VMs using device-dax as a security
/ permissions boundary [4]. Specifically I have seen people (ab)using
memmap=nn!ss (mark System-RAM as Persistent Memory) just to get the
device-dax interface on custom address ranges. A follow-on for the VM
use case is to teach device-dax to dynamically allocate 'struct page' at
runtime to reduce the duplication of 'struct page' space in both the
guest and the host kernel for the same physical pages.
[2]:
http://lore.kernel.org/r/157309097008.1579826.12818463304589384434.st...@dwillia2-desk3.amr.corp.intel.com
[3]:
http://lore.kernel.org/r/154899811738.3165233.12325692939590944259.st...@dwillia2-desk3.amr.corp.intel.com
[4]: http://lore.kernel.org/r/20200110190313.17144-1-joao.m.mart...@oracle.com
---
Dan Williams (11):
device-dax: make pgmap optional for instance creation
device-dax/kmem: introduce dax_kmem_range()
device-dax/kmem: move resource tracking to drvdata
device-dax: add an allocation interface for device-dax instances
device-dax: introduce 'struct dev_dax' typed-driver operations
device-dax: introduce 'seed' devices
drivers/base: make device_find_child_by_name() compatible with sysfs
inputs
device-dax: add resize support
mm/memremap_pages: convert to 'struct range'
mm/memremap_pages: support multiple ranges per invocation
device-dax: add dis-contiguous resource support
arch/powerpc/kvm/book3s_hv_uvmem.c | 14 -
drivers/base/core.c|2
drivers/dax/bus.c | 708 ++--
drivers/dax/bus.h | 11
drivers/dax/dax-private.h | 23 +
drivers/dax/device.c | 71 ++-
drivers/dax/hmem/hmem.c| 14 -
drivers/dax/kmem.c | 198 ++---
drivers/dax/pmem/compat.c |2
drivers/dax/pmem/core.c| 14 -
drivers/gpu/drm/nouveau/nouveau_dmem.c | 15 -
drivers/nvdimm/badrange.c | 26 +
drivers/nvdimm/claim.c | 13 -
drivers/nvdimm/nd.h|3
drivers/nvdimm/pfn_devs.c | 13 -
drivers/nvdimm/pmem.c | 27 +
drivers/nvdimm/region.c| 21 +
drivers/pci/p2pdma.c | 12 -
drivers/xen/unpopulated-alloc.c| 49 +-
include/linux/memre
[PATCH v6 04/11] device-dax: add an allocation interface for device-dax instances
;In preparation for a facility that enables dax regions to be sub-divided,
introduce infrastructure to track and allocate region capacity.
The new dax_region/available_size attribute is only enabled for volatile
hmem devices, not pmem devices that are defined by nvdimm namespace
boundaries. This is per Jeff's feedback the last time dynamic device-dax
capacity allocation support was discussed.
Link:
https://lore.kernel.org/linux-nvdimm/x49shpp3zn8@segfault.boston.devel.redhat.com
Link:
https://lkml.kernel.org/r/159643101035.4062302.6785857915652647857.st...@dwillia2-desk3.amr.corp.intel.com
Cc: Vishal Verma
Cc: Brice Goglin
Cc: Dave Hansen
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 120 +
drivers/dax/bus.h |7 ++-
drivers/dax/dax-private.h |2 -
drivers/dax/hmem/hmem.c |7 +--
drivers/dax/pmem/core.c |8 +--
5 files changed, 121 insertions(+), 23 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 96bd64ba95a5..0a48ce378686 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -130,6 +130,11 @@ ATTRIBUTE_GROUPS(dax_drv);
static int dax_bus_match(struct device *dev, struct device_driver *drv);
+static bool is_static(struct dax_region *dax_region)
+{
+ return (dax_region->res.flags & IORESOURCE_DAX_STATIC) != 0;
+}
+
static struct bus_type dax_bus_type = {
.name = "dax",
.uevent = dax_bus_uevent,
@@ -185,7 +190,48 @@ static ssize_t align_show(struct device *dev,
}
static DEVICE_ATTR_RO(align);
+#define for_each_dax_region_resource(dax_region, res) \
+ for (res = (dax_region)->res.child; res; res = res->sibling)
+
+static unsigned long long dax_region_avail_size(struct dax_region *dax_region)
+{
+ resource_size_t size = resource_size(&dax_region->res);
+ struct resource *res;
+
+ device_lock_assert(dax_region->dev);
+
+ for_each_dax_region_resource(dax_region, res)
+ size -= resource_size(res);
+ return size;
+}
+
+static ssize_t available_size_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dax_region *dax_region = dev_get_drvdata(dev);
+ unsigned long long size;
+
+ device_lock(dev);
+ size = dax_region_avail_size(dax_region);
+ device_unlock(dev);
+
+ return sprintf(buf, "%llu\n", size);
+}
+static DEVICE_ATTR_RO(available_size);
+
+static umode_t dax_region_visible(struct kobject *kobj, struct attribute *a,
+ int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct dax_region *dax_region = dev_get_drvdata(dev);
+
+ if (is_static(dax_region) && a == &dev_attr_available_size.attr)
+ return 0;
+ return a->mode;
+}
+
static struct attribute *dax_region_attributes[] = {
+ &dev_attr_available_size.attr,
&dev_attr_region_size.attr,
&dev_attr_align.attr,
&dev_attr_id.attr,
@@ -195,6 +241,7 @@ static struct attribute *dax_region_attributes[] = {
static const struct attribute_group dax_region_attribute_group = {
.name = "dax_region",
.attrs = dax_region_attributes,
+ .is_visible = dax_region_visible,
};
static const struct attribute_group *dax_region_attribute_groups[] = {
@@ -226,7 +273,8 @@ static void dax_region_unregister(void *region)
}
struct dax_region *alloc_dax_region(struct device *parent, int region_id,
- struct resource *res, int target_node, unsigned int align)
+ struct resource *res, int target_node, unsigned int align,
+ unsigned long flags)
{
struct dax_region *dax_region;
@@ -249,12 +297,17 @@ struct dax_region *alloc_dax_region(struct device
*parent, int region_id,
return NULL;
dev_set_drvdata(parent, dax_region);
- memcpy(&dax_region->res, res, sizeof(*res));
kref_init(&dax_region->kref);
dax_region->id = region_id;
dax_region->align = align;
dax_region->dev = parent;
dax_region->target_node = target_node;
+ dax_region->res = (struct resource) {
+ .start = res->start,
+ .end = res->end,
+ .flags = IORESOURCE_MEM | flags,
+ };
+
if (sysfs_create_groups(&parent->kobj, dax_region_attribute_groups)) {
kfree(dax_region);
return NULL;
@@ -267,6 +320,32 @@ struct dax_region *alloc_dax_region(struct device *parent,
int region_id,
}
EXPORT_SYMBOL_GPL(alloc_dax_region);
+static int alloc_dev_dax_range(struct dev_dax *dev_dax, resource_size_t size)
+{
+ struct dax_region *dax_region = dev_dax->region;
+ struct resource *res = &dax_region->res;
+ struct device *dev = &dev_dax->dev;
+ struct resource *alloc;
+
+ device_lock_assert(d
[PATCH v6 06/11] device-dax: introduce 'seed' devices
Add a seed device concept for dynamic dax regions to be able to split the
region amongst multiple sub-instances. The seed device, similar to
libnvdimm seed devices, is a device that starts with zero capacity
allocated and unbound to a driver. In contrast to libnvdimm seed devices
explicit 'create' and 'delete' interfaces are added to the region to
trigger seeds to be created and unused devices to be reclaimed. The
explicit create and delete replaces implicit create as a side effect of
probe and implicit delete when writing 0 to the size that libnvdimm
implements.
Delete can be performed on any 0-sized and idle device. This avoids the
gymnastics of needing to move device_unregister() to its own async
context. Specifically, it avoids the deadlock of deleting a device via
one of its own attributes. It is also less surprising to userspace which
never sees an extra device it did not request.
For now just add the device creation, teardown, and ->probe() prevention.
A later patch will arrange for the 'dax/size' attribute to be writable to
allocate capacity from the region.
Link:
https://lkml.kernel.org/r/159643101583.4062302.12255093902950754962.st...@dwillia2-desk3.amr.corp.intel.com
Cc: Vishal Verma
Cc: Brice Goglin
Cc: Dave Hansen
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 301 +++--
drivers/dax/dax-private.h |9 +
drivers/dax/hmem/hmem.c |2
3 files changed, 272 insertions(+), 40 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 9549f11ebed0..dce9413a4394 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -139,8 +139,26 @@ static int dax_bus_probe(struct device *dev)
{
struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_region *dax_region = dev_dax->region;
+ struct range *range = &dev_dax->range;
+ int rc;
+
+ if (range_len(range) == 0 || dev_dax->id < 0)
+ return -ENXIO;
+
+ rc = dax_drv->probe(dev_dax);
+
+ if (rc || is_static(dax_region))
+ return rc;
+
+ /*
+* Track new seed creation only after successful probe of the
+* previous seed.
+*/
+ if (dax_region->seed == dev)
+ dax_region->seed = NULL;
- return dax_drv->probe(dev_dax);
+ return 0;
}
static int dax_bus_remove(struct device *dev)
@@ -237,14 +255,216 @@ static ssize_t available_size_show(struct device *dev,
}
static DEVICE_ATTR_RO(available_size);
+static ssize_t seed_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dax_region *dax_region = dev_get_drvdata(dev);
+ struct device *seed;
+ ssize_t rc;
+
+ if (is_static(dax_region))
+ return -EINVAL;
+
+ device_lock(dev);
+ seed = dax_region->seed;
+ rc = sprintf(buf, "%s\n", seed ? dev_name(seed) : "");
+ device_unlock(dev);
+
+ return rc;
+}
+static DEVICE_ATTR_RO(seed);
+
+static ssize_t create_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dax_region *dax_region = dev_get_drvdata(dev);
+ struct device *youngest;
+ ssize_t rc;
+
+ if (is_static(dax_region))
+ return -EINVAL;
+
+ device_lock(dev);
+ youngest = dax_region->youngest;
+ rc = sprintf(buf, "%s\n", youngest ? dev_name(youngest) : "");
+ device_unlock(dev);
+
+ return rc;
+}
+
+static ssize_t create_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dax_region *dax_region = dev_get_drvdata(dev);
+ unsigned long long avail;
+ ssize_t rc;
+ int val;
+
+ if (is_static(dax_region))
+ return -EINVAL;
+
+ rc = kstrtoint(buf, 0, &val);
+ if (rc)
+ return rc;
+ if (val != 1)
+ return -EINVAL;
+
+ device_lock(dev);
+ avail = dax_region_avail_size(dax_region);
+ if (avail == 0)
+ rc = -ENOSPC;
+ else {
+ struct dev_dax_data data = {
+ .dax_region = dax_region,
+ .size = 0,
+ .id = -1,
+ };
+ struct dev_dax *dev_dax = devm_create_dev_dax(&data);
+
+ if (IS_ERR(dev_dax))
+ rc = PTR_ERR(dev_dax);
+ else {
+ /*
+* In support of crafting multiple new devices
+* simultaneously multiple seeds can be created,
+* but only the first one that has not been
+* successfully bound is tracked as the region
+* seed.
+
[PATCH v6 01/11] device-dax: make pgmap optional for instance creation
The passed in dev_pagemap is only required in the pmem case as the
libnvdimm core may have reserved a vmem_altmap for dev_memremap_pages() to
place the memmap in pmem directly. In the hmem case there is no agent
reserving an altmap so it can all be handled by a core internal default.
Pass the resource range via a new @range property of 'struct
dev_dax_data'.
Link:
https://lkml.kernel.org/r/159643099958.4062302.10379230791041872886.st...@dwillia2-desk3.amr.corp.intel.com
Cc: David Hildenbrand
Cc: Vishal Verma
Cc: Dave Hansen
Cc: Pavel Tatashin
Cc: Brice Goglin
Cc: Dave Jiang
Cc: David Hildenbrand
Cc: Ira Weiny
Cc: Jia He
Cc: Joao Martins
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 29 +++--
drivers/dax/bus.h |2 ++
drivers/dax/dax-private.h |4 +++-
drivers/dax/device.c | 28 +++-
drivers/dax/hmem/hmem.c|8
drivers/dax/kmem.c | 12 ++--
drivers/dax/pmem/core.c|4
include/linux/range.h |5 +
tools/testing/nvdimm/dax-dev.c |8
9 files changed, 62 insertions(+), 38 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index dffa4655e128..96bd64ba95a5 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -271,7 +271,7 @@ static ssize_t size_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
- unsigned long long size = resource_size(&dev_dax->region->res);
+ unsigned long long size = range_len(&dev_dax->range);
return sprintf(buf, "%llu\n", size);
}
@@ -293,19 +293,12 @@ static ssize_t target_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(target_node);
-static unsigned long long dev_dax_resource(struct dev_dax *dev_dax)
-{
- struct dax_region *dax_region = dev_dax->region;
-
- return dax_region->res.start;
-}
-
static ssize_t resource_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct dev_dax *dev_dax = to_dev_dax(dev);
- return sprintf(buf, "%#llx\n", dev_dax_resource(dev_dax));
+ return sprintf(buf, "%#llx\n", dev_dax->range.start);
}
static DEVICE_ATTR(resource, 0400, resource_show, NULL);
@@ -376,6 +369,7 @@ static void dev_dax_release(struct device *dev)
dax_region_put(dax_region);
put_dax(dax_dev);
+ kfree(dev_dax->pgmap);
kfree(dev_dax);
}
@@ -412,7 +406,12 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data
*data)
if (!dev_dax)
return ERR_PTR(-ENOMEM);
- memcpy(&dev_dax->pgmap, data->pgmap, sizeof(struct dev_pagemap));
+ if (data->pgmap) {
+ dev_dax->pgmap = kmemdup(data->pgmap,
+ sizeof(struct dev_pagemap), GFP_KERNEL);
+ if (!dev_dax->pgmap)
+ goto err_pgmap;
+ }
/*
* No 'host' or dax_operations since there is no access to this
@@ -421,18 +420,19 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data
*data)
dax_dev = alloc_dax(dev_dax, NULL, NULL, DAXDEV_F_SYNC);
if (IS_ERR(dax_dev)) {
rc = PTR_ERR(dax_dev);
- goto err;
+ goto err_alloc_dax;
}
/* a device_dax instance is dead while the driver is not attached */
kill_dax(dax_dev);
- /* from here on we're committed to teardown via dax_dev_release() */
+ /* from here on we're committed to teardown via dev_dax_release() */
dev = &dev_dax->dev;
device_initialize(dev);
dev_dax->dax_dev = dax_dev;
dev_dax->region = dax_region;
+ dev_dax->range = data->range;
dev_dax->target_node = dax_region->target_node;
kref_get(&dax_region->kref);
@@ -458,8 +458,9 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data
*data)
return ERR_PTR(rc);
return dev_dax;
-
- err:
+err_alloc_dax:
+ kfree(dev_dax->pgmap);
+err_pgmap:
kfree(dev_dax);
return ERR_PTR(rc);
diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
index 299c2e7fac09..4aeb36da83a4 100644
--- a/drivers/dax/bus.h
+++ b/drivers/dax/bus.h
@@ -3,6 +3,7 @@
#ifndef __DAX_BUS_H__
#define __DAX_BUS_H__
#include
+#include
struct dev_dax;
struct resource;
@@ -21,6 +22,7 @@ struct dev_dax_data {
struct dax_region *dax_region;
struct dev_pagemap *pgmap;
enum dev_dax_subsys subsys;
+ struct range range;
int id;
};
diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
index 8a4c40ccd2ef..fbaea36938ae 100644
--- a/drivers/dax/dax-private.h
+++ b/drivers/dax/dax-private.h
@@ -41,6 +41,7 @@ struct dax_region {
* @target_node: effective numa node if dev_dax memory range is onlined
* @dev - device core
* @pgmap - pgmap for mem
[PATCH v6 11/11] device-dax: add dis-contiguous resource support
Break the requirement that device-dax instances are physically contiguous.
With this constraint removed it allows fragmented available capacity to
be fully allocated.
This capability is useful to mitigate the "noisy neighbor" problem with
memory-side-cache management for virtual machines, or any other scenario
where a platform address boundary also designates a performance boundary.
For example a direct mapped memory side cache might rotate cache colors at
1GB boundaries. With dis-contiguous allocations a device-dax instance
could be configured to contain only 1 cache color.
It also satisfies Joao's use case (see link) for partitioning memory for
exclusive guest access. It allows for a future potential mode where the
host kernel need not allocate 'struct page' capacity up-front.
Link:
https://lore.kernel.org/lkml/20200110190313.17144-1-joao.m.mart...@oracle.com/
Link:
https://lkml.kernel.org/r/159643104304.4062302.16561669534797528660.st...@dwillia2-desk3.amr.corp.intel.com
Reported-by: Joao Martins
Signed-off-by: Dan Williams
---
drivers/dax/bus.c | 233 +++-
drivers/dax/dax-private.h |9 +-
drivers/dax/device.c | 55 ++---
drivers/dax/kmem.c | 141
tools/testing/nvdimm/dax-dev.c | 20 ++-
5 files changed, 329 insertions(+), 129 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 00fa73a8dfb4..06a789aba58a 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -136,15 +136,27 @@ static bool is_static(struct dax_region *dax_region)
return (dax_region->res.flags & IORESOURCE_DAX_STATIC) != 0;
}
+static u64 dev_dax_size(struct dev_dax *dev_dax)
+{
+ u64 size = 0;
+ int i;
+
+ device_lock_assert(&dev_dax->dev);
+
+ for (i = 0; i < dev_dax->nr_range; i++)
+ size += range_len(&dev_dax->ranges[i].range);
+
+ return size;
+}
+
static int dax_bus_probe(struct device *dev)
{
struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
struct dev_dax *dev_dax = to_dev_dax(dev);
struct dax_region *dax_region = dev_dax->region;
- struct range *range = &dev_dax->range;
int rc;
- if (range_len(range) == 0 || dev_dax->id < 0)
+ if (dev_dax_size(dev_dax) == 0 || dev_dax->id < 0)
return -ENXIO;
rc = dax_drv->probe(dev_dax);
@@ -354,15 +366,19 @@ void kill_dev_dax(struct dev_dax *dev_dax)
}
EXPORT_SYMBOL_GPL(kill_dev_dax);
-static void free_dev_dax_range(struct dev_dax *dev_dax)
+static void free_dev_dax_ranges(struct dev_dax *dev_dax)
{
struct dax_region *dax_region = dev_dax->region;
- struct range *range = &dev_dax->range;
+ int i;
device_lock_assert(dax_region->dev);
- if (range_len(range))
+ for (i = 0; i < dev_dax->nr_range; i++) {
+ struct range *range = &dev_dax->ranges[i].range;
+
__release_region(&dax_region->res, range->start,
range_len(range));
+ }
+ dev_dax->nr_range = 0;
}
static void unregister_dev_dax(void *dev)
@@ -372,7 +388,7 @@ static void unregister_dev_dax(void *dev)
dev_dbg(dev, "%s\n", __func__);
kill_dev_dax(dev_dax);
- free_dev_dax_range(dev_dax);
+ free_dev_dax_ranges(dev_dax);
device_del(dev);
put_device(dev);
}
@@ -423,7 +439,7 @@ static ssize_t delete_store(struct device *dev, struct
device_attribute *attr,
device_lock(dev);
device_lock(victim);
dev_dax = to_dev_dax(victim);
- if (victim->driver || range_len(&dev_dax->range))
+ if (victim->driver || dev_dax_size(dev_dax))
rc = -EBUSY;
else {
/*
@@ -569,51 +585,86 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax,
u64 start,
struct dax_region *dax_region = dev_dax->region;
struct resource *res = &dax_region->res;
struct device *dev = &dev_dax->dev;
+ struct dev_dax_range *ranges;
+ unsigned long pgoff = 0;
struct resource *alloc;
+ int i;
device_lock_assert(dax_region->dev);
/* handle the seed alloc special case */
if (!size) {
- dev_dax->range = (struct range) {
- .start = res->start,
- .end = res->start - 1,
- };
+ if (dev_WARN_ONCE(dev, dev_dax->nr_range,
+ "0-size allocation must be first\n"))
+ return -EBUSY;
+ /* nr_range == 0 is elsewhere special cased as 0-size device */
return 0;
}
+ ranges = krealloc(dev_dax->ranges, sizeof(*ranges)
+ * (dev_dax->nr_range + 1), GFP_KERNEL);
+ if (!ranges)
+ return -ENOMEM;
+
alloc = __request_region(res, start, size, dev_name(dev), 0);
- if (!alloc)
+
[PATCH v6 10/11] mm/memremap_pages: support multiple ranges per invocation
In support of device-dax growing the ability to front physically
dis-contiguous ranges of memory, update devm_memremap_pages() to track
multiple ranges with a single reference counter and devm instance.
Convert all [devm_]memremap_pages() users to specify the number of
ranges they are mapping in their 'struct dev_pagemap' instance.
Link:
https://lkml.kernel.org/r/159643103789.4062302.18426128170217903785.st...@dwillia2-desk3.amr.corp.intel.com
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Vishal Verma
Cc: Vivek Goyal
Cc: Dave Jiang
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ira Weiny
Cc: Bjorn Helgaas
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Signed-off-by: Dan Williams
---
arch/powerpc/kvm/book3s_hv_uvmem.c |1
drivers/dax/device.c |1
drivers/gpu/drm/nouveau/nouveau_dmem.c |1
drivers/nvdimm/pfn_devs.c |1
drivers/nvdimm/pmem.c |1
drivers/pci/p2pdma.c |1
drivers/xen/unpopulated-alloc.c|1
include/linux/memremap.h | 10 +
lib/test_hmm.c |1
mm/memremap.c | 258 +++-
10 files changed, 166 insertions(+), 110 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 29ec555055c2..84e5a2dc8be5 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -1172,6 +1172,7 @@ int kvmppc_uvmem_init(void)
kvmppc_uvmem_pgmap.type = MEMORY_DEVICE_PRIVATE;
kvmppc_uvmem_pgmap.range.start = res->start;
kvmppc_uvmem_pgmap.range.end = res->end;
+ kvmppc_uvmem_pgmap.nr_range = 1;
kvmppc_uvmem_pgmap.ops = &kvmppc_uvmem_ops;
/* just one global instance: */
kvmppc_uvmem_pgmap.owner = &kvmppc_uvmem_pgmap;
diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index a14448bca83d..5f808617672a 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -417,6 +417,7 @@ int dev_dax_probe(struct dev_dax *dev_dax)
if (!pgmap)
return -ENOMEM;
pgmap->range = *range;
+ pgmap->nr_range = 1;
}
pgmap->type = MEMORY_DEVICE_GENERIC;
addr = devm_memremap_pages(dev, pgmap);
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 25811ed7e274..a13c6215bba8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -251,6 +251,7 @@ nouveau_dmem_chunk_alloc(struct nouveau_drm *drm, struct
page **ppage)
chunk->pagemap.type = MEMORY_DEVICE_PRIVATE;
chunk->pagemap.range.start = res->start;
chunk->pagemap.range.end = res->end;
+ chunk->pagemap.nr_range = 1;
chunk->pagemap.ops = &nouveau_dmem_pagemap_ops;
chunk->pagemap.owner = drm->dev;
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 3c4787b92a6a..b499df630d4d 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -693,6 +693,7 @@ static int __nvdimm_setup_pfn(struct nd_pfn *nd_pfn, struct
dev_pagemap *pgmap)
.start = nsio->res.start + start_pad,
.end = nsio->res.end - end_trunc,
};
+ pgmap->nr_range = 1;
if (nd_pfn->mode == PFN_MODE_RAM) {
if (offset < reserve)
return -EINVAL;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 69cc0e783709..1f45af363a94 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -442,6 +442,7 @@ static int pmem_attach_disk(struct device *dev,
} else if (pmem_should_map_pages(dev)) {
pmem->pgmap.range.start = res->start;
pmem->pgmap.range.end = res->end;
+ pmem->pgmap.nr_range = 1;
pmem->pgmap.type = MEMORY_DEVICE_FS_DAX;
pmem->pgmap.ops = &fsdax_pagemap_ops;
addr = devm_memremap_pages(dev, &pmem->pgmap);
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 256850513813..9d53c16b7329 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -187,6 +187,7 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar,
size_t size,
pgmap = &p2p_pgmap->pgmap;
pgmap->range.start = pci_resource_start(pdev, bar) + offset;
pgmap->range.end = pgmap->range.start + size - 1;
+ pgmap->nr_range = 1;
pgmap->type = MEMORY_DEVICE_PCI_P2PDMA;
p2p_pgmap->provider = pdev;
diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c
index 90a007648082..75ab5de99868 100644
--- a/drivers/xen/unpopulated-alloc.c
+++ b/drivers/xen/unpopulated-alloc.c
@@ -47,6 +47,7 @@ static int fill_list(unsigned int nr_pages)
.start = res->start,
.end =
Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema
On Tue, 6 Oct 2020 at 06:27, Yong Wu wrote: > > On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote: > > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote: > > > Convert MediaTek SMI to DT schema. > > > > > > Signed-off-by: Yong Wu > > > --- > > > .../mediatek,smi-common.txt | 49 - > > > .../mediatek,smi-common.yaml | 100 ++ > > > .../memory-controllers/mediatek,smi-larb.txt | 49 - > > > .../memory-controllers/mediatek,smi-larb.yaml | 91 > > > 4 files changed, 191 insertions(+), 98 deletions(-) > > > delete mode 100644 > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt > > > create mode 100644 > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > > > delete mode 100644 > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt > > > create mode 100644 > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml > ... > > > +properties: > > > + compatible: > > > +oneOf: > > > + - enum: > > > + - mediatek,mt2701-smi-common > > > + - mediatek,mt2712-smi-common > > > + - mediatek,mt6779-smi-common > > > + - mediatek,mt8173-smi-common > > > + - mediatek,mt8183-smi-common > > > + > > > + - description: for mt7623 > > > +items: > > > + - const: mediatek,mt7623-smi-common > > > + - const: mediatek,mt2701-smi-common > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + clocks: > > > +description: | > > > + apb and smi are mandatory. the async is only for generation 1 smi > > > HW. > > > + gals(global async local sync) also is optional, here is the list > > > which > > > + require gals: mt6779 and mt8183. > > > +minItems: 2 > > > +maxItems: 4 > > > +items: > > > + - description: apb is Advanced Peripheral Bus clock, It's the > > > clock for > > > + setting the register. > > > + - description: smi is the clock for transfer data and command. > > > + - description: async is asynchronous clock, it help transform the > > > smi clock > > > + into the emi clock domain. > > > + - description: gals0 is the path0 clock of gals. > > > + - description: gals1 is the path1 clock of gals. > > > + > > > + clock-names: > > > +oneOf: > > > + - items: > > > + - const: apb > > > + - const: smi > > > + - items: > > > + - const: apb > > > + - const: smi > > > + - const: async > > > + - items: > > > + - const: apb > > > + - const: smi > > > + - const: gals0 > > > + - const: gals1 > > > > Similarly to my comment to other properties, this requirement per > > compatible should be part of the schema within 'if-then'. > > I'm not so familiar with this format. Do this has "if-then-'else > if'-then-else"? These are mutually exclusive conditions, so you can skip else: - if-then - if-then - if-then It will be more readable then stacking 'if' under 'else' > > I tried below instead of the clocks segment above: > > === > if: > properties: > compatible: Missing contains. Just take an example from some existing schema. > enum: > - mediatek,mt6779-smi-common > - mediatek,mt8183-smi-common > > then: > properties: > clock: > items: > - description: apb is the clock for setting the register.. > - description: smi is the clock for transfer data and command. > - description: gals0 is the path0 clock of gals(global async > local sync). > - description: gals1 is the path1 clock of gals. > clock-names: > items: > - const: apb > - const: smi > - const: gals0 > - const: gals1 > else: > if: > properties: > compatible: > contains: > enum: > - mediatek,mt2701-smi-common > > then: > properties: > clocks: > items: > - description: apb is the clock for setting the register. > - description: smi is the clock for transfer data and command. > - description: async is asynchronous clock, it help transform > the smi clock > into the emi clock domain. > clock-names: > items: > - const: apb > - const: smi > - const: async > else: > properties: > clocks: > items: > - description: apb is the clock for setting the register. > - description: smi is the clock for transfer data and > command. > clock-names: > items: > - const: apb > - const: smi > > > But I got a warning when dt_binding_check: > > CHKDT > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > SCHEMA
Re: [PATCH v3 18/24] iommu/mediatek: Support master use iova over 32bit
On Wed, Sep 30, 2020 at 03:06:41PM +0800, Yong Wu wrote: > After extending v7s, our pagetable already support iova reach > 16GB(34bit). the master got the iova via dma_alloc_attrs may reach > 34bits, but its HW register still is 32bit. then how to set the > bit32/bit33 iova? this depend on a SMI larb setting(bank_sel). > > we separate whole 16GB iova to four banks: > bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G; > The bank number is (iova >> 32). > > We will preassign which bank the larbs belong to. currently we don't > have a interface for master to adjust its bank number. > > Each a bank is a iova_region which is a independent iommu-domain. > the iova range for each iommu-domain can't cross 4G. > > Signed-off-by: Yong Wu > --- > drivers/iommu/mtk_iommu.c | 12 +--- > drivers/memory/mtk-smi.c | 7 +++ > include/soc/mediatek/smi.h | 1 + > 3 files changed, 17 insertions(+), 3 deletions(-) For the memory part: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [RFC] net: phy: add shutdown hook to struct phy_driver
On Tue, 6 Oct 2020 07:45:10 +0200 Heiner Kallweit wrote: > > On 05.10.2020 18:00, Florian Fainelli wrote: > > > > > > On 10/5/2020 8:54 AM, Heiner Kallweit wrote: > >> On 05.10.2020 17:41, Florian Fainelli wrote: > >>> > >>> > >>> On 10/5/2020 1:53 AM, Jisheng Zhang wrote: > On Wed, 30 Sep 2020 13:23:29 -0700 Florian Fainelli wrote: > > > > > > On 9/30/2020 1:11 PM, Andrew Lunn wrote: > >> On Wed, Sep 30, 2020 at 01:07:19PM -0700, Florian Fainelli wrote: > >>> > >>> > >>> On 9/30/2020 12:09 PM, Andrew Lunn wrote: > On Wed, Sep 30, 2020 at 05:47:43PM +0800, Jisheng Zhang wrote: > > Hi, > > > > A GE phy supports pad isolation which can save power in WOL mode. > > But once the > > isolation is enabled, the MAC can't send/receive pkts to/from the > > phy because > > the phy is "isolated". To make the PHY work normally, I need to > > move the > > enabling isolation to suspend hook, so far so good. But the > > isolation isn't > > enabled in system shutdown case, to support this, I want to add > > shutdown hook > > to net phy_driver, then also enable the isolation in the shutdown > > hook. Is > > there any elegant solution? > > > Or we can break the assumption: ethernet can still send/receive > > pkts after > > enabling WoL, no? > > That is not an easy assumption to break. The MAC might be doing WOL, > so it needs to be able to receive packets. > > What you might be able to assume is, if this PHY device has had WOL > enabled, it can assume the MAC does not need to send/receive after > suspend. The problem is, phy_suspend() will not call into the driver > is WOL is enabled, so you have no idea when you can isolate the MAC > from the PHY. > > So adding a shutdown in mdio_driver_register() seems reasonable. But > you need to watch out for ordering. Is the MDIO bus driver still > running? > >>> > >>> If your Ethernet MAC controller implements a shutdown callback and > >>> that > >>> callback takes care of unregistering the network device which should > >>> also > >>> ensure that phy_disconnect() gets called, then your PHY's suspend > >>> function > >>> will be called. > >> > >> Hi Florian > >> > >> I could be missing something here, but: > >> > >> phy_suspend does not call into the PHY driver if WOL is enabled. So > >> Jisheng needs a way to tell the PHY it should isolate itself from the > >> MAC, and suspend is not that. > > > > I missed that part, that's right if WoL is enabled at the PHY level then > > the suspend callback is not called, how about we change that and we > > always call the PHY's suspend callback? This would require that we > > audit > > Hi all, > > The PHY's suspend callback usually calls genphy_suspend() which will set > BMCR_PDOWN bit, this may break WoL. I think this is one the reason why > we ignore the phydrv->suspend() when WoL is enabled. If we goes to this > directly, it looks like we need to change each phy's suspend > implementation, > I.E if WoL is enabled, ignore genphy_suspend() and do possible isolation; > If WoL is disabled, keep the code path as is. > > So compared with the shutdown hook, which direction is better? > >>> > >>> I believe you will have an easier time to add an argument to the PHY > >>> driver suspend's function to indicate the WoL status, or to move down the > >>> check for WoL being enabled/supported compared to adding support for > >>> shutdown into the MDIO bus layer, and then PHY drivers. > >> > >> Maybe the shutdown callback of mdio_bus_type could be implemented. > >> It could iterate over all PHY's on the bus, check for WoL (similar to > >> mdio_bus_phy_may_suspend) and do whatever is needed. > >> Seems to me to be the most generic way. > > > > OK and we optionally call into a PHY device's shutdown function if defined > > so it can perform PHY specific work? That would work for me. > > If suspend and shutdown procedure are the same for the PHY, then we may not > need a shutdown hook in phy_driver. This seems to be the case here. > I just wonder what the actual use case is, because typically MAC drivers > call phy_stop (that calls phy_suspend) in their shutdown hook. Thank you all, I will follow this direction and send out an RFC for review. Thanks a lot, Jisheng
Re: [PATCH v3 06/24] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Tue, Oct 06, 2020 at 12:26:45PM +0800, Yong Wu wrote: > Hi Krzysztof, > > On Fri, 2020-10-02 at 13:10 +0200, Krzysztof Kozlowski wrote: > > On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote: > > > This patch adds decriptions for mt8192 IOMMU and SMI. > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation > > > table format. The M4U-SMI HW diagram is as below: > > > > > > EMI > > >| > > > M4U > > >| > > > > > >SMI Common > > > > > >| > > > +---+--+--+--+---+ > > > | | | | .. | | > > > | | | | | | > > > larb0 larb1 larb2 larb4 .. larb19 larb20 > > > disp0 disp1 mdpvdec IPE IPE > > > > > > All the connections are HW fixed, SW can NOT adjust it. > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines > > > into different iova ranges: > > > > > > domain-id module iova-range larbs > > >0 disp0 ~ 4G larb0/1 > > >1 vcodec 4G ~ 8G larb4/5/7 > > >2 cam/mdp 8G ~ 12G > > > larb2/9/11/13/14/16/17/18/19/20 > > >3 CCU00x4000_ ~ 0x43ff_ larb13: port 9/10 > > >4 CCU10x4400_ ~ 0x47ff_ larb14: port 4/5 > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement. > > > > > > Signed-off-by: Yong Wu > > > Reviewed-by: Rob Herring > > > --- > > > .../bindings/iommu/mediatek,iommu.yaml| 9 +- > > > .../mediatek,smi-common.yaml | 5 +- > > > .../memory-controllers/mediatek,smi-larb.yaml | 3 +- > > > include/dt-bindings/memory/mt8192-larb-port.h | 239 ++ > > > 4 files changed, 251 insertions(+), 5 deletions(-) > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h > > > > I see it depends on previous patches but does it have to be within one > > commit? Is it not bisectable? The memory changes/bindings could go via > > memory tree if this is split. > > Thanks for the view. > > I can split this into two patchset in next version, one is for iommu and > the other is for smi. > > Only the patch [18/24] change both the code(iommu and smi). I don't plan > to split it, and the smi patch[24/24] don't depend on it(won't > conflict). It got too late in the cycle, so I am not going to take the 24/24 now. > > since 18/24 also touch the smi code, I expect it could get Acked-by from > you or Matthias, then Joerg could take it. Sure. I acked it. Best regards, Krzysztof
Re: [PATCH v11 5/5] drivers/tty/serial: add LiteUART driver
Hi Geert,
On Fri, Sep 25, 2020 at 3:41 PM Geert Uytterhoeven wrote:
>
> Hi Mateusz,
>
> On Wed, Sep 23, 2020 at 12:12 PM Mateusz Holenko
> wrote:
> > From: Filip Kokosinski
> >
> > This commit adds driver for the FPGA-based LiteUART serial controller
> > from LiteX SoC builder.
> >
> > The current implementation supports LiteUART configured
> > for 32 bit data width and 8 bit CSR bus width.
> >
> > It does not support IRQ.
> >
> > Signed-off-by: Filip Kokosinski
> > Signed-off-by: Mateusz Holenko
>
> Thanks for your patch!
Thanks for your review!
>
> > --- /dev/null
> > +++ b/drivers/tty/serial/liteuart.c
>
> > +static int liteuart_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct liteuart_port *uart;
> > + struct uart_port *port;
> > + struct xa_limit limit;
> > + int dev_id, ret;
> > +
> > + /* no device tree */
> > + if (!np)
> > + return -ENODEV;
> > +
> > + /* look for aliases; auto-enumerate for free index if not found */
> > + dev_id = of_alias_get_id(np, "serial");
> > + if (dev_id < 0)
> > + limit = XA_LIMIT(0, CONFIG_SERIAL_LITEUART_MAX_PORTS);
> > + else
> > + limit = XA_LIMIT(dev_id, dev_id);
> > +
> > + uart = kzalloc(sizeof(struct liteuart_port), GFP_KERNEL);
>
> Who frees this memory? Use devm_kzalloc()?
You are right - it leaks right now. We'll switch to devm_kzalloc().
> > + if (!uart)
> > + return -ENOMEM;
> > +
> > + ret = xa_alloc(&liteuart_array, &dev_id, uart, limit, GFP_KERNEL);
>
> Who frees this entry?
We'll add a call to xa_erase() when removing the driver.
> > + if (ret)
> > + return ret;
> > +
> > + port = &uart->port;
> > +
> > + /* get membase */
> > + port->membase = devm_platform_get_and_ioremap_resource(pdev, 0,
> > NULL);
> > + if (!port->membase)
> > + return -ENXIO;
> > +
> > + /* values not from device tree */
> > + port->dev = &pdev->dev;
> > + port->iotype = UPIO_MEM;
> > + port->flags = UPF_BOOT_AUTOCONF;
> > + port->ops = &liteuart_ops;
> > + port->regshift = 2;
> > + port->fifosize = 16;
> > + port->iobase = 1;
> > + port->type = PORT_UNKNOWN;
> > + port->line = dev_id;
> > + spin_lock_init(&port->lock);
> > +
> > + return uart_add_one_port(&liteuart_driver, &uart->port);
> > +}
>
> > +static int __init liteuart_init(void)
> > +{
> > + int res;
> > +
> > + res = uart_register_driver(&liteuart_driver);
> > + if (res)
> > + return res;
> > +
> > + res = platform_driver_register(&liteuart_platform_driver);
> > + if (res) {
> > + uart_unregister_driver(&liteuart_driver);
> > + return res;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void __exit liteuart_exit(void)
> > +{
> > + platform_driver_unregister(&liteuart_platform_driver);
> > + uart_unregister_driver(&liteuart_driver);
> > +}
> > +
> > +module_init(liteuart_init);
> > +module_exit(liteuart_exit);
>
> Several drivers call uart_{,un}register_driver() from their .probe()
> resp. .remove() callbacks, so they can use module_platform_driver()
> instead of the above boilerplate. Greg, what's your stance on that?
I don't have much experience here and can't tell which version is the
preferred one.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Best regards,
Mateusz
--
Mateusz Holenko
Antmicro Ltd | www.antmicro.com
Roosevelta 22, 60-829 Poznan, Poland
Re: [PATCH] usb: host: ehci-sched: avoid possible NULL dereference
On Mon, Oct 05, 2020 at 11:19:02PM +, Harley A.W. Lorenzo wrote: > On Monday, October 5, 2020 5:31 PM, Sudip Mukherjee > wrote: > > > find_tt() can return NULL or the error value in ERR_PTR() and > > dereferencing the return value without checking for the error can > > lead to a possible dereference of NULL pointer or ERR_PTR(). > > Looks fine to me. There is in fact no checks of the return value > before a dereference here, and this solves that. > > Reviewed-by: Harley A.W. Lorenzo ' there. thanks, greg k-h
Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 24-09-20, 10:53, Nicola Mazzucato wrote: > I am seeking some feedback/comments on the following approach. > > Intro: > Info of performance depency for cpus will be beneficial for systems > where f/w description of the CPU performance control domain is different > from the clock domain, e.g. per-CPU control with multiple CPUs sharing > clock, and kernel OSPM s/w components need to take CPU performance > dependency into account. > Essentially these s/w components will have to be provided with > this information from dt and this RFC is presenting a possible way > to do so. I am not sure I understand what performance control mean here. Can you please elaborate a bit more on that ? For example, with current code and understanding, a cpufreq policy belongs to a group of CPUs which change their frequency together, which also mean that they change their performance level together and so I am not able to understand what's going on here. Sorry about that. What kind of hardware configuration doesn't work with this ? -- viresh
[PATCH 0/1] scsi: arcmsr: fix warning: right shift count >= width of type
This patch is against to mkp's 5.10/scsi-staging. 1. fix warning: right shift count >= width of type. ---
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Mon, Oct 05, 2020 at 10:35:43AM -0400, Jonathan Marek wrote:
> The cache synchronization doesn't have anything to do with IOMMU (for
> example: cache synchronization would be useful in cases where drm/msm
> doesn't use IOMMU).
It has to do with doing DMA. And we have two frameworks for doing DMA:
either the DMA API which is for general driver use, and which as part of
the design includes cache maintainance hidden behind the concept of
ownership transfers. And we have the much more bare bones IOMMU API.
If people want to use the "raw" IOMMU API with not cache coherent
devices we'll need a cache maintainance API that goes along with it.
It could either be formally part of the IOMMU API or be separate.
> What is needed is to call arch_sync_dma_for_{cpu,device} (which is what I
> went with initially, but then decided to re-use drm/msm's
> sync_for_{cpu,device}). But you are also saying those functions aren't for
> driver use, and I doubt IOMMU maintainers will want to add wrappers for
> these functions just to satisfy this "not for driver use" requirement.
arch_sync_dma_for_{cpu,device} are low-level helpers (and not very
great ones at that). The definitively should not be used by drivers.
They would be very useful buildblocks for a IOMMU cache maintainance
API.
Of course the best outcome would be if we could find a way for the MSM
drm driver to just use DMA API and not deal with the lower level
abstractions. Do you remember why the driver went for use of the IOMMU
API?
Re: [BUG][PATCH] arm64: bti: fix BTI to handle local indirect branches
Hi Jeremy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on soc/for-next arm/for-next kvmarm/next v5.9-rc8
next-20201002]
[cannot apply to xlnx/master]
[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/Jeremy-Linton/arm64-bti-fix-BTI-to-handle-local-indirect-branches/20201006-021958
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-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/37211f8bd05c9ebcede89bb5c371e34920355d4f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jeremy-Linton/arm64-bti-fix-BTI-to-handle-local-indirect-branches/20201006-021958
git checkout 37211f8bd05c9ebcede89bb5c371e34920355d4f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/arm64/crypto/aes-neonbs-core.S:491:23: error: macro "SYM_END" requires
>> 2 arguments, but only 1 given
491 | SYM_END(aesbs_encrypt8)
| ^
In file included from arch/arm64/crypto/aes-neonbs-core.S:17:
include/linux/linkage.h:166: note: macro "SYM_END" defined here
166 | #define SYM_END(name, sym_type)\
|
arch/arm64/crypto/aes-neonbs-core.S:556:23: error: macro "SYM_END" requires
2 arguments, but only 1 given
556 | SYM_END(aesbs_decrypt8)
| ^
In file included from arch/arm64/crypto/aes-neonbs-core.S:17:
include/linux/linkage.h:166: note: macro "SYM_END" defined here
166 | #define SYM_END(name, sym_type)\
|
vim +/SYM_END +491 arch/arm64/crypto/aes-neonbs-core.S
429
430 .align 4
431 SYM_CODE_START_LOCAL(aesbs_encrypt8)
432 ldr q9, [bskey], #16// round 0 key
433 ldr q8, M0SR
434 ldr q24, SR
435
436 eor v10.16b, v0.16b, v9.16b // xor with
round0 key
437 eor v11.16b, v1.16b, v9.16b
438 tbl v0.16b, {v10.16b}, v8.16b
439 eor v12.16b, v2.16b, v9.16b
440 tbl v1.16b, {v11.16b}, v8.16b
441 eor v13.16b, v3.16b, v9.16b
442 tbl v2.16b, {v12.16b}, v8.16b
443 eor v14.16b, v4.16b, v9.16b
444 tbl v3.16b, {v13.16b}, v8.16b
445 eor v15.16b, v5.16b, v9.16b
446 tbl v4.16b, {v14.16b}, v8.16b
447 eor v10.16b, v6.16b, v9.16b
448 tbl v5.16b, {v15.16b}, v8.16b
449 eor v11.16b, v7.16b, v9.16b
450 tbl v6.16b, {v10.16b}, v8.16b
451 tbl v7.16b, {v11.16b}, v8.16b
452
453 bitslicev0, v1, v2, v3, v4, v5, v6, v7, v8, v9, v10, v11
454
455 sub rounds, rounds, #1
456 b .Lenc_sbox
457
458 .Lenc_loop:
459 shift_rows v0, v1, v2, v3, v4, v5, v6, v7, v24
460 .Lenc_sbox:
461 sboxv0, v1, v2, v3, v4, v5, v6, v7, v8, v9, v10,
v11, v12, \
462 v13,
v14, v15
463 subsrounds, rounds, #1
464 b.cc.Lenc_done
465
466 enc_next_rk
467
468 mix_colsv0, v1, v4, v6, v3, v7, v2, v5, v8, v9, v10,
v11, v12, \
469 v13,
v14, v15
470
471 add_round_key v0, v1, v2, v3, v4, v5, v6, v7
472
473 b.ne.Lenc_loop
474 ldr q24, SRM0
475 b .Lenc_loop
476
477 .Lenc_done:
478 ldr q12, [bskey]// last round
key
479
480 bitslicev0, v1, v4, v6, v3, v7, v2, v5, v8, v9, v10, v11
481
482 eor v0.16b, v0.16b, v12.16b
483 eor v1.16b, v1.16b, v12.16b
484 eor v4.16b, v4.16b, v12.16b
485
Re: [PATCH -v2 03/17] sched/hotplug: Ensure only per-cpu kthreads run during hotplug
On Mon, Oct 05, 2020 at 04:57:20PM +0200, Peter Zijlstra wrote:
> +static inline void balance_switch(struct rq *rq)
> +{
> + if (unlikely(rq->balance_flags)) {
> + /*
> + * Run the balance_callbacks, except on hotplug
> + * when we need to push the current task away.
> + */
> + if (!IS_ENABLED(CONFIG_HOTPLUG_CPU) ||
> + !(rq->balance_flags & BALANCE_PUSH) ||
> + !balance_push(rq))
> + __balance_callbacks(rq);
> + }
> +}
> @@ -1392,12 +1396,13 @@ queue_balance_callback(struct rq *rq,
> {
> lockdep_assert_held(&rq->lock);
>
> - if (unlikely(head->next))
> + if (unlikely(head->next || (rq->balance_flags & BALANCE_PUSH)))
> return;
With this bit from Valentin we can probably simplify the above function,
but I've not thought about that yet.
Re: [PATCH 2/2] ath11k: Handle errors if peer creation fails
Alex Dewar writes:
> ath11k_peer_create() is called without its return value being checked,
> meaning errors will be unhandled. Add missing check and, as the mutex is
> unconditionally unlocked on leaving this function, simplify the exit
> path.
>
> Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
> Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
> Signed-off-by: Alex Dewar
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
> b/drivers/net/wireless/ath/ath11k/mac.c
> index 7f8dd47d2333..58db1b57b941 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -5211,7 +5211,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
> *hw,
> struct ath11k *ar = hw->priv;
> struct ath11k_base *ab = ar->ab;
> struct ath11k_vif *arvif = (void *)vif->drv_priv;
> - int ret;
> + int ret = 0;
I prefer not to initialise the ret variable.
> arvif->is_started = true;
>
> /* TODO: Setup ps and cts/rts protection */
>
> - mutex_unlock(&ar->conf_mutex);
> -
> - return 0;
> -
> -err:
> +unlock:
> mutex_unlock(&ar->conf_mutex);
>
> return ret;
So in the pending branch I changed this to:
ret = 0;
out:
mutex_unlock(&ar->conf_mutex);
return ret;
Please check.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
PATCH 1/1] scsi: arcmsr: fix warning: right shift count >= width of type
From: ching Huang Fix warning: right shift count >= width of type. Reported-by: kernel test robot Signed-off-by: ching Huang --- diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c index be6fb72..d13d672 100644 --- a/drivers/scsi/arcmsr/arcmsr_hba.c +++ b/drivers/scsi/arcmsr/arcmsr_hba.c @@ -655,7 +655,7 @@ static void arcmsr_hbaF_assign_regAddr(struct AdapterControlBlock *acb) /* host buffer low address, bit0:1 all buffer active */ writel((uint32_t)(host_buffer_dma | 1), &pmuF->inbound_msgaddr0); /* host buffer high address */ - writel((uint32_t)(host_buffer_dma >> 32), &pmuF->inbound_msgaddr1); + writel(dma_addr_hi32(host_buffer_dma), &pmuF->inbound_msgaddr1); /* set host buffer physical address */ writel(ARCMSR_HBFMU_DOORBELL_SYNC1, &pmuF->iobound_doorbell); } @@ -4083,7 +4083,7 @@ static int arcmsr_iop_confirm(struct AdapterControlBlock *acb) acb->msgcode_rwbuffer[4] = acb->ccbsize; dma_coherent_handle = acb->dma_coherent_handle2; cdb_phyaddr = (uint32_t)dma_coherent_handle; - cdb_phyaddr_hi32 = (uint32_t)(dma_coherent_handle >> 32); + cdb_phyaddr_hi32 = dma_addr_hi32(dma_coherent_handle); acb->msgcode_rwbuffer[5] = cdb_phyaddr; acb->msgcode_rwbuffer[6] = cdb_phyaddr_hi32; acb->msgcode_rwbuffer[7] = acb->completeQ_size;
Re: [PATCH v2] drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
On 10/4/2020 3:56 AM, Kuogee Hsieh wrote:
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- address review comments
This needs to go below '---' and should not be part of the
change log.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 26 +
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 44 ++---
drivers/gpu/drm/msm/dp/dp_power.h | 2 +-
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..6eb9cdad1421 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@ struct dp_ctrl_private {
struct dp_parser *parser;
struct dp_catalog *catalog;
+ struct opp_table *opp_table;
+
struct completion idle_comp;
struct completion video_comp;
};
@@ -1836,6 +1839,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
struct dp_parser *parser)
{
struct dp_ctrl_private *ctrl;
+ int ret;
if (!dev || !panel || !aux ||
!link || !catalog) {
@@ -1849,6 +1853,19 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device tree\n");
You do this regardless of an OPP table in DT, so for starters the error
message is wrong. Secondly this can return you a -EPROBE_DEFER if the
clock driver isn't ready yet.
So the ideal thing to do here, is return a PTR_ERR(ctrl->opp_table)
+ ctrl->opp_table = NULL;
+ } else {
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret && ret != -ENODEV) {
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+ }
+
init_completion(&ctrl->idle_comp);
init_completion(&ctrl->video_comp);
@@ -1866,4 +1883,13 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct dp_link *link,
void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ if (ctrl->opp_table) {
+ dev_pm_opp_of_remove_table(ctrl->dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..269f83550b46 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -698,7 +698,7 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error;
}
- dp->power = dp_power_get(dp->parser);
+ dp->power = dp_power_get(dev, dp->parser);
if (IS_ERR(dp->power)) {
rc = PTR_ERR(dp->power);
DRM_ERROR("failed to initialize power, rc = %d\n", rc);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..9c4ea00a5f2a 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,51 @@ static int dp_power_clk_deinit(struct dp_power_private
*power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private *power,
+ struct dss_clk *clk_arry, int num_clk, int enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev, rate);
I am not sure how this is expected to work when you have multiple link clocks,
since you can only associate one of them with the OPP table which ends up
getting scaled when you do a dev_pm_opp_set_rate()
Do you really have platforms which will have multiple link clocks?
Re: [PATCH] leds: lm3697: Fix out-of-bound access
By the way I just realized that the DT binding in this driver seems incorrect to me. The controller logically supports 3 LED strings, each having configurable control bank. But the DT binding supports 2 DT nodes, one for each control bank (identified by the `reg` property) and then `led-sources` says which string should be controlled by given bank. But taking in mind that DT should describe how devices are connected to each other, I think the child nodes in the binding should instead describe the 3 supported LED strings... Marek
Re: [PATCH] scripts: kernel-doc: allow passing desired Sphinx C domain dialect
On Tue, 2020-10-06 at 08:42 +0200, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Oct 2020 10:17:36 -0600
> Jonathan Corbet escreveu:
[]
> Sure. It should be easy to make the third argument optional, although
> the regex will be a little more harder to understand.
>
> Something like this should do the trick:
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
[]
> @@ -466,12 +466,16 @@ while ($ARGV[0] =~ m/^--?(.*)/) {
> $show_not_found = 1; # A no-op but don't fail
> } elsif ($cmd eq "sphinx-version") {
> my $ver_string = shift @ARGV;
> - if ($ver_string =~ m/^(\d+)\.(\d+)\.(\d+)/) {
> + if ($ver_string =~ m/^(\d+)\.(\d+)(?:\.?(\d+)?)/) {
trivia: perhaps more readable as
if ($ver_string =~ m/^(\d+)\.(\d+)(\.\d+)?/) {
$sphinx_major = $1;
$sphinx_minor = $2;
if (defined($3)) {
$sphinx_patch = substr($3,1);
} else {
$sphinx_patch = 0;
}
linux-next: manual merge of the char-misc tree with the powerpc tree
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/ocxl/Kconfig
between commit:
dde6f18a8779 ("ocxl: Don't return trigger page when allocating an interrupt")
from the powerpc tree and commit:
4b53a3c72116 ("ocxl: fix kconfig dependency warning for OCXL")
from the char-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/ocxl/Kconfig
index 0d815b2a40b3,947294f6d7f4..
--- a/drivers/misc/ocxl/Kconfig
+++ b/drivers/misc/ocxl/Kconfig
@@@ -9,9 -9,8 +9,9 @@@ config OCXL_BAS
config OCXL
tristate "OpenCAPI coherent accelerator support"
- depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV
+ depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE
++ depends on HOTPLUG_PCI_POWERNV
select OCXL_BASE
- select HOTPLUG_PCI_POWERNV
default m
help
Select this option to enable the ocxl driver for Open
pgpbLESJMpBRj.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
Hi Rob,
On Mon, Oct 5, 2020 at 8:39 PM Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schema (via
> '$ref') and all possible properties and/or child nodes are not
> explicitly listed in the schema with the '$ref'.
>
> This is in preparation to add a meta-schema to check for missing
> 'unevaluatedProperties' or 'additionalProperties'. This has been a
> constant source of review issues.
>
> Signed-off-by: Rob Herring
Thanks for your patch!
> Documentation/devicetree/bindings/bus/renesas,bsc.yaml | 2 ++
> .../bindings/memory-controllers/renesas,rpc-if.yaml | 2 ++
> Documentation/devicetree/bindings/net/renesas,ether.yaml | 2 ++
> Documentation/devicetree/bindings/serial/renesas,hscif.yaml | 2 ++
> Documentation/devicetree/bindings/serial/renesas,sci.yaml| 2 ++
> Documentation/devicetree/bindings/serial/renesas,scif.yaml | 2 ++
> Documentation/devicetree/bindings/serial/renesas,scifa.yaml | 2 ++
> Documentation/devicetree/bindings/serial/renesas,scifb.yaml | 2 ++
> Documentation/devicetree/bindings/spi/renesas,hspi.yaml | 2 ++
> Documentation/devicetree/bindings/spi/renesas,rspi.yaml | 2 ++
> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml | 2 ++
Acked-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
> @@ -85,6 +85,8 @@ required:
>- clocks
>- pinctrl-0
>
> +unevaluatedProperties: false
This one has received an "additionalProperties: false" in commit
41506bff84f1563e ("dt-bindings: net: renesas, ether: Improve schema validation")
in net-next, which you probably want to remove.
> +
> examples:
># Lager board
>- |
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/3] dt-bindings: can: rcar_can: Add r8a7742 support
Hi Marc, On Tue, Aug 25, 2020 at 3:21 AM Rob Herring wrote: > > On Sun, 16 Aug 2020 20:07:31 +0100, Lad Prabhakar wrote: > > Document RZ/G1H (r8a7742) SoC specific bindings. The R8A7742 CAN module > > is identical to R-Car Gen2 family. > > > > No driver change is needed due to the fallback compatible value > > "renesas,rcar-gen2-can". > > > > Signed-off-by: Lad Prabhakar > > Reviewed-by: Chris Paterson > > --- > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Acked-by: Rob Herring > Could you please pick up this patch. It has been acked by the maintainers. Let me know if you want me to RESEND this patch. Cheers, Prabhakar
Re: [PATCH 1/4] drivers core: Introduce CPU type sysfs interface
On Mon, Oct 05, 2020 at 05:57:36PM -0700, Ricardo Neri wrote:
> On Sat, Oct 03, 2020 at 10:53:45AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Oct 02, 2020 at 06:17:42PM -0700, Ricardo Neri wrote:
> > > Hybrid CPU topologies combine CPUs of different microarchitectures in the
> > > same die. Thus, even though the instruction set is compatible among all
> > > CPUs, there may still be differences in features (e.g., some CPUs may
> > > have counters that others CPU do not). There may be applications
> > > interested in knowing the type of micro-architecture topology of the
> > > system to make decisions about process affinity.
> > >
> > > While the existing sysfs for capacity (/sys/devices/system/cpu/cpuX/
> > > cpu_capacity) may be used to infer the types of micro-architecture of the
> > > CPUs in the platform, it may not be entirely accurate. For instance, two
> > > subsets of CPUs with different types of micro-architecture may have the
> > > same capacity due to power or thermal constraints.
> > >
> > > Create the new directory /sys/devices/system/cpu/types. Under such
> > > directory, create individual subdirectories for each type of CPU micro-
> > > architecture. Each subdirectory will have cpulist and cpumap files. This
> > > makes it convenient for user space to read all the CPUs of the same type
> > > at once without having to inspect each CPU individually.
> > >
> > > Implement a generic interface using weak functions that architectures can
> > > override to indicate a) support for CPU types, b) the CPU type number, and
> > > c) a string to identify the CPU vendor and type.
> > >
> > > For example, an x86 system with one Intel Core and four Intel Atom CPUs
> > > would look like this (other architectures have the hooks to use whatever
> > > directory naming convention below "types" that meets their needs):
> > >
> > > user@host:~$: ls /sys/devices/system/cpu/types
> > > intel_atom_0 intel_core_0
> > >
> > > user@host:~$ ls /sys/devices/system/cpu/types/intel_atom_0
> > > cpulist cpumap
> > >
> > > user@host:~$ ls /sys/devices/system/cpu/types/intel_core_0
> > > cpulist cpumap
> > >
> > > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom_0/cpumap
> > > 0f
> > >
> > > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom_0/cpulist
> > > 0-3
> > >
> > > user@ihost:~$ cat /sys/devices/system/cpu/types/intel_core_0/cpumap
> > > 10
> > >
> > > user@host:~$ cat /sys/devices/system/cpu/types/intel_core_0/cpulist
> > > 4
>
> Thank you for the quick and detailed Greg!
>
> >
> > The output of 'tree' sometimes makes it easier to see here, or:
> > grep -R . *
> > also works well.
>
> Indeed, this would definitely make it more readable.
>
> >
> > > On non-hybrid systems, the /sys/devices/system/cpu/types directory is not
> > > created. Add a hook for this purpose.
> >
> > Why should these not show up if the system is not "hybrid"?
>
> My thinking was that on a non-hybrid system, it does not make sense to
> create this interface, as all the CPUs will be of the same type.
Why not just have this an attribute type in the existing cpuX directory?
Why do this have to be a totally separate directory and userspace has to
figure out to look in two different spots for the same cpu to determine
what it is?
That feels wasteful, it should be much simpler to use the existing
object, right?
That way, you also show the "type" of all cpus, no matter if they are
"hybrid" or not, again, making userspace deal with things in a much
simpler manner.
> > > +/**
> > > + * arch_get_cpu_type() - Get the CPU type number
> > > + * @cpu: Index of the CPU of which the index is needed
> > > + *
> > > + * Get the CPU type number of @cpu, a non-zero unsigned 32-bit number
> > > that
> > > + * uniquely identifies a type of CPU micro-architecture. All CPUs of the
> > > same
> > > + * type have the same type number. Type numbers are defined by each CPU
> > > + * architecture.
> > > + */
> > > +u32 __weak arch_get_cpu_type(int cpu)
> >
> > Can you just have this "cpu type" be an enumerated type so we have a
> > clue as to what they really are? Each arch can then define it, right?
>
> Do you mean that each arch can have its own definition of the same
> enumeration or that all archs share a common enumeration?
Each arch should have its own definition of this enumerated type.
> > > +/**
> > > + * arch_get_cpu_type_name() - Get the CPU type name
> > > + * @cpu_type:Type of CPU micro-architecture.
> > > + *
> > > + * Returns a string name associated with the CPU micro-architecture type
> > > as
> > > + * indicated in @cpu_type. The format shall be _.
> > > Returns
> > > + * NULL if the CPU type is not known.
> > > + */
> > > +const char __weak *arch_get_cpu_type_name(u32 cpu_type)
> > > +{
> > > + return NULL;
> > > +}
> >
> > Why is vendor part of this? Shouldn't it just be arch?
> >
> > I say this as "vendor" is kind of "interesting" when it comes to other
> > arches...
>
> I thought of this as may
Re: [PATCH V7 0/2] percpu_ref & block: reduce memory footprint of percpu_ref in fast path
On Thu, Oct 01, 2020 at 11:48:40PM +0800, Ming Lei wrote: > Hi, > > The 1st patch removes memory footprint of percpu_ref in fast path > from 7 words to 2 words, since it is often used in fast path and > embedded in user struct. > > The 2nd patch moves .q_usage_counter to 1st cacheline of > 'request_queue'. > > Simple test on null_blk shows ~2% IOPS boost on one 16cores(two threads > per core) machine, dual socket/numa. > > V7: > - add comments about reason for struct split Hello Jens Can you consider to merge the patchset in block tree if you are fine? Thanks, Ming
Re: [PATCH 3/4] dt-bindings: Explicitly allow additional properties in board/SoC schemas
On Mon, Oct 5, 2020 at 8:39 PM Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As the top-level
> board/SoC schemas always have additional properties, add
> 'additionalProperties: true'.
>
> Signed-off-by: Rob Herring
> Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
On Mon, Oct 5, 2020 at 8:39 PM Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
> Signed-off-by: Rob Herring
> Documentation/devicetree/bindings/bus/simple-pm-bus.yaml | 2 ++
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC] Status of orinoco_usb
+ Jes On 10/5/2020 4:12 PM, Kalle Valo wrote: Greg Kroah-Hartman writes: On Fri, Oct 02, 2020 at 01:53:58PM +0200, Sebastian Andrzej Siewior wrote: On 2020-10-02 13:37:25 [+0200], Greg Kroah-Hartman wrote: Is it possible to end up here in softirq context or is this a relic? I think it's a relic of where USB host controllers completed their urbs in hard-irq mode. The BH/tasklet change is a pretty recent change. But the BH thingy for HCDs went in v3.12 for EHCI. XHCI was v5.5. My guess would be that people using orinoco USB are on EHCI :) USB 3 systems run XHCI, which has a USB 2 controller in it, so these types of things might not have been noticed yet. Who knows :) Should it be removed? We can move it out to drivers/staging/ and then drop it to see if anyone complains that they have the device and is willing to test any changes. Not sure moving is easy since it depends on other files in that folder. USB is one interface next to PCI for instance. Unless you meant to move the whole driver including all interfaces. I was suggesting to remove the USB bits. I forgot this was tied into other code, sorry. I don't know what to suggest other than maybe try to fix it up the best that you can, and let's see if anyone notices... That's what I would suggest as well. These drivers for ancient hardware are tricky. Even if there doesn't seem to be any users on the driver sometimes people pop up reporting that it's still usable. We had that recently with one another wireless driver (forgot the name already). Quite a while ago I shipped an orinoco dongle to Jes Sorensen which he wanted to use for some intern project if I recall correctly. Guess that idea did not fly yet. Regards, Arend smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] KVM: x86: filter guest NX capability for cpuid2
Sean Christopherson writes: > On Mon, Oct 05, 2020 at 05:29:47PM +0200, Vitaly Kuznetsov wrote: >> Tianjia Zhang writes: >> >> > Original KVM_SET_CPUID has removed NX on non-NX hosts as it did >> > before. but KVM_SET_CPUID2 does not. The two should be consistent. >> > >> > Signed-off-by: Tianjia Zhang >> > --- >> > arch/x86/kvm/cpuid.c | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >> > index 3fd6eec202d7..3e7ba2b11acb 100644 >> > --- a/arch/x86/kvm/cpuid.c >> > +++ b/arch/x86/kvm/cpuid.c >> > @@ -257,6 +257,7 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu, >> >goto out; >> >} >> > >> > + cpuid_fix_nx_cap(vcpu); >> >kvm_update_cpuid_runtime(vcpu); >> >kvm_vcpu_after_set_cpuid(vcpu); >> > out: >> >> I stumbled upon this too and came to the conclusion this is >> intentional, e.g. see this: >> >> commit 0771671749b59a507b6da4efb931c44d9691e248 >> Author: Dan Kenigsberg >> Date: Wed Nov 21 17:10:04 2007 +0200 >> >> KVM: Enhance guest cpuid management >> >> ... >> >> [avi: fix original KVM_SET_CPUID not removing nx on non-nx hosts as it >> did >> before] >> >> but this is a very, very old story. > > Doesn't mean it's bogus though :-) _If_ we want to extend this behavior to > KVM_SET_CPUID2, there should be a justified need. Yes, exactly. I meand to say that founding fathers of KVM left the adjustment for KVM_SET_CPUID exclusively on purpose and not by mistake :-) -- Vitaly
Re: [RFC V2] mm/vmstat: Add events for HugeTLB migration
On Tue 06-10-20 08:26:35, Anshuman Khandual wrote: > > > On 10/05/2020 11:35 AM, Michal Hocko wrote: > > On Mon 05-10-20 07:59:12, Anshuman Khandual wrote: > >> > >> > >> On 10/02/2020 05:34 PM, Michal Hocko wrote: > >>> On Wed 30-09-20 11:30:49, Anshuman Khandual wrote: > Add following new vmstat events which will track HugeTLB page migration. > > 1. HUGETLB_MIGRATION_SUCCESS > 2. HUGETLB_MIGRATION_FAILURE > > It follows the existing semantics to accommodate HugeTLB subpages in > total > page migration statistics. While here, this updates current trace event > 'mm_migrate_pages' to accommodate now available HugeTLB based statistics. > >>> What is the actual usecase? And how do you deal with the complexity > >>> introduced by many different hugetlb page sizes. Really, what is the > >>> point to having such a detailed view on hugetlb migration? > >>> > >> > >> It helps differentiate various page migration events i.e normal, THP and > >> HugeTLB and gives us more reliable and accurate measurement. Current stats > >> as per PGMIGRATE_SUCCESS and PGMIGRATE_FAIL are misleading, as they contain > >> both normal and HugeTLB pages as single entities, which is not accurate. > > > > Yes this is true. But why does it really matter? Do you have a specific > > example? > > An example which demonstrates that mixing and misrepresentation in these > stats create some problem ? Well, we could just create one scenario via > an application with different VMA types and triggering some migrations. > But the fact remains, that these stats are inaccurate and misleading > which is very clear and apparent. This doesn't sound like a proper justification to me. > >> After this change, PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will contain page > >> migration statistics in terms of normal pages irrespective of whether any > >> previous migrations until that point involved normal pages, THP or HugeTLB > >> (any size) pages. At the least, this fixes existing misleading stats with > >> PGMIGRATE_SUCCESS and PGMIGRATE_FAIL. > >> > >> Besides, it helps us understand HugeTLB migrations in more detail. Even > >> though HugeTLB can be of various sizes on a given platform, these new > >> stats HUGETLB_MIGRATION_SUCCESS and HUGETLB_MIGRATION_FAILURE give enough > >> overall insight into HugeTLB migration events. > > > > While true this all is way too vague to add yet another imprecise > > counter. > > Given that user knows about all HugeTLB mappings it has got, these counters > are not really vague and could easily be related back. How can you tell a difference between different hugetlb sizes? > Moreover this change > completes the migration stats restructuring which was started with adding > THP counters. Otherwise it remains incomplete. Our counters will be always incomplete. Please do realize they are mere aid rather than a comprihensive toolset to identify the system behavior to the very detail. We have way too many counters and this particular ones are not adding much IMHO. At least not from your description which sounds to me like "Yeah, why not do that although there is no strong reason, well except that THP already has it so let's do it for hugetlb as well". I really do not want to deal with yet another report in few years that somebody wants to distinguish hugetlb migration of different sizes. Really, is there any _real_ practical use for these other than "nice, let's just have it"? -- Michal Hocko SUSE Labs
[PATCH v5 2/4] spi: spi-mtk-nor: use dma_alloc_coherent() for bounce buffer
Use dma_alloc_coherent() for bounce buffer instead of kmalloc() to
make sure the bounce buffer to be allocated within its DMAable range.
Signed-off-by: Ikjoon Jang
---
drivers/spi/spi-mtk-nor.c | 94 ++-
1 file changed, 52 insertions(+), 42 deletions(-)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index ea39736de291..c11bed28b952 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -97,6 +97,7 @@ struct mtk_nor {
struct device *dev;
void __iomem *base;
u8 *buffer;
+ dma_addr_t buffer_dma;
struct clk *spi_clk;
struct clk *ctlr_clk;
unsigned int spi_freq;
@@ -145,6 +146,11 @@ static void mtk_nor_set_addr(struct mtk_nor *sp, const
struct spi_mem_op *op)
}
}
+static bool need_bounce(struct mtk_nor *sp, const struct spi_mem_op *op)
+{
+ return ((uintptr_t)op->data.buf.in & MTK_NOR_DMA_ALIGN_MASK);
+}
+
static bool mtk_nor_match_read(const struct spi_mem_op *op)
{
int dummy = 0;
@@ -238,6 +244,8 @@ static void mtk_nor_adj_prg_size(struct spi_mem_op *op)
static int mtk_nor_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
{
+ struct mtk_nor *sp = spi_controller_get_devdata(mem->spi->master);
+
if (!op->data.nbytes)
return 0;
@@ -251,8 +259,7 @@ static int mtk_nor_adjust_op_size(struct spi_mem *mem,
struct spi_mem_op *op)
if ((op->addr.val & MTK_NOR_DMA_ALIGN_MASK) ||
(op->data.nbytes < MTK_NOR_DMA_ALIGN))
op->data.nbytes = 1;
- else if (!((ulong)(op->data.buf.in) &
- MTK_NOR_DMA_ALIGN_MASK))
+ else if (!need_bounce(sp, op))
op->data.nbytes &= ~MTK_NOR_DMA_ALIGN_MASK;
else if (op->data.nbytes > MTK_NOR_BOUNCE_BUF_SIZE)
op->data.nbytes = MTK_NOR_BOUNCE_BUF_SIZE;
@@ -325,19 +332,12 @@ static void mtk_nor_setup_bus(struct mtk_nor *sp, const
struct spi_mem_op *op)
mtk_nor_rmw(sp, MTK_NOR_REG_BUSCFG, reg, MTK_NOR_BUS_MODE_MASK);
}
-static int mtk_nor_read_dma(struct mtk_nor *sp, u32 from, unsigned int length,
- u8 *buffer)
+static int mtk_nor_dma_exec(struct mtk_nor *sp, u32 from, unsigned int length,
+ dma_addr_t dma_addr)
{
int ret = 0;
ulong delay;
u32 reg;
- dma_addr_t dma_addr;
-
- dma_addr = dma_map_single(sp->dev, buffer, length, DMA_FROM_DEVICE);
- if (dma_mapping_error(sp->dev, dma_addr)) {
- dev_err(sp->dev, "failed to map dma buffer.\n");
- return -EINVAL;
- }
writel(from, sp->base + MTK_NOR_REG_DMA_FADR);
writel(dma_addr, sp->base + MTK_NOR_REG_DMA_DADR);
@@ -362,30 +362,49 @@ static int mtk_nor_read_dma(struct mtk_nor *sp, u32 from,
unsigned int length,
(delay + 1) * 100);
}
- dma_unmap_single(sp->dev, dma_addr, length, DMA_FROM_DEVICE);
if (ret < 0)
dev_err(sp->dev, "dma read timeout.\n");
return ret;
}
-static int mtk_nor_read_bounce(struct mtk_nor *sp, u32 from,
- unsigned int length, u8 *buffer)
+static int mtk_nor_read_bounce(struct mtk_nor *sp, const struct spi_mem_op *op)
{
unsigned int rdlen;
int ret;
- if (length & MTK_NOR_DMA_ALIGN_MASK)
- rdlen = (length + MTK_NOR_DMA_ALIGN) & ~MTK_NOR_DMA_ALIGN_MASK;
+ if (op->data.nbytes & MTK_NOR_DMA_ALIGN_MASK)
+ rdlen = (op->data.nbytes + MTK_NOR_DMA_ALIGN) &
~MTK_NOR_DMA_ALIGN_MASK;
else
- rdlen = length;
+ rdlen = op->data.nbytes;
- ret = mtk_nor_read_dma(sp, from, rdlen, sp->buffer);
- if (ret)
- return ret;
+ ret = mtk_nor_dma_exec(sp, op->addr.val, rdlen, sp->buffer_dma);
- memcpy(buffer, sp->buffer, length);
- return 0;
+ if (!ret)
+ memcpy(op->data.buf.in, sp->buffer, op->data.nbytes);
+
+ return ret;
+}
+
+static int mtk_nor_read_dma(struct mtk_nor *sp, const struct spi_mem_op *op)
+{
+ int ret;
+ dma_addr_t dma_addr;
+
+ if (need_bounce(sp, op))
+ return mtk_nor_read_bounce(sp, op);
+
+ dma_addr = dma_map_single(sp->dev, op->data.buf.in,
+ op->data.nbytes, DMA_FROM_DEVICE);
+
+ if (dma_mapping_error(sp->dev, dma_addr))
+ return -EINVAL;
+
+ ret = mtk_nor_dma_exec(sp, op->addr.val, op->data.nbytes, dma_addr);
+
+ dma_unmap_single(sp->dev, dma_addr, op->data.nbytes, DMA_FROM_DEVICE);
+
+ return ret;
}
static int mtk_nor_read_pio(struct mtk_nor *sp, const struct spi_mem_op *op)
@@ -566,15 +585,8 @@ static int mtk_nor_exec_op(struct spi_mem *mem,
Re: [GIT PULL] devfreq next for v5.10
Dear Rafael, On 10/1/20 12:56 AM, Rafael J. Wysocki wrote: > On Tue, Sep 29, 2020 at 10:56 AM Chanwoo Choi wrote: >> >> Dear Rafael, >> >> This is devfreq-next pull request for v5.10-rc1. I add detailed description >> of >> this pull request on the following tag. Please pull devfreq with following >> updates. >> - tag name : devfreq-next-for-5.10 > > Pulled, thanks! Thanks for pulled the request. But, I tried to check on linux-pm.git, I cannot find the pull request of devfreq patches for v5.10-rc1. Best Regards, Chanwoo Choi
[PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887
The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect
the headset microphone and another headphone jack until
ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied.
The NID 0x15 maps as the headset microphone and NID 0x19 maps as another
headphone jack. Also need the function like alc887_fixup_asus_jack to
enable the audio jacks.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Kailang Yang
---
sound/pci/hda/patch_realtek.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d4f17b465892..8d0928bdc9ff 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1929,6 +1929,8 @@ enum {
ALC1220_FIXUP_CLEVO_P950,
ALC1220_FIXUP_CLEVO_PB51ED,
ALC1220_FIXUP_CLEVO_PB51ED_PINS,
+ ALC887_FIXUP_ASUS_AUDIO,
+ ALC887_FIXUP_ASUS_HMIC,
};
static void alc889_fixup_coef(struct hda_codec *codec,
@@ -2141,6 +2143,30 @@ static void alc1220_fixup_clevo_pb51ed(struct hda_codec
*codec,
alc_fixup_headset_mode_no_hp_mic(codec, fix, action);
}
+static void alc887_asus_hp_automute_hook(struct hda_codec *codec,
+struct hda_jack_callback *jack)
+{
+ struct alc_spec *spec = codec->spec;
+ int vref;
+
+ snd_hda_gen_hp_automute(codec, jack);
+
+ vref = spec->gen.hp_jack_present ? 0xc4 : 0xc0;
+ snd_hda_codec_write(codec, 0x19, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+ vref);
+}
+
+static void alc887_fixup_asus_jack(struct hda_codec *codec,
+const struct hda_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+ if (action != HDA_FIXUP_ACT_PROBE)
+ return;
+ snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+ 0xc0);
+ spec->gen.hp_automute_hook = alc887_asus_hp_automute_hook;
+}
+
static const struct hda_fixup alc882_fixups[] = {
[ALC882_FIXUP_ABIT_AW9D_MAX] = {
.type = HDA_FIXUP_PINS,
@@ -2398,6 +2424,20 @@ static const struct hda_fixup alc882_fixups[] = {
.chained = true,
.chain_id = ALC1220_FIXUP_CLEVO_PB51ED,
},
+ [ALC887_FIXUP_ASUS_AUDIO] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x15, 0x02a14150 }, /* use as headset mic, without
its own jack detect */
+ { 0x19, 0x22219420 },
+ {}
+ },
+ },
+ [ALC887_FIXUP_ASUS_HMIC] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc887_fixup_asus_jack,
+ .chained = true,
+ .chain_id = ALC887_FIXUP_ASUS_AUDIO,
+ },
};
static const struct snd_pci_quirk alc882_fixup_tbl[] = {
@@ -2431,6 +2471,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD),
SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V),
SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC),
+ SND_PCI_QUIRK(0x1043, 0x2390, "Asus D700SA", ALC887_FIXUP_ASUS_HMIC),
SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601),
SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS),
SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII",
ALC882_FIXUP_GPIO3),
--
2.28.0
[PATCH v5 1/4] dt-bindings: spi: add mt8192-nor compatible string
Add MT8192 spi-nor controller support. Signed-off-by: Ikjoon Jang Acked-by: Rob Herring --- Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 42c9205ac991..55c239446a5b 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt7622-nor - mediatek,mt7623-nor - mediatek,mt7629-nor + - mediatek,mt8192-nor - enum: - mediatek,mt8173-nor - items: -- 2.28.0.806.g8561365e88-goog
Re: [PATCH 05/11] arm64: dts: qcom: msm8992: Add support for SDHCI2
Hi Konrad, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v5.9-rc8 next-20201002] [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/Konrad-Dybcio/pm8994-msm8992-4-DT-updates/20201006-003302 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: arm64-allyesconfig (attached as .config) compiler: aarch64-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/3d0d6d93b04f8cd064e594520ccc9c361fa8c949 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Konrad-Dybcio/pm8994-msm8992-4-DT-updates/20201006-003302 git checkout 3d0d6d93b04f8cd064e594520ccc9c361fa8c949 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/qcom/msm8992.dtsi:282.11-12 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
linux-next: manual merge of the staging tree with the devicetree tree
Hi all,
Today's linux-next merge of the staging tree got a conflict in:
Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
between commit:
41fb845621ea ("dt-bindings: Another round of adding missing
'additionalProperties'")
from the devicetree tree and commit:
3b17dd220432 ("dt-bindings: iio: adc: exynos-adc: require second interrupt
with touch screen")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
index 16d76482b4ff,37d6591ff78c..
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
@@@ -107,8 -109,15 +109,17 @@@ allOf
items:
- const: adc
+ - if:
+ required:
+ - has-touchscreen
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+additionalProperties: false
+
examples:
- |
adc: adc@12d1 {
pgp1fOAEx3b09.pgp
Description: OpenPGP digital signature
Re: [PATCH -v2 15/17] sched: Fix migrate_disable() vs rt/dl balancing
On Mon, Oct 05, 2020 at 04:57:32PM +0200, Peter Zijlstra wrote:
> +static inline struct task_struct *get_push_task(struct rq *rq)
> +{
> + struct task_struct *p = rq->curr;
> +
> + lockdep_assert_held(&rq->lock);
> +
> + if (rq->push_busy)
> + return NULL;
> +
> + if (p->nr_cpus_allowed == 1)
> + return NULL;
This; that means what when we're stuck below a per-cpu thread, we're
toast. There's just nothing much you can do... :/
> +
> + rq->push_busy = true;
> + return get_task_struct(p);
> +}
[PATCH v5 4/4] spi: spi-mtk-nor: Add power management support
This patch adds dev_pm_ops to mtk-nor to support suspend/resume,
auto suspend delay is set to -1 by default.
Accessing registers are only permitted after its clock is enabled
to deal with unknown state of operating clk at probe time.
Signed-off-by: Ikjoon Jang
---
drivers/spi/spi-mtk-nor.c | 98 ++-
1 file changed, 76 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index e46d5c93d742..b97f26a60cbe 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -690,22 +691,15 @@ static int mtk_nor_enable_clk(struct mtk_nor *sp)
return 0;
}
-static int mtk_nor_init(struct mtk_nor *sp)
+static void mtk_nor_init(struct mtk_nor *sp)
{
- int ret;
-
- ret = mtk_nor_enable_clk(sp);
- if (ret)
- return ret;
-
- sp->spi_freq = clk_get_rate(sp->spi_clk);
+ writel(0, sp->base + MTK_NOR_REG_IRQ_EN);
+ writel(MTK_NOR_IRQ_MASK, sp->base + MTK_NOR_REG_IRQ_STAT);
writel(MTK_NOR_ENABLE_SF_CMD, sp->base + MTK_NOR_REG_WP);
mtk_nor_rmw(sp, MTK_NOR_REG_CFG2, MTK_NOR_WR_CUSTOM_OP_EN, 0);
mtk_nor_rmw(sp, MTK_NOR_REG_CFG3,
MTK_NOR_DISABLE_WREN | MTK_NOR_DISABLE_SR_POLL, 0);
-
- return ret;
}
static irqreturn_t mtk_nor_irq_handler(int irq, void *data)
@@ -788,6 +782,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
ctlr->num_chipselect = 1;
ctlr->setup = mtk_nor_setup;
ctlr->transfer_one_message = mtk_nor_transfer_one_message;
+ ctlr->auto_runtime_pm = true;
dev_set_drvdata(&pdev->dev, ctlr);
@@ -811,12 +806,19 @@ static int mtk_nor_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ ret = mtk_nor_enable_clk(sp);
+ if (ret < 0)
+ return ret;
+
+ sp->spi_freq = clk_get_rate(sp->spi_clk);
+
+ mtk_nor_init(sp);
+
irq = platform_get_irq_optional(pdev, 0);
+
if (irq < 0) {
dev_warn(sp->dev, "IRQ not available.");
} else {
- writel(MTK_NOR_IRQ_MASK, base + MTK_NOR_REG_IRQ_STAT);
- writel(0, base + MTK_NOR_REG_IRQ_EN);
ret = devm_request_irq(sp->dev, irq, mtk_nor_irq_handler, 0,
pdev->name, sp);
if (ret < 0) {
@@ -827,34 +829,86 @@ static int mtk_nor_probe(struct platform_device *pdev)
}
}
- ret = mtk_nor_init(sp);
- if (ret < 0) {
- kfree(ctlr);
- return ret;
- }
+ pm_runtime_set_autosuspend_delay(&pdev->dev, -1);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
+
+ ret = devm_spi_register_controller(&pdev->dev, ctlr);
+ if (ret < 0)
+ goto err_probe;
+
+ pm_runtime_mark_last_busy(&pdev->dev);
+ pm_runtime_put_autosuspend(&pdev->dev);
dev_info(&pdev->dev, "spi frequency: %d Hz\n", sp->spi_freq);
- return devm_spi_register_controller(&pdev->dev, ctlr);
+ return 0;
+
+err_probe:
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
+
+ mtk_nor_disable_clk(sp);
+
+ return ret;
}
static int mtk_nor_remove(struct platform_device *pdev)
{
- struct spi_controller *ctlr;
- struct mtk_nor *sp;
+ struct spi_controller *ctlr = dev_get_drvdata(&pdev->dev);
+ struct mtk_nor *sp = spi_controller_get_devdata(ctlr);
- ctlr = dev_get_drvdata(&pdev->dev);
- sp = spi_controller_get_devdata(ctlr);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
+
+ mtk_nor_disable_clk(sp);
+
+ return 0;
+}
+
+static int __maybe_unused mtk_nor_runtime_suspend(struct device *dev)
+{
+ struct spi_controller *ctlr = dev_get_drvdata(dev);
+ struct mtk_nor *sp = spi_controller_get_devdata(ctlr);
mtk_nor_disable_clk(sp);
return 0;
}
+static int __maybe_unused mtk_nor_runtime_resume(struct device *dev)
+{
+ struct spi_controller *ctlr = dev_get_drvdata(dev);
+ struct mtk_nor *sp = spi_controller_get_devdata(ctlr);
+
+ return mtk_nor_enable_clk(sp);
+}
+
+static int __maybe_unused mtk_nor_suspend(struct device *dev)
+{
+ return pm_runtime_force_suspend(dev);
+}
+
+static int __maybe_unused mtk_nor_resume(struct device *dev)
+{
+ return pm_runtime_force_resume(dev);
+}
+
+static const struct dev_pm_ops mtk_nor_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_nor_runtime_suspend,
+ mtk_nor_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OP
[PATCH v5 0/4] spi: spi-mtk-nor: Add mt8192 support.
This patchset adds 36bit dma address and power management supports for mt8192-nor. Changes in v5: - Rebase from merge conflict Changes in v4: - Drop two patches from a list, addressed by an another series - Fix 0-day ci 'shift-count-overflow' warning Changes in v3: - Fix a bugfix of v2 in checking spi memory operation. - split read_dma function into two (normal/bounce) - Support 7bytes generic spi xfer Changes in v2: - Add power management support - Fix bugs in checking spi memory operation. - use dma_alloc_coherent for allocating bounce buffer - code cleanups Ikjoon Jang (4): dt-bindings: spi: add mt8192-nor compatible string spi: spi-mtk-nor: use dma_alloc_coherent() for bounce buffer spi: spi-mtk-nor: support 36bit dma addressing spi: spi-mtk-nor: Add power management support .../bindings/spi/mediatek,spi-mtk-nor.yaml| 1 + drivers/spi/spi-mtk-nor.c | 211 -- 2 files changed, 148 insertions(+), 64 deletions(-) -- 2.28.0.806.g8561365e88-goog
[PATCH v5 3/4] spi: spi-mtk-nor: support 36bit dma addressing
This patch enables 36bit dma address support to spi-mtk-nor.
Currently this is enabled only for mt8192-nor.
Signed-off-by: Ikjoon Jang
---
drivers/spi/spi-mtk-nor.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index c11bed28b952..e46d5c93d742 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -79,6 +79,8 @@
#define MTK_NOR_REG_DMA_FADR 0x71c
#define MTK_NOR_REG_DMA_DADR 0x720
#define MTK_NOR_REG_DMA_END_DADR 0x724
+#define MTK_NOR_REG_DMA_DADR_HB0x738
+#define MTK_NOR_REG_DMA_END_DADR_HB0x73c
#define MTK_NOR_PRG_MAX_SIZE 6
// Reading DMA src/dst addresses have to be 16-byte aligned
@@ -103,6 +105,7 @@ struct mtk_nor {
unsigned int spi_freq;
bool wbuf_en;
bool has_irq;
+ bool high_dma;
struct completion op_done;
};
@@ -343,6 +346,13 @@ static int mtk_nor_dma_exec(struct mtk_nor *sp, u32 from,
unsigned int length,
writel(dma_addr, sp->base + MTK_NOR_REG_DMA_DADR);
writel(dma_addr + length, sp->base + MTK_NOR_REG_DMA_END_DADR);
+ if (sp->high_dma) {
+ writel(upper_32_bits(dma_addr),
+ sp->base + MTK_NOR_REG_DMA_DADR_HB);
+ writel(upper_32_bits(dma_addr + length),
+ sp->base + MTK_NOR_REG_DMA_END_DADR_HB);
+ }
+
if (sp->has_irq) {
reinit_completion(&sp->op_done);
mtk_nor_rmw(sp, MTK_NOR_REG_IRQ_EN, MTK_NOR_IRQ_DMA, 0);
@@ -731,7 +741,8 @@ static const struct spi_controller_mem_ops mtk_nor_mem_ops
= {
};
static const struct of_device_id mtk_nor_match[] = {
- { .compatible = "mediatek,mt8173-nor" },
+ { .compatible = "mediatek,mt8192-nor", .data = (void *)36 },
+ { .compatible = "mediatek,mt8173-nor", .data = (void *)32 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_nor_match);
@@ -743,6 +754,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
void __iomem *base;
struct clk *spi_clk, *ctlr_clk;
int ret, irq;
+ unsigned long dma_bits;
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
@@ -756,6 +768,12 @@ static int mtk_nor_probe(struct platform_device *pdev)
if (IS_ERR(ctlr_clk))
return PTR_ERR(ctlr_clk);
+ dma_bits = (unsigned long)of_device_get_match_data(&pdev->dev);
+ if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(dma_bits))) {
+ dev_err(&pdev->dev, "failed to set dma mask(%lu)\n", dma_bits);
+ return -EINVAL;
+ }
+
ctlr = spi_alloc_master(&pdev->dev, sizeof(*sp));
if (!ctlr) {
dev_err(&pdev->dev, "failed to allocate spi controller\n");
@@ -781,6 +799,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
sp->dev = &pdev->dev;
sp->spi_clk = spi_clk;
sp->ctlr_clk = ctlr_clk;
+ sp->high_dma = (dma_bits > 32);
sp->buffer = dmam_alloc_coherent(&pdev->dev,
MTK_NOR_BOUNCE_BUF_SIZE + MTK_NOR_DMA_ALIGN,
&sp->buffer_dma, GFP_KERNEL);
--
2.28.0.806.g8561365e88-goog
Re: [PATCH v11 3/5] drivers/soc/litex: add LiteX SoC Controller driver
Hi Geert,
On Fri, Sep 25, 2020 at 3:16 PM Geert Uytterhoeven wrote:
>
> Hi Mateusz,
>
> On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> wrote:
> > From: Pawel Czarnecki
> >
> > This commit adds driver for the FPGA-based LiteX SoC
> > Controller from LiteX SoC builder.
> >
> > Co-developed-by: Mateusz Holenko
> > Signed-off-by: Mateusz Holenko
> > Signed-off-by: Pawel Czarnecki
>
> Thanks for your patch!
Thanks for your review!
> > --- /dev/null
> > +++ b/drivers/soc/litex/Kconfig
> > @@ -0,0 +1,15 @@
> > +# SPDX-License_Identifier: GPL-2.0
> > +
> > +menu "Enable LiteX SoC Builder specific drivers"
> > +
> > +config LITEX_SOC_CONTROLLER
> > + tristate "Enable LiteX SoC Controller driver"
> > + depends on OF || COMPILE_TEST
> > + help
> > + This option enables the SoC Controller Driver which verifies
> > + LiteX CSR access and provides common litex_get_reg/litex_set_reg
> > + accessors.
> > + All drivers that use functions from litex.h must depend on
> > + LITEX_SOC_CONTROLLER.
>
> I'm wondering if it makes sense to have them depend on a "simpler"
> symbol instead, e.g. LITEX?
>
> Currently the SoC controller is limited to I/O accessors and a simple
> register compatibility check, but you may want to extend it with more
> features later, so you probably want to keep the LITEX_SOC_CONTROLLER.
> Hence you could add
>
> config LITEX
> bool
>
> and let LITEX_SOC_CONTROLLER select LITEX.
But then if other drivers depend just on LITEX, it would not automatically
mean that the LITEX_SOC_CONTROLLER is selected, right?. And if it's not selected
litex_{g,s}et_reg() are not available and the compilation would fail.
I could move the implementation of those functions directly to the
litex.h header
and avoid this KConfig dependency, but I'm not sure if they are not
too big to become a static inline.
What do you think?
> > --- /dev/null
> > +++ b/drivers/soc/litex/litex_soc_ctrl.c
> > @@ -0,0 +1,194 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * LiteX SoC Controller Driver
> > + *
> > + * Copyright (C) 2020 Antmicro
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/*
> > + * The parameters below are true for LiteX SoC
>
> SoCs
Right, I will fix that.
> > + * configured for 8-bit CSR Bus, 32-bit aligned.
> > + *
> > + * Supporting other configurations will require
> > + * extending the logic in this header.
>
> This is no longer a header file.
It's not - you are correct. I will rephrase it to "extending the logic
in this file".
> > + */
> > +#define LITEX_REG_SIZE 0x4
> > +#define LITEX_SUBREG_SIZE 0x1
> > +#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8)
> > +
> > +static DEFINE_SPINLOCK(csr_lock);
> > +
> > +/*
> > + * LiteX SoC Generator, depending on the configuration,
> > + * can split a single logical CSR (Control & Status Register)
> > + * into a series of consecutive physical registers.
> > + *
> > + * For example, in the configuration with 8-bit CSR Bus,
> > + * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit
> > + * logical CSR will be generated as four 32-bit physical registers,
> > + * each one containing one byte of meaningful data.
> > + *
> > + * For details see: https://github.com/enjoy-digital/litex/wiki/CSR-Bus
> > + *
> > + * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
> > + * the logic of writing to/reading from the LiteX CSR in a single
> > + * place that can be then reused by all LiteX drivers.
> > + */
> > +void litex_set_reg(void __iomem *reg, unsigned long reg_size,
> > + unsigned long val)
> > +{
> > + unsigned long shifted_data, shift, i;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&csr_lock, flags);
> > +
> > + for (i = 0; i < reg_size; ++i) {
> > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
> > + shifted_data = val >> shift;
> > +
> > + writel((u32 __force)cpu_to_le32(shifted_data), reg +
> > (LITEX_REG_SIZE * i));
> > + }
> > +
> > + spin_unlock_irqrestore(&csr_lock, flags);
> > +}
> > +EXPORT_SYMBOL_GPL(litex_set_reg);
>
> I'm still wondering about the overhead of loops and multiple accesses,
> and the need for them (see also BenH's earlier comment).
> If e.g. the register widths change for LiteUART (currently they're
> hardcoded to one), would you still consider it using the same
> programming interface, and thus compatible with "litex,liteuart"?
Since the amount of possible `reg_size` is practically limited we could
add explicit 8/32/64/128 accessors to eliminate loops.
As for multiple writel/readl I don't really see an option to avoid
them for the 8-bit bus width.
> The spinlock access will probably become the source of lock contention
> later, especially when considering SMP
PHY reset question
Hello PHY experts,
Short version:
what is the proper way to handle the PHY reset before identifying PHY?
Long version:
I stumbled over following issue:
If PHY reset is registered within PHY node. Then, sometimes, we will not be
able to identify it (read PHY ID), because PHY is under reset.
mdio {
compatible = "virtual,mdio-gpio";
[...]
/* Microchip KSZ8081 */
usbeth_phy: ethernet-phy@3 {
reg = <0x3>;
interrupts-extended = <&gpio5 12 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
reset-assert-us = <500>;
reset-deassert-us = <1000>;
};
[...]
};
On simple boards with one PHY per MDIO bus, it is easy to workaround by using
phy-reset-gpios withing MAC node (illustrated in below DT example), instead of
using reset-gpios within PHY node (see above DT example).
&fec {
[...]
phy-mode = "rmii";
phy-reset-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
[...]
};
On boards with multiple PHYs (for example attached to a switch) and separate
reset lines to each PHY, it becomes more challenging. In my case, after power
cycle the system is working as expected:
- pinmux is configured to GPIO mode with internal pull-up
- GPIO is by default in input state. So the internal pull-up will automatically
dessert the PHY reset.
On reboot, the system will assert the reset. GPIO configuration will survive the
reboot and PHYs will stay in the reset state, and not detected by the system.
So far I have following options/workarounds:
- do all needed configurations in the bootloader.
Disadvantage:
- not clear at which init level it should be done?
1. Boot ROM script (in case of iMX). One fix per each board. Ease to forget.
2. Pre bootloader. Same as 1.
3. GPIO driver in the bootloader. What if some configuration was done in
1. or 2.?
- we will go back to the same problem if we jumped to Kexec
- Use compatible ("compatible = "ethernet-phy-id0022.1560") in the devicetree,
so that reading the PHYID is not needed
- easy to solve.
Disadvantage:
- losing PHY auto-detection capability
- need a new devicetree if different PHY is used (for example in different
board revision)
- modify PHY framework to deassert reset before identifying the PHY.
Disadvantages?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
WARNING in ieee80211_probe_client
Hello, syzbot found the following issue on: HEAD commit:c2568c8c Merge branch 'net-Constify-struct-genl_small_ops' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=14051a2b90 kernel config: https://syzkaller.appspot.com/x/.config?x=1e6c5266df853ae dashboard link: https://syzkaller.appspot.com/bug?extid=999fac712d84878a7379 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1776330b90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=171f17ff90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+999fac712d84878a7...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 6910 at net/mac80211/cfg.c:3620 ieee80211_probe_client+0x6ed/0x7f0 net/mac80211/cfg.c:3620 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 6910 Comm: syz-executor290 Not tainted 5.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x198/0x1fd lib/dump_stack.c:118 panic+0x382/0x7fb kernel/panic.c:231 __warn.cold+0x20/0x4b kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:ieee80211_probe_client+0x6ed/0x7f0 net/mac80211/cfg.c:3620 Code: f9 48 c7 c2 20 77 61 89 be 7b 02 00 00 48 c7 c7 80 77 61 89 c6 05 4c 44 80 03 01 e8 82 1a 85 f9 e9 e3 f9 ff ff e8 13 25 9f f9 <0f> 0b 41 bc ea ff ff ff e9 51 fe ff ff e8 91 e8 e0 f9 e9 de fc ff RSP: 0018:c900056e74f0 EFLAGS: 00010293 RAX: RBX: 88809371 RCX: 87d761d8 RDX: 888092e18280 RSI: 87d7629d RDI: 0005 RBP: 88809a47e020 R08: 0001 R09: 8d10d9e7 R10: R11: R12: 888089750c80 R13: R14: 0001 R15: rdev_probe_client net/wireless/rdev-ops.h:929 [inline] nl80211_probe_client+0x3b7/0xc80 net/wireless/nl80211.c:12734 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2489 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x442169 Code: e8 ac 00 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff7f75b898 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: RCX: 00442169 RDX: RSI: 22c0 RDI: 0004 RBP: 00306e616c77 R08: 0020 R09: 0020 R10: 0020 R11: 0246 R12: ee9b R13: R14: 000c R15: 0004 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
WARNING in sta_info_alloc
Hello,
syzbot found the following issue on:
HEAD commit:549738f1 Linux 5.9-rc8
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b97ba390
kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
dashboard link: https://syzkaller.appspot.com/bug?extid=45d7c243c006f39dc55a
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12bae9c050
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1099b1c050
The issue was bisected to:
commit 643c332d519bdfbf80d21f40d1c0aa0ccf3ec1cb
Author: Zi Shen Lim
Date: Thu Jun 9 04:18:50 2016 +
arm64: bpf: optimize LD_ABS, LD_IND
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d4447790
final oops: https://syzkaller.appspot.com/x/report.txt?x=13d4447790
console output: https://syzkaller.appspot.com/x/log.txt?x=15d4447790
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+45d7c243c006f39dc...@syzkaller.appspotmail.com
Fixes: 643c332d519b ("arm64: bpf: optimize LD_ABS, LD_IND")
[ cut here ]
WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447
ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline]
WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447
sta_info_alloc+0x1900/0x1f90 net/mac80211/sta_info.c:469
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 6879 Comm: syz-executor071 Not tainted 5.9.0-rc8-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x198/0x1fd lib/dump_stack.c:118
panic+0x382/0x7fb kernel/panic.c:231
__warn.cold+0x20/0x4b kernel/panic.c:600
report_bug+0x1bd/0x210 lib/bug.c:198
handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline]
RIP: 0010:sta_info_alloc+0x1900/0x1f90 net/mac80211/sta_info.c:469
Code: 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 04 00
00 49 8b 9f 60 01 00 00 e9 fc f6 ff ff e8 80 20 b6 f9 <0f> 0b e8 e9 62 66 00 31
ff 89 c3 89 c6 e8 ce 1c b6 f9 85 db 74 1d
RSP: 0018:c9000539f498 EFLAGS: 00010293
RAX: RBX: 0001 RCX: 87c01d61
RDX: 8880a91ec3c0 RSI: 87c01e10 RDI: 0005
RBP: 8880896e0c80 R08: 0001 R09: 8d0c29e7
R10: R11: R12:
R13: 8880896e31b0 R14: dc00 R15: 888092f06000
ieee80211_add_station+0x28c/0x660 net/mac80211/cfg.c:1586
rdev_add_station net/wireless/rdev-ops.h:190 [inline]
nl80211_new_station+0xde7/0x1440 net/wireless/nl80211.c:6294
genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731
netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:671
sys_sendmsg+0x6e8/0x810 net/socket.c:2353
___sys_sendmsg+0xf3/0x170 net/socket.c:2407
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441999
Code: e8 dc 05 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
7b 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffd9fa54bf8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: RCX: 00441999
RDX: RSI: 2040 RDI: 0005
RBP: 00306e616c77 R08: R09: 0020
R10: R11: 0246 R12: 0032
R13: R14: 000c R15: 0004
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
WARNING in ieee80211_check_rate_mask
Hello, syzbot found the following issue on: HEAD commit:c2568c8c Merge branch 'net-Constify-struct-genl_small_ops' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=16e2fb4d90 kernel config: https://syzkaller.appspot.com/x/.config?x=1e6c5266df853ae dashboard link: https://syzkaller.appspot.com/bug?extid=be0e03ca215b06199629 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1790e83b90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a5bc790 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+be0e03ca215b06199...@syzkaller.appspotmail.com netlink: 20 bytes leftover after parsing attributes in process `syz-executor823'. [ cut here ] WARNING: CPU: 1 PID: 6878 at net/mac80211/rate.c:281 ieee80211_check_rate_mask+0x1af/0x220 net/mac80211/rate.c:281 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 6878 Comm: syz-executor823 Not tainted 5.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x198/0x1fd lib/dump_stack.c:118 panic+0x382/0x7fb kernel/panic.c:231 __warn.cold+0x20/0x4b kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:ieee80211_check_rate_mask+0x1af/0x220 net/mac80211/rate.c:281 Code: 45 85 ff 0f 84 86 0c 00 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f e9 bf 8c a1 f9 e8 ba 8c a1 f9 0f 0b eb e4 e8 b1 8c a1 f9 <0f> 0b eb db e8 e8 4f e3 f9 e9 f6 fe ff ff 48 89 ef e8 db 4f e3 f9 RSP: 0018:c900055274b0 EFLAGS: 00010293 RAX: RBX: 88808a7d0c00 RCX: 87d4fa14 RDX: 888091b2e000 RSI: 87d4faff RDI: 0005 RBP: R08: 88808a7d1e58 R09: 888091b2e900 R10: R11: R12: R13: R14: 88808a7d0c00 R15: ieee80211_change_bss+0x53c/0xc20 net/mac80211/cfg.c:2314 rdev_change_bss net/wireless/rdev-ops.h:394 [inline] nl80211_set_bss+0x76c/0xc70 net/wireless/nl80211.c:7009 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2489 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4419c9 Code: e8 dc 05 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffdbf57fbe8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: RCX: 004419c9 RDX: RSI: 2140 RDI: 0004 RBP: 00306e616c77 R08: R09: 0020 R10: R11: 0246 R12: 0032 R13: R14: 000c R15: 0004 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v16 15/15] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
On 10/5/20 6:31 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Since this flash doesn't have a Profile 1.0 table, the Octal DTR
> capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
> fast read settings.
>
> Enable Octal DTR mode with 20 dummy cycles to allow running at the
> maximum supported frequency of 200Mhz.
>
> The flash supports the soft reset sequence. So, add the flag in the
> flash's info.
>
> Signed-off-by: Pratyush Yadav
Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/micron-st.c | 115 +++-
> 1 file changed, 114 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
> index ef3695080710..c224e59820a1 100644
> --- a/drivers/mtd/spi-nor/micron-st.c
> +++ b/drivers/mtd/spi-nor/micron-st.c
> @@ -8,10 +8,123 @@
>
> #include "core.h"
>
> +#define SPINOR_OP_MT_DTR_RD0xfd/* Fast Read opcode in DTR mode */
> +#define SPINOR_OP_MT_RD_ANY_REG0x85/* Read volatile register */
> +#define SPINOR_OP_MT_WR_ANY_REG0x81/* Write volatile register */
> +#define SPINOR_REG_MT_CFR0V0x00/* For setting octal DTR mode */
> +#define SPINOR_REG_MT_CFR1V0x01/* For setting dummy cycles */
> +#define SPINOR_MT_OCT_DTR 0xe7/* Enable Octal DTR. */
> +#define SPINOR_MT_EXSPI0xff/* Enable Extended SPI
> (default) */
> +
> +static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
> +{
> + struct spi_mem_op op;
> + u8 *buf = nor->bouncebuf;
> + int ret;
> +
> + if (enable) {
> + /* Use 20 dummy cycles for memory array reads. */
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + *buf = 20;
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
> + SPI_MEM_OP_ADDR(3, SPINOR_REG_MT_CFR1V, 1),
> + SPI_MEM_OP_NO_DUMMY,
> + SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + ret = spi_mem_exec_op(nor->spimem, &op);
> + if (ret)
> + return ret;
> +
> + ret = spi_nor_wait_till_ready(nor);
> + if (ret)
> + return ret;
> + }
> +
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + if (enable)
> + *buf = SPINOR_MT_OCT_DTR;
> + else
> + *buf = SPINOR_MT_EXSPI;
> +
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
> + SPI_MEM_OP_ADDR(enable ? 3 : 4,
> + SPINOR_REG_MT_CFR0V, 1),
> + SPI_MEM_OP_NO_DUMMY,
> + SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + if (!enable)
> + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> +
> + ret = spi_mem_exec_op(nor->spimem, &op);
> + if (ret)
> + return ret;
> +
> + /* Read flash ID to make sure the switch was successful. */
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1),
> + SPI_MEM_OP_NO_ADDR,
> + SPI_MEM_OP_DUMMY(enable ? 8 : 0, 1),
> + SPI_MEM_OP_DATA_IN(round_up(nor->info->id_len, 2),
> + buf, 1));
> +
> + if (enable)
> + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> +
> + ret = spi_mem_exec_op(nor->spimem, &op);
> + if (ret)
> + return ret;
> +
> + if (memcmp(buf, nor->info->id, nor->info->id_len))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static void mt35xu512aba_default_init(struct spi_nor *nor)
> +{
> + nor->params->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
> +}
> +
> +static void mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor)
> +{
> + /* Set the Fast Read settings. */
> + nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
> +
> spi_nor_set_read_settings(&nor->params->reads[SNOR_CMD_READ_8_8_8_DTR],
> + 0, 20, SPINOR_OP_MT_DTR_RD,
> + SNOR_PROTO_8_8_8_DTR);
> +
> + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> + nor->params->rdsr_dummy = 8;
> + nor->params->rdsr_addr_nbytes = 0;
> +
> + /*
> +* The BFPT quad enable field is set to a reserved value so the quad
> +* enable function is ignored by spi_nor_parse_bfpt(). Make sure we
> +* disable it.
> +*/
> + nor->params->quad_enable = NULL;
> +}
Re: [PATCH 2/2] ath11k: Handle errors if peer creation fails
On Tue, Oct 06, 2020 at 10:26:28AM +0300, Kalle Valo wrote:
> Alex Dewar writes:
>
> > ath11k_peer_create() is called without its return value being checked,
> > meaning errors will be unhandled. Add missing check and, as the mutex is
> > unconditionally unlocked on leaving this function, simplify the exit
> > path.
> >
> > Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
> > Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
> > Signed-off-by: Alex Dewar
> > ---
> > drivers/net/wireless/ath/ath11k/mac.c | 21 +
> > 1 file changed, 9 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath11k/mac.c
> > b/drivers/net/wireless/ath/ath11k/mac.c
> > index 7f8dd47d2333..58db1b57b941 100644
> > --- a/drivers/net/wireless/ath/ath11k/mac.c
> > +++ b/drivers/net/wireless/ath/ath11k/mac.c
> > @@ -5211,7 +5211,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
> > *hw,
> > struct ath11k *ar = hw->priv;
> > struct ath11k_base *ab = ar->ab;
> > struct ath11k_vif *arvif = (void *)vif->drv_priv;
> > - int ret;
> > + int ret = 0;
>
> I prefer not to initialise the ret variable.
>
> > arvif->is_started = true;
> >
> > /* TODO: Setup ps and cts/rts protection */
> >
> > - mutex_unlock(&ar->conf_mutex);
> > -
> > - return 0;
> > -
> > -err:
> > +unlock:
> > mutex_unlock(&ar->conf_mutex);
> >
> > return ret;
>
> So in the pending branch I changed this to:
>
> ret = 0;
>
> out:
> mutex_unlock(&ar->conf_mutex);
>
> return ret;
>
> Please check.
Hi Kalle,
I'm afraid you've introduced a bug ;). The body of the first if-statement
in the function doesn't set ret because no error has occurred. So now
it'll jump to the label and the function will return ret uninitialized.
With the gcc extension, ret will be initialised to zero anyway, so we're
not saving anything by explicitly assigning to ret later in the
function.
Best,
Alex
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v6 03/11] device-dax/kmem: move resource tracking to drvdata
On 06.10.20 08:55, Dan Williams wrote: > Towards removing the mode specific @dax_kmem_res attribute from the > generic 'struct dev_dax', and preparing for multi-range support, move > resource tracking to driver data. The memory for the resource name > needs to have its own lifetime separate from the device bind lifetime > for cases where the driver is unbound, but the kmem range could not be > unplugged from the page allocator. > > The resource reservation also needs to be released manually via > release_resource() given the awkward manipulation of the > IORESOURCE_BUSY flag. > > Cc: David Hildenbrand > Cc: Vishal Verma > Cc: Dave Hansen > Cc: Pavel Tatashin > Cc: Brice Goglin > Cc: Dave Jiang > Cc: David Hildenbrand > Cc: Ira Weiny > Cc: Jia He > Cc: Joao Martins > Cc: Jonathan Cameron > Signed-off-by: Dan Williams Reviewed-by: David Hildenbrand Thanks! -- Thanks, David / dhildenb
Re: [PATCH 0/2] Enable GPIO and I2C configs for TI's J721e platform
Nishanth, On 02/10/20 10:32 pm, Nishanth Menon wrote: > On 22:15-20201002, Faiz Abbas wrote: >> The following patches enable configs in the arm64 defconfig to support >> GPIO and I2C support on TI's J721e platform. >> >> Faiz Abbas (2): >> arm64: defconfig: Enable OMAP I2C driver >> arm64: defconfig: Enable DAVINCI_GPIO driver >> >> arch/arm64/configs/defconfig | 2 ++ >> 1 file changed, 2 insertions(+) > > > Could we do an audit and make sure nothing else is missing - Say ALSA / > DRM or something else? I'm not aware of anything that might be missing. That said, I am not aware of every single config in every subsystem. IMO the various driver owners should be responsible for adding their configs to defconfig. > > And I don't really see the need to split these into individual patches, > maybe, take a hint from [1] > > > [1] > https://lore.kernel.org/linux-arm-kernel/20200630171500.11438-1-geert+rene...@glider.be/ > Sounds good. I'll squash into a single patch and repost. Thanks, Faiz
Re: WARNING in sta_info_alloc
On Tue, Oct 06, 2020 at 01:08:23AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:549738f1 Linux 5.9-rc8
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b97ba390
> kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
> dashboard link: https://syzkaller.appspot.com/bug?extid=45d7c243c006f39dc55a
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12bae9c050
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1099b1c050
>
> The issue was bisected to:
>
> commit 643c332d519bdfbf80d21f40d1c0aa0ccf3ec1cb
> Author: Zi Shen Lim
> Date: Thu Jun 9 04:18:50 2016 +
>
> arm64: bpf: optimize LD_ABS, LD_IND
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d4447790
> final oops: https://syzkaller.appspot.com/x/report.txt?x=13d4447790
> console output: https://syzkaller.appspot.com/x/log.txt?x=15d4447790
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+45d7c243c006f39dc...@syzkaller.appspotmail.com
> Fixes: 643c332d519b ("arm64: bpf: optimize LD_ABS, LD_IND")
>
> [ cut here ]
> WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447
> ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline]
> WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447
> sta_info_alloc+0x1900/0x1f90 net/mac80211/sta_info.c:469
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 6879 Comm: syz-executor071 Not tainted 5.9.0-rc8-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x198/0x1fd lib/dump_stack.c:118
> panic+0x382/0x7fb kernel/panic.c:231
> __warn.cold+0x20/0x4b kernel/panic.c:600
> report_bug+0x1bd/0x210 lib/bug.c:198
> handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
> exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
> asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
> RIP: 0010:ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline]
The patch fingered by the bisection only affects arm64, but this is an x86
box. So this is clearly bogus.
Will
[PATCH 2/2] media: staging: atomisp: Removed else branch in function
This patch fixes the checkpatch.pl warning :
WARNING: else is not generally useful after a break or return
Expressions under 'else' branch in function 'gc0310_s_power' are
executed whenever the exppression in 'if' is False. Otherwise, return
from function occurs. Therefore, there is no need in 'else', and it has
been removed.
Signed-off-by: Leonid Kushnir
---
drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
index 6be3ee1d93a5..8201c15b5769 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
@@ -874,11 +874,10 @@ static int gc0310_s_power(struct v4l2_subdev *sd, int on)
if (on == 0)
return power_down(sd);
- else {
- ret = power_up(sd);
- if (!ret)
- return gc0310_init(sd);
- }
+ ret = power_up(sd);
+ if (!ret)
+ return gc0310_init(sd);
+
return ret;
}
--
2.25.1
BUG: unable to handle kernel paging request in cfb_imageblit
Hello, syzbot found the following issue on: HEAD commit:22fbc037 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=133731eb90 kernel config: https://syzkaller.appspot.com/x/.config?x=4e672827d2ffab1f dashboard link: https://syzkaller.appspot.com/bug?extid=dfd0b1c6705301cc4847 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11ba9a5d90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17cfd4af90 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1536a75050 final oops: https://syzkaller.appspot.com/x/report.txt?x=1736a75050 console output: https://syzkaller.appspot.com/x/log.txt?x=1336a75050 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+dfd0b1c6705301cc4...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: 88800118 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD c801067 P4D c801067 PUD c802067 PMD 810001e1 Oops: 0003 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8241 Comm: syz-executor265 Not tainted 5.9.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__writel arch/x86/include/asm/io.h:71 [inline] RIP: 0010:slow_imageblit drivers/video/fbdev/core/cfbimgblt.c:178 [inline] RIP: 0010:cfb_imageblit+0xb15/0x11e0 drivers/video/fbdev/core/cfbimgblt.c:302 Code: 89 e6 89 e9 41 d3 e6 41 09 de 89 ef 8b 5c 24 28 89 de e8 0e db 81 fd 39 dd 73 0a e8 65 d9 81 fd eb 42 0f 1f 00 48 8b 44 24 30 <44> 89 30 48 83 c0 04 48 89 44 24 30 89 ef 89 de e8 e6 da 81 fd 39 RSP: 0018:c9000a037558 EFLAGS: 00010246 RAX: 88800118 RBX: 001c RCX: 001c RDX: 8880a79880c0 RSI: 001c RDI: 001c RBP: 001c R08: 83f32412 R09: 83f31b7c R10: 0002 R11: 8880a79880c0 R12: R13: 888218a81f72 R14: R15: FS: 7f8534532700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 88800118 CR3: a80b4000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: soft_cursor+0xb44/0xdb0 drivers/video/fbdev/core/softcursor.c:74 bit_cursor+0x1753/0x2110 drivers/video/fbdev/core/bitblit.c:377 set_cursor drivers/tty/vt/vt.c:919 [inline] con_flush_chars+0x4e1/0x640 drivers/tty/vt/vt.c:3330 con_write+0x2a/0x40 drivers/tty/vt/vt.c:3251 do_output_char+0x63b/0x940 drivers/tty/n_tty.c:447 __process_echoes+0x2a3/0x930 drivers/tty/n_tty.c:739 flush_echoes drivers/tty/n_tty.c:829 [inline] __receive_buf drivers/tty/n_tty.c:1648 [inline] n_tty_receive_buf_common+0x29fa/0x3100 drivers/tty/n_tty.c:1742 paste_selection+0x32c/0x450 drivers/tty/vt/selection.c:408 vt_ioctl+0x105a/0x3d70 drivers/tty/vt/vt_ioctl.c:862 tty_ioctl+0xee4/0x15c0 drivers/tty/tty_io.c:2656 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x449809 Code: e8 8c e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 05 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f8534531db8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 006dec68 RCX: 00449809 RDX: 2080 RSI: 541c RDI: 0007 RBP: 006dec60 R08: R09: R10: R11: 0246 R12: 006dec6c R13: 7ffe8074321f R14: 7f85345329c0 R15: 0064 Modules linked in: CR2: 88800118 ---[ end trace 4ec628432d38a26a ]--- RIP: 0010:__writel arch/x86/include/asm/io.h:71 [inline] RIP: 0010:slow_imageblit drivers/video/fbdev/core/cfbimgblt.c:178 [inline] RIP: 0010:cfb_imageblit+0xb15/0x11e0 drivers/video/fbdev/core/cfbimgblt.c:302 Code: 89 e6 89 e9 41 d3 e6 41 09 de 89 ef 8b 5c 24 28 89 de e8 0e db 81 fd 39 dd 73 0a e8 65 d9 81 fd eb 42 0f 1f 00 48 8b 44 24 30 <44> 89 30 48 83 c0 04 48 89 44 24 30 89 ef 89 de e8 e6 da 81 fd 39 RSP: 0018:c9000a037558 EFLAGS: 00010246 RAX: 88800118 RBX: 001c RCX: 001c RDX: 8880a79880c0 RSI: 001c RDI: 001c RBP: 001c R08: 83f32412 R09: 83f31b7c R10: 0002 R11: 8880a79880c0 R12: R13: 888218a81f72 R14:
INFO: task hung in hub_port_init
Hello,
syzbot found the following issue on:
HEAD commit:d3d45f82 Merge tag 'pinctrl-v5.9-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14c3b3db90
kernel config: https://syzkaller.appspot.com/x/.config?x=89ab6a0c48f30b49
dashboard link: https://syzkaller.appspot.com/bug?extid=74d6ef051d3d2eacf428
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=153bf5bd90
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124c92af90
The issue was bisected to:
commit 6dcf45e514974a1ff10755015b5e06746a033e5f
Author: Niklas Söderlund
Date: Mon Jan 9 15:34:04 2017 +
sh_eth: use correct name for ECMR_MPDE bit
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152bb76050
final oops: https://syzkaller.appspot.com/x/report.txt?x=172bb76050
console output: https://syzkaller.appspot.com/x/log.txt?x=132bb76050
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+74d6ef051d3d2eacf...@syzkaller.appspotmail.com
Fixes: 6dcf45e51497 ("sh_eth: use correct name for ECMR_MPDE bit")
INFO: task kworker/0:0:5 blocked for more than 143 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/0:0 state:D stack:27664 pid:5 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
hub_port_init+0x11ae/0x2d80 drivers/usb/core/hub.c:4689
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/0x3e60 drivers/usb/core/hub.c:5576
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
process_scheduled_works kernel/workqueue.c:2331 [inline]
worker_thread+0x82b/0x1120 kernel/workqueue.c:2417
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task kworker/1:2:2641 blocked for more than 144 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:2 state:D stack:26992 pid: 2641 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
usb_get_descriptor+0xc5/0x1b0 drivers/usb/core/message.c:655
usb_get_device_descriptor+0x81/0xf0 drivers/usb/core/message.c:927
hub_port_init+0x78f/0x2d80 drivers/usb/core/hub.c:4784
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/0x3e60 drivers/usb/core/hub.c:5576
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task kworker/1:1:6862 blocked for more than 146 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:1 state:D stack:26864 pid: 6862 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
hub_port_init+0x11ae/0x2d80 drivers/usb/core/hub.c:4689
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/0x3e60 drivers/usb/core/hub.c:5576
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.
INFO: task hung in usb_get_descriptor
Hello,
syzbot found the following issue on:
HEAD commit:d3d45f82 Merge tag 'pinctrl-v5.9-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1318aab790
kernel config: https://syzkaller.appspot.com/x/.config?x=89ab6a0c48f30b49
dashboard link: https://syzkaller.appspot.com/bug?extid=31ae6d17d115e980fd14
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17c69eeb90
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17bebadb90
The issue was bisected to:
commit c0303efeab7391ec51c337e0ac5740860ad01fe7
Author: Jesper Dangaard Brouer
Date: Mon Jan 9 15:04:09 2017 +
net: reduce cycles spend on ICMP replies that gets rate limited
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=146872af90
final oops: https://syzkaller.appspot.com/x/report.txt?x=166872af90
console output: https://syzkaller.appspot.com/x/log.txt?x=126872af90
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+31ae6d17d115e980f...@syzkaller.appspotmail.com
Fixes: c0303efeab73 ("net: reduce cycles spend on ICMP replies that gets rate
limited")
INFO: task kworker/0:0:5 blocked for more than 143 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/0:0 state:D stack:27376 pid:5 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
usb_get_descriptor+0xc5/0x1b0 drivers/usb/core/message.c:655
usb_get_device_descriptor+0x81/0xf0 drivers/usb/core/message.c:927
hub_port_init+0x78f/0x2d80 drivers/usb/core/hub.c:4784
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/0x3e60 drivers/usb/core/hub.c:5576
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
process_scheduled_works kernel/workqueue.c:2331 [inline]
worker_thread+0x82b/0x1120 kernel/workqueue.c:2417
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task kworker/0:2:2474 blocked for more than 144 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/0:2 state:D stack:27416 pid: 2474 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
usb_get_descriptor+0xc5/0x1b0 drivers/usb/core/message.c:655
usb_get_device_descriptor+0x81/0xf0 drivers/usb/core/message.c:927
hub_port_init+0x78f/0x2d80 drivers/usb/core/hub.c:4784
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/0x3e60 drivers/usb/core/hub.c:5576
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task kworker/1:2:2597 blocked for more than 145 seconds.
Not tainted 5.9.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:2 state:D stack:26824 pid: 2597 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0xec9/0x2280 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
usb_kill_urb.part.0+0x197/0x220 drivers/usb/core/urb.c:696
usb_kill_urb+0x7c/0x90 drivers/usb/core/urb.c:691
usb_start_wait_urb+0x24a/0x2b0 drivers/usb/core/message.c:64
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
hub_port_init+0x11ae/0x2d80 drivers/usb/core/hub.c:4689
hub_port_connect drivers/usb/core/hub.c:5140 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x1e64/
[PATCH v2 0/2] dt-bindings: Document tpu, pwm support for R8A7742
Hi All, This patches are part of series [1], where patch 1/2 was missed to be applied before YAML conversation and patch 2/2 was never applied. I have restored the Acks for patch 1/2 and patch 2/2 is unchanged. [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=329853 Cheers, Prabhakar Lad Prabhakar (2): dt-bindings: pwm: renesas,tpu-pwm: Document r8a7742 support dt-bindings: pwm: renesas,pwm-rcar: Add r8a7742 support Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 1 + Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 1 + 2 files changed, 2 insertions(+) -- 2.17.1
[PATCH v2 1/2] dt-bindings: pwm: renesas,tpu-pwm: Document r8a7742 support
Document r8a7742 specific compatible strings. No driver change is needed as the fallback compatible string "renesas,tpu" activates the right code in the driver. Signed-off-by: Lad Prabhakar Reviewed-by: Marian-Cristian Rotariu Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring --- Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index 4bf62a3d5bba..aa9a4570c906 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -15,6 +15,7 @@ properties: - enum: - renesas,tpu-r8a73a4 # R-Mobile APE6 - renesas,tpu-r8a7740 # R-Mobile A1 + - renesas,tpu-r8a7742 # RZ/G1H - renesas,tpu-r8a7743 # RZ/G1M - renesas,tpu-r8a7744 # RZ/G1N - renesas,tpu-r8a7745 # RZ/G1E -- 2.17.1
[PATCH v2 2/2] dt-bindings: pwm: renesas,pwm-rcar: Add r8a7742 support
Document RZ/G1H (R8A7742) SoC bindings. Signed-off-by: Lad Prabhakar Reviewed-by: Marian-Cristian Rotariu Acked-by: Uwe Kleine-König Reviewed-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Acked-by: Rob Herring --- Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 5407c11e92a4..3c2fa2e93d1b 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - renesas,pwm-r8a7742 # RZ/G1H - renesas,pwm-r8a7743 # RZ/G1M - renesas,pwm-r8a7744 # RZ/G1N - renesas,pwm-r8a7745 # RZ/G1E -- 2.17.1
Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
On 05/10/2020 19:38, Rob Herring wrote: In order to add meta-schema checks for additional/unevaluatedProperties being present, all schema need to make this explicit. As common/shared schema are included by other schemas, they should always allow for additionalProperties. Signed-off-by: Rob Herring Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 ++ Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 ++ for nvmem parts, Acked-by: Srinivas Kandagatla thanks, srini
[gustavoars-linux:testing/drm/amd/pm/phm] BUILD SUCCESS c43a9eea7b3f51236a4dccc448f636500e3704d9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git testing/drm/amd/pm/phm branch HEAD: c43a9eea7b3f51236a4dccc448f636500e3704d9 drm/amd/pm: Replace one-element array with flexible-array member elapsed time: 725m configs tested: 97 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 armqcom_defconfig sh j2_defconfig mips rs90_defconfig arm exynos_defconfig mips ath79_defconfig arm pxa168_defconfig mips ci20_defconfig powerpc mpc8272_ads_defconfig armmagician_defconfig alpha defconfig arm lpc32xx_defconfig shapsh4ad0a_defconfig mipsvocore2_defconfig c6xevmc6474_defconfig openriscor1ksim_defconfig sh lboxre2_defconfig sh se7722_defconfig sh secureedge5410_defconfig m68km5272c3_defconfig powerpc mpc85xx_cds_defconfig ia64 allmodconfig mipsjmr3927_defconfig arm vf610m4_defconfig mips ath25_defconfig powerpc canyonlands_defconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig 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-a006-20201005 i386 randconfig-a005-20201005 i386 randconfig-a001-20201005 i386 randconfig-a004-20201005 i386 randconfig-a003-20201005 i386 randconfig-a002-20201005 x86_64 randconfig-a012-20201005 x86_64 randconfig-a015-20201005 x86_64 randconfig-a014-20201005 x86_64 randconfig-a013-20201005 x86_64 randconfig-a011-20201005 x86_64 randconfig-a016-20201005 i386 randconfig-a014-20201005 i386 randconfig-a015-20201005 i386 randconfig-a013-20201005 i386 randconfig-a016-20201005 i386 randconfig-a011-20201005 i386 randconfig-a012-20201005 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201005 x86_64 randconfig-a002-20201005 x86_64 randconfig-a001-20201005 x86_64 randconfig-a003-20201005 x86_64 randconfig-a005-20201005 x86_64 randconfig-a006-20201005 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@list
Re: [PATCH v4 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags
Em Mon, 5 Oct 2020 12:08:23 -0700 Eric Biggers escreveu: > On Mon, Oct 05, 2020 at 02:06:22PM +0200, Mauro Carvalho Chehab wrote: > > The latest version at: > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=sphinx3-fixes-v4 > > Doesn't work either. > > $ git remote add mchehab https://git.linuxtv.org/mchehab/experimental.git > $ git fetch mchehab > warning: alternate disabled by http.followRedirects: > https://git.linuxtv.org/git/linux.git/ > warning: alternate disabled by http.followRedirects: > https://git.linuxtv.org/git/media_tree.git/ > warning: alternate disabled by http.followRedirects: > https://git.linuxtv.org/git/linux.git/ > error: Unable to find 4d9f4b7b8bf7af2d8deb4435833a7e165b9bdd21 under > https://git.linuxtv.org/mchehab/experimental.git > Fetching objects: 286, done. > Cannot obtain needed object 4d9f4b7b8bf7af2d8deb4435833a7e165b9bdd21 > while processing commit 0a0cde580853340e1a585a1959eaaf055b7cff9a. > error: fetch failed. Well, support for https was broken at linuxtv.org. Not many media developers use https instead of git. The main issue is that we heavily use alternates there, in order to minimize disk space usage. After some server upgrade, https stopped working properly. I just fixed it, by adding some new rewrite rules that will call git http-backend in order to solve alternates. Thanks for reporting it. > > In the specific case of fscript.rst, there are only two patches on my > > series affecting it, both as part of this /52 series: > > But those two patches don't apply because they also change other files. > > I need to apply patches to do a proper review. Reviewers shouldn't have to > waste time trying to figure out how to apply your patches. Yeah, agreed. Sorry for that. Not sure what would be the best way to minimize the issues, though. I mean, I might place those documentation patches on my linux-next branch, making them visible at tomorrow's linux-next, but that doesn't sound a good idea, as this will be a source of conflicts, since several patches from my tree are based on patches applied via someone's else's tree. Hopefully, after getting this series merged upstream, the docs build for html will finally went into a clean state. Any new warnings that might sleep though maintainer's reviews could easily be fixed without depending on a 100+ patch series. - Btw, there was no new linux-next tag yesterday. The last one is still next-20201002. I'll wait for a while a today's linux-next. After rebasing on the top of that, I'll submit a v5 of this series. Thanks, Mauro
RE: [PATCH v3 1/2] exfat: add exfat_update_inode()
> @@ -1352,19 +1340,13 @@ static int exfat_rename(struct inode *old_dir, struct > dentry *old_dentry, > new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime = > EXFAT_I(new_dir)->i_crtime = current_time(new_dir); > exfat_truncate_atime(&new_dir->i_atime); > - if (IS_DIRSYNC(new_dir)) > - exfat_sync_inode(new_dir); > - else > - mark_inode_dirty(new_dir); > + exfat_update_inode(new_dir); > > i_pos = ((loff_t)EXFAT_I(old_inode)->dir.dir << 32) | > (EXFAT_I(old_inode)->entry & 0x); > exfat_unhash_inode(old_inode); > exfat_hash_inode(old_inode, i_pos); > - if (IS_DIRSYNC(new_dir)) > - exfat_sync_inode(old_inode); > - else > - mark_inode_dirty(old_inode); > + exfat_update_inode(old_inode); This is checking if old_inode is IS_DIRSYNC, not new_dir. Is there any reason ?
Re: [PATCH 5.4 00/57] 5.4.70-rc1 review
On Tue, 6 Oct 2020 at 11:24, Naresh Kamboju wrote: > > On Mon, 5 Oct 2020 at 20:59, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.4.70 release. > > There are 57 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed, 07 Oct 2020 14:20:55 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.70-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.4.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Tested-by: Linux Kernel Functional Testing NOTE: While running LTP containers test suite, I noticed this kernel panic on arm64 Juno-r2 devices. Not easily reproducible and not seen on any other arm64 devices. steps to reproduce: --- # boot stable rc 5.4.70 kernel on juno-r2 machine # cd /opt/ltp # ./runltp -f containers Crash log, --- pidns13 0 TINFO : cinit2: writing some data in pipe pidns13 0 TINFO : cinit1: setup handler for async I/O on pipe pidns13 1 TPASS : cinit1: si_fd is 6, si_code is 1 [ 122.275627] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 122.283139] Modules linked in: tda998x drm_kms_helper drm crct10dif_ce fuse [ 122.290130] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.70-rc1 #1 [ 122.296406] Hardware name: ARM Juno development board (r2) (DT) [ 122.302337] pstate: 8085 (Nzcv daIf -PAN -UAO) [ 122.307144] pc : sil24_interrupt+0x28/0x5f0 [ 122.311337] lr : __handle_irq_event_percpu+0x78/0x2c0 [ 122.316395] sp : 800010003db0 [ 122.319712] x29: 800010003db0 x28: 800011f73d80 [ 122.325034] x27: 800011962018 x26: 000954a82000 [ 122.330357] x25: 800011962018 x24: 800011f6a158 [ 122.335679] x23: 800010003ef4 x22: 00097574 [ 122.341001] x21: 0033 x20: 80001233d044 [ 122.346324] x19: 000975742500 x18: [ 122.351646] x17: x16: [ 122.356967] x15: x14: 003d0900 [ 122.362290] x13: 3d09 x12: [ 122.367612] x11: 3d09 x10: 0040 [ 122.372934] x9 : 800011f89b68 x8 : 800011f89b60 [ 122.378256] x7 : 000975800408 x6 : [ 122.383578] x5 : 000975800248 x4 : 80096d5ba000 [ 122.388900] x3 : 800010003f30 x2 : 80001093a078 [ 122.394222] x1 : 00097574 x0 : 00097574df80 [ 122.399545] Call trace: [ 122.401995] sil24_interrupt+0x28/0x5f0 [ 122.405838] __handle_irq_event_percpu+0x78/0x2c0 [ 122.410550] handle_irq_event_percpu+0x3c/0x98 [ 122.415002] handle_irq_event+0x4c/0xe8 [ 122.418844] handle_fasteoi_irq+0xbc/0x168 [ 122.422947] generic_handle_irq+0x34/0x50 [ 122.426963] __handle_domain_irq+0x6c/0xc0 [ 122.431066] gic_handle_irq+0x58/0xb0 [ 122.434733] el1_irq+0xbc/0x180 [ 122.437880] cpuidle_enter_state+0xb8/0x528 [ 122.442070] cpuidle_enter+0x3c/0x50 [ 122.445652] call_cpuidle+0x40/0x78 [ 122.449146] do_idle+0x1f0/0x2a0 [ 122.452379] cpu_startup_entry+0x2c/0x88 [ 122.456311] rest_init+0xdc/0xe8 [ 122.459545] arch_call_rest_init+0x14/0x1c [ 122.463647] start_kernel+0x484/0x4b8 [ 122.467321] Code: d503201f f9400ac0 f9400014 91011294 (b9400294) [ 122.473437] ---[ end trace 68b3da9e48a77548 ]--- [ 122.478062] Kernel panic - not syncing: Fatal exception in interrupt [ 122.484429] SMP: stopping secondary CPUs [ 122.488569] Kernel Offset: disabled [ 122.492062] CPU features: 0x0002,24006004 [ 122.496074] Memory Limit: none [ 122.499141] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Reported-by: Naresh Kamboju Full test log, https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.69-58-g7b199c4db17f/testrun/3273934/suite/linux-log-parser/test/check-kernel-panic-1818664/log - Naresh
Re: [RFC PATCH v2 00/30] 1GB PUD THP support on x86_64
On 05.10.20 21:11, Roman Gushchin wrote: > On Mon, Oct 05, 2020 at 08:33:44PM +0200, David Hildenbrand wrote: >> On 05.10.20 20:25, Roman Gushchin wrote: >>> On Mon, Oct 05, 2020 at 07:27:47PM +0200, David Hildenbrand wrote: On 05.10.20 19:16, Roman Gushchin wrote: > On Mon, Oct 05, 2020 at 11:03:56AM -0400, Zi Yan wrote: >> On 2 Oct 2020, at 4:30, David Hildenbrand wrote: >> >>> On 02.10.20 10:10, Michal Hocko wrote: On Fri 02-10-20 09:50:02, David Hildenbrand wrote: - huge page sizes controllable by the userspace? >>> >>> It might be good to allow advanced users to choose the page sizes, >>> so they >>> have better control of their applications. >> >> Could you elaborate more? Those advanced users can use hugetlb, >> right? >> They get a very good control over page size and pool preallocation >> etc. >> So they can get what they need - assuming there is enough memory. >> > > I am still not convinced that 1G THP (TGP :) ) are really what we want > to support. I can understand that there are some use cases that might > benefit from it, especially: Well, I would say that internal support for larger huge pages (e.g. 1GB) that can transparently split under memory pressure is a useful funtionality. I cannot really judge how complex that would be >>> >>> Right, but that's then something different than serving (scarce, >>> unmovable) gigantic pages from CMA / reserved hugetlbfs pool. Nothing >>> wrong about *real* THP support, meaning, e.g., grouping consecutive >>> pages and converting them back and forth on demand. (E.g., 1GB -> >>> multiple 2MB -> multiple single pages), for example, when having to >>> migrate such a gigantic page. But that's very different from our >>> existing gigantic page code as far as I can tell. >> >> Serving 1GB PUD THPs from CMA is a compromise, since we do not want to >> bump MAX_ORDER to 20 to enable 1GB page allocation in buddy allocator, >> which needs section size increase. In addition, unmoveable pages cannot >> be allocated in CMA, so allocating 1GB pages has much higher chance from >> it than from ZONE_NORMAL. > > s/higher chances/non-zero chances Well, the longer the system runs (and consumes a significant amount of available main memory), the less likely it is. > > Currently we have nothing that prevents the fragmentation of the memory > with unmovable pages on the 1GB scale. It means that in a common case > it's highly unlikely to find a continuous GB without any unmovable page. > As now CMA seems to be the only working option. > And I completely dislike the use of CMA in this context (for example, allocating via CMA and freeing via the buddy by patching CMA when splitting up PUDs ...). > However it seems there are other use cases for the allocation of > continuous > 1GB pages: e.g. secretfd ( > https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_831628_&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=mdcwiGna7gQ4-RC_9XdaxFZ271PEQ09M0YtCcRoCkf8&s=4KlK2p0AVh1QdL8XDVeWyXPz4F63pdbbSCoxQlkNaa4&e= > ), where using > 1GB pages can reduce the fragmentation of the direct mapping. Yes, see RFC v1 where I already cced Mike. > > So I wonder if we need a new mechanism to avoid fragmentation on 1GB/PUD > scale. > E.g. something like a second level of pageblocks. That would allow to > group > all unmovable memory in few 1GB blocks and have more 1GB regions > available for > gigantic THPs and other use cases. I'm looking now into how it can be > done. Anything bigger than sections is somewhat problematic: you have to track that data somewhere. It cannot be the section (in contrast to pageblocks) >>> >>> Well, it's not a large amount of data: the number of 1GB regions is not that >>> high even on very large machines. >> >> Yes, but then you can have very sparse systems. And some use cases would >> actually want to avoid fragmentation on smaller levels (e.g., 128MB) - >> optimizing memory efficiency by turning off banks and such ... > > It's a definitely a good question. Oh, and I forgot that there might be users that want bigger granularity :) (primarily, memory hotunplug that wants to avoid ZONE_MOVABLE but still have higher chances to eventually unplug some memory) > >>> > If anybody has any ideas here, I'll appreciate a lot. I already brought up the idea of ZONE_PREFER_MOVABLE (see RFC v1). That somewhat mimics what CMA does (when sized reasonably), works well with memory hot(un)plug, and is immune to misconfiguration. Within such a zone, we can try to optimize the placement of larg
Re: [PATCH 0/4] dt-bindings: additional/unevaluatedProperties clean-ups
On 05/10/2020 19:38, Rob Herring wrote: The default behavior for json-schema is any unknown property is allowed. T hat is generally not the behavior we want for DT. In order to disallow extra properties, schemas need to define 'additionalProperties: false' typically. Ideally, we'd just add that automatically with the tools, but there are some exceptions so only making things explicit everywhere really works. Missing 'additionalProperties' or 'unevaluatedProperties' has been a constant source of review comments, so a meta-schema check is really needed here. Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 ++ .../devicetree/bindings/nvmem/qcom,qfprom.yaml | 2 ++ for nvmem parts, Acked-by: Srinivas Kandagatla thanks, --srini
Re: [PATCH 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable
On Mon, Oct 05, 2020 at 12:30:03PM -0700, Andy Lutomirski wrote:
> @@ -441,6 +441,9 @@ struct fixed_percpu_data {
>* GCC hardcodes the stack canary as %gs:40. Since the
>* irq_stack is the object at %gs:0, we reserve the bottom
>* 48 bytes of the irq stack for the canary.
> + *
> + * Once we are willing to require -mstack-protector-guard-symbol=
> + * support for x86_64 stackprotector, we can get rid of this.
>*/
> chargs_base[40];
> unsigned long stack_canary;
I'm all in favour of simply requiring GCC-8.1 to build a more secure
x86_64 kernel. Gives people an incentive to not use ancient compilers.
And if you do want to use your ancient compiler, we'll still build, you
just don't get to have stackprotector.
[PATCH v6] Introduce support for Systems Management Driver over WMI for Dell Systems
The Dell WMI Systems Management Driver provides a sysfs
interface for systems management to enable BIOS configuration
capability on certain Dell Systems.
This driver allows user to configure Dell systems with a
uniform common interface. To facilitate this, the patch
introduces a generic way for driver to be able to create
configurable BIOS Attributes available in Setup (F2) screen.
Cc: Hans de Goede
Cc: Andy Shevchenko
Cc: mark gross
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Prasanth KSR
Signed-off-by: Prasanth KSR
Signed-off-by: Divya Bharathi
---
Changes from v5 to v6:
- Fixed Mutex bug in set_bios_defaults
- Adjust wrapping for enum-attributes.c description
- Adjust wrapping for int-attributes.c comparison
- Make current_password mandatory for mechanism == password
- Move strlen of admin check into populate_security_password
- Use correct device for dev_err calls (bios_attr_wdev)
- Remove type from structs and add type-string directly in show functions
- Remove unneeded macro definition (make function static)
- Make calls to get_*_instance_id error handling match kernel style
- Adjust -AE_ERROR to -EIO
- Adjust validate_integer_input to propagate errors
- Make current_password_store return -EIO for an unknown type
- Don't store current_value, read dynamically every time
- Move kobject_uevents to class_dev
- Update all kernel doc comments with standard termination '*/'
- Correct dereferences in alloc_*_data()
- Make value_modifier and value_modifier_count local
- Remove is_enabled from po
- Fix current_password_store const char* handling
- Propagate error value from get_po_instance_id() in is_enabled_show()
- Adjust validate_str_input
- Cleanups to reset_bios_store to use sysfs_match_string
- Adjust set_bios_defaults
- Rename create_reset_bios
- strlcpy_attr handling
- Check number of kset_unregister calls in error path
- Make teardown order match error order
- Pass password into calculate_security_buffer
- Correct handling of const char * values in macros
- Add new function for populating string buffers
- Switch strncasecmp to strcasecmp
+ This wasn't strictly necessary (the firmware rejected invalid strings)
+ However, by doing it in the kernel we can send a more sensbile error
-EINVAL
Changes from v4 to v5:
- Correct Kconfig description to not use "WMI" twice.
- s/is_authentication_set/is_enabled/
- Specify that all attributes are optional and take UTF8
- Change authentication type to "role" and "mechanism"
- Explain what semicolons are
- Adjust whitespace of documentation
Changes from v3 to v4:
- Create a firmware-attributes class and tie ksets to a virtual device in it
- Make modifier and value_modifier "dell only" attributes.
- Correct some errors caught by kernel build bot around missing prototypes
- Remove mutexes from populate_* functions and put in
init_dell_bios_attrib_wmi instead
- Move all code into a subdirectory drivers/platform/x86/dell-wmi-sysman and
remove dell-wmi-*
prefix on files
- Move all data structures into shared struct
- In alloc functions instead of kzalloc use kcalloc and check that there is no
overflow
+ Same check for other alloc_foo-data functions
- populate_*: Move sysfs_create_group to end of the function to prevent race
conditions
- Save kernel object into each data instance and only remove that rather than
sysfs_remove_group
- Document in sysfs file what causes change uevents to come through
- Only notify with change uevent one time on multiple settings modifications
- Adjust lots of string handling
- Make more objects static
- Various whitespace corrections
- Document map_wmi_error properly
- Bump version to 5.11 (February 2021)
Changes from v2 to v3:
- Fix a possible NULL pointer error in init
- Add missing newlines to all dev_err/dev_dbg/pr_err/pr_debug statements
- Correct updating passwords when both Admin and System password are set
- Correct the WMI driver name
- Correct some namespace clashing when compiled into the kernel (Reported by
Mark Gross)
- Correct some comment typos
- Adopt suggestions made by Hans:
+ Use single global mutex
+ Clarify reason for uevents with a comment
+ Remove functions for set and get current password
+ Rename lower_bound to min_value and upper_bound to max_value
+ Rename possible_value to possible_values
+ Remove references to float
+ Build a separate passwords directory again since it behaves differently
from the other
attributes
+ Move more calls from pr_err -> dev_err
- Documentation cleanups (see v2 patch feedback)
+ Grouping types
+ Syntax of `modifier` output
Changes from v1 to v2:
- use pr_fmt instead of pr_err(DRIVER_NAME
- re-order variables reverse xmas tree order
- correct returns of -1 to error codes
- correct usage of {} on some split line statements
- Refine all documentation deficiencies suggested by Hans
- Merge all attributes to a single
Re: [PATCH 0/2] Clean up x86_32 stackprotector
On Mon, Oct 05, 2020 at 07:10:39PM -0400, Brian Gerst wrote: > On Mon, Oct 5, 2020 at 3:30 PM Andy Lutomirski wrote: > > > > x86_32 stackprotector is a maintenance nightmare. Clean it up. This > > disables stackprotector on x86_32 on GCC 8.1 and on all clang > > versions -- I'll file a bug for the latter. > > This should be doable on 64-bit too. All that would need to be done > is to remove the zero-base of the percpu segment (which would simplify > alot of other code). Like what? I don't think it'd be hard to do, but I really don't see it doing anything other than make things confusing as heck.
Re: [PATCH v2 0/2] arm: sti: LL_UART updates & STiH418 addition
On Tue, Oct 6, 2020 at 7:04 AM Alain Volmat wrote: > Hi Russell, > > Could you have a look a those two patches for the STi platform ? I don't think there is much to say about those patches they are straight-forward. I would just put them into Russell's patch tracker. I think the SoC tree also takes patches of this type for a specific SoC at times. Yours, Linus Walleij
Re: [BUG][PATCH] crypto: arm64: Avoid indirect branch to bti_c
On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Instead of trying to replace the branch
> target with a bti_jc, lets replace the indirect branch with a
> bl/ret, bl sequence that can target the existing bti_c.
>
> Bad mode in Synchronous Abort handler detected on CPU1, code 0x3403 --
> BTI
> CPU: 1 PID: 265 Comm: cryptomgr_test Not tainted 5.8.11-300.fc33.aarch64 #1
> pstate: 20400c05 (nzCv daif +PAN -UAO BTYPE=j-)
> pc : aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs]
> lr : aesbs_xts_encrypt+0x48/0xe0 [aes_neon_bs]
> sp : 80001052b730
>
> aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs]
>__xts_crypt+0xb0/0x2dc [aes_neon_bs]
>xts_encrypt+0x28/0x3c [aes_neon_bs]
> crypto_skcipher_encrypt+0x50/0x84
> simd_skcipher_encrypt+0xc8/0xe0
> crypto_skcipher_encrypt+0x50/0x84
> test_skcipher_vec_cfg+0x224/0x5f0
> test_skcipher+0xbc/0x120
> alg_test_skcipher+0xa0/0x1b0
> alg_test+0x3dc/0x47c
> cryptomgr_test+0x38/0x60
>
> Fixes: commit 0e89640b640d ("crypto: arm64 - Use modern annotations for
> assembly functions")
nit: the "commit" string shouldn't be here, and I think the linux-next
scripts will yell at us if we don't remove it.
> Signed-off-by: Jeremy Linton
> ---
> arch/arm64/crypto/aes-neonbs-core.S | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/crypto/aes-neonbs-core.S
> b/arch/arm64/crypto/aes-neonbs-core.S
> index b357164379f6..32f53ebe5e2c 100644
> --- a/arch/arm64/crypto/aes-neonbs-core.S
> +++ b/arch/arm64/crypto/aes-neonbs-core.S
> @@ -788,7 +788,7 @@ SYM_FUNC_START_LOCAL(__xts_crypt8)
>
> 0: mov bskey, x21
> mov rounds, x22
> - br x7
> + ret
> SYM_FUNC_END(__xts_crypt8)
>
> .macro __xts_crypt, do8, o0, o1, o2, o3, o4, o5, o6, o7
> @@ -806,8 +806,8 @@ SYM_FUNC_END(__xts_crypt8)
> uzp1v30.4s, v30.4s, v25.4s
> ld1 {v25.16b}, [x24]
>
> -99: adr x7, \do8
> - bl __xts_crypt8
> +99: bl __xts_crypt8
> + bl \do8
>
> ldp q16, q17, [sp, #.Lframe_local_offset]
> ldp q18, q19, [sp, #.Lframe_local_offset + 32]
Acked-by: Will Deacon
Catalin -- can you pick this for 5.9 please?
Will
Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free
On Mon, 5 Oct 2020, Kees Cook wrote: > > TYPESAFE_BY_RCU, but if forcing that on by default would enhance security > > by a measurable amount, it wouldn't be a terribly hard sell ... > > Isn't the "easy" version of this already controlled by slab_merge? (i.e. > do not share same-sized/flagged kmem_caches between different caches) Right. > The large trouble are the kmalloc caches, which don't have types > associated with them. Having implicit kmem caches based on the type > being allocated there would need some pretty extensive plumbing, I > think? Actually typifying those accesses may get rid of a lot of kmalloc allocations and could help to ease the management and control of objects. It may be a big task though given the ubiquity of kmalloc and the need to create a massive amount of new slab caches. This is going to reduce the cache hit rate significantly.
Re: [PATCH 2/2] x86/entry/32: Remove leftover macros after stackprotector cleanups
On Mon, Oct 05, 2020 at 12:30:04PM -0700, Andy Lutomirski wrote: > .macro SAVE_ALL pt_regs_ax=%eax switch_stacks=0 skip_gs=0 unwind_espfix=0 > cld > .if \skip_gs == 0 > - PUSH_GS > + pushl $0 > .endif > pushl %fs > Is there a good reason not to just push gs into it? It might be nice if pt_regs is complete.
Re: [PATCH 9/9] mm, page_alloc: optionally disable pcplists during page isolation
On Tue 22-09-20 16:37:12, Vlastimil Babka wrote:
> Page isolation can race with process freeing pages to pcplists in a way that
> a page from isolated pageblock can end up on pcplist. This can be fixed by
> repeated draining of pcplists, as done by patch "mm/memory_hotplug: drain
> per-cpu pages again during memory offline" in [1].
>
> David and Michal would prefer that this race was closed in a way that callers
> of page isolation who need stronger guarantees don't need to repeatedly drain.
> David suggested disabling pcplists usage completely during page isolation,
> instead of repeatedly draining them.
>
> To achieve this without adding special cases in alloc/free fastpath, we can
> use
> the same approach as boot pagesets - when pcp->high is 0, any pcplist addition
> will be immediately flushed.
>
> The race can thus be closed by setting pcp->high to 0 and draining pcplists
> once, before calling start_isolate_page_range(). The draining will serialize
> after processes that already disabled interrupts and read the old value of
> pcp->high in free_unref_page_commit(), and processes that have not yet
> disabled
> interrupts, will observe pcp->high == 0 when they are rescheduled, and skip
> pcplists. This guarantees no stray pages on pcplists in zones where isolation
> happens.
>
> This patch thus adds zone_pcplist_disable() and zone_pcplist_enable()
> functions
> that page isolation users can call before start_isolate_page_range() and after
> unisolating (or offlining) the isolated pages. A new zone->pcplist_disabled
> atomic variable makes sure we disable only pcplists once and don't enable
> them prematurely in case there are multiple users in parallel.
>
> We however have to avoid external updates to high and batch by taking
> pcp_batch_high_lock. To allow multiple isolations in parallel, change this
> lock
> from mutex to rwsem.
The overall idea makes sense. I just suspect you are over overcomplicating
the implementation a bit. Is there any reason that we cannot start with
a really dumb implementation first. The only user of this functionality
is the memory offlining and that is already strongly synchronized
(mem_hotplug_begin) so a lot of trickery can be dropped here. Should we
find a new user later on we can make the implementation finer grained
but now it will not serve any purpose. So can we simply update pcp->high
and drain all pcp in the given zone and wait for all remote pcp draining
in zone_pcplist_enable and updte revert all that in zone_pcplist_enable.
We can stick to the existing pcp_batch_high_lock.
What do you think?
Btw. zone_pcplist_{enable,disable} would benefit from a documentation
explaining the purpose and guarantees. And side effect on the
performance. I would even stick this interface to internal.h
> Currently the only user of this functionality is offline_pages().
>
> [1]
> https://lore.kernel.org/linux-mm/20200903140032.380431-1-pasha.tatas...@soleen.com/
>
> Suggested-by: David Hildenbrand
> Suggested-by: Michal Hocko
> Signed-off-by: Vlastimil Babka
> ---
> include/linux/mmzone.h | 2 ++
> include/linux/page-isolation.h | 2 ++
> mm/internal.h | 4
> mm/memory_hotplug.c| 28
> mm/page_alloc.c| 29 ++---
> mm/page_isolation.c| 22 +++---
> 6 files changed, 57 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 7ad3f14dbe88..3c653d6348b1 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -536,6 +536,8 @@ struct zone {
>* of pageblock. Protected by zone->lock.
>*/
> unsigned long nr_isolate_pageblock;
> + /* Track requests for disabling pcplists */
> + atomic_tpcplist_disabled;
> #endif
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> index 572458016331..1dec5d0f62a6 100644
> --- a/include/linux/page-isolation.h
> +++ b/include/linux/page-isolation.h
> @@ -38,6 +38,8 @@ struct page *has_unmovable_pages(struct zone *zone, struct
> page *page,
> void set_pageblock_migratetype(struct page *page, int migratetype);
> int move_freepages_block(struct zone *zone, struct page *page,
> int migratetype, int *num_movable);
> +void zone_pcplist_disable(struct zone *zone);
> +void zone_pcplist_enable(struct zone *zone);
>
> /*
> * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
> diff --git a/mm/internal.h b/mm/internal.h
> index ea66ef45da6c..154e38e702dd 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -7,6 +7,7 @@
> #ifndef __MM_INTERNAL_H
> #define __MM_INTERNAL_H
>
> +#include
> #include
> #include
> #include
> @@ -199,8 +200,11 @@ extern void post_alloc_hook(struct page *page, unsigned
> int order,
> gfp_t gfp_flags)
ACPI _CST introduced performance regresions on Haswll
Hi Rafael,
Numerous workload regressions have bisected repeatedly to the commit
6d4f08a6776 ("intel_idle: Use ACPI _CST on server systems") but only on
a set of haswell machines that all have the same CPU.
CPU(s): 48
On-line CPU(s) list: 0-47
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 2
NUMA node(s):2
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
Stepping:2
CPU MHz: 1200.359
CPU max MHz: 3100.
CPU min MHz: 1200.
As well as being bisected in mainline, backporting the patch to a
distribution kernel also showed the same type of problem so the patch
is definitely suspicious. An example comparison showing the performance
before CST was enabled and recent mainline kernels is as follow
netperf UDP_STREAM
5.5.0 5.5.0-rc2
5.5.0-rc2 5.6.0 5.9.0-rc8
vanilla sle15-sp2-pre-cst
sle15-sp2-enable-cstvanillavanilla
Hmean send-64 203.21 ( 0.00%) 206.43 * 1.58%* 176.89
* -12.95%* 181.18 * -10.84%* 194.45 * -4.31%*
Hmean send-128401.40 ( 0.00%) 414.19 * 3.19%* 355.84
* -11.35%* 364.13 * -9.29%* 387.83 * -3.38%*
Hmean send-256786.69 ( 0.00%) 799.70 ( 1.65%) 700.65
* -10.94%* 719.82 * -8.50%* 756.40 * -3.85%*
Hmean send-1024 3059.57 ( 0.00%) 3106.57 * 1.54%* 2659.62
* -13.07%* 2793.58 * -8.69%* 3006.95 * -1.72%*
Hmean send-2048 5976.66 ( 0.00%) 6102.64 ( 2.11%) 5249.34
* -12.17%* 5392.04 * -9.78%* 5805.02 * -2.87%*
Hmean send-3312 9145.09 ( 0.00%) 9304.85 * 1.75%* 8197.25
* -10.36%* 8398.36 * -8.17%* 9120.88 ( -0.26%)
Hmean send-4096 10871.63 ( 0.00%)11129.76 * 2.37%* 9667.68
* -11.07%* 9929.70 * -8.66%*10863.41 ( -0.08%)
Hmean send-8192 17747.35 ( 0.00%)17969.19 ( 1.25%)15652.91
* -11.80%*16081.20 * -9.39%*17316.13 * -2.43%*
Hmean send-1638429187.16 ( 0.00%)29418.75 * 0.79%*26296.64
* -9.90%*27028.18 * -7.40%*26941.26 * -7.69%*
Hmean recv-64 203.21 ( 0.00%) 206.43 * 1.58%* 176.89
* -12.95%* 181.18 * -10.84%* 194.45 * -4.31%*
Hmean recv-128401.40 ( 0.00%) 414.19 * 3.19%* 355.84
* -11.35%* 364.13 * -9.29%* 387.83 * -3.38%*
Hmean recv-256786.69 ( 0.00%) 799.70 ( 1.65%) 700.65
* -10.94%* 719.82 * -8.50%* 756.40 * -3.85%*
Hmean recv-1024 3059.57 ( 0.00%) 3106.57 * 1.54%* 2659.62
* -13.07%* 2793.58 * -8.69%* 3006.95 * -1.72%*
Hmean recv-2048 5976.66 ( 0.00%) 6102.64 ( 2.11%) 5249.34
* -12.17%* 5392.00 * -9.78%* 5805.02 * -2.87%*
Hmean recv-3312 9145.09 ( 0.00%) 9304.85 * 1.75%* 8197.25
* -10.36%* 8398.36 * -8.17%* 9120.88 ( -0.26%)
Hmean recv-4096 10871.63 ( 0.00%)11129.76 * 2.37%* 9667.68
* -11.07%* 9929.70 * -8.66%*10863.38 ( -0.08%)
Hmean recv-8192 17747.35 ( 0.00%)17969.19 ( 1.25%)15652.91
* -11.80%*16081.20 * -9.39%*17315.96 * -2.43%*
Hmean recv-1638429187.13 ( 0.00%)29418.72 * 0.79%*26296.63
* -9.90%*27028.18 * -7.40%*26941.23 * -7.69%*
pre-cst is just before commit 6d4f08a6776 ("intel_idle: Use ACPI _CST on
server systems") and enable-cst is the commit. It was not fixed by 5.6 or
5.9-rc8. A lot of bisections ended up here including kernel compilation,
tbench, syscall entry/exit microbenchmark, hackbench, Java workloads etc.
What I don't understand is why. The latencies for c-state exit states
before and after the patch are both as follows
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:2
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency:10
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency:33
/sys/devices/system/cpu/cpu0/cpuidle/state4/latency:133
Perf profiles did not show up anything interesting. A diff of
/sys/devices/system/cpu/cpu0/cpuidle/state0/ before and after the patch
showed up nothing interesting. Any idea why exactly this patch shows up
as being hazardous on Haswell in particular?
--
Mel Gorman
SUSE Labs
Re: irq_build_affinity_masks() allocates improper affinity if num_possible_cpus() > num_present_cpus()?
On Tue, 2020-10-06 at 06:47 +, Dexuan Cui wrote:
> Hi all,
> I'm running a single-CPU Linux VM on Hyper-V. The Linux kernel is v5.9-rc7
> and I have CONFIG_NR_CPUS=256.
>
> The Hyper-V Host (Version 17763-10.0-1-0.1457) provides a guest firmware,
> which always reports 128 Local APIC entries in the ACPI MADT table. Here
> only the first Local APIC entry's "Processor Enabled" is 1 since this
> Linux VM is configured to have only 1 CPU. This means: in the Linux kernel,
> the "cpu_present_mask" and " cpu_online_mask " have only 1 CPU (i.e. CPU0),
> while the "cpu_possible_mask" has 128 CPUs, and the "nr_cpu_ids" is 128.
>
> I pass through an MSI-X-capable PCI device to the Linux VM (which has
> only 1 virtual CPU), and the below code does *not* report any error
> (i.e. pci_alloc_irq_vectors_affinity() returns 2, and request_irq()
> returns 0), but the code does not work: the second MSI-X interrupt is not
> happening while the first interrupt does work fine.
>
> int nr_irqs = 2;
> int i, nvec, irq;
>
> nvec = pci_alloc_irq_vectors_affinity(pdev, nr_irqs, nr_irqs,
> PCI_IRQ_MSIX | PCI_IRQ_AFFINITY, NULL);
>
> for (i = 0; i < nvec; i++) {
> irq = pci_irq_vector(pdev, i);
> err = request_irq(irq, test_intr, 0, "test_intr", &intr_cxt[i]);
> }
>
> It turns out that pci_alloc_irq_vectors_affinity() -> ... ->
> irq_create_affinity_masks() allocates an improper affinity for the second
> interrupt. The below printk() shows that the second interrupt's affinity is
> 1-64, but only CPU0 is present in the system! As a result, later,
> request_irq() -> ... -> irq_startup() -> __irq_startup_managed() returns
> IRQ_STARTUP_ABORT because cpumask_any_and(aff, cpu_online_mask) is
> empty (i.e. >= nr_cpu_ids), and irq_startup() *silently* fails (i.e. "return
> 0;"),
> since __irq_startup() is only called for IRQ_STARTUP_MANAGED and
> IRQ_STARTUP_NORMAL.
>
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -484,6 +484,9 @@ struct irq_affinity_desc *
> for (i = affd->pre_vectors; i < nvecs - affd->post_vectors; i++)
> masks[i].is_managed = 1;
>
> + for (i = 0; i < nvecs; i++)
> + printk("i=%d, affi = %*pbl\n", i,
> + cpumask_pr_args(&masks[i].mask));
> return masks;
> }
>
> [ 43.770477] i=0, affi = 0,65-127
> [ 43.770484] i=1, affi = 1-64
>
> Though here the issue happens to a Linux VM on Hyper-V, I think the same
> issue can also happen to a physical machine, if the physical machine also
> uses a lot of static MADT entries, of which only the entries of the present
> CPUs are marked to be "Processor Enabled == 1".
>
> I think pci_alloc_irq_vectors_affinity() -> __pci_enable_msix_range() ->
> irq_calc_affinity_vectors() -> cpumask_weight(cpu_possible_mask) should
> use cpu_present_mask rather than cpu_possible_mask (), so here
> irq_calc_affinity_vectors() would return 1, and
> __pci_enable_msix_range() would immediately return -ENOSPC to avoid a
> *silent* failure.
>
> However, git-log shows that this 2018 commit intentionally changed the
> cpu_present_mask to cpu_possible_mask:
> 84676c1f21e8 ("genirq/affinity: assign vectors to all possible CPUs")
>
> so I'm not sure whether (and how?) we should address the *silent* failure.
>
> BTW, here I use a single-CPU VM to simplify the discussion. Actually,
> if the VM has n CPUs, with the above usage of
> pci_alloc_irq_vectors_affinity() (which might seem incorrect, but my point is
> that it's really not good to have a silent failure, which makes it a lot more
> difficult to figure out what goes wrong), it looks only the first n MSI-X
> interrupts
> can work, and the (n+1)'th MSI-X interrupt can not work due to the allocated
> improper affinity.
>
> According to my tests, if we need n+1 MSI-X interrupts in such a VM that
> has n CPUs, it looks we have 2 options (the second should be better):
>
> 1. Do not use the PCI_IRQ_AFFINITY flag, i.e.
> pci_alloc_irq_vectors_affinity(pdev, n+1, n+1, PCI_IRQ_MSIX, NULL);
>
> 2. Use the PCI_IRQ_AFFINITY flag, and pass a struct irq_affinity affd,
> which tells the API that we don't care about the first interrupt's affinity:
>
> struct irq_affinity affd = {
> .pre_vectors = 1,
> ...
> };
>
> pci_alloc_irq_vectors_affinity(pdev, n+1, n+1,
> PCI_IRQ_MSIX | PCI_IRQ_AFFINITY, &affd);
>
> PS, irq_create_affinity_masks() is complicated. Let me know if you're
> interested to know how it allocates the invalid affinity "1-64" for the
> second MSI-X interrupt.
Go on. It'll save me a cup of coffee or two...
> PS2, the latest Hyper-V provides only one ACPI MADT entry to a 1-CPU VM,
> so the issue described above can not reproduce there.
It seems fairly easy to reproduce in qemu with -smp 1,maxcpus=128 and a
virtio-blk drive, having commented out the 'desc->pre_vectors++' around
line 130 of virtio_pci_common.c so that it
Re: [PATCH v2 0/4] AX88796C SPI Ethernet Adapter
It was <2020-10-02 pią 21:45>, when Andrew Lunn wrote: > On Fri, Oct 02, 2020 at 09:22:06PM +0200, Łukasz Stelmach wrote: >> This is a driver for AX88796C Ethernet Adapter connected in SPI mode as >> found on ARTIK5 evaluation board. The driver has been ported from a >> v3.10.9 vendor kernel for ARTIK5 board. > > Hi Łukasz > > Please include a brief list of changes since the previous version. > It can be found at the bottom of the message. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: [PATCH v4 00/32] Make charlcd device independent
On Mon, Oct 05, 2020 at 05:30:59PM +0200, Miguel Ojeda wrote: > Hi Lars, > > On Mon, Oct 5, 2020 at 2:27 PM wrote: > > > > This tries to make charlcd device independent. > > Thanks a lot for the work! > > I see you have written the differences between versions in each patch, > but given there are 32 patches, it'd be nice to comment which ones have > changed so that folks that already did a review can take a look at > those. Changes in v4: - modtronix -> Modtronix in new lcd2s driver - Kconfig: remove "default n" in new lcd2s driver Changes in v3: - Fix some typos in Kconfig stuff - Fix kernel test robot reported error: Missed EXPORT_SYMBOL_GPL - new patch to reduce display timeout - better patch description to why not move cursor beyond end of a line - Fixed make dt_binding_doc errors Changes in v2: - split whole patch into many smaller chunks - device tree doc in yaml Regards, Lars
Re: [PATCH v11 3/5] drivers/soc/litex: add LiteX SoC Controller driver
Hi Mateusz,
On Tue, Oct 6, 2020 at 10:02 AM Mateusz Holenko wrote:
> On Fri, Sep 25, 2020 at 3:16 PM Geert Uytterhoeven
> wrote:
> > On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> > wrote:
> > > From: Pawel Czarnecki
> > >
> > > This commit adds driver for the FPGA-based LiteX SoC
> > > Controller from LiteX SoC builder.
> > >
> > > Co-developed-by: Mateusz Holenko
> > > Signed-off-by: Mateusz Holenko
> > > Signed-off-by: Pawel Czarnecki
> > > --- /dev/null
> > > +++ b/drivers/soc/litex/Kconfig
> > > @@ -0,0 +1,15 @@
> > > +# SPDX-License_Identifier: GPL-2.0
> > > +
> > > +menu "Enable LiteX SoC Builder specific drivers"
> > > +
> > > +config LITEX_SOC_CONTROLLER
> > > + tristate "Enable LiteX SoC Controller driver"
> > > + depends on OF || COMPILE_TEST
> > > + help
> > > + This option enables the SoC Controller Driver which verifies
> > > + LiteX CSR access and provides common litex_get_reg/litex_set_reg
> > > + accessors.
> > > + All drivers that use functions from litex.h must depend on
> > > + LITEX_SOC_CONTROLLER.
> >
> > I'm wondering if it makes sense to have them depend on a "simpler"
> > symbol instead, e.g. LITEX?
> >
> > Currently the SoC controller is limited to I/O accessors and a simple
> > register compatibility check, but you may want to extend it with more
> > features later, so you probably want to keep the LITEX_SOC_CONTROLLER.
> > Hence you could add
> >
> > config LITEX
> > bool
> >
> > and let LITEX_SOC_CONTROLLER select LITEX.
>
> But then if other drivers depend just on LITEX, it would not automatically
> mean that the LITEX_SOC_CONTROLLER is selected, right?. And if it's not
> selected
> litex_{g,s}et_reg() are not available and the compilation would fail.
As the LITEX config symbol above uses plain "bool", without a
description, it is invisible. Hence it cannot be enabled by the user,
only be selected by other symbols.
If LITEX_SOC_CONTROLLER is the only symbol selecting LITEX, the
dependency is met.
> I could move the implementation of those functions directly to the
> litex.h header
> and avoid this KConfig dependency, but I'm not sure if they are not
> too big to become a static inline.
> What do you think?
With the spinlock and the loop, they're too large to be inlined, IMHO.
> > > --- /dev/null
> > > +++ b/drivers/soc/litex/litex_soc_ctrl.c
> > > + */
> > > +#define LITEX_REG_SIZE 0x4
> > > +#define LITEX_SUBREG_SIZE 0x1
> > > +#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8)
> > > +
> > > +static DEFINE_SPINLOCK(csr_lock);
> > > +
> > > +/*
> > > + * LiteX SoC Generator, depending on the configuration,
> > > + * can split a single logical CSR (Control & Status Register)
> > > + * into a series of consecutive physical registers.
> > > + *
> > > + * For example, in the configuration with 8-bit CSR Bus,
> > > + * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit
> > > + * logical CSR will be generated as four 32-bit physical registers,
> > > + * each one containing one byte of meaningful data.
> > > + *
> > > + * For details see: https://github.com/enjoy-digital/litex/wiki/CSR-Bus
> > > + *
> > > + * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
> > > + * the logic of writing to/reading from the LiteX CSR in a single
> > > + * place that can be then reused by all LiteX drivers.
> > > + */
> > > +void litex_set_reg(void __iomem *reg, unsigned long reg_size,
> > > + unsigned long val)
> > > +{
> > > + unsigned long shifted_data, shift, i;
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(&csr_lock, flags);
> > > +
> > > + for (i = 0; i < reg_size; ++i) {
> > > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
> > > + shifted_data = val >> shift;
> > > +
> > > + writel((u32 __force)cpu_to_le32(shifted_data), reg +
> > > (LITEX_REG_SIZE * i));
> > > + }
> > > +
> > > + spin_unlock_irqrestore(&csr_lock, flags);
> > > +}
> > > +EXPORT_SYMBOL_GPL(litex_set_reg);
> >
> > I'm still wondering about the overhead of loops and multiple accesses,
> > and the need for them (see also BenH's earlier comment).
> > If e.g. the register widths change for LiteUART (currently they're
> > hardcoded to one), would you still consider it using the same
> > programming interface, and thus compatible with "litex,liteuart"?
>
> Since the amount of possible `reg_size` is practically limited we could
> add explicit 8/32/64/128 accessors to eliminate loops.
Good.
(assuming 32-bit physical reg accesses below)
> As for multiple writel/readl I don't really see an option to avoid
> them for the 8-bit bus width.
Sure, 64-bit register accesses consist of two 32-bit accesses on other
32-bit platforms, too.
> > The spinlock access will probably become the source of lock contention
> > later, especially when considering SMP variants.
>
> Do you have any
