* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Herbert Xu @ 2020-05-29 11:51 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, Stephan Mueller, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <CAMj1kXE43VvEXyYQF=s5HybhF6Wq23wDTrvTfNV9d4fUVZZ8aw@mail.gmail.com>
On Fri, May 29, 2020 at 10:20:27AM +0200, Ard Biesheuvel wrote:
>
> But many implementation do not return an output IV at all. The only
> mode that requires it (for the selftests to pass) is CBC.
Most modes can be chained, e.g., CBC, PCBC, OFB, CFB and CTR.
As it stands algif_skcipher requres all algorithms to support
chaining.
> For XTS, we would have to carry some metadata around that tells you
> whether the initial encryption of the IV has occurred or not. In the
You're right, XTS in its current form cannot be chained. So we
do need a way to mark that for algif_skcipher.
> CTS case, you need two swap the last two blocks of ciphertext at the
> very end.
CTS can be easily chained. You just need to always keep two blocks
from being processed until you reach the end.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
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] Bluetooth: btmtkuart: Improve exception handling in btmtuart_probe()
From: Marcel Holtmann @ 2020-05-29 11:41 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Johan Hedberg, Sean Wang, linux-kernel,
open list:BLUETOOTH DRIVERS, Markus Elfring, Matthias Brugger,
linux-mediatek, linux-arm-kernel
In-Reply-To: <20200529022726.917826-1-hslester96@gmail.com>
Hi Chuhong,
> Calls of the functions clk_disable_unprepare() and hci_free_dev()
> were missing for the exception handling.
> Thus add the missed function calls together with corresponding
> jump targets.
>
> Fixes: 055825614c6b ("Bluetooth: btmtkuart: add an implementation for clock osc property")
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v2:
> - Modify description.
> - Add fixes tag.
>
> drivers/bluetooth/btmtkuart.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
_______________________________________________
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/1] tty: serial: owl: Initialize lock before registering port
From: Andy Shevchenko @ 2020-05-29 11:35 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Greg Kroah-Hartman, Manivannan Sadhasivam, linux-actions,
Linux Kernel Mailing List, open list:SERIAL DRIVERS, Jiri Slaby,
Andy Shevchenko, Andreas Färber, linux-arm Mailing List
In-Reply-To: <89f6393934fc6d493f8b9e87c1a6e916642b6a18.1590749143.git.cristian.ciocaltea@gmail.com>
On Fri, May 29, 2020 at 2:09 PM Cristian Ciocaltea
<cristian.ciocaltea@gmail.com> wrote:
>
> Running a lockdep-enabled kernel leads to the following splat when
> probing the owl-uart driver:
>
> [ 1.271784] b0124000.serial: ttyOWL2 at MMIO 0xb0124000 (irq = 22, base_baud = 1500000) is a owl-uart
> [ 1.281226] INFO: trying to register non-static key.
> [ 1.286179] the code is fine but needs lockdep annotation.
> [ 1.291648] turning off the locking correctness validator.
> [ 1.297125] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc7+ #70
> [ 1.303462] Hardware name: Generic DT based system
> [ 1.308268] [<80111d3c>] (unwind_backtrace) from [<8010c9b8>] (show_stack+0x10/0x14)
> [ 1.316003] [<8010c9b8>] (show_stack) from [<805016b4>] (dump_stack+0xb4/0xe0)
> [ 1.323218] [<805016b4>] (dump_stack) from [<80182dec>] (register_lock_class+0x25c/0x8f4)
> [ 1.331391] [<80182dec>] (register_lock_class) from [<8017ee34>] (__lock_acquire+0xb4/0x2ee4)
> [ 1.339901] [<8017ee34>] (__lock_acquire) from [<8018291c>] (lock_acquire+0x424/0x4c8)
> [ 1.347813] [<8018291c>] (lock_acquire) from [<808597b0>] (_raw_spin_lock_irqsave+0x54/0x68)
> [ 1.356242] [<808597b0>] (_raw_spin_lock_irqsave) from [<80582e94>] (uart_add_one_port+0x384/0x510)
> [ 1.365276] [<80582e94>] (uart_add_one_port) from [<8058b4d0>] (owl_uart_probe+0x1bc/0x248)
> [ 1.373621] [<8058b4d0>] (owl_uart_probe) from [<8059c0e4>] (platform_drv_probe+0x48/0x94)
> [ 1.381874] [<8059c0e4>] (platform_drv_probe) from [<805997c4>] (really_probe+0x200/0x470)
> [ 1.390123] [<805997c4>] (really_probe) from [<80599c80>] (driver_probe_device+0x16c/0x1bc)
> [ 1.398461] [<80599c80>] (driver_probe_device) from [<80599f18>] (device_driver_attach+0x44/0x60)
> [ 1.407317] [<80599f18>] (device_driver_attach) from [<8059a078>] (__driver_attach+0x144/0x14c)
> [ 1.416000] [<8059a078>] (__driver_attach) from [<805978ac>] (bus_for_each_dev+0x5c/0xb4)
> [ 1.424162] [<805978ac>] (bus_for_each_dev) from [<8059896c>] (bus_add_driver+0x118/0x204)
> [ 1.432410] [<8059896c>] (bus_add_driver) from [<8059ae6c>] (driver_register+0xbc/0xf8)
> [ 1.440405] [<8059ae6c>] (driver_register) from [<80c1fd24>] (owl_uart_init+0x20/0x40)
> [ 1.448313] [<80c1fd24>] (owl_uart_init) from [<801021d8>] (do_one_initcall+0x184/0x3a4)
> [ 1.456399] [<801021d8>] (do_one_initcall) from [<80c01100>] (kernel_init_freeable+0x264/0x2e4)
> [ 1.465085] [<80c01100>] (kernel_init_freeable) from [<80850a88>] (kernel_init+0x8/0x110)
> [ 1.473249] [<80850a88>] (kernel_init) from [<80100114>] (ret_from_fork+0x14/0x20)
> [ 1.480800] Exception stack(0xee8bdfb0 to 0xee8bdff8)
> [ 1.485841] dfa0: 00000000 00000000 00000000 00000000
> [ 1.494002] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.502162] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 1.508914] printk: console [ttyOWL2] enabled
>
> The locking issue occurs in uart_configure_port() when trying to
> guard the call to set_mctrl().
>
> uart_add_one_port() should normally initialize the spinlock via
> uart_port_spin_lock_init(), but it never happens because the port is
> detected as a console and, as a consequence, the spinlock is expected
> to be already initialized.
>
> The commit a3cb39d258ef
> ("serial: core: Allow detach and attach serial device for console")
> changed the lock initialization logic to assume the spinlock is
> initialized even if the console is not enabled.
>
> Therefore, initialize the lock explicitly in owl_uart_probe(), before
> attempting to invoke uart_add_one_port().
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
You are faster than me, thanks!
> Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> ---
> drivers/tty/serial/owl-uart.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> index c149f8c30007..c2fa2f15d50a 100644
> --- a/drivers/tty/serial/owl-uart.c
> +++ b/drivers/tty/serial/owl-uart.c
> @@ -705,6 +705,8 @@ static int owl_uart_probe(struct platform_device *pdev)
> owl_uart_ports[pdev->id] = owl_port;
> platform_set_drvdata(pdev, owl_port);
>
> + spin_lock_init(&owl_port->port.lock);
> +
> ret = uart_add_one_port(&owl_uart_driver, &owl_port->port);
> if (ret)
> owl_uart_ports[pdev->id] = NULL;
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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/1] tty: serial: owl: Initialize lock before registering port
From: Greg Kroah-Hartman @ 2020-05-29 11:34 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Manivannan Sadhasivam, linux-actions, linux-kernel, linux-serial,
Jiri Slaby, Andy Shevchenko, Andreas Färber,
linux-arm-kernel
In-Reply-To: <89f6393934fc6d493f8b9e87c1a6e916642b6a18.1590749143.git.cristian.ciocaltea@gmail.com>
On Fri, May 29, 2020 at 02:06:47PM +0300, Cristian Ciocaltea wrote:
> Running a lockdep-enabled kernel leads to the following splat when
> probing the owl-uart driver:
>
> [ 1.271784] b0124000.serial: ttyOWL2 at MMIO 0xb0124000 (irq = 22, base_baud = 1500000) is a owl-uart
> [ 1.281226] INFO: trying to register non-static key.
> [ 1.286179] the code is fine but needs lockdep annotation.
> [ 1.291648] turning off the locking correctness validator.
> [ 1.297125] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc7+ #70
> [ 1.303462] Hardware name: Generic DT based system
> [ 1.308268] [<80111d3c>] (unwind_backtrace) from [<8010c9b8>] (show_stack+0x10/0x14)
> [ 1.316003] [<8010c9b8>] (show_stack) from [<805016b4>] (dump_stack+0xb4/0xe0)
> [ 1.323218] [<805016b4>] (dump_stack) from [<80182dec>] (register_lock_class+0x25c/0x8f4)
> [ 1.331391] [<80182dec>] (register_lock_class) from [<8017ee34>] (__lock_acquire+0xb4/0x2ee4)
> [ 1.339901] [<8017ee34>] (__lock_acquire) from [<8018291c>] (lock_acquire+0x424/0x4c8)
> [ 1.347813] [<8018291c>] (lock_acquire) from [<808597b0>] (_raw_spin_lock_irqsave+0x54/0x68)
> [ 1.356242] [<808597b0>] (_raw_spin_lock_irqsave) from [<80582e94>] (uart_add_one_port+0x384/0x510)
> [ 1.365276] [<80582e94>] (uart_add_one_port) from [<8058b4d0>] (owl_uart_probe+0x1bc/0x248)
> [ 1.373621] [<8058b4d0>] (owl_uart_probe) from [<8059c0e4>] (platform_drv_probe+0x48/0x94)
> [ 1.381874] [<8059c0e4>] (platform_drv_probe) from [<805997c4>] (really_probe+0x200/0x470)
> [ 1.390123] [<805997c4>] (really_probe) from [<80599c80>] (driver_probe_device+0x16c/0x1bc)
> [ 1.398461] [<80599c80>] (driver_probe_device) from [<80599f18>] (device_driver_attach+0x44/0x60)
> [ 1.407317] [<80599f18>] (device_driver_attach) from [<8059a078>] (__driver_attach+0x144/0x14c)
> [ 1.416000] [<8059a078>] (__driver_attach) from [<805978ac>] (bus_for_each_dev+0x5c/0xb4)
> [ 1.424162] [<805978ac>] (bus_for_each_dev) from [<8059896c>] (bus_add_driver+0x118/0x204)
> [ 1.432410] [<8059896c>] (bus_add_driver) from [<8059ae6c>] (driver_register+0xbc/0xf8)
> [ 1.440405] [<8059ae6c>] (driver_register) from [<80c1fd24>] (owl_uart_init+0x20/0x40)
> [ 1.448313] [<80c1fd24>] (owl_uart_init) from [<801021d8>] (do_one_initcall+0x184/0x3a4)
> [ 1.456399] [<801021d8>] (do_one_initcall) from [<80c01100>] (kernel_init_freeable+0x264/0x2e4)
> [ 1.465085] [<80c01100>] (kernel_init_freeable) from [<80850a88>] (kernel_init+0x8/0x110)
> [ 1.473249] [<80850a88>] (kernel_init) from [<80100114>] (ret_from_fork+0x14/0x20)
> [ 1.480800] Exception stack(0xee8bdfb0 to 0xee8bdff8)
> [ 1.485841] dfa0: 00000000 00000000 00000000 00000000
> [ 1.494002] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.502162] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 1.508914] printk: console [ttyOWL2] enabled
>
> The locking issue occurs in uart_configure_port() when trying to
> guard the call to set_mctrl().
>
> uart_add_one_port() should normally initialize the spinlock via
> uart_port_spin_lock_init(), but it never happens because the port is
> detected as a console and, as a consequence, the spinlock is expected
> to be already initialized.
>
> The commit a3cb39d258ef
> ("serial: core: Allow detach and attach serial device for console")
> changed the lock initialization logic to assume the spinlock is
> initialized even if the console is not enabled.
>
> Therefore, initialize the lock explicitly in owl_uart_probe(), before
> attempting to invoke uart_add_one_port().
>
> Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> ---
> drivers/tty/serial/owl-uart.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> index c149f8c30007..c2fa2f15d50a 100644
> --- a/drivers/tty/serial/owl-uart.c
> +++ b/drivers/tty/serial/owl-uart.c
> @@ -705,6 +705,8 @@ static int owl_uart_probe(struct platform_device *pdev)
> owl_uart_ports[pdev->id] = owl_port;
> platform_set_drvdata(pdev, owl_port);
>
> + spin_lock_init(&owl_port->port.lock);
> +
> ret = uart_add_one_port(&owl_uart_driver, &owl_port->port);
> if (ret)
> owl_uart_ports[pdev->id] = NULL;
Ugh, another one :(
Thanks for this, will queue this up now.
greg k-h
_______________________________________________
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] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Tzung-Bi Shih @ 2020-05-29 11:22 UTC (permalink / raw)
To: Mark Brown
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20200529110915.GH4610@sirena.org.uk>
On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 07:04:53PM +0800, Jiaxin Yu wrote:
> > Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
>
> What is DMIC one wire mode? This doesn't sound like something I'd
> expect to vary at runtime.
It means: 1 PDM data wire carries 2 channel data (rising edge for left
and falling edge for right).
The setting shouldn't and won't change at runtime. Would you suggest
putting it into DTS binding?
_______________________________________________
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 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect()
From: Catalin Marinas @ 2020-05-29 11:19 UTC (permalink / raw)
To: Evgenii Stepanov
Cc: linux-arch, nd, Szabolcs Nagy, Peter Collingbourne, Kevin Brodsky,
Linux Memory Management List, Andrey Konovalov, Vincenzo Frascino,
Will Deacon, Dave P Martin, Linux ARM
In-Reply-To: <CAFKCwri+X=de0gFrMZfA84dYmftSkcDc0DEvQ2JAmeOw2sLR=A@mail.gmail.com>
On Thu, May 28, 2020 at 11:35:50AM -0700, Evgenii Stepanov wrote:
> On Thu, May 28, 2020 at 9:34 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, May 28, 2020 at 12:05:09PM +0100, Szabolcs Nagy wrote:
> > > On 05/28/2020 10:14, Catalin Marinas wrote:
> > > > I don't think the stack initialisation is that difficult. On program
> > > > startup (can be the dynamic loader). Something like (untested):
> > > >
> > > > register unsigned long stack asm ("sp");
> > > > unsigned long page_sz = sysconf(_SC_PAGESIZE);
> > > >
> > > > mprotect((void *)(stack & ~(page_sz - 1)), page_sz,
> > > > PROT_READ | PROT_WRITE | PROT_MTE | PROT_GROWSDOWN);
> > > >
> > > > (the essential part it PROT_GROWSDOWN so that you don't have to specify
> > > > a stack lower limit)
> > >
> > > does this work even if the currently mapped stack is more than page_sz?
> > > determining the mapped main stack area is i think non-trivial to do in
> > > userspace (requires parsing /proc/self/maps or similar).
> >
> > Because of PROT_GROWSDOWN, the kernel adjusts the start of the range
> > down automatically. It is potentially problematic if the top of the
> > stack is more than a page away and you want the whole stack coloured. I
> > haven't run a test but my reading of the kernel code is that the stack
> > vma would be split in this scenario, so the range beyond sp+page_sz
> > won't have PROT_MTE set.
> >
> > My assumption is that if you do this during program start, the stack is
> > smaller than a page. Alternatively, could we use argv or envp to
> > determine the top of the user stack (the bottom is taken care of by the
> > kernel)?
>
> PROT_GROWSDOWN seems to work fine in our case, and the extra tag
> maintenance overhead sounds like a valid argument against setting PROT_MTE
> unconditionally.
>
> On the other hand, we may end up doing this in the userspace in every
> process. The reason is, PROT_MTE can not be set on a page that contains a
> live frame with stack tagging because of mismatching tags (IRG is not
> affected by PROT_MTE but STG is). So ideally, this should be done at (or
> near) the program entry point, while the stack is mostly empty.
Since stack tagging cannot use instructions in the NOP space anyway, I
think we need an ELF note to check for the presence of STG etc. and, in
addition, we can turn PROT_MTE by default on the initial stack. Maybe on
such binaries we could just set PROT_MTE on all anonymous and ramfs
mappings (i.e. VM_MTE_ALLOWED implies VM_MTE).
For dynamically linked binaries, we base this decision on the main ELF,
not the interpreter, and it would be up to the dynamic loader to reject
libraries that have such note when HWCAP2_MTE is not present.
> > > (and eventually there should be a way to use PROT_MTE on
> > > writable global data and appropriate code generation that
> > > takes colors into account when globals are accessed, but
> > > that requires significant ELF, ld.so and compiler changes,
> > > that need not be part of the initial mte design).
> >
> > The .data section needs to be driven by the ELF information. It's also a
> > file mapping and we don't support PROT_MTE on them even if MAP_PRIVATE.
> > There are complications like DAX where the file you mmap for CoW may be
> > hosted on memory that does not support MTE (copied to RAM on write).
> >
> > Is there a use-case for global data to be tagged?
>
> Yes, catching global buffer overflow bugs. They are not nearly as
> common as heap-based issues though.
OK, so these would be tagged red-zones around global data. IIUC, having
different colours for global variables was not considered because of the
relocations and relative accesses.
If such red-zone colouring is done during load (the dynamic linker?), we
could set PROT_MTE only when MAP_PRIVATE and copied on write to make
sure it is in RAM. As above, I think this should be driven by some ELF
information.
There's also the option of scrapping PROT_MTE altogether and enabling
MTE (default tag 0) on all anonymous and private+copied pages (i.e.
those stored in RAM). At this point, I can't really tell whether there
will be a performance impact.
--
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 04/12] dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
From: Lokesh Vutla @ 2020-05-29 11:13 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Marc Zyngier, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200528221406.GA769073@bogus>
Hi Rob,
[..snip..]
>>
>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> index 1a8718f8855d..8b56b2de1c73 100644
>> --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> @@ -44,15 +44,17 @@ Required Properties:
>> 4: If intr supports level triggered interrupts.
>> - interrupt-controller: Identifies the node as an interrupt controller
>> - #interrupt-cells: Specifies the number of cells needed to encode an
>> - interrupt source. The value should be 2.
>> - First cell should contain the TISCI device ID of source
>> - Second cell should contain the interrupt source offset
>> - within the device.
>> + interrupt source. The value should be 1.
>> + First cell should contain interrupt router input number
>> + as specified by hardware.
>> - ti,sci: Phandle to TI-SCI compatible System controller node.
>> -- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
>> -- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
>> - assigned to this interrupt router. Each subtype id
>> - corresponds to a range of host irqs.
>> +- ti,sci-dev-id: TISCI device id of interrupt controller.
>> +- ti,interrupt-ranges: Set of triplets containing ranges that convert
>> + the INTR output interrupt numbers to parent's
>> + interrupt number. Each triplet has following entries:
>> + - First entry specifies the base for intr output irq
>> + - Second entry specifies the base for parent irqs
>> + - Third entry specifies the limit
>
> Humm, sounds like what interrupt-map does.
IIUC, for every irq translation there should be an entry in interrupt-map
property. These Controllers has interrupts ranging from 32, 256 and more. It
might be odd to have 256 entries in the interrupt map no? Also there are
multiple interrupt controllers which need such translations.
Thanks and regards,
Lokesh
_______________________________________________
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 RFCv2 9/9] arm64: Support async page fault
From: Paolo Bonzini @ 2020-05-29 11:11 UTC (permalink / raw)
To: Marc Zyngier, Gavin Shan
Cc: catalin.marinas, linux-kernel, shan.gavin, will, kvmarm,
linux-arm-kernel
In-Reply-To: <6965aaf641a23fab64fbe2ceeb790272@kernel.org>
On 29/05/20 11:41, Marc Zyngier wrote:
>>>
>>>
>>> For x86 the advantage is that the processor can take care of raising the
>>> stage2 page fault in the guest, so it's faster.
>>>
>> I think there might be too much overhead if the page can be populated
>> quickly by host. For example, it's fast to populate the pages if swapin
>> isn't involved.
Those would still be handled by the host. Only those that are not
present in the host (which you can see through the MMU notifier) would
be routed to the guest. You can do things differently between "not
present fault because the page table does not exist" and "not present
fault because the page is missing in the host".
>> If I'm correct enough, it seems arm64 doesn't have similar mechanism,
>> routing stage2 page fault to guest.
>
> Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are
> always routed to EL2.
Is there an ARM-approved way to reuse the S2 fault syndromes to detect
async page faults?
(By the way, another "modern" use for async page faults is for postcopy
live migration).
Thanks,
Paolo
_______________________________________________
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] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Mark Brown @ 2020-05-29 11:09 UTC (permalink / raw)
To: Jiaxin Yu
Cc: hariprasad.kelam, alsa-devel, linux-kernel, howie.huang,
lgirdwood, tiwai, tzungbi, linux-mediatek, matthias.bgg,
linux-arm-kernel
In-Reply-To: <1590750293-12769-1-git-send-email-jiaxin.yu@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 229 bytes --]
On Fri, May 29, 2020 at 07:04:53PM +0800, Jiaxin Yu wrote:
> Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
What is DMIC one wire mode? This doesn't sound like something I'd
expect to vary at runtime.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] watchdog: sunxi_wdt: fix improper error exit code
From: Maxime Ripard @ 2020-05-29 11:08 UTC (permalink / raw)
To: Frank Lee
Cc: linux-watchdog, tiny.windzz, linux-kernel, wens, linux, wuyan,
wim, linux-arm-kernel
In-Reply-To: <20200529094514.26374-1-frank@allwinnertech.com>
[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]
On Fri, May 29, 2020 at 05:45:14PM +0800, Frank Lee wrote:
> From: Martin Wu <wuyan@allwinnertech.com>
>
> sunxi_wdt_probe() should return -ENOMEM when devm_kzalloc() fails.
>
> Signed-off-by: Martin Wu <wuyan@allwinnertech.com>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Jiaxin Yu @ 2020-05-29 11:04 UTC (permalink / raw)
To: lgirdwood, broonie, tiwai, matthias.bgg, hariprasad.kelam
Cc: alsa-devel, howie.huang, linux-kernel, Jiaxin Yu, tzungbi,
linux-mediatek, linux-arm-kernel
Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
---
sound/soc/codecs/mt6358.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c
index 1b830ea..ca7628d 100644
--- a/sound/soc/codecs/mt6358.c
+++ b/sound/soc/codecs/mt6358.c
@@ -95,6 +95,8 @@ struct mt6358_priv {
struct regulator *avdd_reg;
int wov_enabled;
+
+ int dmic_one_wire_mode;
};
int mt6358_set_mtkaif_protocol(struct snd_soc_component *cmpnt,
@@ -566,6 +568,28 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol,
return 0;
}
+static int mt6358_dmic_one_wire_mode_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol);
+ struct mt6358_priv *priv = snd_soc_component_get_drvdata(cmpnt);
+
+ ucontrol->value.integer.value[0] = priv->dmic_one_wire_mode;
+
+ return 0;
+}
+
+static int mt6358_dmic_one_wire_mode_set(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol);
+ struct mt6358_priv *priv = snd_soc_component_get_drvdata(cmpnt);
+
+ priv->dmic_one_wire_mode = ucontrol->value.integer.value[0];
+
+ return 0;
+}
+
static const DECLARE_TLV_DB_SCALE(playback_tlv, -1000, 100, 0);
static const DECLARE_TLV_DB_SCALE(pga_tlv, 0, 600, 0);
@@ -588,6 +612,10 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol,
SOC_SINGLE_BOOL_EXT("Wake-on-Voice Phase2 Switch", 0,
mt6358_get_wov, mt6358_put_wov),
+
+ SOC_SINGLE_BOOL_EXT("Dmic One Wire Mode", 0,
+ mt6358_dmic_one_wire_mode_get,
+ mt6358_dmic_one_wire_mode_set),
};
/* MUX */
@@ -1740,7 +1768,10 @@ static int mt6358_amic_enable(struct mt6358_priv *priv)
mt6358_mtkaif_tx_enable(priv);
/* UL dmic setting off */
- regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0000);
+ if (priv->dmic_one_wire_mode)
+ regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0400);
+ else
+ regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0080);
/* UL turn on */
regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_L, 0x0001);
--
1.8.1.1.dirty
_______________________________________________
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 1/1] tty: serial: owl: Initialize lock before registering port
From: Cristian Ciocaltea @ 2020-05-29 11:06 UTC (permalink / raw)
To: Andreas Färber, Manivannan Sadhasivam, Greg Kroah-Hartman,
Jiri Slaby, Andy Shevchenko
Cc: linux-actions, linux-arm-kernel, linux-serial, linux-kernel
Running a lockdep-enabled kernel leads to the following splat when
probing the owl-uart driver:
[ 1.271784] b0124000.serial: ttyOWL2 at MMIO 0xb0124000 (irq = 22, base_baud = 1500000) is a owl-uart
[ 1.281226] INFO: trying to register non-static key.
[ 1.286179] the code is fine but needs lockdep annotation.
[ 1.291648] turning off the locking correctness validator.
[ 1.297125] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc7+ #70
[ 1.303462] Hardware name: Generic DT based system
[ 1.308268] [<80111d3c>] (unwind_backtrace) from [<8010c9b8>] (show_stack+0x10/0x14)
[ 1.316003] [<8010c9b8>] (show_stack) from [<805016b4>] (dump_stack+0xb4/0xe0)
[ 1.323218] [<805016b4>] (dump_stack) from [<80182dec>] (register_lock_class+0x25c/0x8f4)
[ 1.331391] [<80182dec>] (register_lock_class) from [<8017ee34>] (__lock_acquire+0xb4/0x2ee4)
[ 1.339901] [<8017ee34>] (__lock_acquire) from [<8018291c>] (lock_acquire+0x424/0x4c8)
[ 1.347813] [<8018291c>] (lock_acquire) from [<808597b0>] (_raw_spin_lock_irqsave+0x54/0x68)
[ 1.356242] [<808597b0>] (_raw_spin_lock_irqsave) from [<80582e94>] (uart_add_one_port+0x384/0x510)
[ 1.365276] [<80582e94>] (uart_add_one_port) from [<8058b4d0>] (owl_uart_probe+0x1bc/0x248)
[ 1.373621] [<8058b4d0>] (owl_uart_probe) from [<8059c0e4>] (platform_drv_probe+0x48/0x94)
[ 1.381874] [<8059c0e4>] (platform_drv_probe) from [<805997c4>] (really_probe+0x200/0x470)
[ 1.390123] [<805997c4>] (really_probe) from [<80599c80>] (driver_probe_device+0x16c/0x1bc)
[ 1.398461] [<80599c80>] (driver_probe_device) from [<80599f18>] (device_driver_attach+0x44/0x60)
[ 1.407317] [<80599f18>] (device_driver_attach) from [<8059a078>] (__driver_attach+0x144/0x14c)
[ 1.416000] [<8059a078>] (__driver_attach) from [<805978ac>] (bus_for_each_dev+0x5c/0xb4)
[ 1.424162] [<805978ac>] (bus_for_each_dev) from [<8059896c>] (bus_add_driver+0x118/0x204)
[ 1.432410] [<8059896c>] (bus_add_driver) from [<8059ae6c>] (driver_register+0xbc/0xf8)
[ 1.440405] [<8059ae6c>] (driver_register) from [<80c1fd24>] (owl_uart_init+0x20/0x40)
[ 1.448313] [<80c1fd24>] (owl_uart_init) from [<801021d8>] (do_one_initcall+0x184/0x3a4)
[ 1.456399] [<801021d8>] (do_one_initcall) from [<80c01100>] (kernel_init_freeable+0x264/0x2e4)
[ 1.465085] [<80c01100>] (kernel_init_freeable) from [<80850a88>] (kernel_init+0x8/0x110)
[ 1.473249] [<80850a88>] (kernel_init) from [<80100114>] (ret_from_fork+0x14/0x20)
[ 1.480800] Exception stack(0xee8bdfb0 to 0xee8bdff8)
[ 1.485841] dfa0: 00000000 00000000 00000000 00000000
[ 1.494002] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.502162] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.508914] printk: console [ttyOWL2] enabled
The locking issue occurs in uart_configure_port() when trying to
guard the call to set_mctrl().
uart_add_one_port() should normally initialize the spinlock via
uart_port_spin_lock_init(), but it never happens because the port is
detected as a console and, as a consequence, the spinlock is expected
to be already initialized.
The commit a3cb39d258ef
("serial: core: Allow detach and attach serial device for console")
changed the lock initialization logic to assume the spinlock is
initialized even if the console is not enabled.
Therefore, initialize the lock explicitly in owl_uart_probe(), before
attempting to invoke uart_add_one_port().
Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
---
drivers/tty/serial/owl-uart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
index c149f8c30007..c2fa2f15d50a 100644
--- a/drivers/tty/serial/owl-uart.c
+++ b/drivers/tty/serial/owl-uart.c
@@ -705,6 +705,8 @@ static int owl_uart_probe(struct platform_device *pdev)
owl_uart_ports[pdev->id] = owl_port;
platform_set_drvdata(pdev, owl_port);
+ spin_lock_init(&owl_port->port.lock);
+
ret = uart_add_one_port(&owl_uart_driver, &owl_port->port);
if (ret)
owl_uart_ports[pdev->id] = NULL;
--
2.26.2
_______________________________________________
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 v12 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Andy Shevchenko @ 2020-05-29 10:58 UTC (permalink / raw)
To: Fengping Yu
Cc: Dmitry Torokhov, Marco Felsch, linux-mediatek, linux-input,
Yingjoe Chen, linux-arm-kernel
In-Reply-To: <20200529015618.128283-3-fengping.yu@mediatek.com>
On Fri, May 29, 2020 at 09:56:20AM +0800, Fengping Yu wrote:
> From: "fengping.yu" <fengping.yu@mediatek.com>
>
> This adds matrix keypad support for Mediatek SoCs.
FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
One comment to the code below, up to Dmitry to decide.
P.S. If you ignore tags given you, people will be discouraged to review your
contribution. Yes, I'm talking about Marco's ones.
> Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/mtk-kpd.c | 205 +++++++++++++++++++++++++++++++
> 3 files changed, 217 insertions(+)
> create mode 100644 drivers/input/keyboard/mtk-kpd.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 28de965a08d5..0803668bfa36 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -782,6 +782,17 @@ config KEYBOARD_BCM
> To compile this driver as a module, choose M here: the
> module will be called bcm-keypad.
>
> +config KEYBOARD_MTK_KPD
> + tristate "MediaTek Keypad Support"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + select REGMAP_MMIO
> + select INPUT_MATRIXKMAP
> + help
> + Say Y here if you want to use the keypad on MediaTek SoCs.
> + If unsure, say N.
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-kpd.
> +
> config KEYBOARD_MTK_PMIC
> tristate "MediaTek PMIC keys support"
> depends on MFD_MT6397
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 1d689fdd5c00..6c9d852c377e 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
> obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
> obj-$(CONFIG_KEYBOARD_MCS) += mcs_touchkey.o
> obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o
> +obj-$(CONFIG_KEYBOARD_MTK_KPD) += mtk-kpd.o
> obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o
> obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
> obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o
> diff --git a/drivers/input/keyboard/mtk-kpd.c b/drivers/input/keyboard/mtk-kpd.c
> new file mode 100644
> index 000000000000..0a6b8e2530bc
> --- /dev/null
> +++ b/drivers/input/keyboard/mtk-kpd.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + * Author Terry Chang <terry.chang@mediatek.com>
> + */
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/input/matrix_keypad.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#define MTK_KPD_NAME "mtk-kpd"
> +#define MTK_KPD_MEM 0x0004
> +#define MTK_KPD_DEBOUNCE 0x0018
> +#define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0)
> +#define MTK_KPD_DEBOUNCE_MAX_US 256000
> +#define MTK_KPD_NUM_MEMS 5
> +#define MTK_KPD_NUM_BITS 136 /* 4*32+8 MEM5 only use 8 BITS */
> +
> +struct mtk_keypad {
> + struct regmap *regmap;
> + struct input_dev *input_dev;
> + struct clk *clk;
> + void __iomem *base;
> + u32 n_rows;
> + u32 n_cols;
> + DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS);
> +};
> +
> +static const struct regmap_config keypad_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 36,
> +};
> +
> +static irqreturn_t kpd_irq_handler(int irq, void *dev_id)
> +{
> + struct mtk_keypad *keypad = dev_id;
> + unsigned short *keycode = keypad->input_dev->keycode;
> + DECLARE_BITMAP(new_state, MTK_KPD_NUM_BITS);
> + DECLARE_BITMAP(change, MTK_KPD_NUM_BITS);
> + int bit_nr;
> + int pressed;
> + unsigned short code;
> +
> + regmap_raw_read(keypad->regmap, MTK_KPD_MEM,
> + new_state, MTK_KPD_NUM_MEMS);
> +
> + bitmap_xor(change, new_state, keypad->keymap_state, MTK_KPD_NUM_BITS);
> +
> + for_each_set_bit(bit_nr, change, MTK_KPD_NUM_BITS) {
> + /* 1: not pressed, 0: pressed */
> + pressed = !test_bit(bit_nr, new_state);
> + dev_dbg(&keypad->input_dev->dev, "%s",
> + pressed ? "pressed" : "released");
> +
> + /* 32bit register only use low 16bit as keypad mem register */
> + code = keycode[bit_nr - 16 * (BITS_TO_U32(bit_nr) - 1)];
> +
> + input_report_key(keypad->input_dev, code, pressed);
> + input_sync(keypad->input_dev);
> +
> + dev_dbg(&keypad->input_dev->dev,
> + "report Linux keycode = %d\n", code);
> + }
> +
> + bitmap_copy(keypad->keymap_state, new_state, MTK_KPD_NUM_BITS);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void kpd_clk_disable(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> +static int kpd_pdrv_probe(struct platform_device *pdev)
> +{
> + struct mtk_keypad *keypad;
> + unsigned int irq;
> + u32 debounce;
> + bool wakeup;
> + int ret;
> +
> + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> + if (!keypad)
> + return -ENOMEM;
> +
> + keypad->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(keypad->base))
> + return PTR_ERR(keypad->base);
> +
> + keypad->regmap = devm_regmap_init_mmio(&pdev->dev,
> + keypad->base,
> + &keypad_regmap_cfg);
> + if (IS_ERR(keypad->regmap)) {
> + dev_err(&pdev->dev,
> + "regmap init failed:%ld\n", PTR_ERR(keypad->regmap));
> + return PTR_ERR(keypad->regmap);
> + }
> +
> + bitmap_fill(keypad->keymap_state, MTK_KPD_NUM_BITS);
> +
> + keypad->input_dev = devm_input_allocate_device(&pdev->dev);
> + if (!keypad->input_dev) {
> + dev_err(&pdev->dev, "Failed to allocate input dev\n");
> + return -ENOMEM;
> + }
> +
> + keypad->input_dev->name = MTK_KPD_NAME;
> + keypad->input_dev->id.bustype = BUS_HOST;
> +
> + ret = matrix_keypad_parse_properties(&pdev->dev, &keypad->n_rows,
> + &keypad->n_cols);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to parse keypad params\n");
> + return ret;
> + }
> +
> + if (device_property_read_u32(&pdev->dev, "mediatek,debounce-us",
> + &debounce))
> + debounce = 16000;
> +
> + if (debounce > MTK_KPD_DEBOUNCE_MAX_US) {
> + dev_err(&pdev->dev, "Debounce time exceeds the maximum allowed time %dus\n",
> + MTK_KPD_DEBOUNCE_MAX_US);
> + return -EINVAL;
> + }
> +
> + wakeup = device_property_read_bool(&pdev->dev, "wakeup-source");
> +
> + dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n",
> + keypad->n_rows, keypad->n_cols, debounce);
> +
> + ret = matrix_keypad_build_keymap(NULL, NULL,
> + keypad->n_rows,
> + keypad->n_cols,
> + NULL,
> + keypad->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to build keymap\n");
> + return ret;
> + }
> +
> + regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
> + debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
> +
> + keypad->clk = devm_clk_get(&pdev->dev, "kpd");
> + if (IS_ERR(keypad->clk))
> + return keypad->clk;
> +
> + ret = clk_prepare_enable(keypad->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "cannot prepare/enable keypad clock\n");
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(&pdev->dev, kpd_clk_disable, keypad->clk);
> + if (ret)
> + return ret;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, irq,
> + NULL, kpd_irq_handler, 0,
> + MTK_KPD_NAME, keypad);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
> + irq, ret);
> + return ret;
> + }
> +
> + ret = input_register_device(keypad->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register device\n");
> + return ret;
> + }
> +
> + return device_init_wakeup(&pdev->dev, wakeup);
I'm not sure that it's good idea to fail the probe if we can't register wake up
source. Keypad is still working, right? Perhaps simple warning?
> +}
> +
> +static const struct of_device_id kpd_of_match[] = {
> + { .compatible = "mediatek,mt6779-keypad" },
> + { .compatible = "mediatek,mt6873-keypad" },
> + { /* sentinel */ }
> +};
> +
> +static struct platform_driver kpd_pdrv = {
> + .probe = kpd_pdrv_probe,
> + .driver = {
> + .name = MTK_KPD_NAME,
> + .of_match_table = kpd_of_match,
> + },
> +};
> +module_platform_driver(kpd_pdrv);
> +
> +MODULE_AUTHOR("Mediatek Corporation");
> +MODULE_DESCRIPTION("MTK Keypad (KPD) Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.18.0
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 04/12] dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
From: Marc Zyngier @ 2020-05-29 10:18 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Nishanth Menon, Rob Herring, Grygorii Strashko, Peter Ujfalusi,
Device Tree Mailing List, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <f803f646-2a55-4f15-9682-1dc616d7c714@ti.com>
On 2020-05-29 11:14, Lokesh Vutla wrote:
> Hi Rob,
>
> On 29/05/20 3:44 am, Rob Herring wrote:
>> On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:
>>> Drop the firmware related dt-bindings and use the hardware specified
>>> interrupt numbers within Interrupt Router. This ensures interrupt
>>> router
>>> DT node need not assume any interrupt parent type.
>>
>> I didn't like this binding to begin with, but now you're breaking
>> compatibility.
>
> Yes, I do agree that this change is breaking backward compatibility.
> But IMHO,
> this does cleanup of firmware specific properties from DT. Since this
> is not
> deployed out yet in the wild market, I took the leverage of breaking
> backward
> compatibility. Before accepting these changes from firmware team, I did
> discuss[0] with Marc on this topic.
And I assume that should anyone complain about the kernel being broken
because they have an old firmware, you'll be OK with the patches being
reverted, right?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 04/12] dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
From: Lokesh Vutla @ 2020-05-29 10:14 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Marc Zyngier, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200528221406.GA769073@bogus>
Hi Rob,
On 29/05/20 3:44 am, Rob Herring wrote:
> On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:
>> Drop the firmware related dt-bindings and use the hardware specified
>> interrupt numbers within Interrupt Router. This ensures interrupt router
>> DT node need not assume any interrupt parent type.
>
> I didn't like this binding to begin with, but now you're breaking
> compatibility.
Yes, I do agree that this change is breaking backward compatibility. But IMHO,
this does cleanup of firmware specific properties from DT. Since this is not
deployed out yet in the wild market, I took the leverage of breaking backward
compatibility. Before accepting these changes from firmware team, I did
discuss[0] with Marc on this topic.
>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> .../interrupt-controller/ti,sci-intr.txt | 31 ++++++++++---------
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> index 1a8718f8855d..8b56b2de1c73 100644
>> --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
>> @@ -44,15 +44,17 @@ Required Properties:
>> 4: If intr supports level triggered interrupts.
>> - interrupt-controller: Identifies the node as an interrupt controller
>> - #interrupt-cells: Specifies the number of cells needed to encode an
>> - interrupt source. The value should be 2.
>> - First cell should contain the TISCI device ID of source
>> - Second cell should contain the interrupt source offset
>> - within the device.
>> + interrupt source. The value should be 1.
>> + First cell should contain interrupt router input number
>> + as specified by hardware.
>> - ti,sci: Phandle to TI-SCI compatible System controller node.
>> -- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
>> -- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
>> - assigned to this interrupt router. Each subtype id
>> - corresponds to a range of host irqs.
>> +- ti,sci-dev-id: TISCI device id of interrupt controller.
>> +- ti,interrupt-ranges: Set of triplets containing ranges that convert
>> + the INTR output interrupt numbers to parent's
>> + interrupt number. Each triplet has following entries:
>> + - First entry specifies the base for intr output irq
>> + - Second entry specifies the base for parent irqs
>> + - Third entry specifies the limit
>
> Humm, sounds like what interrupt-map does.
Okay, Ill look at it.
[0]
https://lore.kernel.org/linux-arm-kernel/2331f04eacee3b06cc152fc609225233@www.loen.fr/
Thanks and regards,
Lokesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci baseline: 24 runs, 2 regressions (v5.7-rc7-156-g46909976c59d)
From: kernelci.org bot @ 2020-05-29 10:14 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
arm64/for-kernelci baseline: 24 runs, 2 regressions (v5.7-rc7-156-g46909976c59d)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
meson-gxl-s805x-libretech-ac | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v5.7-rc7-156-g46909976c59d/plan/baseline/
Test: baseline
Tree: arm64
Branch: for-kernelci
Describe: v5.7-rc7-156-g46909976c59d
URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
SHA: 46909976c59d6f251cede6280611aac5b6813867
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/plan/id/5ed0d69e283f18e1e01dba70
Results: 4 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc7-156-g46909976c59d/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.txt
HTML log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc7-156-g46909976c59d/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02-11-g17e793fa4728/arm64/baseline/rootfs.cpio.gz
* baseline.dmesg.crit: https://kernelci.org/test/case/id/5ed0d69e283f18e1e01dba73
new failure (last pass: v5.7-rc6-152-gf4582661223d)
3 lines
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
meson-gxl-s805x-libretech-ac | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/plan/id/5ed0d880a257a2135c1dba73
Results: 4 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc7-156-g46909976c59d/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-gxl-s805x-libretech-ac.txt
HTML log: https://storage.kernelci.org//arm64/for-kernelci/v5.7-rc7-156-g46909976c59d/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-gxl-s805x-libretech-ac.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02-11-g17e793fa4728/arm64/baseline/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/5ed0d880a257a2135c1dba78
new failure (last pass: v5.7-rc6-124-g96bc42ff0a82)
2 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci boot: 25 boots: 0 failed, 25 passed (v5.7-rc7-156-g46909976c59d)
From: kernelci.org bot @ 2020-05-29 10:14 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v5.7-rc7-156-g46909976c59d/plan/baseline/
-------------------------------------------------------------------------------
arm64/for-kernelci boot: 25 boots: 0 failed, 25 passed (v5.7-rc7-156-g46909976c59d)
Full Boot Summary: https://kernelci.org/boot/all/job/arm64/branch/for-kernelci/kernel/v5.7-rc7-156-g46909976c59d/
Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v5.7-rc7-156-g46909976c59d/
Tree: arm64
Branch: for-kernelci
Git Describe: v5.7-rc7-156-g46909976c59d
Git Commit: 46909976c59d6f251cede6280611aac5b6813867
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Tested: 22 unique boards, 6 SoC families, 1 build out of 3
---
For more info write to <info@kernelci.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 v3 1/9] dt-bindings: atmel-tcb: convert bindings to json-schema
From: Sebastian Andrzej Siewior @ 2020-05-29 10:13 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: kamel.bouhara, Alexandre Belloni, Daniel Lezcano, linux-kernel,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200506080554.283177-2-alexandre.belloni@bootlin.com>
Rob, could you please bless the DT parts of this series? Daniel Lezcano
asked for the blessing in:
https://lkml.kernel.org/r/f0feb409-11fb-08de-cc06-216a16de994a@linaro.org
On 2020-05-06 10:05:46 [+0200], Alexandre Belloni wrote:
> Convert Atmel Timer Counter Blocks bindings to DT schema format using
> json-schema.
>
> Also move it out of mfd as it is not and has never been related to mfd.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> Cc: Rob Herring <robh+dt@kernel.org>
>
> Changes in v3:
> - Moved the child node documentation to the parent documentation
>
> Changes in v2:
> - Rebased on v5.7-rc1
> - Moved the binding documentation to its proper place
> - Added back the atmel,tcb-timer child node documentation
>
>
> .../devicetree/bindings/mfd/atmel-tcb.txt | 56 --------
> .../soc/microchip/atmel,at91rm9200-tcb.yaml | 126 ++++++++++++++++++
Sebastian
_______________________________________________
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 6/7] KVM: MIPS: clean up redundant 'kvm_run' parameters
From: Paolo Bonzini @ 2020-05-29 9:48 UTC (permalink / raw)
To: Tianjia Zhang, Huacai Chen
Cc: wanpengli, kvm, david, Benjamin Herrenschmidt, heiko.carstens,
Peter Xu, open list:MIPS, paulus, hpa, kvmarm, linux-s390,
frankja, Marc Zyngier, joro, x86, borntraeger, mingo,
julien.thierry.kdev, thuth, gor, suzuki.poulose, kvm-ppc,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel, jmattson,
Thomas Bogendoerfer, cohuck, christoffer.dall,
sean.j.christopherson, LKML, james.morse, mpe, vkuznets,
linuxppc-dev
In-Reply-To: <37246a25-c4dc-7757-3f5c-d46870a4f186@linux.alibaba.com>
On 27/05/20 08:24, Tianjia Zhang wrote:
>>>
>>>
>
> Hi Huacai,
>
> These two patches(6/7 and 7/7) should be merged into the tree of the
> mips architecture separately. At present, there seems to be no good way
> to merge the whole architecture patchs.
>
> For this series of patches, some architectures have been merged, some
> need to update the patch.
Hi Tianjia, I will take care of this during the merge window.
Thanks,
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] watchdog: sunxi_wdt: fix improper error exit code
From: Frank Lee @ 2020-05-29 9:45 UTC (permalink / raw)
To: wim, linux, mripard, wens
Cc: linux-watchdog, tiny.windzz, linux-kernel, Frank Lee, wuyan,
linux-arm-kernel
From: Martin Wu <wuyan@allwinnertech.com>
sunxi_wdt_probe() should return -ENOMEM when devm_kzalloc() fails.
Signed-off-by: Martin Wu <wuyan@allwinnertech.com>
Signed-off-by: Frank Lee <frank@allwinnertech.com>
---
drivers/watchdog/sunxi_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
index 5f05a45ac187..b50757882a98 100644
--- a/drivers/watchdog/sunxi_wdt.c
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -235,7 +235,7 @@ static int sunxi_wdt_probe(struct platform_device *pdev)
sunxi_wdt = devm_kzalloc(dev, sizeof(*sunxi_wdt), GFP_KERNEL);
if (!sunxi_wdt)
- return -EINVAL;
+ return -ENOMEM;
sunxi_wdt->wdt_regs = of_device_get_match_data(dev);
if (!sunxi_wdt->wdt_regs)
--
2.24.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: [PATCH RFCv2 9/9] arm64: Support async page fault
From: Marc Zyngier @ 2020-05-29 9:41 UTC (permalink / raw)
To: Gavin Shan
Cc: catalin.marinas, linux-kernel, shan.gavin, Paolo Bonzini, will,
kvmarm, linux-arm-kernel
In-Reply-To: <6a4a82a4-af01-98c2-c854-9199f55f7bd3@redhat.com>
On 2020-05-29 00:02, Gavin Shan wrote:
> Hi Paolo,
>
> On 5/28/20 8:48 PM, Paolo Bonzini wrote:
>> On 28/05/20 08:14, Gavin Shan wrote:
>>>> - for x86 we're also thinking of initiating the page fault from the
>>>> exception handler, rather than doing so from the hypervisor before
>>>> injecting the exception. If ARM leads the way here, we would do our
>>>> best to share code when x86 does the same.
>>>
>>> Sorry, Paolo, I don't follow your idea here. Could you please provide
>>> more details?
>>
>> The idea is to inject stage2 page faults into the guest even before
>> the
>> host starts populates the page. The guest then invokes a hypercall,
>> telling the host to populate the page table and inject the 'page
>> ready'
>> event (interrupt) when it's done.
>>
>> For x86 the advantage is that the processor can take care of raising
>> the
>> stage2 page fault in the guest, so it's faster.
>>
> I think there might be too much overhead if the page can be populated
> quickly by host. For example, it's fast to populate the pages if swapin
> isn't involved.
>
> If I'm correct enough, it seems arm64 doesn't have similar mechanism,
> routing stage2 page fault to guest.
Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are
always routed to EL2.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64/for-kernelci build: 3 builds: 0 failed, 3 passed, 48 warnings (v5.7-rc7-156-g46909976c59d)
From: kernelci.org bot @ 2020-05-29 9:30 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel, kernel-build-reports
arm64/for-kernelci build: 3 builds: 0 failed, 3 passed, 48 warnings (v5.7-rc7-156-g46909976c59d)
Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v5.7-rc7-156-g46909976c59d/
Tree: arm64
Branch: for-kernelci
Git Describe: v5.7-rc7-156-g46909976c59d
Git Commit: 46909976c59d6f251cede6280611aac5b6813867
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture
Warnings Detected:
arm64:
allmodconfig (gcc-8): 24 warnings
defconfig (gcc-8): 24 warnings
Warnings summary:
32 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
6 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
6 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
2 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
2 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
allmodconfig (arm64, gcc-8) — PASS, 0 errors, 24 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
--------------------------------------------------------------------------------
allnoconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 24 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi:1068.4-52: Warning (dma_ranges_format): /soc/dram-controller@1c62000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
---
For more info write to <info@kernelci.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 v7 16/20] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-29 9:25 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529103222.18c5b89b@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Fri, 29 May
2020 10:32:22 +0200:
> On Fri, 29 May 2020 02:25:13 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Embed a generic NAND ECC high-level object in the nand_device
> > structure to carry all the ECC engine configuration/data. Adapt the
> > raw NAND and SPI-NAND cores to fit the change.
>
> In order to split that one, and make future re-organizations less
> painful (hope we won't have to do that again, but who knows), I would
> recommend doing things in this order:
>
> 1/ create a nanddev_get_ecc_requirements() helper that returns a
> const struct nand_ecc_props *
> 2/ patch spinand to use this helper
> 3/ introduce nand_ecc
> 4/ patch rawnand to use the new ecc layer
Sounds like a lot of efforts for a mechanical change to me. Not
mentioning that the diff is pretty small now. But ok, I'll try.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> > drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> > drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> > drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> > drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> > drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> > drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> > drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> > drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> > drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> > drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> > drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> > drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> > drivers/mtd/nand/spi/core.c | 8 ++--
> > drivers/mtd/nand/spi/macronix.c | 6 +--
> > drivers/mtd/nand/spi/toshiba.c | 6 +--
> > include/linux/mtd/nand.h | 8 ++--
> > 19 files changed, 114 insertions(+), 100 deletions(-)
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/5] scsi: ufs-mediatek: Fix unbalanced clock on/off
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
MediaTek UFS clocks are separated to two parts and controlled
by different modules: ufs-mediatek and phy-ufs-mediatek.
If both Auto-Hibern8 and clk-gating feature are enabled, mphy
power control is not balanced thus unbalanced control also
happens to the clocks probed by phy-ufs-mediatek module.
Fix this issue by
- Promise usage of phy_power_on/off balanced
- Remove phy_power_on/off control in suspend/resume vops since
both can be handled in setup_clock vops only
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 56 +++++++++++++++++++--------------
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 5f41b7b7db8f..de9e643fb8dd 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -205,6 +205,23 @@ int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
return -ETIMEDOUT;
}
+static void ufs_mtk_mphy_power_on(struct ufs_hba *hba, bool on)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct phy *mphy = host->mphy;
+
+ if (!mphy)
+ return;
+
+ if (on && !host->mphy_powered_on)
+ phy_power_on(mphy);
+ else if (!on && host->mphy_powered_on)
+ phy_power_off(mphy);
+ else
+ return;
+ host->mphy_powered_on = on;
+}
+
/**
* ufs_mtk_setup_clocks - enables/disable clocks
* @hba: host controller instance
@@ -228,25 +245,24 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
return 0;
if (!on && status == PRE_CHANGE) {
- if (!ufshcd_is_link_active(hba)) {
- ufs_mtk_setup_ref_clk(hba, on);
- ret = phy_power_off(host->mphy);
- } else {
- /*
- * Gate ref-clk if link state is in Hibern8
- * triggered by Auto-Hibern8.
- */
- if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba)) {
- ret = ufs_mtk_wait_link_state(hba,
- VS_LINK_HIBERN8,
- 15);
- if (!ret)
- ufs_mtk_setup_ref_clk(hba, on);
+ /*
+ * Gate ref-clk and poweroff mphy if link state is in OFF
+ * or Hibern8 by either ufshcd_link_state_transition() or
+ * Auto-Hibern8.
+ */
+ if (!ufshcd_is_link_active(hba) ||
+ (!ufshcd_can_hibern8_during_gating(hba) &&
+ ufshcd_is_auto_hibern8_enabled(hba))) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret) {
+ ufs_mtk_setup_ref_clk(hba, on);
+ ufs_mtk_mphy_power_on(hba, on);
}
}
} else if (on && status == POST_CHANGE) {
- ret = phy_power_on(host->mphy);
+ ufs_mtk_mphy_power_on(hba, on);
ufs_mtk_setup_ref_clk(hba, on);
}
@@ -538,7 +554,6 @@ static void ufs_mtk_vreg_set_lpm(struct ufs_hba *hba, bool lpm)
static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
int err;
- struct ufs_mtk_host *host = ufshcd_get_variant(hba);
if (ufshcd_is_link_hibern8(hba)) {
err = ufs_mtk_link_set_lpm(hba);
@@ -559,20 +574,13 @@ static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufs_mtk_vreg_set_lpm(hba, true);
}
- if (!ufshcd_is_link_active(hba))
- phy_power_off(host->mphy);
-
return 0;
}
static int ufs_mtk_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
- struct ufs_mtk_host *host = ufshcd_get_variant(hba);
int err;
- if (!ufshcd_is_link_active(hba))
- phy_power_on(host->mphy);
-
if (ufshcd_is_link_hibern8(hba)) {
ufs_mtk_vreg_set_lpm(hba, false);
err = ufs_mtk_link_set_hpm(hba);
--
2.18.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 2/5] scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered yet
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
There are some chances that link enters hibern8 lately by auto-hibern8
scheme during the clock-gating flow. Clocks shall not be gated if link
is still active otherwise host or device may hang.
Fix this by returning error code to the caller __ufshcd_setup_clocks()
to skip gating clocks there if link is not confirmed in hibern8
state yet.
Also allow some waiting time for the hibern8 state transition.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 36 ++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 523ee5573921..3c85f5e97dea 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -178,15 +178,30 @@ static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
host->ref_clk_ungating_wait_us = ungating_us;
}
-static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
+int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
+ unsigned long max_wait_ms)
{
+ ktime_t timeout, time_checked;
u32 val;
- ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
- val = ufshcd_readl(hba, REG_UFS_PROBE);
- val = val >> 28;
+ timeout = ktime_add_us(ktime_get(), ms_to_ktime(max_wait_ms));
+ do {
+ time_checked = ktime_get();
+ ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
+ val = ufshcd_readl(hba, REG_UFS_PROBE);
+ val = val >> 28;
+
+ if (val == state)
+ return 0;
- return val;
+ /* Sleep for max. 200us */
+ usleep_range(100, 200);
+ } while (ktime_before(time_checked, timeout));
+
+ if (val == state)
+ return 0;
+
+ return -ETIMEDOUT;
}
/**
@@ -221,10 +236,13 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
* triggered by Auto-Hibern8.
*/
if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba) &&
- ufs_mtk_link_get_state(hba) ==
- VS_LINK_HIBERN8)
- ufs_mtk_setup_ref_clk(hba, on);
+ ufshcd_is_auto_hibern8_enabled(hba)) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret)
+ ufs_mtk_setup_ref_clk(hba, on);
+ }
}
} else if (on && status == POST_CHANGE) {
ret = phy_power_on(host->mphy);
--
2.18.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
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