* Re: [PATCH v3 1/6] ASoC: dmaengine: do not use a NULL prepare_slave_config() callback
From: Codrin.Ciubotariu @ 2022-04-20 9:58 UTC (permalink / raw)
To: sha
Cc: devicetree, alsa-devel, lars, tiwai, linux-kernel, robh+dt, perex,
broonie, linux-arm-kernel
In-Reply-To: <20220420091552.GD2387@pengutronix.de>
On 20.04.2022 12:15, Sascha Hauer wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi,
Hi Sascha,
>
> On Mon, Mar 07, 2022 at 02:21:57PM +0200, Codrin Ciubotariu wrote:
>> Even if struct snd_dmaengine_pcm_config is used, prepare_slave_config()
>> callback might not be set. Check if this callback is set before using it.
>>
>> Fixes: fa654e085300 ("ASoC: dmaengine-pcm: Provide default config")
>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> ---
>>
>> Changes in v2,v3:
>> - none
>>
>> sound/soc/soc-generic-dmaengine-pcm.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
>> index 285441d6aeed..2ab2ddc1294d 100644
>> --- a/sound/soc/soc-generic-dmaengine-pcm.c
>> +++ b/sound/soc/soc-generic-dmaengine-pcm.c
>> @@ -86,10 +86,10 @@ static int dmaengine_pcm_hw_params(struct snd_soc_component *component,
>>
>> memset(&slave_config, 0, sizeof(slave_config));
>>
>> - if (!pcm->config)
>> - prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config;
>> - else
>> + if (pcm->config && pcm->config->prepare_slave_config)
>> prepare_slave_config = pcm->config->prepare_slave_config;
>> + else
>> + prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config;
>>
>> if (prepare_slave_config) {
>> int ret = prepare_slave_config(substream, params, &slave_config);
>
> I wonder if this patch is correct. There are drivers like
> sound/soc/mxs/mxs-pcm.c which call snd_dmaengine_pcm_register() with a
> config which has the prepare_slave_config callback unset. For these
> drivers dmaengine_pcm_hw_params() previously was a no-op. Now with this
> patch snd_dmaengine_pcm_prepare_slave_config() and
> dmaengine_slave_config() are called. At least for the mxs-pcm driver
> calling dmaengine_slave_config() will return -ENOSYS.
>
> At least the "Check if this callback is set before using it" part is
> wrong, the callback is checked before using it with
>
> if (prepare_slave_config) {
> ...
> }
>
> I don't have any mxs hardware at hand to test this. I just stumbled upon
> the change of behaviour when rebasing
> https://patchwork.kernel.org/project/alsa-devel/patch/20220301122111.1073174-1-s.hauer@pengutronix.de/
> on current master.
You are right. I changed the behavior from:
if (pmc->config && !pcm->config->prepare_slave_config)
<do nothing>
to:
if (pmc->config && !pcm->config->prepare_slave_config)
snd_dmaengine_pcm_prepare_slave_config()
It was not intended and I agree that the commit message is not accurate.
I guess some drivers might not need dmaengine_slave_config()...
However, in my case, for the mchp-pdmc driver, I do have pcm->config
with pcm->config->prepare_slave_config NULL, but I still need
snd_dmaengine_pcm_prepare_slave_config() to be called. Should we add a
separate flag to call snd_dmaengine_pcm_prepare_slave_config() if
pcm->config->prepare_slave_config is NULL?
Nice catch!
Best regards,
Codrin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter
From: Catalin Marinas @ 2022-04-20 9:57 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, broonie, linux-arm-kernel, jeremy.linton, hjl.tools,
libc-alpha, szabolcs.nagy, yu-cheng.yu, ebiederm, linux-arch
In-Reply-To: <20220420093612.GB6954@willie-the-truck>
On Wed, Apr 20, 2022 at 10:36:13AM +0100, Will Deacon wrote:
> On Tue, Apr 19, 2022 at 10:33:06PM -0700, Kees Cook wrote:
> > On Tue, 19 Apr 2022 11:51:54 +0100, Mark Brown wrote:
> > > Deployments of BTI on arm64 have run into issues interacting with
> > > systemd's MemoryDenyWriteExecute feature. Currently for dynamically
> > > linked executables the kernel will only handle architecture specific
> > > properties like BTI for the interpreter, the expectation is that the
> > > interpreter will then handle any properties on the main executable.
> > > For BTI this means remapping the executable segments PROT_EXEC |
> > > PROT_BTI.
> > >
> > > [...]
> >
> > Applied to for-next/execve, thanks!
> >
> > [1/2] elf: Allow architectures to parse properties on the main executable
> > https://git.kernel.org/kees/c/b2f2553c8e89
> > [2/2] arm64: Enable BTI for main executable as well as the interpreter
> > https://git.kernel.org/kees/c/b65c760600e2
>
> Kees, please can you drop this series while Catalin's alternative solution
> is under discussion (his Reviewed-by preceded the other patches)?
>
> https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@arm.com
>
> Both series expose new behaviours to userspace and we don't need both.
I agree. Even though the patches have my reviewed-by, I think we should
postpone them until we figure out a better W^X solution that does not
affect BTI (and if we can't, we revisit these patches).
Arguably, the two approaches are complementary but the way this series
turned out is for the BTI on main executable to be default off. I have a
worry that the feature won't get used, so we just carry unnecessary code
in the kernel. Jeremy also found this approach less than ideal:
https://lore.kernel.org/r/59fc8a58-5013-606b-f544-8277cda18e50@arm.com
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] nvme-apple: Add initial Apple SoC NVMe driver
From: Arnd Bergmann @ 2022-04-20 9:53 UTC (permalink / raw)
To: hch@lst.de
Cc: Arnd Bergmann, Sven Peter, Keith Busch, axboe@fb.com,
sagi@grimberg.me, Hector Martin, Alyssa Rosenzweig, Rob Herring,
Krzysztof Kozlowski, Marc Zyngier, DTML, Linux ARM,
Linux Kernel Mailing List, linux-nvme, linux-spdx
In-Reply-To: <20220420043437.GA1123@lst.de>
On Wed, Apr 20, 2022 at 6:34 AM hch@lst.de <hch@lst.de> wrote:
> On Tue, Apr 19, 2022 at 11:52:15AM +0200, Arnd Bergmann wrote:
> > > I just checked again and 64-bit accesses seem to work fine.
> > > I'll remove the lo_hi_* calls and this include.
> >
> > If you remove the #include, it is no longer possible to compile-test
> > this on all 32-bit architectures, though that is probably fine as long
> > as the Kconfig file has the right dependencies, like
> >
> > depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
> >
> > I'd prefer to keep the #include here, but I don't mind the dependency
> > if Christoph prefers it that way.
>
> So thre's really two steps here:
>
> 1) stop uing lo_hi_readq diretly which forces 32-bit access even on
> 64-bit platforms
> 2) stop using the io-64-nonatomic headers entirely
>
> I definitively want 1) done if the hardware does not require it.
Yes, of cours.e
> Trying to cater to 32-bit build tests on hardware that has no chance of
> ever being used there by including the header seems a bit silly, but if
> it makes folks happy I can live with it.
As I said, I don't have a strong opinion either, it's either a trivial change
in Kconfig or a trivial header inclusion and I'd pick the header one because
it's more obvious what this is for without adding a comment.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext
From: Russell King (Oracle) @ 2022-04-20 9:44 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage,
Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton,
max.krummenacher, Shawn Guo, Stefano Stabellini,
Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman
In-Reply-To: <CA+G9fYvRdg6t6OnoJy62Vte5XnSymyL6B6kARC_1Jao52h6ZYg@mail.gmail.com>
On Wed, Apr 20, 2022 at 02:25:32PM +0530, Naresh Kamboju wrote:
> On Wed, 20 Apr 2022 at 00:28, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote:
> > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard
> > > x15 device.
> >
> > Was the immediately previous linux-next behaving correctly?
>
> This crash started happening from the next-20220413 tag.
That rules out any arm32 specific changes - the last time my tree
changed in for-next was 1st April.
Ard points out that the pte table is on the stack, which it really
should not be. I'm guessing there's some inappropriate generic
kernel change that has broken arm32. A pte table should never ever
appear on a kernel stack.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] gpio: use raw spinlock for gpio chip shadowed data
From: Serge Semin @ 2022-04-20 9:37 UTC (permalink / raw)
To: Schspa Shi
Cc: Serge Semin, brgl, andy.shevchenko, linus.walleij, f.fainelli,
hoan, linux-arm-kernel, linux-gpio, linux-kernel, opendmb
In-Reply-To: <20220419012810.88417-1-schspa@gmail.com>
On Tue, Apr 19, 2022 at 09:28:10AM +0800, Schspa Shi wrote:
> In case of PREEMPT_RT, there is a raw_spinlock -> spinlock dependency
> as the lockdep report shows.
>
> __irq_set_handler
> irq_get_desc_buslock
> __irq_get_desc_lock
> raw_spin_lock_irqsave(&desc->lock, *flags); // raw spinlock get here
> __irq_do_set_handler
> mask_ack_irq
> dwapb_irq_ack
> spin_lock_irqsave(&gc->bgpio_lock, flags); // sleep able spinlock
> irq_put_desc_busunlock
>
> Replace with a raw lock to avoid BUGs. This lock is only used to access
> registers, and It's safe to replace with the raw lock without bad
> influence.
>
> [ 15.090359][ T1] =============================
> [ 15.090365][ T1] [ BUG: Invalid wait context ]
> [ 15.090373][ T1] 5.10.59-rt52-00983-g186a6841c682-dirty #3 Not tainted
> [ 15.090386][ T1] -----------------------------
> [ 15.090392][ T1] swapper/0/1 is trying to lock:
> [ 15.090402][ T1] 70ff00018507c188 (&gc->bgpio_lock){....}-{3:3}, at: _raw_spin_lock_irqsave+0x1c/0x28
> [ 15.090470][ T1] other info that might help us debug this:
> [ 15.090477][ T1] context-{5:5}
> [ 15.090485][ T1] 3 locks held by swapper/0/1:
> [ 15.090497][ T1] #0: c2ff0001816de1a0 (&dev->mutex){....}-{4:4}, at: __device_driver_lock+0x98/0x104
> [ 15.090553][ T1] #1: ffff90001485b4b8 (irq_domain_mutex){+.+.}-{4:4}, at: irq_domain_associate+0xbc/0x6d4
> [ 15.090606][ T1] #2: 4bff000185d7a8e0 (lock_class){....}-{2:2}, at: _raw_spin_lock_irqsave+0x1c/0x28
> [ 15.090654][ T1] stack backtrace:
> [ 15.090661][ T1] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.59-rt52-00983-g186a6841c682-dirty #3
> [ 15.090682][ T1] Hardware name: Horizon Robotics Journey 5 DVB (DT)
> [ 15.090692][ T1] Call trace:
> ......
> [ 15.090811][ T1] _raw_spin_lock_irqsave+0x1c/0x28
> [ 15.090828][ T1] dwapb_irq_ack+0xb4/0x300
> [ 15.090846][ T1] __irq_do_set_handler+0x494/0xb2c
> [ 15.090864][ T1] __irq_set_handler+0x74/0x114
> [ 15.090881][ T1] irq_set_chip_and_handler_name+0x44/0x58
> [ 15.090900][ T1] gpiochip_irq_map+0x210/0x644
>
> Signed-off-by: Schspa Shi <schspa@gmail.com>
>
> ---
>
> Changelog:
> v1 -> v2:
> - Reduce the useless stacktrace.
> - Split to series of patches
> v2 -> v3:
> - Restore to a single patch as Andy and Bartosz's suggest
> - add cutter ‘--- ‘ line for Change log
> ---
> drivers/gpio/gpio-amdpt.c | 10 +++----
> drivers/gpio/gpio-brcmstb.c | 12 ++++----
> drivers/gpio/gpio-cadence.c | 12 ++++----
> drivers/gpio/gpio-dwapb.c | 36 +++++++++++------------
for the dwapb-gpio.c driver:
Acked-by: Serge Semin <fancer.lancer@gmail.com>
-Sergey
> drivers/gpio/gpio-grgpio.c | 30 +++++++++----------
> drivers/gpio/gpio-hlwd.c | 18 ++++++------
> drivers/gpio/gpio-idt3243x.c | 12 ++++----
> drivers/gpio/gpio-ixp4xx.c | 4 +--
> drivers/gpio/gpio-loongson1.c | 8 ++---
> drivers/gpio/gpio-menz127.c | 8 ++---
> drivers/gpio/gpio-mlxbf2.c | 18 ++++++------
> drivers/gpio/gpio-mmio.c | 22 +++++++-------
> drivers/gpio/gpio-sifive.c | 12 ++++----
> drivers/gpio/gpio-tb10x.c | 4 +--
> drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 8 ++---
> include/linux/gpio/driver.h | 2 +-
> 16 files changed, 108 insertions(+), 108 deletions(-)
>
[...]
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index b0f3aca61974..7130195da48d 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -243,9 +243,9 @@ static void dwapb_irq_ack(struct irq_data *d)
> u32 val = BIT(irqd_to_hwirq(d));
> unsigned long flags;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> dwapb_write(gpio, GPIO_PORTA_EOI, val);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> }
>
> static void dwapb_irq_mask(struct irq_data *d)
> @@ -255,10 +255,10 @@ static void dwapb_irq_mask(struct irq_data *d)
> unsigned long flags;
> u32 val;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> val = dwapb_read(gpio, GPIO_INTMASK) | BIT(irqd_to_hwirq(d));
> dwapb_write(gpio, GPIO_INTMASK, val);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> }
>
> static void dwapb_irq_unmask(struct irq_data *d)
> @@ -268,10 +268,10 @@ static void dwapb_irq_unmask(struct irq_data *d)
> unsigned long flags;
> u32 val;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> val = dwapb_read(gpio, GPIO_INTMASK) & ~BIT(irqd_to_hwirq(d));
> dwapb_write(gpio, GPIO_INTMASK, val);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> }
>
> static void dwapb_irq_enable(struct irq_data *d)
> @@ -281,11 +281,11 @@ static void dwapb_irq_enable(struct irq_data *d)
> unsigned long flags;
> u32 val;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> val = dwapb_read(gpio, GPIO_INTEN);
> val |= BIT(irqd_to_hwirq(d));
> dwapb_write(gpio, GPIO_INTEN, val);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> }
>
> static void dwapb_irq_disable(struct irq_data *d)
> @@ -295,11 +295,11 @@ static void dwapb_irq_disable(struct irq_data *d)
> unsigned long flags;
> u32 val;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> val = dwapb_read(gpio, GPIO_INTEN);
> val &= ~BIT(irqd_to_hwirq(d));
> dwapb_write(gpio, GPIO_INTEN, val);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> }
>
> static int dwapb_irq_set_type(struct irq_data *d, u32 type)
> @@ -309,7 +309,7 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
> irq_hw_number_t bit = irqd_to_hwirq(d);
> unsigned long level, polarity, flags;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> level = dwapb_read(gpio, GPIO_INTTYPE_LEVEL);
> polarity = dwapb_read(gpio, GPIO_INT_POLARITY);
>
> @@ -344,7 +344,7 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
> dwapb_write(gpio, GPIO_INTTYPE_LEVEL, level);
> if (type != IRQ_TYPE_EDGE_BOTH)
> dwapb_write(gpio, GPIO_INT_POLARITY, polarity);
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
>
> return 0;
> }
> @@ -374,7 +374,7 @@ static int dwapb_gpio_set_debounce(struct gpio_chip *gc,
> unsigned long flags, val_deb;
> unsigned long mask = BIT(offset);
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
>
> val_deb = dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
> if (debounce)
> @@ -383,7 +383,7 @@ static int dwapb_gpio_set_debounce(struct gpio_chip *gc,
> val_deb &= ~mask;
> dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, val_deb);
>
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
>
> return 0;
> }
> @@ -738,7 +738,7 @@ static int dwapb_gpio_suspend(struct device *dev)
> unsigned long flags;
> int i;
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> for (i = 0; i < gpio->nr_ports; i++) {
> unsigned int offset;
> unsigned int idx = gpio->ports[i].idx;
> @@ -765,7 +765,7 @@ static int dwapb_gpio_suspend(struct device *dev)
> dwapb_write(gpio, GPIO_INTMASK, ~ctx->wake_en);
> }
> }
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
>
> clk_bulk_disable_unprepare(DWAPB_NR_CLOCKS, gpio->clks);
>
> @@ -785,7 +785,7 @@ static int dwapb_gpio_resume(struct device *dev)
> return err;
> }
>
> - spin_lock_irqsave(&gc->bgpio_lock, flags);
> + raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
> for (i = 0; i < gpio->nr_ports; i++) {
> unsigned int offset;
> unsigned int idx = gpio->ports[i].idx;
> @@ -812,7 +812,7 @@ static int dwapb_gpio_resume(struct device *dev)
> dwapb_write(gpio, GPIO_PORTA_EOI, 0xffffffff);
> }
> }
> - spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> + raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
>
> return 0;
> }
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter
From: Will Deacon @ 2022-04-20 9:36 UTC (permalink / raw)
To: Kees Cook
Cc: broonie, catalin.marinas, linux-arm-kernel, jeremy.linton,
hjl.tools, libc-alpha, szabolcs.nagy, yu-cheng.yu, ebiederm,
linux-arch
In-Reply-To: <165043278356.1481705.13924459838445776007.b4-ty@chromium.org>
On Tue, Apr 19, 2022 at 10:33:06PM -0700, Kees Cook wrote:
> On Tue, 19 Apr 2022 11:51:54 +0100, Mark Brown wrote:
> > Deployments of BTI on arm64 have run into issues interacting with
> > systemd's MemoryDenyWriteExecute feature. Currently for dynamically
> > linked executables the kernel will only handle architecture specific
> > properties like BTI for the interpreter, the expectation is that the
> > interpreter will then handle any properties on the main executable.
> > For BTI this means remapping the executable segments PROT_EXEC |
> > PROT_BTI.
> >
> > [...]
>
> Applied to for-next/execve, thanks!
>
> [1/2] elf: Allow architectures to parse properties on the main executable
> https://git.kernel.org/kees/c/b2f2553c8e89
> [2/2] arm64: Enable BTI for main executable as well as the interpreter
> https://git.kernel.org/kees/c/b65c760600e2
Kees, please can you drop this series while Catalin's alternative solution
is under discussion (his Reviewed-by preceded the other patches)?
https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@arm.com
Both series expose new behaviours to userspace and we don't need both.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] usb: mtu3: fix USB 3.0 dual-role-switch from device to host
From: Chunfeng Yun @ 2022-04-20 9:18 UTC (permalink / raw)
To: Macpaul Lin, Greg Kroah-Hartman, Matthias Brugger, linux-usb,
linux-arm-kernel, linux-mediatek, linux-kernel
Cc: Miles Chen, Bear Wang, Pablo Sun, Fabien Parent,
Mediatek WSD Upstream, Macpaul Lin, stable, Tainping Fang
In-Reply-To: <20220419081245.21015-1-macpaul.lin@mediatek.com>
On Tue, 2022-04-19 at 16:12 +0800, Macpaul Lin wrote:
> Issue description:
> When an OTG port has been switched to device role and then switch
> back
> to host role again, the USB 3.0 Host (XHCI) will not be able to
> detect
> "plug in event of a connected USB 2.0/1.0 ((Highspeed and
> Fullspeed)
> devices until system reboot.
>
> Root cause and Solution:
> There is a condition checking flag "ssusb->otg_switch.is_u3_drd" in
> toggle_opstate(). At the end of role switch procedure,
> toggle_opstate()
> will be called to set DC_SESSION and SOFT_CONN bit. If "is_u3_drd"
> was
> set and switched the role to USB host 3.0, bit DC_SESSION and
> SOFT_CONN
> will be skipped hence caused the port cannot detect connected USB
> 2.0
> (Highspeed and Fullspeed) devices. Simply remove the condition
> check to
> solve this issue.
>
> Fixes: d0ed062a8b75 ("usb: mtu3: dual-role mode support")
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> Signed-off-by: Tainping Fang <tianping.fang@mediatek.com>
> Tested-by: Fabien Parent <fparent@baylibre.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/usb/mtu3/mtu3_dr.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
> index ec6ec621838b..b820724c56e4 100644
> --- a/drivers/usb/mtu3/mtu3_dr.c
> +++ b/drivers/usb/mtu3/mtu3_dr.c
> @@ -21,10 +21,8 @@ static inline struct ssusb_mtk
> *otg_sx_to_ssusb(struct otg_switch_mtk *otg_sx)
>
> static void toggle_opstate(struct ssusb_mtk *ssusb)
> {
> - if (!ssusb->otg_switch.is_u3_drd) {
> - mtu3_setbits(ssusb->mac_base, U3D_DEVICE_CONTROL,
> DC_SESSION);
> - mtu3_setbits(ssusb->mac_base, U3D_POWER_MANAGEMENT,
> SOFT_CONN);
> - }
> + mtu3_setbits(ssusb->mac_base, U3D_DEVICE_CONTROL, DC_SESSION);
> + mtu3_setbits(ssusb->mac_base, U3D_POWER_MANAGEMENT, SOFT_CONN);
> }
>
Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Thanks
> /* only port0 supports dual-role mode */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] perf/arm-cmn: Add CMN-650 support
From: Will Deacon @ 2022-04-20 9:26 UTC (permalink / raw)
To: Ilkka Koskinen; +Cc: Robin Murphy, mark.rutland, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.22.394.2204191637120.1991@ubuntu200401>
On Tue, Apr 19, 2022 at 04:47:11PM -0700, Ilkka Koskinen wrote:
> On Tue, 19 Apr 2022, Ilkka Koskinen wrote:
> > On Mon, 18 Apr 2022, Robin Murphy wrote:
> > > Add the identifiers and events for CMN-650, which slots into its
> > > evolutionary position between CMN-600 and the 700-series products.
> > > Imagine CMN-600 made bigger, and with most of the rough edges smoothed
> > > off, but that then balanced out by some bonkers PMU functionality for
> > > the new HN-P enhancement in CMN-650r2.
> > >
> > > Most of the CXG events are actually common to newer revisions of CMN-600
> > > too, so they're arguably a little late; oh well.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/perf/arm-cmn.c | 222 ++++++++++++++++++++++++++++++++---------
> > > 1 file changed, 176 insertions(+), 46 deletions(-)
> > >
> > > diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> > > index 9c1d82be7a2f..cce8516d465c 100644
> > > --- a/drivers/perf/arm-cmn.c
> > > +++ b/drivers/perf/arm-cmn.c
>
>
> > > @@ -1979,6 +2108,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match);
> > > #ifdef CONFIG_ACPI
> > > static const struct acpi_device_id arm_cmn_acpi_match[] = {
> > > { "ARMHC600", CMN600 },
> > > + { "ARMHC650", CMN650 },
> >
> > Not the great place for this comment but there probably isn't any better.
> >
> > Based on DEN0093 v1.1, CMN's DSDT entries have been changed since
> > CMN-600. ROOTNODEBASE seems to be specific for CMN-600. Moreover, if you
> > compare the address maps in TRMs' Discovery chapters, you can see the
> > difference.
> >
> > I'm thinking, at the minimal the second platform_get_resource() call has
> > to be skipped and zero returned in arm_cmn600_acpi_probe(), if the model
> > is cmn650 (probably also for cmn-700)
>
> Uh, if only I had read the code more carefully, I had noticed that's what
> the driver does indeed.
>
>
> Anyway, so far it everything works fine. I test the driver a little more
> (and review the patches more carefully) and will let know how it goes.
Thanks for giving it a spin!
Please reply with a Tested-by if/when you're happy with them, then I can
queue them up (you've still got a couple of weeks, so no rush).
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/41] video: fbdev: omapfb: lcd_ams_delta: fix unused variable warning
From: Sergei Shtylyov @ 2022-04-20 9:24 UTC (permalink / raw)
To: Arnd Bergmann, linux-omap, tony, aaro.koskinen, jmkrzyszt
Cc: Arnd Bergmann, Russell King, Paul Walmsley, Kevin Hilman,
Peter Ujfalusi, Vinod Koul, Dmitry Torokhov, Ulf Hansson,
Dominik Brodowski, Mark Brown, Felipe Balbi, Alan Stern,
Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
linux-kernel, linux-usb, dmaengine, linux-input, linux-mmc,
linux-serial, dri-devel, linux-fbdev, alsa-devel
In-Reply-To: <20220419133723.1394715-2-arnd@kernel.org>
Hello!
On 4/19/22 4:36 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> A recent cleanup patch removed the only reference to a local variable
> in some configurations.
>
> Move the variable into the one block it is still used in, inside
> of an #ifdef, to avoid this warning.
>
> Fixes: 9d773f103b89 ("video: fbdev: omapfb: lcd_ams_delta: Make use of the helper function dev_err_probe()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/video/fbdev/omap/lcd_ams_delta.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap/lcd_ams_delta.c b/drivers/video/fbdev/omap/lcd_ams_delta.c
> index bbf871f9d862..01944ce46aa1 100644
> --- a/drivers/video/fbdev/omap/lcd_ams_delta.c
> +++ b/drivers/video/fbdev/omap/lcd_ams_delta.c
[...]
> @@ -145,7 +144,7 @@ static int ams_delta_panel_probe(struct platform_device *pdev)
> &ams_delta_lcd_ops);
>
> if (IS_ERR(lcd_device)) {
> - ret = PTR_ERR(lcd_device);
> + int ret = PTR_ERR(lcd_device);
How about inserting an empty line after declaration?
> dev_err(&pdev->dev, "failed to register device\n");
> return ret;
> }
MBR, Sergey
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 00/12] Fix broken usage of driver_override (and kfree of static memory)
From: Krzysztof Kozlowski @ 2022-04-20 9:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki
Cc: Stuart Yoder, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, Dexuan Cui, Bjorn Helgaas, Bjorn Andersson,
Mathieu Poirier, Vineeth Vijayan, Peter Oberparleiter,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Andy Gross, linux-kernel,
linux-clk, NXP Linux Team, linux-arm-kernel, linux-hyperv,
linux-pci, linux-remoteproc, linux-s390, linux-arm-msm,
alsa-devel, linux-spi, virtualization, Linus Torvalds,
Rasmus Villemoes, Andy Shevchenko
In-Reply-To: <20220419113435.246203-1-krzysztof.kozlowski@linaro.org>
On 19/04/2022 13:34, Krzysztof Kozlowski wrote:
Hi Greg, Rafael,
The patchset was for some time on the lists, got some reviews, some
changes/feedback which I hope I applied/responded.
Entire set depends on the driver core changes, so maybe you could pick
up everything via drivers core tree?
> Dependencies (and stable):
> ==========================
> 1. All patches, including last three fixes, depend on the first patch
> introducing the helper.
> 2. The last three commits - fixes - are probably not backportable
> directly, because of this dependency. I don't know how to express
> this dependency here, since stable-kernel-rules.rst mentions only commits as
> possible dependencies.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] phy: freescale: imx8m-pcie: Handle IMX8_PCIE_REFCLK_PAD_UNUSED
From: Vinod Koul @ 2022-04-20 9:16 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-phy, Richard Zhu, Fabio Estevam, Kishon Vijay Abraham I,
Marcel Ziswiler, NXP Linux Team, Peng Fan, Shawn Guo,
linux-arm-kernel
In-Reply-To: <20220413140710.10074-1-marex@denx.de>
On 13-04-22, 16:07, Marek Vasut wrote:
> The 'fsl,refclk-pad-mode' DT property used to select clock source for
> PCIe PHY can have either of three values, IMX8_PCIE_REFCLK_PAD_INPUT,
> IMX8_PCIE_REFCLK_PAD_OUTPUT, IMX8_PCIE_REFCLK_PAD_UNUSED. The first
> two options are handled correctly by the driver, the last one is not,
> this patch implements support for the last option.
>
> The IMX8_PCIE_REFCLK_PAD_INPUT means PCIE_RESREF is PHY clock input,
> the IMX8_PCIE_REFCLK_PAD_OUTPUT means PHY clock are sourced from SoC
> internal PLL and output to PCIE_RESREF external IO pin. The last
> IMX8_PCIE_REFCLK_PAD_UNUSED is a combination of previous two, PHY
> clock are sourced from SoC internal PLL and not output anywhere.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/6] ASoC: dmaengine: do not use a NULL prepare_slave_config() callback
From: Sascha Hauer @ 2022-04-20 9:15 UTC (permalink / raw)
To: Codrin Ciubotariu
Cc: devicetree, alsa-devel, lars, tiwai, linux-kernel, robh+dt, perex,
broonie, linux-arm-kernel
In-Reply-To: <20220307122202.2251639-2-codrin.ciubotariu@microchip.com>
Hi,
On Mon, Mar 07, 2022 at 02:21:57PM +0200, Codrin Ciubotariu wrote:
> Even if struct snd_dmaengine_pcm_config is used, prepare_slave_config()
> callback might not be set. Check if this callback is set before using it.
>
> Fixes: fa654e085300 ("ASoC: dmaengine-pcm: Provide default config")
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
>
> Changes in v2,v3:
> - none
>
> sound/soc/soc-generic-dmaengine-pcm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
> index 285441d6aeed..2ab2ddc1294d 100644
> --- a/sound/soc/soc-generic-dmaengine-pcm.c
> +++ b/sound/soc/soc-generic-dmaengine-pcm.c
> @@ -86,10 +86,10 @@ static int dmaengine_pcm_hw_params(struct snd_soc_component *component,
>
> memset(&slave_config, 0, sizeof(slave_config));
>
> - if (!pcm->config)
> - prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config;
> - else
> + if (pcm->config && pcm->config->prepare_slave_config)
> prepare_slave_config = pcm->config->prepare_slave_config;
> + else
> + prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config;
>
> if (prepare_slave_config) {
> int ret = prepare_slave_config(substream, params, &slave_config);
I wonder if this patch is correct. There are drivers like
sound/soc/mxs/mxs-pcm.c which call snd_dmaengine_pcm_register() with a
config which has the prepare_slave_config callback unset. For these
drivers dmaengine_pcm_hw_params() previously was a no-op. Now with this
patch snd_dmaengine_pcm_prepare_slave_config() and
dmaengine_slave_config() are called. At least for the mxs-pcm driver
calling dmaengine_slave_config() will return -ENOSYS.
At least the "Check if this callback is set before using it" part is
wrong, the callback is checked before using it with
if (prepare_slave_config) {
...
}
I don't have any mxs hardware at hand to test this. I just stumbled upon
the change of behaviour when rebasing
https://patchwork.kernel.org/project/alsa-devel/patch/20220301122111.1073174-1-s.hauer@pengutronix.de/
on current master.
Sascha
--
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-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] phy: rockchip-inno-usb2: RK356x OTG fix and enhancements
From: Vinod Koul @ 2022-04-20 9:14 UTC (permalink / raw)
To: Samuel Holland
Cc: Kishon Vijay Abraham I, Heiko Stuebner, Peter Geis,
linux-arm-kernel, linux-kernel, linux-phy, linux-rockchip
In-Reply-To: <20220414032258.40984-1-samuel@sholland.org>
On 13-04-22, 22:22, Samuel Holland wrote:
> This series gets USB OTG working on the RK356x SoCs, as used in the
> PineNote tablet.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] thermal: imx: Update critical temp threshold
From: Francesco Dolcini @ 2022-04-20 9:13 UTC (permalink / raw)
To: Rafael J . Wysocki, Daniel Lezcano, linux-pm
Cc: Francesco Dolcini, Amit Kucheria, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
linux-arm-kernel, Tim Harvey, Jon Nettleton
Increase the critical temperature threshold to the datasheet defined
value according to the temperature grade of the SoC, increasing the
actual critical temperature value of 5 degrees.
Without this change the emergency shutdown will trigger earlier then
required affecting applications that are expected to be working on this
close to the limit, but yet valid, temperature range.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Not sure if there is an alternative to this patch, the critical threshold seems
to be read-only and it is not possible to just change it from user space that
would be my preferred solution.
According to the original discussion [1] the reasoning was the following:
On Tue, Jul 28, 2015 at 4:50 PM, Tim Harvey <tharvey@gateworks.com> wrote:
> Yes - the purpose of lowering the critical threshold from the hardware
> default is to allow Linux to shutdown more cleanly.
But I do not understand it.
[1] https://lore.kernel.org/all/CAJ+vNU1PQZa9KoCU9o_ws6jAAjhGVJby-1P583SVejT5TrAFTQ@mail.gmail.com/
---
drivers/thermal/imx_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 16663373b682..75a631a23e61 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -504,10 +504,10 @@ static void imx_init_temp_grade(struct platform_device *pdev, u32 ocotp_mem0)
}
/*
- * Set the critical trip point at 5 °C under max
+ * Set the critical trip point at max
* Set the passive trip point at 10 °C under max (changeable via sysfs)
*/
- data->temp_critical = data->temp_max - (1000 * 5);
+ data->temp_critical = data->temp_max;
data->temp_passive = data->temp_max - (1000 * 10);
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] phy: amlogic: fix error path in phy_g12a_usb3_pcie_probe()
From: Vinod Koul @ 2022-04-20 9:13 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Kishon Vijay Abraham I, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-phy, linux-arm-kernel,
open list:ARM/Amlogic Meson...
In-Reply-To: <8e416f95-1084-ee28-860e-7884f7fa2e32@gmail.com>
On 15-04-22, 16:03, Heiner Kallweit wrote:
> If clk_prepare_enable() fails we call clk_disable_unprepare()
> in the error path what results in a warning that the clock
> is disabled and unprepared already.
> And if we fail later in phy_g12a_usb3_pcie_probe() then we
> bail out w/o calling clk_disable_unprepare().
> This patch fixes both errors.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/8] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2
From: Vinod Koul @ 2022-04-20 9:10 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-phy, Yong Deng, Mauro Carvalho Chehab,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Sakari Ailus, Hans Verkuil, Laurent Pinchart,
Kishon Vijay Abraham I, Maxime Ripard, Thomas Petazzoni
In-Reply-To: <20220415152138.635525-3-paul.kocialkowski@bootlin.com>
On 15-04-22, 17:21, Paul Kocialkowski wrote:
> The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter
> is already supported and used for MIPI DSI this adds support for the
> former, to be used with MIPI CSI-2.
>
> This implementation is inspired by Allwinner's V3s Linux SDK
> implementation, which was used as a documentation base.
>
> It uses the direction dt property to distinguish between tx and rx
> directions.
Applied to phy-next, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: sun6i-a31-mipi-dphy: Add optional direction property
From: Vinod Koul @ 2022-04-20 9:10 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-phy, Yong Deng, Mauro Carvalho Chehab,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Sakari Ailus, Hans Verkuil, Laurent Pinchart,
Kishon Vijay Abraham I, Maxime Ripard, Thomas Petazzoni,
Rob Herring
In-Reply-To: <20220415152138.635525-2-paul.kocialkowski@bootlin.com>
On 15-04-22, 17:21, Paul Kocialkowski wrote:
> The Allwinner A31 MIPI D-PHY block supports both tx and rx directions,
> although each instance of the block is meant to be used in one
> direction only. There will typically be one instance for MIPI DSI and
> one for MIPI CSI-2 (it seems unlikely to ever see a shared instance).
>
> Describe the direction with a new allwinner,direction property.
> For backwards compatibility, the property is optional and tx mode
> should be assumed by default.
Applied to phy-next, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: mt8183-kukui: align SPI NOR node name with dtschema
From: Krzysztof Kozlowski @ 2022-04-20 9:10 UTC (permalink / raw)
To: linux-mediatek, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, linux-arm-kernel, Matthias Brugger,
Krzysztof Kozlowski
In-Reply-To: <20220407142143.293740-1-krzysztof.kozlowski@linaro.org>
On Thu, 7 Apr 2022 16:21:43 +0200, Krzysztof Kozlowski wrote:
> The node names should be generic and SPI NOR dtschema expects "flash".
>
>
Looks like no one wants to take this, so let me take care of it.
Applied, thanks!
[1/1] arm64: dts: mt8183-kukui: align SPI NOR node name with dtschema
commit: 4e3ffebd69e0aada1ce6bf4bf832e14a3c4f50db
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH 2/2] arm64: dts: microchip: align SPI NOR node name with dtschema
From: Krzysztof Kozlowski @ 2022-04-20 9:10 UTC (permalink / raw)
To: Alexandre Belloni, devicetree, Steen Hegelund, Lars Povlsen,
Rob Herring, linux-kernel, linux-arm-kernel, Krzysztof Kozlowski,
Krzysztof Kozlowski, Claudiu Beznea, Nicolas Ferre,
UNGLinuxDriver
In-Reply-To: <20220407143223.295344-2-krzysztof.kozlowski@linaro.org>
On Thu, 7 Apr 2022 16:32:23 +0200, Krzysztof Kozlowski wrote:
> The node names should be generic and SPI NOR dtschema expects "flash".
>
>
Looks like no one wants to take this, so let me take care of it.
Applied, thanks!
[2/2] arm64: dts: microchip: align SPI NOR node name with dtschema
commit: b5ff234ffa602bea7f7409dea427596fbe72561c
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: marvell: align SPI NOR node name with dtschema
From: Krzysztof Kozlowski @ 2022-04-20 9:10 UTC (permalink / raw)
To: Luka Perkov, Andrew Lunn, Russell King, devicetree,
Gregory Clement, Sebastian Hesselbarth, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Vladimir Vid, linux-arm-kernel,
Krzysztof Kozlowski, Luka Kovacic
In-Reply-To: <20220407143234.295426-1-krzysztof.kozlowski@linaro.org>
On Thu, 7 Apr 2022 16:32:33 +0200, Krzysztof Kozlowski wrote:
> The node names should be generic and SPI NOR dtschema expects "flash".
>
>
Looks like no one wants to take this, so let me take care of it.
Applied, thanks!
[1/2] ARM: dts: marvell: align SPI NOR node name with dtschema
commit: 9cc510ff788ce2f93e45c64767a8215363735a2e
[2/2] arm64: dts: marvell: align SPI NOR node name with dtschema
commit: 456e580bf08fd9a0f499ad64fbe1a2b6e89add0d
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] spi: stm32: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
From: cgel.zte @ 2022-04-20 9:04 UTC (permalink / raw)
To: alain.volmat
Cc: broonie, linux-spi, linux-stm32, linux-arm-kernel, linux-kernel,
Minghao Chi, Zeal Robot
From: Minghao Chi <chi.minghao@zte.com.cn>
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
---
drivers/spi/spi-stm32.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index a6adc20f6862..6fe617b445a5 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -2000,9 +2000,8 @@ static int __maybe_unused stm32_spi_resume(struct device *dev)
return ret;
}
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
- pm_runtime_put_noidle(dev);
dev_err(dev, "Unable to power device:%d\n", ret);
return ret;
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] spi: mxs: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
From: cgel.zte @ 2022-04-20 9:04 UTC (permalink / raw)
To: broonie
Cc: shawnguo, linux-spi, linux-arm-kernel, linux-kernel, Minghao Chi,
Zeal Robot
From: Minghao Chi <chi.minghao@zte.com.cn>
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
---
drivers/spi/spi-mxs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 435309b09227..55178579f3c6 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -605,9 +605,8 @@ static int mxs_spi_probe(struct platform_device *pdev)
}
}
- ret = pm_runtime_get_sync(ssp->dev);
+ ret = pm_runtime_resume_and_get(ssp->dev);
if (ret < 0) {
- pm_runtime_put_noidle(ssp->dev);
dev_err(ssp->dev, "runtime_get_sync failed\n");
goto out_pm_runtime_disable;
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: keystone: fix missing fallback and case in SPI NOR node compatible
From: Krzysztof Kozlowski @ 2022-04-20 9:02 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar, Rob Herring,
Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20220420090247.73410-1-krzysztof.kozlowski@linaro.org>
Vendor prefix in compatible should be lower-case and the jedec,spi-nor
should be used as fallback, according to the bindings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes since v1:
1. Add fallback (Nishanth).
2. Got review from Grygorii but due to changes not including it here.
---
arch/arm/boot/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2l-evm.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts b/arch/arm/boot/dts/keystone-k2e-evm.dts
index 8f49883a675e..5d6d074011df 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -140,7 +140,7 @@ &spi0 {
nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "Micron,n25q128a11";
+ compatible = "micron,n25q128a11", "jedec,spi-nor";
spi-max-frequency = <54000000>;
m25p,fast-read;
reg = <0>;
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index f968af0bfad3..4a91f5ded402 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -164,7 +164,7 @@ &spi0 {
nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "Micron,n25q128a11";
+ compatible = "micron,n25q128a11", "jedec,spi-nor";
spi-max-frequency = <54000000>;
m25p,fast-read;
reg = <0>;
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts b/arch/arm/boot/dts/keystone-k2l-evm.dts
index 32619b3c5804..1c880cf8fa91 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -113,7 +113,7 @@ &spi0 {
nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "Micron,n25q128a11";
+ compatible = "micron,n25q128a11", "jedec,spi-nor";
spi-max-frequency = <54000000>;
m25p,fast-read;
reg = <0>;
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: keystone: align SPI NOR node name with dtschema
From: Krzysztof Kozlowski @ 2022-04-20 9:02 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar, Rob Herring,
Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Grygorii Strashko
The node names should be generic and SPI NOR dtschema expects "flash".
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Changes since v1:
1. Add review tag.
---
arch/arm/boot/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2g-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2g-ice.dts | 2 +-
arch/arm/boot/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2l-evm.dts | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts b/arch/arm/boot/dts/keystone-k2e-evm.dts
index 66fec5f5d081..8f49883a675e 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -137,7 +137,7 @@ partition@180000 {
};
&spi0 {
- nor_flash: n25q128a11@0 {
+ nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "Micron,n25q128a11";
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index d800f26b6275..88be868cf71e 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -392,7 +392,7 @@ &qspi {
pinctrl-0 = <&qspi_pins>;
cdns,rclk-en;
- flash0: m25p80@0 {
+ flash0: flash@0 {
compatible = "s25fl512s", "jedec,spi-nor";
reg = <0>;
spi-tx-bus-width = <1>;
diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts b/arch/arm/boot/dts/keystone-k2g-ice.dts
index 2a2d38cf0fff..bd84d7f0f2fe 100644
--- a/arch/arm/boot/dts/keystone-k2g-ice.dts
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -325,7 +325,7 @@ &qspi {
cdns,rclk-en;
status = "okay";
- flash0: m25p80@0 {
+ flash0: flash@0 {
compatible = "s25fl256s1", "jedec,spi-nor";
reg = <0>;
spi-tx-bus-width = <1>;
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index ad4e22afe133..f968af0bfad3 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -161,7 +161,7 @@ dtt@50 {
};
&spi0 {
- nor_flash: n25q128a11@0 {
+ nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "Micron,n25q128a11";
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts b/arch/arm/boot/dts/keystone-k2l-evm.dts
index e200533d26a4..32619b3c5804 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -110,7 +110,7 @@ partition@180000 {
};
&spi0 {
- nor_flash: n25q128a11@0 {
+ nor_flash: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "Micron,n25q128a11";
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests
From: Oleksandr @ 2022-04-20 9:00 UTC (permalink / raw)
To: Stefano Stabellini, Juergen Gross
Cc: Christoph Hellwig, xen-devel, linux-kernel, linux-arm-kernel,
Oleksandr Tyshchenko, Boris Ostrovsky, Julien Grall,
Michael S. Tsirkin
In-Reply-To: <alpine.DEB.2.22.394.2204191717020.915916@ubuntu-linux-20-04-desktop>
Hello Stefano, Juergen
On 20.04.22 03:23, Stefano Stabellini wrote:
> On Tue, 19 Apr 2022, Oleksandr wrote:
>> On 19.04.22 17:48, Juergen Gross wrote:
>>> On 19.04.22 14:17, Oleksandr wrote:
>>>> Hello Stefano, Juergen
>>>>
>>>>
>>>> On 18.04.22 22:11, Stefano Stabellini wrote:
>>>>> On Mon, 18 Apr 2022, Oleksandr wrote:
>>>>>> On 16.04.22 09:07, Christoph Hellwig wrote:
>>>>>>
>>>>>> Hello Christoph
>>>>>>
>>>>>>> On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
>>>>>>>> This makes sense overall. Considering that the swiotlb-xen case
>>>>>>>> and the
>>>>>>>> virtio case are mutually exclusive, I would write it like this:
>>>>>>> Curious question: Why can't the same grant scheme also be used for
>>>>>>> non-virtio devices? I really hate having virtio hooks in the arch
>>>>>>> dma code. Why can't Xen just say in DT/ACPI that grants can be used
>>>>>>> for a given device?
>>>>> [...]
>>>>>
>>>>>> This patch series tries to make things work with "virtio" devices in
>>>>>> Xen
>>>>>> system without introducing any modifications to code under
>>>>>> drivers/virtio.
>>>>> Actually, I think Christoph has a point.
>>>>>
>>>>> There is nothing inherently virtio specific in this patch series or in
>>>>> the "xen,dev-domid" device tree binding.
>>>>
>>>> Although the main intention of this series was to enable using virtio
>>>> devices in Xen guests, I agree that nothing in new DMA ops layer
>>>> (xen-virtio.c) is virtio specific (at least at the moment). Regarding the
>>>> whole patch series I am not quite sure, as it uses
>>>> arch_has_restricted_virtio_memory_access(). >
>>>>> Assuming a given device is
>>>>> emulated by a Xen backend, it could be used with grants as well.
>>>>>
>>>>> For instance, we could provide an emulated e1000 NIC with a
>>>>> "xen,dev-domid" property in device tree. Linux could use grants with it
>>>>> and the backend could map the grants. It would work the same way as
>>>>> virtio-net/block/etc. Passthrough devices wouldn't have the
>>>>> "xen,dev-domid" property, so no problems.
>>>>>
>>>>> So I think we could easily generalize this work and expand it to any
>>>>> device. We just need to hook on the "xen,dev-domid" device tree
>>>>> property.
>>>>>
>>>>> I think it is just a matter of:
>>>>> - remove the "virtio,mmio" check from xen_is_virtio_device
>>>>> - rename xen_is_virtio_device to something more generic, like
>>>>> xen_is_grants_device
>>> xen_is_grants_dma_device, please. Normal Xen PV devices are covered by
>>> grants, too, and I'd like to avoid the confusion arising from this.
>>
>> yes, this definitely makes sense as we need to distinguish
>>
>>
>>>
>>>>> - rename xen_virtio_setup_dma_ops to something more generic, like
>>>>> xen_grants_setup_dma_ops
>>>>>
>>>>> And that's pretty much it.
>>>> + likely renaming everything in that patch series not to mention virtio
>>>> (mostly related to xen-virtio.c internals).
>>>>
>>>>
>>>> Stefano, thank you for clarifying Christoph's point.
>>>>
>>>> Well, I am not against going this direction. Could we please make a
>>>> decision on this? @Juergen, what is your opinion?
>>> Yes, why not.
>>
>> ok, thank you for confirming.
>>
>>
>>>
>>> Maybe rename xen-virtio.c to grant-dma.c?
>>
>> Personally I don't mind.
>>
>>
>>> I'd keep the XEN_VIRTIO related config option, as this will be the normal
>>> use
>>> case. grant-dma.c should be covered by a new hidden config option
>>> XEN_GRANT_DMA
>>> selected by XEN_VIRTIO.
>>
>> I got it, ok
>>
>>
>>>
>>> CONFIG_XEN_VIRTIO should still guard
>>> xen_has_restricted_virtio_memory_access().
>>
>> ok
>>
>>
>> So a few questions to clarify:
>>
>> 1. What is the best place to keep "xen,dev-domid" binding's description now? I
>> think that proposed in current series place
>> (Documentation/devicetree/bindings/virtio/) is not good fit now.
> I would probably add it to the existing
> Documentation/devicetree/bindings/arm/xen.txt.
>
>
>> 2. I assume the logic in the current patch will remain the same, I mean we
>> will still assign Xen grant DMA ops from xen_setup_dma_ops() here?
> Yes I think so
Stefano, thank you for clarifying!
Regarding new naming scheme...
As there is an existing Kconfig option XEN_GRANT_DMA_ALLOC used for
different purpose, we need to clarify naming scheme here a bit to avoid
possible confusion.
For example, I am happy with proposed by Juergen ...
... Kconfig option: XEN_GRANT_DMA_OPS
and
... file: grant-dma-ops.c
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox