Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

[Vincent Guittot]

On Mon, 21 Jan 2019 at 23:53, Rafael J. Wysocki  wrote:
>
> On Mon, Jan 21, 2019 at 4:17 PM Vincent Guittot
>  wrote:
> >
> > On Fri, 18 Jan 2019 at 13:08, Guenter Roeck  wrote:
> > >
> > > On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
> > > > On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
> > > >  wrote:
> > > >>
> > > >> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> > > >>  wrote:
> > > >>>
> > > >>> Hi Guenter,
> > > >>>
> > > >>> Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
> > >  On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > > > From: Thara Gopinath 
> > > >
> > > > This patch replaces jiffies based accounting for runtime_active_time
> > > > and runtime_suspended_time with ktime base accounting. This makes 
> > > > the
> > > > runtime debug counters inline with genpd and other pm subsytems 
> > > > which
> > > > uses ktime based accounting.
> > > >
> > > > timekeeping is initialized before pm_runtime_init() so ktime_get() 
> > > > will
> > > > be ready before first call. In fact, timekeeping_init() is called 
> > > > early
> > > > in start_kernel() which is way before driver_init() (and that's when
> > > > devices can start to be initialized) called from rest_init() via
> > > > kernel_init_freeable() and do_basic_setup().
> > > >
> > >  This is not (always) correct. My qemu "collie" boot test fails with 
> > >  this
> > >  patch applied. Reverting the patch fixes the problem. Bisect log 
> > >  attached.
> > > 
> > > >>>
> > > >>> Can you try the patch below ?
> > > >>> ktime_get_mono_fast_ns() has the advantage of being init with dummy 
> > > >>> clock so
> > > >>> it can be used at early_init.
> > > >>
> > > >> Another possibility would be delay the init of the gpiochip
> > > >
> > > > Well, right.
> > > >
> > > > Initializing devices before timekeeping doesn't feel particularly
> > > > robust from the design perspective.
> > > >
> > > > How exactly does that happen?
> > > >
> > >
> > > With an added 'initialized' flag and backtrace into the timekeeping code,
> > > with the change suggested earlier applied:
> > >
> > > [ cut here ]
> > > WARNING: CPU: 0 PID: 0 at kernel/time/timekeeping.c:453 
> > > ktime_get_mono_fast_ns+0x114/0x12c
> > > Timekeeping not initialized
> > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc2-next-20190117-dirty #2
> > > Hardware name: Sharp-Collie
> > > Backtrace:
> > > [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
> > >   r7:0009 r6: r5:c065ba90 r4:c06d3e54
> > > [] (show_stack) from [] (dump_stack+0x20/0x28)
> > > [] (dump_stack) from [] (__warn+0xcc/0xf4)
> > > [] (__warn) from [] (warn_slowpath_fmt+0x4c/0x6c)
> > >   r8:df407b08 r7: r6:c0c01550 r5:c065bad8 r4:c06dd028
> > > [] (warn_slowpath_fmt) from [] 
> > > (ktime_get_mono_fast_ns+0x114/0x12c)
> > >   r3: r2:c065bad8
> > >   r5: r4:df407b08
> > > [] (ktime_get_mono_fast_ns) from [] 
> > > (pm_runtime_init+0x38/0xb8)
> > >   r9:c06c9a5c r8:df407b08 r7: r6:c0c01550 r5: r4:df407b08
> > > [] (pm_runtime_init) from [] 
> > > (device_initialize+0xb0/0xec)
> > >   r7: r6:c0c01550 r5: r4:df407b08
> > > [] (device_initialize) from [] 
> > > (gpiochip_add_data_with_key+0x9c/0x884)
> > >   r7: r6:c06fca34 r5: r4:
> > > [] (gpiochip_add_data_with_key) from [] 
> > > (sa1100_init_gpio+0x40/0x98)
> > >   r10:dfffcd60 r9:c06c9a5c r8:c06dd020 r7:c06dd028 r6: r5:
> > >   r4:c06fca34
> > > [] (sa1100_init_gpio) from [] 
> > > (sa1100_init_irq+0x2c/0x3c)
> > >   r7:c06dd028 r6: r5:c0713300 r4:c06e1070
> > > [] (sa1100_init_irq) from [] (init_IRQ+0x20/0x28)
> > >   r5:c0713300 r4:
> > > [] (init_IRQ) from [] (start_kernel+0x254/0x4cc)
> > > [] (start_kernel) from [<>] (  (null))
> > >   r10:717f r9:6901b119 r8:c100 r7:0092 r6:313d r5:0053
> > >   r4:c06a7330
> > > ---[ end trace 91e1bd00dd7cce32 ]---
> >
> > Does it means that only the pm_runtime_init is done before
> > timekeeping_init() but no update_pm_runtime_accounting() ?
>
> This platform calls device_initialize(), via sa1100_init_irq(), from
> init_IRQ() which is in the start_kernel() code path before
> timekeeping_init().  That's the initialization of structure fields
> alone.
>
> Runtime PM really cannot be used legitimately before driver_init(),
> because it needs bus types to be there at least.
>
> > In this case, we can keep using ktimeçget in
> > update_pm_runtime_accounting() and find a solution to deal with
> > early_call of pm_runtime_init()
>
> Given the above, I think that initializing accounting_timestamp in
> pm_runtime_init() to anything different from 0 is a mistake.

I agree

>
> Note that update_pm_runtime_accounting() ignores the delta value if
> power.disable_depth is not zero anyway, so it really should be
> sufficient to update 

Re: [PATCH] drivers: extcon: Add support for ptn5150

[Vijai Kumar K]

On Tue, Jan 22, 2019 at 03:20:09PM +0900, Chanwoo Choi wrote:
> Hi Vijai,
> 
> This patch looks better. But theare are comments about code clean.
> I added the comments.
> 
Thanks. And Thank you for reviewing it Chanwoo. Please find my inline comments.

I will rebase, implement the review comments and will push an updated
patch.
> On 19. 1. 21. 오후 6:09, Vijai Kumar K wrote:
> > PTN5150A is a small thin low power CC Logic chip supporting
> > the USB Type-C connector application with Configurationn Channel(CC)
> > control logic detection and indication functions.
> > 
> > Add driver, Kconfig and Makefile entries.
> > 
> > Change-Id: I3b2da147a33b913b9ec60cd914b20acd955950c7
> 
> Remove it of gerrit system.
> 
Sure.

> > Signed-off-by: Vijai Kumar K 
> > ---
> >  .../devicetree/bindings/extcon/extcon-ptn5150.txt  |  22 ++
> >  drivers/extcon/Kconfig |   8 +
> >  drivers/extcon/Makefile|   1 +
> >  drivers/extcon/extcon-ptn5150.c| 327 
> > +
> >  drivers/extcon/extcon-ptn5150.h|  51 
> >  5 files changed, 409 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> >  create mode 100644 drivers/extcon/extcon-ptn5150.c
> >  create mode 100644 drivers/extcon/extcon-ptn5150.h
> > 
> > diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt 
> > b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> > new file mode 100644
> > index 000..8ea33bb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> > @@ -0,0 +1,22 @@
> > +
> > +* PTN5150 CC logic device
> 
> You better to specify the full name as following:
> : PTN5150 CC (Configuration Channel) Logic device
> 
> > +PTN5150A is a small thin low power CC Logic chip supporting the USB Type-C
> 
> s/Logic/logic
> 
noted.

> > +connector application with Configuration Channel (CC) control logic 
> > detection and
> > +indication functions. It is Interfaced to the host controller using an I2C 
> > interface.
> 
> s/Interfaced/interfaced
> 
noted.

> > +
> > +Required properties:
> > +- compatible: Should be "nxp,ptn5150"
> > +- reg: Specifies the I2C slave address of the device
> > +- int-gpio: GPIO to which INTB is connected
> 
> What is meaning of 'INTB'?
> 
INTB is the interrupt out pin of PTN5150.

> > +- vbus-gpio: GPIO which controls VBUS on/off
> > +
> > +Example:
> > +   ptn5150@1d  {
> > +   compatible = "nxp,ptn5150";
> > +   reg = <0x1d>;
> > +   int-gpio = < 78 GPIO_ACTIVE_HIGH>;
> > +   vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_default>;
> 
> You need to add some description why pinctrl properties are needed.
> For example, some hwmon device driver[1] explained the properties
> related to pinctrl. Please add the description as following.
> 
> - pinctrl-names : a pinctrl state named "default" must be defined.
>   
> - pinctrl-0 : phandle referencing pin configuration of the PWM ports. 
>   
> 
> [1] Documentation/devicetree/hwmon/aspeed-pwm-tacho.txt
> 
Thanks for the pointer. Will look into it and add appropiate description.

> 
> > +   status = "okay";
> > +   };
> 
> Remove the one tab in front of dt node.
noted.

> 
>   ptn5150@1d  {
>   compatible = "nxp,ptn5150";
>   reg = <0x1d>;
>   int-gpio = < 78 GPIO_ACTIVE_HIGH>;
>   vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_default>;
>   status = "okay";
>   };
> 
> 
> 
> > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> > index a7bca42..6adc797 100644
> > --- a/drivers/extcon/Kconfig
> > +++ b/drivers/extcon/Kconfig
> > @@ -113,6 +113,14 @@ config EXTCON_PALMAS
> >   Say Y here to enable support for USB peripheral and USB host
> >   detection by palmas usb.
> >  
> > +config EXTCON_PTN5150
> > +   tristate "PTN5150 CC LOGIC USB EXTCON support"
> 
> PTN5150 CC (Configuration Channel) LOGIC USB EXTCON support
> 
noted.

> > +   depends on I2C
> > +   select REGMAP_I2C
> > +   help
> > + Say Y here to enable support for USB peripheral and USB host
> > + detection by ptn5150 cc logic chip.
> 
> cc -> CC (Configuration Channel)
> 
noted.

> > +
> >  config EXTCON_QCOM_SPMI_MISC
> > tristate "Qualcomm USB extcon support"
> > depends on ARCH_QCOM || COMPILE_TEST
> > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> > index 0888fde..261ce4c 100644
> > --- a/drivers/extcon/Makefile
> > +++ b/drivers/extcon/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> >  obj-$(CONFIG_EXTCON_MAX77843)  += extcon-max77843.o
> >  obj-$(CONFIG_EXTCON_MAX8997)   += 

Re: [PATCH 2/3] scsi: arcmsr: Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2

[Dan Carpenter]

On Thu, Jan 17, 2019 at 05:52:28PM +0800, Ching Huang wrote:
> On Thu, 2019-01-17 at 12:16 +0300, Dan Carpenter wrote:
> > On Thu, Jan 17, 2019 at 04:47:07PM +0800, Ching Huang wrote:
> > > On Thu, 2019-01-17 at 10:59 +0300, Dan Carpenter wrote:
> > > > On Thu, Jan 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > > > > >From Ching Huang 
> > > > > 
> > > > > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
> > > > > 
> > > > 
> > > > What does this look like from a user perspective?  Does it fail every
> > > > time or does it only fail sometimes?
> > > > 
> > > > What's the bug exactly?
> > > > 
> > > > There is no Fixes tag...
> > > >From user's perspective, hibernate/resume are OK.
> > > But following IO may cause 'isr get an illegal ccb command' in
> > > log/messages sometime.
> > > > 
> > 
> > 
> > You will need to resend with that information included in the commit
> > message.
> OK. I will resend this patch later.
> > 
> > > > > Signed-off-by: Ching Huang 
> > > > > ---
> > > > > 
> > > > > diff --git a/drivers/scsi/arcmsr/arcmsr.h 
> > > > > b/drivers/scsi/arcmsr/arcmsr.h
> > > > > index a94c513..b98c632 100755
> > > > > --- a/drivers/scsi/arcmsr/arcmsr.h
> > > > > +++ b/drivers/scsi/arcmsr/arcmsr.h
> > > > > @@ -508,9 +508,9 @@ struct MessageUnit_A
> > > > >  struct MessageUnit_B
> > > > >  {
> > > > >   uint32_tpost_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > > - uint32_tdone_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > > + volatile uint32_t   done_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > 
> > > > There is a well known rule of thumb that when someone uses "volatile"
> > > > in the kernel it means there is a locking problem...  Is this __iomem or
> > > > something?
> > > The done_qbuffer was a command completion queue, it was an area written
> > > by IO processor and read by device driver. So, ...
> > 
> > I'm not totally positive I understand this sentence.  I can find a bunch
> > of places which read from this buffer, but I haven't immediately found
> > which place writes to it.  Can you give me a function name that I should
> > read?
> Well, we allocate memory for struct MessageUnit_B in
> arcmsr_alloc_ccb_pool(), by assign to acb->dma_coherent_handle2.
> Then we tell IO controller its DMA address in arcmsr_iop_confirm().
> When a command was completed, controller's firmware program will write a
> completion ccb in done_qbuffer through DMA. So, you can't see any driver
> funtion write to it.

DMA memory doesn't need to be marked as volatile.

regards,
dan carpenter

RE: [PATCH v3 1/2] dt-bindings: usb: ci-hdrc-usb2: add property power-active-high

[Peter Chen]

 
> Am 17.01.19 um 08:01 schrieb Peter Chen:
> >
> >>
> >> The i.MX6q/dl USB controller may drive the usb power line directly,
> >> but the polarity depends on the board. Reset state of the polarity is
> >> low-active so add this property to allow it to be high-active.
> >>
> >
> > As far as I know, most of i.mx USB controllers (except imx28/23, but
> > they don't have non-core registers) work like this, and most of them
> > are low active for PP default. Would you just use "i.mx" at both your code 
> > and
> your comment?
> 
> Am i right that i have to add my code block to (nearly) all other version 
> specific init
> functions then?

Besides your current patch, only usbmisc_imx7d_init is needed to add the same 
content.

Peter

> Will do so in next days and then send a v4 of this patch.
> >
> > Peter
> >
> >> Signed-off-by: Philipp Puschmann 
> >> ---
> >> Changes in v3: add description
> >> ---
> >>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> >> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> >> index adae82385dd6..8696e3eff6e7 100644
> >> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> >> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> >> @@ -93,6 +93,7 @@ i.mx specific properties
> >>  - over-current-active-low: over current signal polarity is active low.
> >>  - over-current-active-high: over current signal polarity is active high.
> >>It's recommended to specify the over current polarity.
> >> +- power-active-high: power signal polarity is high active (only for
> >> +imx6q/dl)
> >>  - external-vbus-divider: enables off-chip resistor divider for Vbus
> >>
> >>  Example:
> >> --
> >> 2.20.1
> >

Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem

[Miquel Raynal]

Hi Masahiro,

Masahiro Yamada  wrote on Tue, 22 Jan
2019 16:42:55 +0900:

> Although drivers do not directly get access to the private data of
> instruction patterns, let's use unnamed union field to be consistent
> with nand_op_instr.
> 

Actually this is how we wrote it the first time. Then we got robots
reporting that anonymous unions where not allowed with older (still
supported) GCC versions and I had to do this:


commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce
Author: Miquel Raynal 
Date:   Fri Jan 19 19:11:27 2018 +0100

mtd: nand: Fix build issues due to an anonymous union

GCC-4.4.4 raises errors when assigning a parameter in an anonymous
union, leading to this kind of failure:

drivers/mtd/nand/marvell_nand.c:1936:
warning: missing braces around initializer
warning: (near initialization for '(anonymous)[1].')
error: unknown field 'data' specified in initializer
error: unknown field 'addr' specified in initializer

Work around the situation by naming these unions.

Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
Reported-by: Andrew Morton 
Signed-off-by: Miquel Raynal 
Tested-by: Andrew Morton 
Signed-off-by: Boris Brezillon 


Thanks,
Miquèl

Re: [PATCH v1 1/1] mmc: dw_mmc-bluefield: : Fix the license information

[Ulf Hansson]

On Fri, 18 Jan 2019 at 19:12, Liming Sun  wrote:
>
> The SPDX license identifier and the boiler plate text are
> contradicting. Only the SPDX license identifier is needed. The
> other one is removed.
>
> Fixes: 86958dcc5ad7 ("mmc: dw_mmc-bluefield: Add driver extension")
> Cc: sta...@vger.kernel.org
> Reviewed-by: David Woods 
> Signed-off-by: Liming Sun 

Applied for fixes, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/dw_mmc-bluefield.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-bluefield.c 
> b/drivers/mmc/host/dw_mmc-bluefield.c
> index ed8f225..aa38b1a 100644
> --- a/drivers/mmc/host/dw_mmc-bluefield.c
> +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> @@ -1,11 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (C) 2018 Mellanox Technologies.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
>   */
>
>  #include 
> --
> 1.8.3.1
>

Re: [PATCH V4 2/3] arm64: dts: tegra: Add SDMMC Auto-cal settings

[Ulf Hansson]

On Thu, 10 Jan 2019 at 23:46, Sowjanya Komatineni
 wrote:
>
> Add SDMMC initial pad offsets used by auto calibration process.
>
> Add SDMMC fixed drive strengths for Tegra210, Tegra186 and
> Tegra194 which are used when calibration timeouts.
>
> Fixed drive strengths are based on Pre SI Analysis of the pads.
>
> Signed-off-by: Sowjanya Komatineni 

For clarity, I am leaving this one for arm-soc.

Kind regards
Uffe


> ---
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi |  2 ++
>  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 34 +++
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 57 
> ++--
>  3 files changed, 91 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
> b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 22815db4a3ed..169aee59ceac 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -315,6 +315,8 @@
> nvidia,pad-autocal-pull-down-offset-hs400 = <0x05>;
> nvidia,pad-autocal-pull-up-offset-1v8-timeout = <0x0a>;
> nvidia,pad-autocal-pull-down-offset-1v8-timeout = <0x0a>;
> +   nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x0a>;
> +   nvidia,pad-autocal-pull-down-offset-3v3-timeout = <0x0a>;
> nvidia,default-tap = <0x5>;
> nvidia,default-trim = <0x9>;
> nvidia,dqs-trim = <63>;
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
> b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 6dfa1ca0b851..596a36705c0f 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -303,6 +303,17 @@
> clock-names = "sdhci";
> resets = < TEGRA194_RESET_SDMMC1>;
> reset-names = "sdhci";
> +   nvidia,pad-autocal-pull-up-offset-3v3-timeout =
> +   
> <0x07>;
> +   nvidia,pad-autocal-pull-down-offset-3v3-timeout =
> +   
> <0x07>;
> +   nvidia,pad-autocal-pull-up-offset-1v8-timeout = 
> <0x06>;
> +   nvidia,pad-autocal-pull-down-offset-1v8-timeout =
> +   
> <0x07>;
> +   nvidia,pad-autocal-pull-up-offset-sdr104 = <0x00>;
> +   nvidia,pad-autocal-pull-down-offset-sdr104 = <0x00>;
> +   nvidia,default-tap = <0x9>;
> +   nvidia,default-trim = <0x5>;
> status = "disabled";
> };
>
> @@ -314,6 +325,18 @@
> clock-names = "sdhci";
> resets = < TEGRA194_RESET_SDMMC3>;
> reset-names = "sdhci";
> +   nvidia,pad-autocal-pull-up-offset-1v8 = <0x00>;
> +   nvidia,pad-autocal-pull-down-offset-1v8 = <0x7a>;
> +   nvidia,pad-autocal-pull-up-offset-3v3-timeout = 
> <0x07>;
> +   nvidia,pad-autocal-pull-down-offset-3v3-timeout =
> +   
> <0x07>;
> +   nvidia,pad-autocal-pull-up-offset-1v8-timeout = 
> <0x06>;
> +   nvidia,pad-autocal-pull-down-offset-1v8-timeout =
> +   
> <0x07>;
> +   nvidia,pad-autocal-pull-up-offset-sdr104 = <0x00>;
> +   nvidia,pad-autocal-pull-down-offset-sdr104 = <0x00>;
> +   nvidia,default-tap = <0x9>;
> +   nvidia,default-trim = <0x5>;
> status = "disabled";
> };
>
> @@ -325,6 +348,17 @@
> clock-names = "sdhci";
> resets = < TEGRA194_RESET_SDMMC4>;
> reset-names = "sdhci";
> +   nvidia,pad-autocal-pull-up-offset-hs400 = <0x00>;
> +   nvidia,pad-autocal-pull-down-offset-hs400 = <0x00>;
> +   nvidia,pad-autocal-pull-up-offset-1v8-timeout = 
> <0x0a>;
> +   nvidia,pad-autocal-pull-down-offset-1v8-timeout =
> +   
> <0x0a>;
> +   nvidia,pad-autocal-pull-up-offset-3v3-timeout = 
> <0x0a>;
> +   nvidia,pad-autocal-pull-down-offset-3v3-timeout =
> +   
> <0x0a>;
> +   nvidia,default-tap = <0x8>;
> +   nvidia,default-trim = <0x14>;
> +   nvidia,dqs-trim = <40>;
> status = "disabled";
> };
>

Re: [PATCH V4 3/3] mmc: tegra: SDMMC pads auto-calibration

[Ulf Hansson]

On Thu, 10 Jan 2019 at 23:46, Sowjanya Komatineni
 wrote:
>
> Program initial drive code offsets which will be used by auto
> calibration process.
>
> Program fixed drive strengths for SDMMC pads in pad control
> register when auto cal timeouts.
> Fixed settings are based on Pre-SI analysis of the pad design.
>
> Signed-off-by: Sowjanya Komatineni 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-tegra.c | 160 
> ++---
>  1 file changed, 119 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index e6ace31e2a41..7d681a8fa4ba 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -75,6 +75,7 @@
>  #define SDHCI_TEGRA_SDMEM_COMP_PADCTRL_VREF_SEL_MASK   0x000f
>  #define SDHCI_TEGRA_SDMEM_COMP_PADCTRL_VREF_SEL_VAL0x7
>  #define SDHCI_TEGRA_SDMEM_COMP_PADCTRL_E_INPUT_E_PWRD  BIT(31)
> +#define SDHCI_COMP_PADCTRL_DRVUPDN_OFFSET_MASK 0x07FFF000
>
>  #define SDHCI_TEGRA_AUTO_CAL_STATUS0x1ec
>  #define SDHCI_TEGRA_AUTO_CAL_ACTIVEBIT(31)
> @@ -121,6 +122,8 @@ struct sdhci_tegra {
> struct pinctrl *pinctrl_sdmmc;
> struct pinctrl_state *pinctrl_state_3v3;
> struct pinctrl_state *pinctrl_state_1v8;
> +   struct pinctrl_state *pinctrl_state_3v3_drv;
> +   struct pinctrl_state *pinctrl_state_1v8_drv;
>
> struct sdhci_tegra_autocal_offsets autocal_offsets;
> ktime_t last_calib;
> @@ -411,6 +414,76 @@ static void tegra_sdhci_set_pad_autocal_offset(struct 
> sdhci_host *host,
> sdhci_writel(host, reg, SDHCI_TEGRA_AUTO_CAL_CONFIG);
>  }
>
> +static int tegra_sdhci_set_padctrl(struct sdhci_host *host, int voltage,
> +  bool state_drvupdn)
> +{
> +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +   struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
> +   struct sdhci_tegra_autocal_offsets *offsets =
> +   _host->autocal_offsets;
> +   struct pinctrl_state *pinctrl_drvupdn = NULL;
> +   int ret = 0;
> +   u8 drvup = 0, drvdn = 0;
> +   u32 reg;
> +
> +   if (!state_drvupdn) {
> +   /* PADS Drive Strength */
> +   if (voltage == MMC_SIGNAL_VOLTAGE_180) {
> +   if (tegra_host->pinctrl_state_1v8_drv) {
> +   pinctrl_drvupdn =
> +   tegra_host->pinctrl_state_1v8_drv;
> +   } else {
> +   drvup = offsets->pull_up_1v8_timeout;
> +   drvdn = offsets->pull_down_1v8_timeout;
> +   }
> +   } else {
> +   if (tegra_host->pinctrl_state_3v3_drv) {
> +   pinctrl_drvupdn =
> +   tegra_host->pinctrl_state_3v3_drv;
> +   } else {
> +   drvup = offsets->pull_up_3v3_timeout;
> +   drvdn = offsets->pull_down_3v3_timeout;
> +   }
> +   }
> +
> +   if (pinctrl_drvupdn != NULL) {
> +   ret = pinctrl_select_state(tegra_host->pinctrl_sdmmc,
> +   pinctrl_drvupdn);
> +   if (ret < 0)
> +   dev_err(mmc_dev(host->mmc),
> +   "failed pads drvupdn, ret: %d\n", 
> ret);
> +   } else if ((drvup) || (drvdn)) {
> +   reg = sdhci_readl(host,
> +   SDHCI_TEGRA_SDMEM_COMP_PADCTRL);
> +   reg &= ~SDHCI_COMP_PADCTRL_DRVUPDN_OFFSET_MASK;
> +   reg |= (drvup << 20) | (drvdn << 12);
> +   sdhci_writel(host, reg,
> +   SDHCI_TEGRA_SDMEM_COMP_PADCTRL);
> +   }
> +
> +   } else {
> +   /* Dual Voltage PADS Voltage selection */
> +   if (!tegra_host->pad_control_available)
> +   return 0;
> +
> +   if (voltage == MMC_SIGNAL_VOLTAGE_180) {
> +   ret = pinctrl_select_state(tegra_host->pinctrl_sdmmc,
> +   
> tegra_host->pinctrl_state_1v8);
> +   if (ret < 0)
> +   dev_err(mmc_dev(host->mmc),
> +   "setting 1.8V failed, ret: %d\n", 
> ret);
> +   } else {
> +   ret = pinctrl_select_state(tegra_host->pinctrl_sdmmc,
> +   
> tegra_host->pinctrl_state_3v3);
> +   if (ret < 0)
> +   dev_err(mmc_dev(host->mmc),
> 

Re: [PATCH] mmc: core: annotate implicit fall through

[Ulf Hansson]

On Mon, 14 Jan 2019 at 21:42, Mathieu Malaterre  wrote:
>
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> this place in the code produced a warning (W=1).
>
> In this particular case rewrote the comment to start with the string "fall
> through", so as to match the regular expression expected by GCC. Truncate
> the comment slightly to fit the max line length of 80 characters.
>
> This commit remove the following warning:
>
>   drivers/mmc/core/host.c:196:14: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>
> Signed-off-by: Mathieu Malaterre 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/core/host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index f57f5de54206..0052d6fed7c8 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -194,7 +194,7 @@ int mmc_of_parse(struct mmc_host *host)
> switch (bus_width) {
> case 8:
> host->caps |= MMC_CAP_8_BIT_DATA;
> -   /* Hosts capable of 8-bit transfers can also do 4 bits */
> +   /* fall through - Hosts capable of 8-bit can also do 4 bits */
> case 4:
> host->caps |= MMC_CAP_4_BIT_DATA;
> break;
> --
> 2.19.2
>

Re: [PATCH] mmc: Annotate implicit fall through in jz_mmc_irq_worker

[Ulf Hansson]

On Wed, 16 Jan 2019 at 20:52, Mathieu Malaterre  wrote:
>
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> these places in the code produced warnings (W=1).
>
> This commit removes the following warnings:
>
>   drivers/mmc/host/jz4740_mmc.c:745:3: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>   drivers/mmc/host/jz4740_mmc.c:779:3: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>
> Signed-off-by: Mathieu Malaterre 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/jz4740_mmc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
> index 33215d66afa2..a1df8bc0b964 100644
> --- a/drivers/mmc/host/jz4740_mmc.c
> +++ b/drivers/mmc/host/jz4740_mmc.c
> @@ -743,6 +743,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void *devid)
> break;
>
> jz_mmc_prepare_data_transfer(host);
> +   /* fall through */
>
> case JZ4740_MMC_STATE_TRANSFER_DATA:
> if (host->use_dma) {
> @@ -777,6 +778,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void *devid)
> break;
> }
> jz4740_mmc_write_irq_reg(host, JZ_MMC_IRQ_DATA_TRAN_DONE);
> +   /* fall through */
>
> case JZ4740_MMC_STATE_SEND_STOP:
> if (!req->stop)
> --
> 2.19.2
>

Re: [PATCH V4 1/3] dt-bindings: mmc: tegra: Add pinctrl for SDMMC drive strengths

[Ulf Hansson]

On Thu, 10 Jan 2019 at 23:46, Sowjanya Komatineni
 wrote:
>
> Add pinctrls for 3V3 and 1V8 pad drive strength configuration for
> Tegra210 sdmmc.
>
> Tegra210 sdmmc has pad configuration registers in pinmux register
> domain and handled thru pinctrl to pinmux device node.
>
> Tegra186 and Tegra194 has pad configuration register with in the
> SDMMC register domain itself and are handles thru drive strength
> properties in sdmmc device node.
>
> Signed-off-by: Sowjanya Komatineni 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
> index 32b4b4e41923..2cecdc71d94c 100644
> --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
> @@ -39,12 +39,16 @@ sdhci@c8000200 {
> bus-width = <8>;
>  };
>
> -Optional properties for Tegra210 and Tegra186:
> +Optional properties for Tegra210, Tegra186 and Tegra194:
>  - pinctrl-names, pinctrl-0, pinctrl-1 : Specify pad voltage
>configurations. Valid pinctrl-names are "sdmmc-3v3" and "sdmmc-1v8"
>for controllers supporting multiple voltage levels. The order of names
>should correspond to the pin configuration states in pinctrl-0 and
>pinctrl-1.
> +- pinctrl-names : "sdmmc-3v3-drv" and "sdmmc-1v8-drv" are applicable for
> +  Tegra210 where pad config registers are in the pinmux register domain
> +  for pull-up-strength and pull-down-strength values configuration when
> +  using pads at 3V3 and 1V8 levels.
>  - nvidia,only-1-8-v : The presence of this property indicates that the
>controller operates at a 1.8 V fixed I/O voltage.
>  - nvidia,pad-autocal-pull-up-offset-3v3,
> --
> 2.7.4
>

[PATCH v2] arm: sun8i-h3-nanopi-m1-plus: enable HDMI

[Corentin Labbe]

This patch enable HDMI output on sun8i-h3-nanopi-m1-plus.

Signed-off-by: Corentin Labbe 
---
Change since v1:
- removed status=okay from hdmi_out
 arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 25 +++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
index 65cba1050802..4ec94d72f021 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -67,6 +67,21 @@
pinctrl-names = "default";
reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
};
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
 };
 
  {
@@ -94,6 +109,16 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.19.2

[PATCH 1/2] mtd: rawnand: use unnamed union in struct nand_op_instr

[Masahiro Yamada]

Getting the instruction private data ends up with a quite long
accessors, annoyingly.

Use anonymous union field to save 4 characters "ctx." This should
not introduce ambiguity.

I do not know when GCC started to support unnamed struct/union field,
but at least, the current minimum compiler version, GCC 4.6 supports
it, and so does Clang.

The unnamed struct/union was standardized only recently (ISO C11).
Anyway, the kernel code relies on the GNU extension to some extent.

Besides, struct nand_flash_dev in the same header exploits it.
If this is a problem, somebody should already have reported it.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/raw/ams-delta.c| 18 ++---
 drivers/mtd/nand/raw/fsmc_nand.c| 41 ++---
 drivers/mtd/nand/raw/marvell_nand.c | 16 ++--
 drivers/mtd/nand/raw/nand_base.c| 52 ++---
 drivers/mtd/nand/raw/tegra_nand.c   | 10 +++
 drivers/mtd/nand/raw/vf610_nfc.c| 14 +-
 include/linux/mtd/rawnand.h | 28 ++--
 7 files changed, 87 insertions(+), 92 deletions(-)

diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 8312182..e0e4f3b 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -172,33 +172,33 @@ static int ams_delta_exec_op(struct nand_chip *this,
switch (instr->type) {
case NAND_OP_CMD_INSTR:
gpiod_set_value(priv->gpiod_cle, 1);
-   ams_delta_write_buf(priv, >ctx.cmd.opcode, 1);
+   ams_delta_write_buf(priv, >cmd.opcode, 1);
gpiod_set_value(priv->gpiod_cle, 0);
break;
 
case NAND_OP_ADDR_INSTR:
gpiod_set_value(priv->gpiod_ale, 1);
-   ams_delta_write_buf(priv, instr->ctx.addr.addrs,
-   instr->ctx.addr.naddrs);
+   ams_delta_write_buf(priv, instr->addr.addrs,
+   instr->addr.naddrs);
gpiod_set_value(priv->gpiod_ale, 0);
break;
 
case NAND_OP_DATA_IN_INSTR:
-   ams_delta_read_buf(priv, instr->ctx.data.buf.in,
-  instr->ctx.data.len);
+   ams_delta_read_buf(priv, instr->data.buf.in,
+  instr->data.len);
break;
 
case NAND_OP_DATA_OUT_INSTR:
-   ams_delta_write_buf(priv, instr->ctx.data.buf.out,
-   instr->ctx.data.len);
+   ams_delta_write_buf(priv, instr->data.buf.out,
+   instr->data.len);
break;
 
case NAND_OP_WAITRDY_INSTR:
ret = priv->gpiod_rdy ?
  nand_gpio_waitrdy(this, priv->gpiod_rdy,
-   instr->ctx.waitrdy.timeout_ms) :
+   instr->waitrdy.timeout_ms) :
  nand_soft_waitrdy(this,
-   instr->ctx.waitrdy.timeout_ms);
+   instr->waitrdy.timeout_ms);
break;
}
 
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index c9149a3..dac0f74 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -615,54 +615,51 @@ static int fsmc_exec_op(struct nand_chip *chip, const 
struct nand_operation *op,
 
switch (instr->type) {
case NAND_OP_CMD_INSTR:
-   pr_debug("  ->CMD  [0x%02x]\n",
-instr->ctx.cmd.opcode);
+   pr_debug("  ->CMD  [0x%02x]\n", instr->cmd.opcode);
 
-   writeb_relaxed(instr->ctx.cmd.opcode, host->cmd_va);
+   writeb_relaxed(instr->cmd.opcode, host->cmd_va);
break;
 
case NAND_OP_ADDR_INSTR:
-   pr_debug("  ->ADDR [%d cyc]",
-instr->ctx.addr.naddrs);
+   pr_debug("  ->ADDR [%d cyc]", instr->addr.naddrs);
 
-   for (i = 0; i < instr->ctx.addr.naddrs; i++)
-   writeb_relaxed(instr->ctx.addr.addrs[i],
+   for (i = 0; i < instr->addr.naddrs; i++)
+   writeb_relaxed(instr->addr.addrs[i],
   host->addr_va);
break;
 
case NAND_OP_DATA_IN_INSTR:
-   pr_debug("  ->DATA_IN  [%d B%s]\n", 

[PATCH 0/2] mtd: nand: use unnamed union field

[Masahiro Yamada]

The new exec_op() scheme takes advantage of union
in order to store instruction private data, which is mutually
exclusive.

I felt a bit annoyed with the long accessors.
At least, we can omit "ctx." by making the union anonymous.

I converted nand_op_instr and nand_op_parser_pattern_elem.

I still see more instances, e.g.

  struct nand_op_data_instr {
  unsigned int len;
  union {
  void *in;
  const void *out;
  } buf;
  bool force_8bit;
  };

We could convert this into:

  struct nand_op_data_instr {
  unsigned int len;
  union {
  void *ibuf;
  const void *obuf;
  };
  bool force_8bit;
  };

Or, if we want to match the struct to NAND_OP_*_INSTR,
we can split it into two structures.

  struct nand_op_data_in_instr {
  unsigned int len;
  void *buf;
  bool force_8bit;
  };

  struct nand_op_data_out_instr {
  unsigned int len;
  const void *buf;
  bool force_8bit;
  };

Anyway, let's see if people are positive about
this shortning.



Masahiro Yamada (2):
  mtd: rawnand: use unnamed union in struct nand_op_instr
  mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem

 drivers/mtd/nand/raw/ams-delta.c| 18 +--
 drivers/mtd/nand/raw/fsmc_nand.c| 41 +++-
 drivers/mtd/nand/raw/marvell_nand.c | 16 +-
 drivers/mtd/nand/raw/nand_base.c| 64 ++---
 drivers/mtd/nand/raw/tegra_nand.c   | 10 +++---
 drivers/mtd/nand/raw/vf610_nfc.c| 14 
 include/linux/mtd/rawnand.h | 36 ++---
 7 files changed, 97 insertions(+), 102 deletions(-)

-- 
2.7.4

[PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem

[Masahiro Yamada]

Although drivers do not directly get access to the private data of
instruction patterns, let's use unnamed union field to be consistent
with nand_op_instr.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/raw/nand_base.c | 12 ++--
 include/linux/mtd/rawnand.h  |  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 3b620cd..d29de69 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -1995,24 +1995,24 @@ nand_op_parser_must_split_instr(const struct 
nand_op_parser_pattern_elem *pat,
 {
switch (pat->type) {
case NAND_OP_ADDR_INSTR:
-   if (!pat->ctx.addr.maxcycles)
+   if (!pat->addr.maxcycles)
break;
 
if (instr->addr.naddrs - *start_offset >
-   pat->ctx.addr.maxcycles) {
-   *start_offset += pat->ctx.addr.maxcycles;
+   pat->addr.maxcycles) {
+   *start_offset += pat->addr.maxcycles;
return true;
}
break;
 
case NAND_OP_DATA_IN_INSTR:
case NAND_OP_DATA_OUT_INSTR:
-   if (!pat->ctx.data.maxlen)
+   if (!pat->data.maxlen)
break;
 
if (instr->data.len - *start_offset >
-   pat->ctx.data.maxlen) {
-   *start_offset += pat->ctx.data.maxlen;
+   pat->data.maxlen) {
+   *start_offset += pat->data.maxlen;
return true;
}
break;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index b606ed3..7abb605 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -741,7 +741,7 @@ struct nand_op_parser_pattern_elem {
union {
struct nand_op_parser_addr_constraints addr;
struct nand_op_parser_data_constraints data;
-   } ctx;
+   };
 };
 
 #define NAND_OP_PARSER_PAT_CMD_ELEM(_opt)  \
@@ -754,21 +754,21 @@ struct nand_op_parser_pattern_elem {
{   \
.type = NAND_OP_ADDR_INSTR, \
.optional = _opt,   \
-   .ctx.addr.maxcycles = _maxcycles,   \
+   .addr.maxcycles = _maxcycles,   \
}
 
 #define NAND_OP_PARSER_PAT_DATA_IN_ELEM(_opt, _maxlen) \
{   \
.type = NAND_OP_DATA_IN_INSTR,  \
.optional = _opt,   \
-   .ctx.data.maxlen = _maxlen, \
+   .data.maxlen = _maxlen, \
}
 
 #define NAND_OP_PARSER_PAT_DATA_OUT_ELEM(_opt, _maxlen)\
{   \
.type = NAND_OP_DATA_OUT_INSTR, \
.optional = _opt,   \
-   .ctx.data.maxlen = _maxlen, \
+   .data.maxlen = _maxlen, \
}
 
 #define NAND_OP_PARSER_PAT_WAITRDY_ELEM(_opt)  \
-- 
2.7.4

[PATCH v2] powerpc: build virtex dtb

[Corentin Labbe]

I wanted to test the virtex440-ml507 qemu machine and found that the dtb
for it was not builded.
All powerpc DTB are only built when CONFIG_OF_ALL_DTBS is set which depend on
COMPILE_TEST.

This patchs adds build of virtex dtbs depending on
CONFIG_XILINX_VIRTEX440_GENERIC_BOARD option.

Signed-off-by: Corentin Labbe 
---
Changes since v1:
- squashed the two dtb into one make line
 arch/powerpc/boot/dts/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/boot/dts/Makefile b/arch/powerpc/boot/dts/Makefile
index fb335d05aae8..1cbc0e4ce857 100644
--- a/arch/powerpc/boot/dts/Makefile
+++ b/arch/powerpc/boot/dts/Makefile
@@ -4,3 +4,4 @@ subdir-y += fsl
 
 dtstree:= $(srctree)/$(src)
 dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+dtb-$(CONFIG_XILINX_VIRTEX440_GENERIC_BOARD) += virtex440-ml507.dtb 
virtex440-ml510.dtb
-- 
2.19.2

Re: [PATCH v2] alpha: fix page fault handling for r16-r18 targets

[Matt Turner]

On Mon, Dec 31, 2018 at 3:54 AM Sergei Trofimovich  wrote:
>
> Fix page fault handling code to fixup r16-r18 registers.
> Before the patch code had off-by-two registers bug.
> This bug caused overwriting of ps,pc,gp registers instead
> of fixing intended r16,r17,r18 (see `struct pt_regs`).
>
> More details:
>
> Initially Dmitry noticed a kernel bug as a failure
> on strace test suite. Test passes unmapped userspace
> pointer to io_submit:
>
> ```c
> #include 
> #include 
> #include 
> #include 
> int main(void)
> {
> unsigned long ctx = 0;
> if (syscall(__NR_io_setup, 1, ))
> err(1, "io_setup");
> const size_t page_size = sysconf(_SC_PAGESIZE);
> const size_t size = page_size * 2;
> void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
>  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> if (MAP_FAILED == ptr)
> err(1, "mmap(%zu)", size);
> if (munmap(ptr, size))
> err(1, "munmap");
> syscall(__NR_io_submit, ctx, 1, ptr + page_size);
> syscall(__NR_io_destroy, ctx);
> return 0;
> }
> ```
>
> Running this test causes kernel to crash when handling page fault:
>
> ```
> Unable to handle kernel paging request at virtual address 9468
> CPU 3
> aio(26027): Oops 0
> pc = []  ra = []  ps = Not 
> tainted
> pc is at sys_io_submit+0x108/0x200
> ra is at sys_io_submit+0x6c/0x200
> v0 = fc00c58e6300  t0 = fff2  t1 = 0225e000
> t2 = fc01f159fef8  t3 = fc0001009640  t4 = fce0f6e0
> t5 = 020001002e9e  t6 = 4c41564e49452031  t7 = fc01f159c000
> s0 = 0002  s1 = 0225e000  s2 = 
> s3 =   s4 =   s5 = fff2
> s6 = fc00c58e6300
> a0 = fc00c58e6300  a1 =   a2 = 0225e000
> a3 = 021ac260  a4 = 021ac1e8  a5 = 0001
> t8 = 0008  t9 = 00011f8bce30  t10= 021ac440
> t11=   pv = fc6fd320  at = 
> gp =   sp = 265fd174
> Disabling lock debugging due to kernel taint
> Trace:
> [] entSys+0xa4/0xc0
> ```
>
> Here `gp` has invalid value. `gp is s overwritten by a fixup for the
> following page fault handler in `io_submit` syscall handler:
>
> ```
> __se_sys_io_submit
> ...
> ldq a1,0(t1)
> bne t0,4280 <__se_sys_io_submit+0x180>
> ```
>
> After a page fault `t0` should contain -EFALUT and `a1` is 0.
> Instead `gp` was overwritten in place of `a1`.
>
> This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
> (aka `a0-a2`).
>
> I think the bug went unnoticed for a long time as `gp` is one
> of scratch registers. Any kernel function call would re-calculate `gp`.
>
> Dmitry tracked down the bug origin back to 2.1.32 kernel version
> where trap_a{0,1,2} fields were inserted into struct pt_regs.
> And even before that `dpf_reg()` contained off-by-one error.

Wow, nice work.

I've vacuumed the patch up and will include it in my next pull req.

Re: question about head_64.S

[Cao jin]

Hi, Kirll,

On 1/15/19 7:45 PM, Cao jin wrote:
> Hi,
>   I have been digging into this file for a while, and I still have 2
> questions unclear, hope to get your help.
> 

> 
> 2.
> Why gdt64 has following definition?:
> 
> gdt64:
>   .word   gdt_end - gdt
>   .long   0
>   .word   0
>   .quad   0
> 
> obviously, gdt64 stores the GDTR content under x86_64, which is 10 bytes
> long, so why not just:
> 
> gdt64:
>   .word   gdt_end - gdt
>   .quad   0
> 
> With above modification, it can boot.
> 

Seems you introduced gdt64 code in commit beebaccd50, could you help
with this question?

And it also remind me of another question about adjust_got which is also
introduced by you. Because I failed to construct a test environment with
ld version less than 2.24 until now, so I wanna do a quick ask here:
does it make sense to adjust GOT from the 4th entry of it? Because as I
know, the first 3 entries are special one, which (I guess) will be not used.
-- 
Sincerely,
Cao jin

[PATCH] drm/sun4i: hdmi: Fix usage of TMDS clock

[Priit Laes]

From: Priit Laes 

Although TMDS clock is required for HDMI to properly function,
nobody called clk_prepare_enable(). This fixes reference counting
issues and makes sure clock is running when it needs to be running.

Due to TDMS clock being parent clock for DDC clock, TDMS clock
was turned on/off for each EDID probe, causing spurious failures
for certain HDMI/DVI screens.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 061d2e0d9011..25f4d676fd82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -92,6 +92,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+   clk_disable_unprepare(hdmi->tmds_clk);
 }
 
 static void sun4i_hdmi_enable(struct drm_encoder *encoder)
@@ -112,6 +114,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
 
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+   clk_prepare_enable(hdmi->tmds_clk);
 }
 
 static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
-- 
2.11.0

Re: [PATCH] drm/vkms: Fix license inconsistent

[Greg KH]

On Mon, Jan 21, 2019 at 06:58:57PM -0200, Rodrigo Siqueira wrote:
> Fixes license inconsistent related to the VKMS driver and remove the
> redundant boilerplate comment.
> 
> Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")
> 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/vkms_crc.c| 3 ++-
>  drivers/gpu/drm/vkms/vkms_crtc.c   | 8 +---
>  drivers/gpu/drm/vkms/vkms_drv.c| 7 +--
>  drivers/gpu/drm/vkms/vkms_drv.h| 2 ++
>  drivers/gpu/drm/vkms/vkms_gem.c| 8 +---
>  drivers/gpu/drm/vkms/vkms_output.c | 8 +---
>  drivers/gpu/drm/vkms/vkms_plane.c  | 8 +---
>  7 files changed, 9 insertions(+), 35 deletions(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH] ALSA: hda - Fix unused variable warning

[kbuild test robot]

Hi Takashi,

I love your patch! Yet something to improve:

[auto build test ERROR on sound/for-next]
[also build test ERROR on v5.0-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Takashi-Iwai/ALSA-hda-Fix-unused-variable-warning/20190122-135307
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   In file included from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from include/linux/slab.h:15,
from sound/pci//hda/hda_codec.c:24:
   sound/pci//hda/hda_codec.c: In function 'hda_codec_runtime_suspend':
>> sound/pci//hda/hda_codec.c:2929:22: error: 'pcm' undeclared (first use in 
>> this function)
 list_for_each_entry(pcm, >pcm_list_head, list)
 ^~~
   include/linux/list.h:517:7: note: in definition of macro 
'list_for_each_entry'
 for (pos = list_first_entry(head, typeof(*pos), member); \
  ^~~
   sound/pci//hda/hda_codec.c:2929:22: note: each undeclared identifier is 
reported only once for each function it appears in
 list_for_each_entry(pcm, >pcm_list_head, list)
 ^~~
   include/linux/list.h:517:7: note: in definition of macro 
'list_for_each_entry'
 for (pos = list_first_entry(head, typeof(*pos), member); \
  ^~~

vim +/pcm +2929 sound/pci//hda/hda_codec.c

59ed1ead Takashi Iwai 2015-02-18  2922  
cc72da7d Takashi Iwai 2015-02-19  2923  static int 
hda_codec_runtime_suspend(struct device *dev)
59ed1ead Takashi Iwai 2015-02-18  2924  {
59ed1ead Takashi Iwai 2015-02-18  2925  struct hda_codec *codec = 
dev_to_hda_codec(dev);
cc72da7d Takashi Iwai 2015-02-19  2926  unsigned int state;
59ed1ead Takashi Iwai 2015-02-18  2927  
59ed1ead Takashi Iwai 2015-02-18  2928  
cancel_delayed_work_sync(>jackpoll_work);
bbbc7e85 Takashi Iwai 2015-02-27 @2929  list_for_each_entry(pcm, 
>pcm_list_head, list)
bbbc7e85 Takashi Iwai 2015-02-27  2930  
snd_pcm_suspend_all(pcm->pcm);
cc72da7d Takashi Iwai 2015-02-19  2931  state = 
hda_call_codec_suspend(codec);
57cb54e5 Takashi Iwai 2018-06-21  2932  if (codec->link_down_at_suspend 
||
57cb54e5 Takashi Iwai 2018-06-21  2933  (codec_has_clkstop(codec) 
&& codec_has_epss(codec) &&
57cb54e5 Takashi Iwai 2018-06-21  2934   (state & 
AC_PWRST_CLK_STOP_OK)))
7639a06c Takashi Iwai 2015-03-03  2935  
snd_hdac_codec_link_down(>core);
029d92c2 Takashi Iwai 2018-12-08  2936  codec_display_power(codec, 
false);
59ed1ead Takashi Iwai 2015-02-18  2937  return 0;
59ed1ead Takashi Iwai 2015-02-18  2938  }
59ed1ead Takashi Iwai 2015-02-18  2939  

:: The code at line 2929 was first introduced by commit
:: bbbc7e8502c95237dbd86cc4d0a12ca9a6b18c8f ALSA: hda - Allocate hda_pcm 
objects dynamically

:: TO: Takashi Iwai 
:: CC: Takashi Iwai 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2] tty: moxa: Fix coding style issues

[Greg KH]

On Mon, Jan 21, 2019 at 05:45:43PM -0500, Antoine Robertson wrote:
> Fix coding style issues
> 
> Signed-off-by: Antoine Robertson 
> ---
>  drivers/tty/moxa.c | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)

What changed from v1?

Always put that below the --- line, as the documentation asks you to do
so.

Please fix up and send a v3.

thanks,

greg k-h

Re: [PATCH 1/3] drivers: base: Add frequency constraint infrastructure

[Viresh Kumar]

On 18-01-19, 14:45, Matthias Kaehlcke wrote:
> On Fri, Jan 18, 2019 at 03:32:34PM +0530, Viresh Kumar wrote:
> > On 17-01-19, 17:03, Matthias Kaehlcke wrote:
> > > On Fri, Jan 11, 2019 at 02:48:34PM +0530, Viresh Kumar wrote:
> > > > +static void fcs_update(struct freq_constraints *fcs, struct freq_pair 
> > > > *freq,
> > > > +  enum fc_event event)
> > > > +{
> > > > +   mutex_lock(>lock);
> > > > +
> > > > +   if (_fcs_update(fcs, freq, event)) {
> > > > +   if (fcs->callback)
> > > > +   schedule_work(>work);
> > > 
> > > IIUC the constraints aren't applied until the callback is executed. I
> > > wonder if a dedicated workqueue should be used instead of the system
> > > one, to avoid longer delays from other kernel entities that might
> > > 'misbehave'. Especially for thermal constraints we want a quick
> > > response.
> > 
> > I thought the system workqueue should be fast enough, it contains
> > multiple threads which can all run in parallel and service this work.
> 
> Ok, I was still stuck at the old one thread per CPU model, where a
> slow work would block other items in the same workqueue until it
> finishes execution. After reading a bit through
> Documentation/core-api/workqueue.rst I agree that a system workqueue
> is probably fast enough. It might be warranted though to use
> system_highpri_wq here.

Is this really that high priority stuff ? I am not sure.

-- 
viresh

Re: /proc//status: incorrect format breaks userland tool

[Greg KH]

On Tue, Jan 22, 2019 at 12:31:08AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 22, 2019 at 11:29:16AM +0800, Lei Chen wrote:
> > Hi Konrad,
> 
> Hi,
> 
> CC-ing stable,Greg,and LKML. Pls see attached and inline patch and explanation
> at bottom.
> 
> > I'm running kernel 4.4.153. When running iotop, I got such failure:
> >  # iotop -P
> > Traceback (most recent call last):
> >   File "/sbin/iotop", line 17, in 
> > main()
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 620, in main
> > main_loop()
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 610, in 
> > main_loop = lambda: run_iotop(options)
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 508, in
> > run_iotop
> > return curses.wrapper(run_iotop_window, options)
> >   File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
> > return func(stdscr, *args, **kwds)
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 501, in
> > run_iotop_window
> > ui.run()
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 155, in run
> > self.process_list.duration)
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 434, in
> > refresh_display
> > lines = self.get_data()
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 415, in get_data
> > return list(map(format, processes))
> >   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 388, in format
> > cmdline = p.get_cmdline()
> >   File "/usr/lib/python2.7/site-packages/iotop/data.py", line 292, in
> > get_cmdline
> > proc_status = parse_proc_pid_status(self.pid)
> >   File "/usr/lib/python2.7/site-packages/iotop/data.py", line 196, in
> > parse_proc_pid_status
> > key, value = line.split(':\t', 1)
> > ValueError: need more than 1 value to unpack
> > 
> > Having a little further debug, I found this error is caused by the
> > unexpected blank line in /proc//status file, like below:
> > 
> > CapBnd: 003f
> > CapAmb: 
> > 
> > Speculation_Store_Bypass:   vulnerable
> > Cpus_allowed:   ff
> > 
> > Checking the git history, I see you touched the line "seq_printf(m,
> > "\nSpeculation_Store_Bypass:\t");". Do you think this additional blank line
> > is caused by the leading "\n" of "Speculation_Store_Bypass"?
> 
> That is correct.
> It looks that the backport missed the change. The v4.4 has:
> 
> static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
>  
> { 
>  
> #ifdef CONFIG_SECCOMP 
>  
> seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode); 
>  
> #endif
>  
> seq_printf(m, "\nSpeculation_Store_Bypass:\t");  
> 
> Upstream has:
> 
> tatic inline void task_seccomp(struct seq_file *m, struct task_struct *p) 
> 
> { 
>  
> seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));
>  
> #ifdef CONFIG_SECCOMP 
>  
> seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);  
>  
> #endif
>  
> seq_printf(m, "\nSpeculation_Store_Bypass:\t");   
>   
> 
> The af884cd4a5ae6 is the one that removed the '\n' from the end and put it in 
> the
> front of 'Seccomp '.
> 
> Greg, I am not sure how one would fix this in a stable tree. But the fix is 
> simple
> (hadn't tested it..)
> 
> >From 9e1909f29e1162f2fba190dbab88d1bbcaf0365d Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Tue, 22 Jan 2019 00:27:55 -0500
> Subject: [PATCH] Fix: proc: Use underscores for SSBD in 'status'
> 
> Upstream af884cd4a5ae6 (not backported) added a '\n' in front
> of 'Seccomp' but we have the old format with '\n' at the end.
> This causes mayhem with 'Speculation_Store_Bypass' adding an extra
> newline breaking tools.
> 
> Reported-by:Lei Chen 
> CC: sta...@vger.kernel.org
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  fs/proc/array.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index cb71cbae606d..60cbaa821164 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -333,7 +333,7 @@ static inline void task_seccomp(struct seq_file *m, 
> struct task_struct *p)
>  #ifdef CONFIG_SECCOMP
>   seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
>  #endif
> - seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> + seq_printf(m, "Speculation_Store_Bypass:\t");
>   switch (arch_prctl_spec_ctrl_get(p, PR_SPEC_STORE_BYPASS)) {
>   case -EINVAL:
>   seq_printf(m, "unknown");
> -- 
> 

Re: [PATCH v1 0/2] thermal: trivial fixes to error messages

[Viresh Kumar]

On 21-01-19, 15:12, Amit Kucheria wrote:
> Fix up a couple of error messages
> 
> Amit Kucheria (2):
>   thermal: of-thermal: Print name of device node with error
>   thermal: cpu_cooling: Clarify error message

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] drivers: extcon: Add support for ptn5150

[Vijai Kumar K]

On Tue, Jan 22, 2019 at 02:27:51PM +0900, Chanwoo Choi wrote:
> Hi Vijai,
> 
> On 19. 1. 22. 오후 1:42, Vijai Kumar K wrote:
> > Hi Chanwoo Choi,
> > 
> > This is the first time I am sending a driver to LKML. I have a few doubts. 
> > Can
> > you please clarify them when you are free?
> > 
> > 1. I have developed and tested this patch on 4.14.89 kernel. When trying to 
> > mainline the driver should I rebase and send the patch on top of current 
> > tree(v5.0-rc2)?
> 
> You better to rebase your patch on extcon-next branch (v5.0-rc1).
> because the extcon.git[1] keep the v5.0-rc1 version. But, if you use over 
> v5.0-rc1 version,
> it doesn't matter. Maybe, this patch doesn't get the any impact from the 
> modification
> of v5.0-rcX.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
Thanks, I will rebase and share an updated patchset.
> 
> > 
> > 2. Is there any specific git on which I should test this driver on? Like 
> > below?
> > https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
> 
> Yes.
> 
> > 
> > Thanks,
> > Vijai Kumar K
> > 
> > On Tue, Jan 22, 2019 at 08:05:33AM +0800, kbuild test robot wrote:
> >> Hi Vijai,
> >>
> >> Thank you for the patch! Yet something to improve:
> >>
> >> [auto build test ERROR on chanwoo-extcon/extcon-next]
> >> [also build test ERROR on v5.0-rc2]
> >> [if your patch is applied to the wrong git tree, please drop us a note to 
> >> help improve the system]
> >>
> >> url:
> >> https://github.com/0day-ci/linux/commits/Vijai-Kumar-K/drivers-extcon-Add-support-for-ptn5150/20190122-041153
> >> base:   https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> >> extcon-next
> >> config: sh-allyesconfig (attached as .config)
> >> compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> >> reproduce:
> >> wget 
> >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross 
> >> -O ~/bin/make.cross
> >> chmod +x ~/bin/make.cross
> >> # save the attached .config to linux build tree
> >> GCC_VERSION=8.2.0 make.cross ARCH=sh 
> >>
> >> All error/warnings (new ones prefixed by >>):
> >>
> >>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_irq_work':
>  drivers//extcon/extcon-ptn5150.c:93:5: error: implicit declaration of 
>  function 'extcon_set_state_sync'; did you mean 'extcon_get_state'? 
>  [-Werror=implicit-function-declaration]
> >> extcon_set_state_sync(info->edev,
> >> ^
> >> extcon_get_state
> >>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_i2c_probe':
>  drivers//extcon/extcon-ptn5150.c:255:15: error: implicit declaration of 
>  function 'devm_extcon_dev_allocate'; did you mean 'extcon_get_state'? 
>  [-Werror=implicit-function-declaration]
> >>  info->edev = devm_extcon_dev_allocate(info->dev, 
> >> ptn5150_extcon_cable);
> >>   ^~~~
> >>   extcon_get_state
>  drivers//extcon/extcon-ptn5150.c:255:13: warning: assignment to 'struct 
>  extcon_dev *' from 'int' makes pointer from integer without a cast 
>  [-Wint-conversion]
> >>  info->edev = devm_extcon_dev_allocate(info->dev, 
> >> ptn5150_extcon_cable);
> >> ^
>  drivers//extcon/extcon-ptn5150.c:262:8: error: implicit declaration of 
>  function 'devm_extcon_dev_register'; did you mean 
>  'devm_pinctrl_register'? [-Werror=implicit-function-declaration]
> >>  ret = devm_extcon_dev_register(info->dev, info->edev);
> >>^~~~
> >>devm_pinctrl_register
> >>cc1: some warnings being treated as errors
> >>
> >> vim +93 drivers//extcon/extcon-ptn5150.c
> >>
> >> 51 
> >> 52 static void ptn5150_irq_work(struct work_struct *work)
> >> 53 {
> >> 54 struct ptn5150_info *info = container_of(work,
> >> 55 struct ptn5150_info, irq_work);
> >> 56 int ret = 0;
> >> 57 unsigned int reg_data;
> >> 58 unsigned int port_status;
> >> 59 unsigned int vbus;
> >> 60 unsigned int cable_attach;
> >> 61 unsigned int int_status;
> >> 62 
> >> 63 if (!info->edev)
> >> 64 return;
> >> 65 
> >> 66 mutex_lock(>mutex);
> >> 67 
> >> 68 ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS, 
> >> _data);
> >> 69 if (ret) {
> >> 70 dev_err(info->dev,
> >> 71 "failed to read CC STATUS %d\n", ret);
> >> 72 mutex_unlock(>mutex);
> >> 73 return;
> >> 74 }
> >> 75 /* Clear interrupt. Read would clear the register */
> >> 76 ret = regmap_read(info->regmap, PTN5150_REG_INT_STATUS, 
> >> _status);
> >>   

[PATCH] Bluetooth: btusb: fix semicolon.cocci warnings

[kbuild test robot]

From: kbuild test robot 

drivers/bluetooth/btusb.c:2683:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 49e8dd3d9eae ("Bluetooth: btusb: Add protocol support for MediaTek 
MT7668U USB devices")
CC: Sean Wang 
Signed-off-by: kbuild test robot 
---

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Bluetooth-btusb-Add-protocol-support-for-MediaTek-MT7668U-USB-devices/20190122-041846
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
master

 btusb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2680,7 +2680,7 @@ static int btusb_mtk_hci_wmt_sync(struct
else
status = BTMTK_WMT_ON_UNDONE;
break;
-   };
+   }
 
if (wmt_params->status)
*wmt_params->status = status;

Re: [PATCH v5 1/2] Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices

[kbuild test robot]

Hi Sean,

I love your patch! Perhaps something to improve:

[auto build test WARNING on bluetooth-next/master]
[also build test WARNING on v5.0-rc2 next-20190116]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Bluetooth-btusb-Add-protocol-support-for-MediaTek-MT7668U-USB-devices/20190122-041846
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
master


coccinelle warnings: (new ones prefixed by >>)

>> drivers/bluetooth/btusb.c:2683:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 9/9] drm/mediatek: add dpi dual edge support

[Jitao Shi]

On Wed, 2019-01-09 at 17:58 +0100, Matthias Brugger wrote:
> 
> On 04/01/2019 08:03, chunhui dai wrote:
> > DPI sample on rising and falling edge. It can reduce half data io.
> > 
> > Signed-off-by: Jitao Shi 
> > Signed-off-by: chunhui dai 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 30 ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 4a2f4a6..acb4f47 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
> > unsigned int (*cal_factor)(int clock);
> > u32 reg_h_fre_con;
> > bool edge_sel_en;
> > +   bool dual_edge;
> >  };
> >  
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> > @@ -353,6 +354,15 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
> > *dpi)
> > mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
> >  }
> >  
> > +static void mtk_dpi_config_dual_edge(struct mtk_dpi *dpi)
> 
> I think it is clearer if you rename the function to something like:
> mtk_dpi_enable_dual_edge and call it in mtk_dpi_set_display_mode if
> dpi->conf->dual_edge is true.
> 
> Regards,
> Matthias
> 

I'll fix it in next patch.

Best Regards
Jitao

> > +{
> > +   if (dpi->conf->dual_edge) {
> > +   mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN |
> > +   DDR_4PHASE, DDR_EN | DDR_4PHASE);
> > +   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> > +   }
> > +}
> > +
> >  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> > enum mtk_dpi_out_color_format format)
> >  {
> > @@ -509,6 +519,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> > mtk_dpi_config_color_format(dpi, dpi->color_format);
> > mtk_dpi_config_2n_h_fre(dpi);
> > mtk_dpi_config_disable_edge(dpi);
> > +   mtk_dpi_config_dual_edge(dpi);
> > mtk_dpi_sw_reset(dpi, false);
> >  
> > return 0;
> > @@ -669,6 +680,16 @@ static unsigned int mt2701_calculate_factor(int clock)
> > return 1;
> >  }
> >  
> > +static unsigned int mt8183_calculate_factor(int clock)
> > +{
> > +   if (clock <= 27000)
> > +   return 8;
> > +   else if (clock <= 167000)
> > +   return 4;
> > +   else
> > +   return 2;
> > +}
> > +
> >  static const struct mtk_dpi_conf mt8173_conf = {
> > .cal_factor = mt8173_calculate_factor,
> > .reg_h_fre_con = 0xe0,
> > @@ -680,6 +701,12 @@ static unsigned int mt2701_calculate_factor(int clock)
> > .edge_sel_en = true,
> >  };
> >  
> > +static const struct mtk_dpi_conf mt8183_conf = {
> > +   .cal_factor = mt8183_calculate_factor,
> > +   .reg_h_fre_con = 0xe0,
> > +   .dual_edge = true,
> > +};
> > +
> >  static int mtk_dpi_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = >dev;
> > @@ -775,6 +802,9 @@ static int mtk_dpi_remove(struct platform_device *pdev)
> > { .compatible = "mediatek,mt8173-dpi",
> >   .data = _conf,
> > },
> > +   { .compatible = "mediatek,mt8183-dpi",
> > + .data = _conf,
> > +   },
> > { },
> >  };
> >  
> > 

Re: [PATCH 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

[Souptick Joarder]

On Fri, Jan 11, 2019 at 8:33 PM Souptick Joarder  wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating new functions and use it across
> the drivers.
>
> vm_insert_range() is the API which could be used to mapped
> kernel memory/pages in drivers which has considered vm_pgoff
>
> vm_insert_range_buggy() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
>
> We _could_ then at a later "fix" these drivers which are using
> vm_insert_range_buggy() to behave according to the normal vm_pgoff
> offsetting simply by removing the _buggy suffix on the function
> name and if that causes regressions, it gives us an easy way to revert.
>
> Signed-off-by: Souptick Joarder 
> Suggested-by: Russell King 
> Suggested-by: Matthew Wilcox 

Any comment on these APIs ?

> ---
>  include/linux/mm.h |  4 +++
>  mm/memory.c| 81 
> ++
>  mm/nommu.c | 14 ++
>  3 files changed, 99 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5411de9..9d1dff6 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2514,6 +2514,10 @@ unsigned long change_prot_numa(struct vm_area_struct 
> *vma,
>  int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
> unsigned long pfn, unsigned long size, pgprot_t);
>  int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page 
> *);
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> +   unsigned long num);
> +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
> +   unsigned long num);
>  vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> unsigned long pfn);
>  vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long 
> addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index 4ad2d29..00e66df 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma, 
> unsigned long addr,
>  }
>  EXPORT_SYMBOL(vm_insert_page);
>
> +/**
> + * __vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + * @offset: user's requested vm_pgoff
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma.
> + *
> + * If we fail to insert any page into the vma, the function will return
> + * immediately leaving any previously inserted pages present.  Callers
> + * from the mmap handler may immediately return the error as their caller
> + * will destroy the vma, removing any successfully inserted pages. Other
> + * callers should make their own arrangements for calling unmap_region().
> + *
> + * Context: Process context.
> + * Return: 0 on success and error code otherwise.
> + */
> +static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> +   unsigned long num, unsigned long offset)
> +{
> +   unsigned long count = vma_pages(vma);
> +   unsigned long uaddr = vma->vm_start;
> +   int ret, i;
> +
> +   /* Fail if the user requested offset is beyond the end of the object 
> */
> +   if (offset > num)
> +   return -ENXIO;
> +
> +   /* Fail if the user requested size exceeds available object size */
> +   if (count > num - offset)
> +   return -ENXIO;
> +
> +   for (i = 0; i < count; i++) {
> +   ret = vm_insert_page(vma, uaddr, pages[offset + i]);
> +   if (ret < 0)
> +   return ret;
> +   uaddr += PAGE_SIZE;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * vm_insert_range - insert range of kernel pages starts with non zero offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + *
> + * Maps an object consisting of `num' `pages', catering for the user's
> + * requested vm_pgoff
> + *
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> +   unsigned long num)
> +{
> +   return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> + * vm_insert_range_buggy - insert range of kernel pages starts with zero 
> offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> 

Re: [PATCH v3] mm/hotplug: invalid PFNs from pfn_to_online_page()

[Michal Hocko]

On Mon 21-01-19 16:27:47, Qian Cai wrote:
[...]

Sorry to miss this before but you want to

> +#define pfn_to_online_page(pfn) \
> +({  \
> + struct page *___page = NULL;   \
unsigned long ___pfn = pfn;
> + unsigned long ___nr = pfn_to_section_nr(pfn);  \
  pfn_to_section_nr(___pfn);
> +\
> + if (___nr < NR_MEM_SECTIONS && online_section_nr(___nr) && \
> + pfn_valid_within(pfn)) \
pfn_valid_within(___pfn))

> + ___page = pfn_to_page(pfn);\
> + ___page;   \
>  })

to prevent from issues when pfn expression has side effects.
-- 
Michal Hocko
SUSE Labs

Re: Re: [PATCH] drivers: extcon: Add support for ptn5150

[Vijai Kumar K]

On Tue, Jan 22, 2019 at 01:57:46PM +0900, MyungJoo Ham wrote:
> >Hi Chanwoo Choi,
> >
> >This is the first time I am sending a driver to LKML. I have a few doubts. 
> >Can
> >you please clarify them when you are free?
> 
> Although I'm not Chanwoo, but a guy who's about 50ft away from his cubicle,
> as he appears to be busy today... :)
:)
> 
> >
> >1. I have developed and tested this patch on 4.14.89 kernel. When trying to 
> >mainline the driver should I rebase and send the patch on top of current 
> >tree(v5.0-rc2)?
> 
> Yes, you are supposed to be based on the most recent RC.
Sure. Will do that and push an updated patch
> 
> >
> >2. Is there any specific git on which I should test this driver on? Like 
> >below?
> >https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
> 
> I'd recommend to pull torvald's master with RC tag.
Thanks. Will took into that.
> 
> 
> Cheers,
> MyungJoo
> 
> >
> >Thanks,
> >Vijai Kumar K

RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller thermal support

[Anson Huang]

Hi, Eduardo

Best Regards!
Anson Huang

> -Original Message-
> From: Anson Huang
> Sent: 2019年1月10日 17:28
> To: 'Eduardo Valentin' 
> Cc: 'robh...@kernel.org' ; 'mark.rutl...@arm.com'
> ; 'catalin.mari...@arm.com'
> ; 'will.dea...@arm.com'
> ; 'rui.zh...@intel.com' ;
> 'daniel.lezc...@linaro.org' ; Aisheng Dong
> ; 's.ha...@pengutronix.de'
> ; 'shawn...@kernel.org' ;
> Andy Gross ; 'a...@arndb.de' ;
> 'horms+rene...@verge.net.au' ;
> 'he...@sntech.de' ; 'bjorn.anders...@linaro.org'
> ; 'enric.balle...@collabora.com'
> ; 'amit.kuche...@linaro.org'
> ; 'ezequ...@collabora.com'
> ; 'o...@lixom.net' ;
> 'devicet...@vger.kernel.org' ;
> 'linux-kernel@vger.kernel.org' ;
> 'linux-arm-ker...@lists.infradead.org' ;
> 'linux...@vger.kernel.org' ; dl-linux-imx
> 
> Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller
> thermal support
> 
> Hi, Eduardo
> 
> Best Regards!
> Anson Huang
> 
> > -Original Message-
> > From: Anson Huang
> > Sent: 2018年12月26日 11:36
> > To: 'Eduardo Valentin' 
> > Cc: robh...@kernel.org; mark.rutl...@arm.com;
> catalin.mari...@arm.com;
> > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org;
> > Aisheng Dong ; s.ha...@pengutronix.de;
> > shawn...@kernel.org; Andy Gross ;
> > a...@arndb.de;
> > horms+rene...@verge.net.au; he...@sntech.de;
> > horms+bjorn.anders...@linaro.org;
> > enric.balle...@collabora.com; amit.kuche...@linaro.org;
> > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux...@vger.kernel.org; dl-linux-imx 
> > Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system
> > controller thermal support
> >
> > Hi, Eduardo
> >
> > Best Regards!
> > Anson Huang
> >
> > > -Original Message-
> > > From: Eduardo Valentin [mailto:edubez...@gmail.com]
> > > Sent: 2018年12月26日 6:44
> > > To: Anson Huang 
> > > Cc: robh...@kernel.org; mark.rutl...@arm.com;
> > catalin.mari...@arm.com;
> > > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org;
> > > Aisheng Dong ; s.ha...@pengutronix.de;
> > > shawn...@kernel.org; Andy Gross ;
> > > a...@arndb.de;
> > > horms+rene...@verge.net.au; he...@sntech.de;
> > > horms+bjorn.anders...@linaro.org;
> > > enric.balle...@collabora.com; amit.kuche...@linaro.org;
> > > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux...@vger.kernel.org; dl-linux-imx 
> > > Subject: Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system
> > > controller thermal support
> > >
> > > On Thu, Dec 20, 2018 at 09:08:32AM +, Anson Huang wrote:
> > > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > > > inside, the system controller is in charge of controlling power,
> > > > clock and thermal sensors etc..
> > > >
> > > > This patch adds i.MX system controller thermal driver support,
> > > > Linux kernel has to communicate with system controller via MU
> > > > (message
> > > > unit) IPC to get each thermal sensor's temperature, it supports
> > > > multiple sensors which are passed from device tree, please see the
> > > > binding doc for details.
> > > >
> > > > Signed-off-by: Anson Huang 
> > > > ---
> > > > ChangeLog since V4:
> > > > - Add driver dependency on IMX_SCU to avoid compile error when
> > > IMX_SCU is NOT selected;
> > > > - Remove unnecessary of different errors handle for
> > > imx_scu_get_handle, already included in API.
> > > > ---
> > > >  drivers/thermal/Kconfig  |  11 +++
> > > >  drivers/thermal/Makefile |   1 +
> > > >  drivers/thermal/imx_sc_thermal.c | 200
> > > > +++
> > > >  3 files changed, 212 insertions(+)  create mode 100644
> > > > drivers/thermal/imx_sc_thermal.c
> > > >
> > > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > > > index 0e69edc..8d4601d 100644
> > > > --- a/drivers/thermal/Kconfig
> > > > +++ b/drivers/thermal/Kconfig
> > > > @@ -222,6 +222,17 @@ config IMX_THERMAL
> > > >   cpufreq is used as the cooling device to throttle CPUs when 
> > > > the
> > > >   passive trip is crossed.
> > > >
> > > > +config IMX_SC_THERMAL
> > > > +   tristate "Temperature sensor driver for NXP i.MX SoCs with
> > > > +System
> > > Controller"
> > > > +   depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
> > > > +   depends on OF
> > > > +   help
> > > > + Support for Temperature Monitor (TEMPMON) found on NXP i.MX
> > > > +SoCs
> > > with
> > > > + system controller inside, Linux kernel has to communicate with
> system
> > > > + controller via MU (message unit) IPC to get temperature from
> thermal
> > > > + sensor. It supports one critical trip point and one
> > > > + passive trip point for each thermal sensor.
> > > > +
> > > >  config MAX77620_THERMAL
> > > > tristate "Temperature sensor driver for 

Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support

[alokc]

Please don't review this patch. I've resend patches after adding all the 
mailing list.
Sorry for inconvenience. Please review patches with spi/i2c/uart/kernel 
mailing list added.


On 2019-01-21 16:51, Alok Chauhan wrote:

Get the interconnect paths for I2C based Serial Engine device
and vote accordingly based on maximum supported I2C frequency.

Signed-off-by: Alok Chauhan 
---
 drivers/i2c/busses/i2c-qcom-geni.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index db075bc..e8fe63a 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 #define SE_I2C_TX_TRANS_LEN0x26c
 #define SE_I2C_RX_TRANS_LEN0x270
@@ -508,6 +509,15 @@ static int geni_i2c_probe(struct platform_device 
*pdev)

return ret;
}

+   /* Set the bus quota to a reasonable value */
+   gi2c->se.avg_bw = Bps_to_icc(1000);
+   gi2c->se.peak_bw = Bps_to_icc(7680);
+   ret = geni_interconnect_init(>se);
+   if (ret) {
+   dev_err(>dev, "interconnect_init failed %d\n", ret);
+   return ret;
+   }
+
ret = device_property_read_u32(>dev, "clock-frequency",
>clk_freq_out);
if (ret) {
@@ -611,6 +621,8 @@ static int __maybe_unused
geni_i2c_runtime_suspend(struct device *dev)
gi2c->suspended = 1;
}

+   geni_icc_update_bw(>se, false);
+
return 0;
 }

@@ -619,6 +631,7 @@ static int __maybe_unused
geni_i2c_runtime_resume(struct device *dev)
int ret;
struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);

+   geni_icc_update_bw(>se, true);
ret = geni_se_resources_on(>se);
if (ret)
return ret;


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,a Linux Foundation Collaborative Project

Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake

[Kai-Heng Feng]

> On Jan 22, 2019, at 14:45, Kai-Heng Feng  wrote:
> 
> There are some e1000e devices can only be woken up from D3 one time, by
> plugging ethernet cable. Subsequent cable plugging does set PME bit
> correctly, but it still doesn't get woken up.
> 
> Since e1000e connects to the root complex directly, we rely on ACPI to
> wake it up. In this case, the GPE from _PRW only works once and stops
> working after that.
> 
> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
> platform firmwares that have unreliable GPE wake.

Forgot this:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202181

> 
> Signed-off-by: Kai-Heng Feng 
> ---
> drivers/pci/pci-acpi.c | 2 +-
> drivers/pci/quirks.c   | 8 
> include/linux/pci.h| 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index e1949f7efd9c..184e2fc8a294 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -430,7 +430,7 @@ static void pci_acpi_wake_dev(struct 
> acpi_device_wakeup_context *context)
> 
>   pci_dev = to_pci_dev(context->dev);
> 
> - if (pci_dev->pme_poll)
> + if (pci_dev->pme_poll && !pci_dev->unreliable_acpi_wake)
>   pci_dev->pme_poll = false;
> 
>   if (pci_dev->current_state == PCI_D3cold) {
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b0a413f3f7ca..ed4863496fa8 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4948,6 +4948,14 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD, 
> PCI_ANY_ID,
> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
> PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
> 
> +static void quirk_unreliable_acpi_wake(struct pci_dev *pdev)
> +{
> + pci_info(pdev, "ACPI Wake unreliable, always poll PME\n");
> + pdev->unreliable_acpi_wake = 1;
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bb, 
> quirk_unreliable_acpi_wake);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bd, 
> quirk_unreliable_acpi_wake);
> +
> /*
>  * Some IDT switches incorrectly flag an ACS Source Validation error on
>  * completions for config read requests even though PCIe r4.0, sec
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 65f1d8c2f082..d22065c1576f 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -331,6 +331,7 @@ struct pci_dev {
>   unsigned intpme_support:5;  /* Bitmask of states from which PME#
>  can be generated */
>   unsigned intpme_poll:1; /* Poll device's PME status bit */
> + unsigned intunreliable_acpi_wake:1; /* ACPI Wake doesn't always 
> work */
>   unsigned intd1_support:1;   /* Low power state D1 is supported */
>   unsigned intd2_support:1;   /* Low power state D2 is supported */
>   unsigned intno_d1d2:1;  /* D1 and D2 are forbidden */
> -- 
> 2.17.1
> 

[PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake

[Kai-Heng Feng]

There are some e1000e devices can only be woken up from D3 one time, by
plugging ethernet cable. Subsequent cable plugging does set PME bit
correctly, but it still doesn't get woken up.

Since e1000e connects to the root complex directly, we rely on ACPI to
wake it up. In this case, the GPE from _PRW only works once and stops
working after that.

So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
platform firmwares that have unreliable GPE wake.

Signed-off-by: Kai-Heng Feng 
---
 drivers/pci/pci-acpi.c | 2 +-
 drivers/pci/quirks.c   | 8 
 include/linux/pci.h| 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index e1949f7efd9c..184e2fc8a294 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -430,7 +430,7 @@ static void pci_acpi_wake_dev(struct 
acpi_device_wakeup_context *context)
 
pci_dev = to_pci_dev(context->dev);
 
-   if (pci_dev->pme_poll)
+   if (pci_dev->pme_poll && !pci_dev->unreliable_acpi_wake)
pci_dev->pme_poll = false;
 
if (pci_dev->current_state == PCI_D3cold) {
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b0a413f3f7ca..ed4863496fa8 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4948,6 +4948,14 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD, 
PCI_ANY_ID,
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
  PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
 
+static void quirk_unreliable_acpi_wake(struct pci_dev *pdev)
+{
+   pci_info(pdev, "ACPI Wake unreliable, always poll PME\n");
+   pdev->unreliable_acpi_wake = 1;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bb, 
quirk_unreliable_acpi_wake);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bd, 
quirk_unreliable_acpi_wake);
+
 /*
  * Some IDT switches incorrectly flag an ACS Source Validation error on
  * completions for config read requests even though PCIe r4.0, sec
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 65f1d8c2f082..d22065c1576f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -331,6 +331,7 @@ struct pci_dev {
unsigned intpme_support:5;  /* Bitmask of states from which PME#
   can be generated */
unsigned intpme_poll:1; /* Poll device's PME status bit */
+   unsigned intunreliable_acpi_wake:1; /* ACPI Wake doesn't always 
work */
unsigned intd1_support:1;   /* Low power state D1 is supported */
unsigned intd2_support:1;   /* Low power state D2 is supported */
unsigned intno_d1d2:1;  /* D1 and D2 are forbidden */
-- 
2.17.1

Re: [PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path

[alokc]

Please don't review this patch. I've resend patches after adding all the 
mailing list.

Sorry for inconvenience.

On 2019-01-21 16:51, Alok Chauhan wrote:

Add the wrapper to support for interconnect path voting
from GENI QUP. This wrapper provides the functionalities
to individual Serial Engine device to get the interconnect
path and to vote for bandwidth based on their need.

This wrapper maintains bandwidth votes from each Serial Engine
and send the aggregated vote from GENI QUP to interconnect
framework.

Signed-off-by: Alok Chauhan 
---
 drivers/soc/qcom/qcom-geni-se.c | 129 


 include/linux/qcom-geni-se.h|  11 
 2 files changed, 140 insertions(+)

diff --git a/drivers/soc/qcom/qcom-geni-se.c 
b/drivers/soc/qcom/qcom-geni-se.c

index 6b8ef01..1d8dcb1 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * DOC: Overview
@@ -84,11 +85,21 @@
  * @dev:   Device pointer of the QUP wrapper core
  * @base:  Base address of this instance of QUP wrapper core
  * @ahb_clks:  Handle to the primary & secondary AHB clocks
+ * @icc_path:  Array of interconnect path handles
+ * @geni_wrapper_lock: Lock to protect the bus bandwidth request
+ * @cur_avg_bw:Current Bus Average BW request value from GENI 
QUP
+ * @cur_peak_bw:   Current Bus Peak BW request value from GENI QUP
+ * @peak_bw_list_head: Sorted resource list based on peak bus BW
  */
 struct geni_wrapper {
struct device *dev;
void __iomem *base;
struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
+   struct icc_path *icc_path[2];
+   struct mutex geni_wrapper_lock;
+   u32 cur_avg_bw;
+   u32 cur_peak_bw;
+   struct list_head peak_bw_list_head;
 };

 #define QUP_HW_VER_REG 0x4
@@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
 }

 /**
+ * geni_icc_update_bw() - Request to update bw vote on an interconnect 
path

+ * @se:Pointer to the concerned serial engine.
+ * @update:Flag to update bw vote.
+ *
+ * This function is used to request set bw vote on interconnect path 
handle.

+ */
+void geni_icc_update_bw(struct geni_se *se, bool update)
+{
+   struct geni_se *temp = NULL;
+   struct list_head *ins_list_head;
+   struct geni_wrapper *wrapper;
+
+   mutex_lock(>wrapper->geni_wrapper_lock);
+
+   wrapper = se->wrapper;
+
+   if (update) {
+   wrapper->cur_avg_bw += se->avg_bw;
+   ins_list_head = >peak_bw_list_head;
+   list_for_each_entry(temp, >peak_bw_list_head,
+   peak_bw_list) {
+   if (temp->peak_bw < se->peak_bw)
+   break;
+   ins_list_head = >peak_bw_list;
+   }
+
+   list_add(>peak_bw_list, ins_list_head);
+
+   if (ins_list_head == >peak_bw_list_head)
+   wrapper->cur_peak_bw = se->peak_bw;
+   } else {
+   if (unlikely(list_empty(>peak_bw_list))) {
+   mutex_unlock(>geni_wrapper_lock);
+   return;
+   }
+
+   wrapper->cur_avg_bw -= se->avg_bw;
+
+   list_del_init(>peak_bw_list);
+   temp = list_first_entry_or_null(>peak_bw_list_head,
+   struct geni_se, peak_bw_list);
+   if (temp && temp->peak_bw != wrapper->cur_peak_bw)
+   wrapper->cur_peak_bw = temp->peak_bw;
+   else if (!temp && wrapper->cur_peak_bw)
+   wrapper->cur_peak_bw = 0;
+   }
+
+   /*
+* This bw vote is to enable internal QUP core clock as well as to
+* enable path towards memory.
+*/
+   icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
+   wrapper->cur_peak_bw);
+
+   /*
+* This is just register configuration path so doesn't need avg bw.
+* Set only peak bw to enable this path.
+*/
+   icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
+
+   mutex_unlock(>geni_wrapper_lock);
+}
+EXPORT_SYMBOL(geni_icc_update_bw);
+
+/**
  * geni_se_resources_off() - Turn off resources associated with the 
serial

  *   engine
  * @se:Pointer to the concerned serial engine.
@@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se,
dma_addr_t iova, size_t len)
 }
 EXPORT_SYMBOL(geni_se_rx_dma_unprep);

+/**
+ * geni_interconnect_init() - Request to get interconnect path handle
+ * @se:Pointer to the concerned serial engine.
+ *
+ * This function is used to get interconnect path handle.
+ */
+int geni_interconnect_init(struct geni_se *se)
+{
+   struct geni_wrapper *wrapper_rsc;
+
+   if (unlikely(!se || 

Re: [PATCH 1/6] dt-bindings: soc: qcom: Add interconnect binding for GENI QUP

[alokc]

Please don't review this patch. I've resend patches after adding all the 
mailing list.

Sorry for inconvenience.

On 2019-01-21 16:51, Alok Chauhan wrote:

Add documentation for the interconnect and interconnect-names bindings
for the GENI QUP as detailed by bindings/interconnect/interconnect.txt.

Signed-off-by: Alok Chauhan 
---
 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10 
++

 1 file changed, 10 insertions(+)

diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
index dab7ca9..44d7e02 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -17,6 +17,12 @@ Required properties if child node exists:
 - #address-cells:  Must be <1> for Serial Engine Address
 - #size-cells: Must be <1> for Serial Engine Address Size
 - ranges:  Must be present
+- interconnects:   phandle to a interconnect provider. Please refer
+   ../interconnect/interconnect.txt for details.
+   Must be 2 paths corresponding to 2 AXI ports.
+- interconnect-names:  Port names to differentiate between the
+   2 interconnect paths defined with interconnect
+   specifier.

 Properties for children:

@@ -67,6 +73,10 @@ Example:
#size-cells = <1>;
ranges;

+   interconnects = < 11  512>,
+   < 0  543>;
+   interconnect-names = "qup-memory", "qup-config";
+
i2c0: i2c@a94000 {
compatible = "qcom,geni-i2c";
reg = <0xa94000 0x4000>;


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,a Linux Foundation Collaborative Project

Re: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

[Kimberly Brown]

On Tue, Jan 22, 2019 at 03:46:48AM +, Dexuan Cui wrote:
> > From: Kimberly Brown 
> > Sent: Monday, January 21, 2019 6:08 PM
> > Subject: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show 
> > functions
> > 
> > The channel level "_show" functions are vulnerable to race conditions.
> > Add a mutex lock and unlock around the call to the channel level "_show"
> > functions in vmbus_chan_attr_show().
> > 
> > This problem was discussed here:
> > https://lkml.org/lkml/2018/10/18/830
> > 
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -1414,6 +1414,7 @@ static ssize_t vmbus_chan_attr_show(struct kobject
> > *kobj,
> > = container_of(attr, struct vmbus_chan_attribute, attr);
> > const struct vmbus_channel *chan
> > = container_of(kobj, struct vmbus_channel, kobj);
> > +   ssize_t ret;
> > 
> > if (!attribute->show)
> > return -EIO;
> > @@ -1421,7 +1422,10 @@ static ssize_t vmbus_chan_attr_show(struct
> > kobject *kobj,
> > if (chan->state != CHANNEL_OPENED_STATE)
> > return -EINVAL;
> > 
> > -   return attribute->show(chan, buf);
> > +   mutex_lock(_connection.channel_mutex);
> > +   ret = attribute->show(chan, buf);
> > +   mutex_unlock(_connection.channel_mutex);
> > +   return ret;
> >  }
> 
> It looks this patch is already able to fix the original issue:
> 6712cc9c2211 ("vmbus: don't return values for uninitalized channels"),
> as chan->state can't be CHANNEL_OPENED_STATE when
> channel->ringbuffer_page is not set up yet, or has been freed.
> 
> Thanks,
> -- Dexuan

I think that patch 6712cc9c2211 fixes the problem when the channel is
not set up yet, but it doesn't fix the problem when the channel is being
closed. The channel could be freed after the check that "chan->state" is
CHANNEL_OPENED_STATE, while the "attribute->show()" function is running.

Actually, there should be checks that "chan" is not null and that
"chan->state" is CHANNEL_OPENED_STATE within the locked section. I'll
need to fix that.

[PATCH v4 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller

[Vignesh R]

Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.

Tested with mt35xu512aba Octal flash on TI's AM654 EVM.

Signed-off-by: Vignesh R 
---

v4: Fix comments by Tudor on v3
v3: No changes
v2: Declare Octal mode capability based on compatible.

 drivers/mtd/spi-nor/cadence-quadspi.c | 53 +--
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..2091addc45a3 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
 /* Quirks */
 #define CQSPI_NEEDS_WR_DELAY   BIT(0)
 
+/* Capabilities mask */
+#define cqspi_base_hwcaps_mask \
+   (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+   SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 |   \
+   SNOR_HWCAPS_PP)
+
 struct cqspi_st;
 
 struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
 };
 
+struct cqspi_driver_platdata {
+   u32 hwcaps_mask;
+   u8 quirks;
+};
+
 /* Operation timeout value */
 #define CQSPI_TIMEOUT_MS   500
 #define CQSPI_READ_TIMEOUT_MS  10
@@ -101,6 +112,7 @@ struct cqspi_st {
 #define CQSPI_INST_TYPE_SINGLE 0
 #define CQSPI_INST_TYPE_DUAL   1
 #define CQSPI_INST_TYPE_QUAD   2
+#define CQSPI_INST_TYPE_OCTAL  3
 
 #define CQSPI_DUMMY_CLKS_PER_BYTE  8
 #define CQSPI_DUMMY_BYTES_MAX  4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const 
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+   case SNOR_PROTO_1_1_8:
+   f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+   break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,22 @@ static void cqspi_request_mmap_dma(struct cqspi_st 
*cqspi)
 
 static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
 {
-   const struct spi_nor_hwcaps hwcaps = {
-   .mask = SNOR_HWCAPS_READ |
-   SNOR_HWCAPS_READ_FAST |
-   SNOR_HWCAPS_READ_1_1_2 |
-   SNOR_HWCAPS_READ_1_1_4 |
-   SNOR_HWCAPS_PP,
-   };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+   const struct cqspi_driver_platdata *ddata;
+   struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
 
+   ddata = of_device_get_match_data(dev);
+   if (!ddata)
+   hwcaps.mask = cqspi_base_hwcaps_mask;
+   else
+   hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
-   unsigned long data;
+   const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
 
@@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
 
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
-   data  = (unsigned long)of_device_get_match_data(dev);
-   if (data & CQSPI_NEEDS_WR_DELAY)
+   ddata  = of_device_get_match_data(dev);
+   if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
   cqspi->master_ref_clk_hz);
 
@@ -1460,14 +1476,27 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
 #define CQSPI_DEV_PM_OPS   NULL
 #endif
 
+static const struct cqspi_driver_platdata k2g_qspi = {
+   .hwcaps_mask = cqspi_base_hwcaps_mask,
+   .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+   .hwcaps_mask = cqspi_base_hwcaps_mask | SNOR_HWCAPS_READ_1_1_8,
+   .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
 static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
-   .data = (void *)0,
},
{
.compatible = "ti,k2g-qspi",
-   .data = (void *)CQSPI_NEEDS_WR_DELAY,
+   .data = 

[PATCH v4 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC

[Vignesh R]

AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence
QSPI controller but supports Octal IO(x8 data lines) and Double Data
Rate(DDR) mode. Add new compatible to support OSPI controller on TI's
AM654 SoCs.

Signed-off-by: Vignesh R 
Reviewed-by: Rob Herring 
---
v4: No changes

 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index bb2075df9b38..4345c3a6f530 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible : should be one of the following:
Generic default - "cdns,qspi-nor".
For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
+   For TI AM654 SoC  - "ti,am654-ospi", "cdns,qspi-nor".
 - reg : Contains two entries, each of which is a tuple consisting of a
physical address and length. The first entry is the address and
length of the controller register set. The second entry is the
-- 
2.20.1

Re: [PATCH 9/9] drm/mediatek: add dpi dual edge support

[Jitao Shi]

Hi CK,

Ok, I'll send it again in an independent patch.

Best Regards
Jitao

On Wed, 2019-01-16 at 14:52 +0800, CK Hu (胡俊光) wrote:
> Hi, Chunhui:
> 
> > -Original Message-
> > From: chunhui dai [mailto:chunhui@mediatek.com]
> > Sent: Friday, January 04, 2019 3:04 PM
> > To: --to=Michael Turquette; Stephen Boyd; CK Hu (胡俊光)
> > Cc: Matthias Brugger; Philipp Zabel; David Airlie; Chunhui Dai (戴春晖); Sean
> > Wang; Ryder Lee (李庚諺); Colin Ian King; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux-media...@lists.infradead.org; dri-de...@lists.freedesktop.org;
> > srv_heupstream; Bibby Hsieh (謝濟遠); JamesJJ Liao (廖建智); Jitao Shi (石记
> > 涛)
> > Subject: [PATCH 9/9] drm/mediatek: add dpi dual edge support
> > 
> > DPI sample on rising and falling edge. It can reduce half data io.
> 
> This patch looks like a patch for MT8183. For MT8173 and MT2701, dual_edge is 
> false.
> For now, we have not support MT8183 yet.
> So you could just set dual_edge to false and remove MT8183 part in this patch.
> You could send the MT8183 part in an independent patch, not in a series of 
> MT2701.
> 
> Regards,
> CK
> 
> > 
> > Signed-off-by: Jitao Shi 
> > Signed-off-by: chunhui dai 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 30
> > ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 4a2f4a6..acb4f47 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
> > unsigned int (*cal_factor)(int clock);
> > u32 reg_h_fre_con;
> > bool edge_sel_en;
> > +   bool dual_edge;
> >  };
> > 
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> > @@ -353,6 +354,15 @@ static void mtk_dpi_config_disable_edge(struct
> > mtk_dpi *dpi)
> > mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);  }
> > 
> > +static void mtk_dpi_config_dual_edge(struct mtk_dpi *dpi) {
> > +   if (dpi->conf->dual_edge) {
> > +   mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN |
> > +   DDR_4PHASE, DDR_EN | DDR_4PHASE);
> > +   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> > +   }
> > +}
> > +
> >  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> > enum mtk_dpi_out_color_format format)  
> > { @@
> > -509,6 +519,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> > mtk_dpi_config_color_format(dpi, dpi->color_format);
> > mtk_dpi_config_2n_h_fre(dpi);
> > mtk_dpi_config_disable_edge(dpi);
> > +   mtk_dpi_config_dual_edge(dpi);
> > mtk_dpi_sw_reset(dpi, false);
> > 
> > return 0;
> > @@ -669,6 +680,16 @@ static unsigned int mt2701_calculate_factor(int
> > clock)
> > return 1;
> >  }
> > 
> > +static unsigned int mt8183_calculate_factor(int clock) {
> > +   if (clock <= 27000)
> > +   return 8;
> > +   else if (clock <= 167000)
> > +   return 4;
> > +   else
> > +   return 2;
> > +}
> > +
> >  static const struct mtk_dpi_conf mt8173_conf = {
> > .cal_factor = mt8173_calculate_factor,
> > .reg_h_fre_con = 0xe0,
> > @@ -680,6 +701,12 @@ static unsigned int mt2701_calculate_factor(int
> > clock)
> > .edge_sel_en = true,
> >  };
> > 
> > +static const struct mtk_dpi_conf mt8183_conf = {
> > +   .cal_factor = mt8183_calculate_factor,
> > +   .reg_h_fre_con = 0xe0,
> > +   .dual_edge = true,
> > +};
> > +
> >  static int mtk_dpi_probe(struct platform_device *pdev)  {
> > struct device *dev = >dev;
> > @@ -775,6 +802,9 @@ static int mtk_dpi_remove(struct platform_device
> > *pdev)
> > { .compatible = "mediatek,mt8173-dpi",
> >   .data = _conf,
> > },
> > +   { .compatible = "mediatek,mt8183-dpi",
> > + .data = _conf,
> > +   },
> > { },
> >  };
> > 
> > --
> > 1.9.1
> 

[PATCH v4 0/2] cadence-quadspi: Add Octal mode support

[Vignesh R]

This series adds support for OSPI version of Cadence QSPI controller IP.
Tested with AM654 EVM with MT35x512 Octal flash

Changes:
v4:
Fix comments on v3 by Tudor.
Rebase on top latest linux-next(all dependencies are now part of -next)

v3:
Rebase on top of v7 of Yogesh's series[1]

v2:
spi-nor core patches dropped, are now part of Yogesh's series [1]
Declare Octal mode capability based on compatible.

Vignesh R (2):
  dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
  mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller

 .../bindings/mtd/cadence-quadspi.txt  |  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 53 ++-
 2 files changed, 42 insertions(+), 12 deletions(-)

-- 
2.20.1

[PATCHv6 4/4] misc: pci_endpoint_test: Add the layerscape EP device support

[Xiaowei Bao]

Add the layerscape EP device support in pci_endpoint_test driver.

Signed-off-by: Xiaowei Bao 
Reviewed-by: Minghuan Lian 
Reviewed-by: Zhiqiang Hou 
Reviewed-by: Greg KH 
---
v2:
 - no change
v3:
 - no change
v4:
 - delate the comments.
v5:
 - no change.
v6:
 - no change.

 drivers/misc/pci_endpoint_test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 896e2df..29582fe 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -788,6 +788,7 @@ static void pci_endpoint_test_remove(struct pci_dev *pdev)
 static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
+   { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
{ PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, 0xedda) },
{ }
 };
-- 
1.7.1

[PATCHv6 2/4] arm64: dts: Add the PCIE EP node in dts

[Xiaowei Bao]

Add the PCIE EP node in dts for ls1046a.

Signed-off-by: Xiaowei Bao 
Reviewed-by: Minghuan Lian 
Reviewed-by: Zhiqiang Hou 
Reviewed-by: Rob Herring 
---
v2:
 - Add the SoC specific compatibles. 
v3:
 - no change
v4:
 - no change
v5:
 - change the OB win number due to the RM update.
v6:
 - no change

 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   34 +++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 0e762ca..cb71850 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -666,6 +666,17 @@
status = "disabled";
};
 
+   pcie_ep@340 {
+   compatible = "fsl,ls1046a-pcie-ep","fsl,ls-pcie-ep";
+   reg = <0x00 0x0340 0x0 0x0010
+   0x40 0x 0x8 0x>;
+   reg-names = "regs", "addr_space";
+   num-ib-windows = <6>;
+   num-ob-windows = <8>;
+   num-lanes = <2>;
+   status = "disabled";
+   };
+
pcie@350 {
compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
@@ -693,6 +704,17 @@
status = "disabled";
};
 
+   pcie_ep@350 {
+   compatible = "fsl,ls1046a-pcie-ep","fsl,ls-pcie-ep";
+   reg = <0x00 0x0350 0x0 0x0010
+   0x48 0x 0x8 0x>;
+   reg-names = "regs", "addr_space";
+   num-ib-windows = <6>;
+   num-ob-windows = <8>;
+   num-lanes = <2>;
+   status = "disabled";
+   };
+
pcie@360 {
compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
@@ -720,6 +742,17 @@
status = "disabled";
};
 
+   pcie_ep@360 {
+   compatible = "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep";
+   reg = <0x00 0x0360 0x0 0x0010
+   0x50 0x 0x8 0x>;
+   reg-names = "regs", "addr_space";
+   num-ib-windows = <6>;
+   num-ob-windows = <8>;
+   num-lanes = <2>;
+   status = "disabled";
+   };
+
qdma: dma-controller@838 {
compatible = "fsl,ls1046a-qdma", "fsl,ls1021a-qdma";
reg = <0x0 0x838 0x0 0x1000>, /* Controller regs */
@@ -740,7 +773,6 @@
queue-sizes = <64 64>;
big-endian;
};
-
};
 
reserved-memory {
-- 
1.7.1

[PATCHv6 3/4] pci: layerscape: Add the EP mode support.

[Xiaowei Bao]

Add the PCIe EP mode support for layerscape platform.

Signed-off-by: Xiaowei Bao 
Reviewed-by: Minghuan Lian 
Reviewed-by: Zhiqiang Hou 
Reviewed-by: Kishon Vijay Abraham I 
---
depends on: https://patchwork.kernel.org/project/linux-pci/list/?series=66177

v2:
 - remove the EP mode check function.
v3:
 - modif the return value when enter default case.
v4:
 - no change.
v5:
 - no change.
v6:
 - modify the code base on the submit patch of the EP framework.

 drivers/pci/controller/dwc/Makefile|2 +-
 drivers/pci/controller/dwc/pci-layerscape-ep.c |  157 
 2 files changed, 158 insertions(+), 1 deletions(-)
 create mode 100644 drivers/pci/controller/dwc/pci-layerscape-ep.c

diff --git a/drivers/pci/controller/dwc/Makefile 
b/drivers/pci/controller/dwc/Makefile
index 7bcdcdf..b5f3b83 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
 obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c 
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
new file mode 100644
index 000..ddc2dbb
--- /dev/null
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe controller EP driver for Freescale Layerscape SoCs
+ *
+ * Copyright (C) 2018 NXP Semiconductor.
+ *
+ * Author: Xiaowei Bao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE_DBI2_OFFSET   0x1000  /* DBI2 base address*/
+
+struct ls_pcie_ep {
+   struct dw_pcie  *pci;
+};
+
+#define to_ls_pcie_ep(x)   dev_get_drvdata((x)->dev)
+
+static int ls_pcie_establish_link(struct dw_pcie *pci)
+{
+   return 0;
+}
+
+static const struct dw_pcie_ops ls_pcie_ep_ops = {
+   .start_link = ls_pcie_establish_link,
+};
+
+static const struct of_device_id ls_pcie_ep_of_match[] = {
+   { .compatible = "fsl,ls-pcie-ep",},
+   { },
+};
+
+static const struct pci_epc_features ls_pcie_epc_features = {
+   .linkup_notifier = false,
+   .msi_capable = true,
+   .msix_capable = false,
+};
+
+static const struct pci_epc_features*
+ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
+{
+   return _pcie_epc_features;
+}
+
+static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
+{
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   struct pci_epc *epc = ep->epc;
+   enum pci_barno bar;
+
+   for (bar = BAR_0; bar <= BAR_5; bar++)
+   dw_pcie_ep_reset_bar(pci, bar);
+}
+
+static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
+ enum pci_epc_irq_type type, u16 interrupt_num)
+{
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+   switch (type) {
+   case PCI_EPC_IRQ_LEGACY:
+   return dw_pcie_ep_raise_legacy_irq(ep, func_no);
+   case PCI_EPC_IRQ_MSI:
+   return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
+   case PCI_EPC_IRQ_MSIX:
+   return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
+   default:
+   dev_err(pci->dev, "UNKNOWN IRQ type\n");
+   return -EINVAL;
+   }
+}
+
+static struct dw_pcie_ep_ops pcie_ep_ops = {
+   .ep_init = ls_pcie_ep_init,
+   .raise_irq = ls_pcie_ep_raise_irq,
+   .get_features = ls_pcie_ep_get_features,
+};
+
+static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
+   struct platform_device *pdev)
+{
+   struct dw_pcie *pci = pcie->pci;
+   struct device *dev = pci->dev;
+   struct dw_pcie_ep *ep;
+   struct resource *res;
+   int ret;
+
+   ep = >ep;
+   ep->ops = _ep_ops;
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
+   if (!res)
+   return -EINVAL;
+
+   ep->phys_base = res->start;
+   ep->addr_size = resource_size(res);
+
+   ret = dw_pcie_ep_init(ep);
+   if (ret) {
+   dev_err(dev, "failed to initialize endpoint\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int __init ls_pcie_ep_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct dw_pcie *pci;
+   struct ls_pcie_ep *pcie;
+   struct resource *dbi_base;
+   int ret;
+
+   pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
+   if (!pcie)
+   return -ENOMEM;
+
+   pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+   if (!pci)
+   

[PATCHv6 1/4] dt-bindings: add DT binding for the layerscape PCIe controller with EP mode

[Xiaowei Bao]

Add the documentation for the Device Tree binding for the layerscape PCIe
controller with EP mode.

Signed-off-by: Xiaowei Bao 
Reviewed-by: Minghuan Lian 
Reviewed-by: Zhiqiang Hou 
Reviewed-by: Rob Herring 
---
v2:
 - Add the SoC specific compatibles.
v3:
 - modify the commit message.
v4:
 - no change.
v5:
 - no change.
v6:
 - no change.

 .../devicetree/bindings/pci/layerscape-pci.txt |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 9b2b8d6..e20ceaa 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -13,6 +13,7 @@ information.
 
 Required properties:
 - compatible: should contain the platform identifier such as:
+  RC mode:
 "fsl,ls1021a-pcie"
 "fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
 "fsl,ls2088a-pcie"
@@ -20,6 +21,8 @@ Required properties:
 "fsl,ls1046a-pcie"
 "fsl,ls1043a-pcie"
 "fsl,ls1012a-pcie"
+  EP mode:
+   "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
 - reg: base addresses and lengths of the PCIe controller register blocks.
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
-- 
1.7.1

[PATCH 5/6] tty: serial: qcom_geni_serial: Add interconnect support

[Alok Chauhan]

Get the interconnect paths for Uart based Serial Engine device
and vote accordingly based on maximum supported Uart frequency.

Signed-off-by: Alok Chauhan 
---
 drivers/tty/serial/qcom_geni_serial.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/qcom_geni_serial.c 
b/drivers/tty/serial/qcom_geni_serial.c
index a72d6d9..e2ea499 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* UART specific GENI registers */
 #define SE_UART_LOOPBACK_CFG   0x22c
@@ -1348,6 +1349,22 @@ static int qcom_geni_serial_probe(struct platform_device 
*pdev)
return ret;
}
 
+   /* Set the bus quota to a reasonable value */
+   port->se.avg_bw = console ? Bps_to_icc(1000) : Bps_to_icc(2500);
+   port->se.peak_bw = Bps_to_icc(7680);
+   ret = geni_interconnect_init(>se);
+   if (ret) {
+   dev_err(>dev, "interconnect_init failed %d\n", ret);
+   return ret;
+   }
+
+   /*
+* Vote for interconnect path early. This has to move as part of
+* Runtime PM APIs when implemented for better control betwen
+* console and non-console usecases
+*/
+   geni_icc_update_bw(>se, true);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
@@ -1385,8 +1402,15 @@ static int __maybe_unused 
qcom_geni_serial_sys_suspend(struct device *dev)
 {
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = >uport;
+   int ret;
+
+   ret = uart_suspend_port(uport->private_data, uport);
+   if (ret)
+   return ret;
+
+   geni_icc_update_bw(>se, false);
 
-   return uart_suspend_port(uport->private_data, uport);
+   return 0;
 }
 
 static int __maybe_unused qcom_geni_serial_sys_resume(struct device *dev)
@@ -1394,6 +1418,7 @@ static int __maybe_unused 
qcom_geni_serial_sys_resume(struct device *dev)
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = >uport;
 
+   geni_icc_update_bw(>se, true);
return uart_resume_port(uport->private_data, uport);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 6/6] arm64: dts: sdm845: Add interconnect for GENI QUP

[Alok Chauhan]

Add interconnect ports for GENI QUPs to set bus
capabilities.

Signed-off-by: Alok Chauhan 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c27cbd3..fb0a8a7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -374,6 +374,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+   interconnects = <_hlos MASTER_BLSP_1
+   _hlos SLAVE_EBI1>,
+   <_hlos MASTER_APPSS_PROC
+   _hlos SLAVE_BLSP_1>;
+   interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
 
i2c0: i2c@88 {
@@ -682,6 +689,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+   interconnects = <_hlos MASTER_BLSP_2
+   _hlos SLAVE_EBI1>,
+   <_hlos MASTER_APPSS_PROC
+   _hlos SLAVE_BLSP_2>;
+   interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
 
i2c8: i2c@a8 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 4/6] spi: spi-geni-qcom: Add interconnect support

[Alok Chauhan]

Get the interconnect paths for SPI based Serial Engine device
and vote accordingly based on maximum supported SPI frequency.

Signed-off-by: Alok Chauhan 
---
 drivers/spi/spi-geni-qcom.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index fdb7cb88..7bbbe9d 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* SPI SE specific registers and respective register fields */
 #define SE_SPI_CPHA0x224
@@ -589,6 +590,15 @@ static int spi_geni_probe(struct platform_device *pdev)
spin_lock_init(>lock);
pm_runtime_enable(>dev);
 
+   /* Set the bus quota to a reasonable value */
+   mas->se.avg_bw = Bps_to_icc(2500);
+   mas->se.peak_bw = Bps_to_icc(2);
+   ret = geni_interconnect_init(>se);
+   if (ret) {
+   dev_err(>dev, "interconnect_init failed %d\n", ret);
+   return ret;
+   }
+
ret = spi_geni_init(mas);
if (ret)
goto spi_geni_probe_runtime_disable;
@@ -628,8 +638,15 @@ static int __maybe_unused spi_geni_runtime_suspend(struct 
device *dev)
 {
struct spi_master *spi = dev_get_drvdata(dev);
struct spi_geni_master *mas = spi_master_get_devdata(spi);
+   int ret;
 
-   return geni_se_resources_off(>se);
+   ret = geni_se_resources_off(>se);
+   if (ret)
+   return ret;
+
+   geni_icc_update_bw(>se, false);
+
+   return 0;
 }
 
 static int __maybe_unused spi_geni_runtime_resume(struct device *dev)
@@ -637,6 +654,7 @@ static int __maybe_unused spi_geni_runtime_resume(struct 
device *dev)
struct spi_master *spi = dev_get_drvdata(dev);
struct spi_geni_master *mas = spi_master_get_devdata(spi);
 
+   geni_icc_update_bw(>se, true);
return geni_se_resources_on(>se);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/6] dt-bindings: soc: qcom: Add interconnect binding for GENI QUP

[Alok Chauhan]

Add documentation for the interconnect and interconnect-names bindings
for the GENI QUP as detailed by bindings/interconnect/interconnect.txt.

Signed-off-by: Alok Chauhan 
---
 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
index dab7ca9..44d7e02 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -17,6 +17,12 @@ Required properties if child node exists:
 - #address-cells:  Must be <1> for Serial Engine Address
 - #size-cells: Must be <1> for Serial Engine Address Size
 - ranges:  Must be present
+- interconnects:   phandle to a interconnect provider. Please refer
+   ../interconnect/interconnect.txt for details.
+   Must be 2 paths corresponding to 2 AXI ports.
+- interconnect-names:  Port names to differentiate between the
+   2 interconnect paths defined with interconnect
+   specifier.
 
 Properties for children:
 
@@ -67,6 +73,10 @@ Example:
#size-cells = <1>;
ranges;
 
+   interconnects = < 11  512>,
+   < 0  543>;
+   interconnect-names = "qup-memory", "qup-config";
+
i2c0: i2c@a94000 {
compatible = "qcom,geni-i2c";
reg = <0xa94000 0x4000>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path

[Alok Chauhan]

Add the wrapper to support for interconnect path voting
from GENI QUP. This wrapper provides the functionalities
to individual Serial Engine device to get the interconnect
path and to vote for bandwidth based on their need.

This wrapper maintains bandwidth votes from each Serial Engine
and send the aggregated vote from GENI QUP to interconnect
framework.

Signed-off-by: Alok Chauhan 
---
 drivers/soc/qcom/qcom-geni-se.c | 129 
 include/linux/qcom-geni-se.h|  11 
 2 files changed, 140 insertions(+)

diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index 6b8ef01..1d8dcb1 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: Overview
@@ -84,11 +85,21 @@
  * @dev:   Device pointer of the QUP wrapper core
  * @base:  Base address of this instance of QUP wrapper core
  * @ahb_clks:  Handle to the primary & secondary AHB clocks
+ * @icc_path:  Array of interconnect path handles
+ * @geni_wrapper_lock: Lock to protect the bus bandwidth request
+ * @cur_avg_bw:Current Bus Average BW request value from GENI 
QUP
+ * @cur_peak_bw:   Current Bus Peak BW request value from GENI QUP
+ * @peak_bw_list_head: Sorted resource list based on peak bus BW
  */
 struct geni_wrapper {
struct device *dev;
void __iomem *base;
struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
+   struct icc_path *icc_path[2];
+   struct mutex geni_wrapper_lock;
+   u32 cur_avg_bw;
+   u32 cur_peak_bw;
+   struct list_head peak_bw_list_head;
 };
 
 #define QUP_HW_VER_REG 0x4
@@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
 }
 
 /**
+ * geni_icc_update_bw() - Request to update bw vote on an interconnect path
+ * @se:Pointer to the concerned serial engine.
+ * @update:Flag to update bw vote.
+ *
+ * This function is used to request set bw vote on interconnect path handle.
+ */
+void geni_icc_update_bw(struct geni_se *se, bool update)
+{
+   struct geni_se *temp = NULL;
+   struct list_head *ins_list_head;
+   struct geni_wrapper *wrapper;
+
+   mutex_lock(>wrapper->geni_wrapper_lock);
+
+   wrapper = se->wrapper;
+
+   if (update) {
+   wrapper->cur_avg_bw += se->avg_bw;
+   ins_list_head = >peak_bw_list_head;
+   list_for_each_entry(temp, >peak_bw_list_head,
+   peak_bw_list) {
+   if (temp->peak_bw < se->peak_bw)
+   break;
+   ins_list_head = >peak_bw_list;
+   }
+
+   list_add(>peak_bw_list, ins_list_head);
+
+   if (ins_list_head == >peak_bw_list_head)
+   wrapper->cur_peak_bw = se->peak_bw;
+   } else {
+   if (unlikely(list_empty(>peak_bw_list))) {
+   mutex_unlock(>geni_wrapper_lock);
+   return;
+   }
+
+   wrapper->cur_avg_bw -= se->avg_bw;
+
+   list_del_init(>peak_bw_list);
+   temp = list_first_entry_or_null(>peak_bw_list_head,
+   struct geni_se, peak_bw_list);
+   if (temp && temp->peak_bw != wrapper->cur_peak_bw)
+   wrapper->cur_peak_bw = temp->peak_bw;
+   else if (!temp && wrapper->cur_peak_bw)
+   wrapper->cur_peak_bw = 0;
+   }
+
+   /*
+* This bw vote is to enable internal QUP core clock as well as to
+* enable path towards memory.
+*/
+   icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
+   wrapper->cur_peak_bw);
+
+   /*
+* This is just register configuration path so doesn't need avg bw.
+* Set only peak bw to enable this path.
+*/
+   icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
+
+   mutex_unlock(>geni_wrapper_lock);
+}
+EXPORT_SYMBOL(geni_icc_update_bw);
+
+/**
  * geni_se_resources_off() - Turn off resources associated with the serial
  *   engine
  * @se:Pointer to the concerned serial engine.
@@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t 
iova, size_t len)
 }
 EXPORT_SYMBOL(geni_se_rx_dma_unprep);
 
+/**
+ * geni_interconnect_init() - Request to get interconnect path handle
+ * @se:Pointer to the concerned serial engine.
+ *
+ * This function is used to get interconnect path handle.
+ */
+int geni_interconnect_init(struct geni_se *se)
+{
+   struct geni_wrapper *wrapper_rsc;
+
+   if (unlikely(!se || !se->wrapper))
+   return -EINVAL;
+
+   wrapper_rsc = se->wrapper;
+
+   if ((IS_ERR_OR_NULL(wrapper_rsc->icc_path[0]) ||
+   

[PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support

[Alok Chauhan]

Get the interconnect paths for I2C based Serial Engine device
and vote accordingly based on maximum supported I2C frequency.

Signed-off-by: Alok Chauhan 
---
 drivers/i2c/busses/i2c-qcom-geni.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index db075bc..e8fe63a 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define SE_I2C_TX_TRANS_LEN0x26c
 #define SE_I2C_RX_TRANS_LEN0x270
@@ -508,6 +509,15 @@ static int geni_i2c_probe(struct platform_device *pdev)
return ret;
}
 
+   /* Set the bus quota to a reasonable value */
+   gi2c->se.avg_bw = Bps_to_icc(1000);
+   gi2c->se.peak_bw = Bps_to_icc(7680);
+   ret = geni_interconnect_init(>se);
+   if (ret) {
+   dev_err(>dev, "interconnect_init failed %d\n", ret);
+   return ret;
+   }
+
ret = device_property_read_u32(>dev, "clock-frequency",
>clk_freq_out);
if (ret) {
@@ -611,6 +621,8 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct 
device *dev)
gi2c->suspended = 1;
}
 
+   geni_icc_update_bw(>se, false);
+
return 0;
 }
 
@@ -619,6 +631,7 @@ static int __maybe_unused geni_i2c_runtime_resume(struct 
device *dev)
int ret;
struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
 
+   geni_icc_update_bw(>se, true);
ret = geni_se_resources_on(>se);
if (ret)
return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/6] Add interconnect support for GENI QUPs

[Alok Chauhan]

This patch series contains following:
* Add wrapper framework to support interconnect path from GENI QUPs.
  This wrapper enabled and help individual SEs to put their BW request.
  Adding this wrapper make sense because we don't want individual SEs
  to request to interconnect driver separately and put individual bw
  votes from QUP.

  This wrapper framework does the following:
  - Request for interconnect path handle
  - Maintain record of individual SEs' avg/peak bw.
  - Aggregated avg/peak bw based on how many SE's are active and put
single bw request from QUP

* Interconnect wrapper API calling from I2C, SPI & Uart driver
* dt binding in sdm845 soc for Interconnect path for GENI QUPs
* dt binding documentation


Alok Chauhan (6):
  dt-bindings: soc: qcom: Add interconnect binding for GENI QUP
  soc: qcom: Add wrapper to support for Interconnect path
  i2c: i2c-qcom-geni: Add interconnect support
  spi: spi-geni-qcom: Add interconnect support
  tty: serial: qcom_geni_serial: Add interconnect support
  arm64: dts: sdm845: Add interconnect for GENI QUP

 .../devicetree/bindings/soc/qcom/qcom,geni-se.txt  |  10 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi   |  14 +++
 drivers/i2c/busses/i2c-qcom-geni.c |  13 +++
 drivers/soc/qcom/qcom-geni-se.c| 129 +
 drivers/spi/spi-geni-qcom.c|  20 +++-
 drivers/tty/serial/qcom_geni_serial.c  |  27 -
 include/linux/qcom-geni-se.h   |  11 ++
 7 files changed, 222 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that

[Keerthy]

On 19/01/19 1:28 PM, J, KEERTHY wrote:
> 
> 
> On 1/19/2019 12:42 PM, Andreas Kemnade wrote:
>> On Sat, 19 Jan 2019 12:09:48 +0530
>> "J, KEERTHY"  wrote:
>>
>>> On 1/19/2019 1:18 AM, Tony Lindgren wrote:
 * Andreas Kemnade  [190118 19:42]:
> On Fri, 18 Jan 2019 20:38:47 +0100
> Andreas Kemnade  wrote:
>  
>> Hi,
>>
>> On Fri, 18 Jan 2019 10:36:30 -0800
>> Tony Lindgren  wrote:
>>
>> [...]
>>> til the next workaround.
>>>  
 That flags also causes the iclk being enabled/disabled
 manually.
>>>
>>> Yes but SWSUP_IDLE for the interface clock to me currently
>>> just means:
>>>
>>> "manually enable and disable ocp interface clock"
>>>   
>> well, if we want to manually disable it and not automatically,
>> we have to disable autoidle or it will be automatically disabled.
>>
>> Disabling it manually when it is already auto-disabled (by
>> autoidle) is
>> just practically a no-op towards the clock.
>>  
>>> and with your changes it becomes:
>>>
>>> "manually enable and disable ocp interface clock and block
>>>    autoidle while in use".
>>>
>>> So aren't we now changing the way things behave in general
>>> for SWSUP_IDLE?
>>>   
>> Yes, we are, so proper testing is needed. But If I read those
>> comments
>> it was always intended this way but not fully implemented because it
>> appeared to be more work like needing a usecounter (which my patchset
>> also adds) for that autoidle flag.
>>   
> and there are quite few hwmods marked by this flag.
> And then there are those clocks marked by this flags (on am33xx) which
> do not have that autoidle feature at all, so the risk is not too high.

 Keerthy, can you please test this series on top of the
 related clock patches with your am335x PM test cases?
>>>
>>> Can you point me to the clock series that needs to be tested
>>> along with this?
>>>
>>
>> https://patchwork.kernel.org/project/linux-clk/list/?series=66691
> 
> Thanks Andreas. I will test both series and get back.

Tested for DS0 (deeps sleep 0 on am33/am43 boards) No issues seen with
the current patch series on top of clock series.

Tested-by: Keerthy 

> 
>>
>> Regards,
>> Andreas
>>

[PATCH v2] media: docs-rst: Document m2m stateless video decoder interface

[Alexandre Courbot]

Documents the protocol that user-space should follow when
communicating with stateless video decoders.

The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
should probably still be considered staging for a short while.

Signed-off-by: Alexandre Courbot 
---
Changes since v1:

* Use timestamps instead of tags to reference frames,
* Applied Paul's suggestions to not require one frame worth of data per OUTPUT
  buffer

One of the effects of requiring sub-frame units to be submitted per request is
that the stateless decoders are not exactly "stateless" anymore: if a frame is
made of several slices, then the decoder must keep track of the buffer in which
the current frame is being decoded between requests, and all the slices for the
current frame must be submitted before we can consider decoding the next one.

Also if we decide to force clients to submit one slice per request, then doesn't
some of the H.264 controls need to change? For instance, in the current v2
there is still a v4l2_ctrl_h264_decode_param::num_slices member. It is used in
Chromium to specify the number of slices given to the
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS control, but is apparently ignored by the
Cedrus driver. Maxime, can you comment on this?

 Documentation/media/uapi/v4l/dev-codec.rst|   5 +
 .../media/uapi/v4l/dev-stateless-decoder.rst  | 378 ++
 2 files changed, 383 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst

diff --git a/Documentation/media/uapi/v4l/dev-codec.rst 
b/Documentation/media/uapi/v4l/dev-codec.rst
index b5e017c17834..6ce38045d3c8 100644
--- a/Documentation/media/uapi/v4l/dev-codec.rst
+++ b/Documentation/media/uapi/v4l/dev-codec.rst
@@ -13,6 +13,11 @@
 Codec Interface
 ***
 
+.. toctree::
+:maxdepth: 1
+
+dev-stateless-decoder
+
 A V4L2 codec can compress, decompress, transform, or otherwise convert
 video data from one format into another format, in memory. Typically
 such devices are memory-to-memory devices (i.e. devices with the
diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst 
b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
new file mode 100644
index ..148b1751dd20
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
@@ -0,0 +1,378 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _stateless_decoder:
+
+**
+Memory-to-memory Stateless Video Decoder Interface
+**
+
+A stateless decoder is a decoder that works without retaining any kind of state
+between processing frames. This means that each frame is decoded independently
+of any previous and future frames, and that the client is responsible for
+maintaining the decoding state and providing it to the decoder with each
+decoding request. This is in contrast to the stateful video decoder interface,
+where the hardware and driver maintain the decoding state and all the client
+has to do is to provide the raw encoded stream.
+
+This section describes how user-space ("the client") is expected to communicate
+with such decoders in order to successfully decode an encoded stream. Compared
+to stateful codecs, the decoder/client sequence is simpler, but the cost of
+this simplicity is extra complexity in the client which must maintain a
+consistent decoding state.
+
+Stateless decoders make use of the request API. A stateless decoder must thus
+expose the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its ``OUTPUT`` 
queue
+when :c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are invoked.
+
+Querying capabilities
+=
+
+1. To enumerate the set of coded formats supported by the decoder, the client
+   calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
+
+   * The driver must always return the full set of supported ``OUTPUT`` 
formats,
+ irrespective of the format currently set on the ``CAPTURE`` queue.
+
+   * Simultaneously, the driver must restrain the set of values returned by
+ codec-specific capability controls (such as H.264 profiles) to the set
+ actually supported by the hardware.
+
+2. To enumerate the set of supported raw formats, the client calls
+   :c:func:`VIDIOC_ENUM_FMT` on the ``CAPTURE`` queue.
+
+   * The driver must return only the formats supported for the format currently
+ active on the ``OUTPUT`` queue.
+
+   * Depending on the currently set ``OUTPUT`` format, the set of supported raw
+ formats may depend on the value of some controls (e.g. parsed format
+ headers) which are codec-dependent. The client is responsible for making
+ sure that these controls are set before querying the ``CAPTURE`` queue.
+ Failure to do so will result in the default values for these controls 
being
+ used, and a returned set of formats that may not be usable for the media
+ 

Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support

[alokc]

On 2019-01-21 18:13, Mark Brown wrote:

On Mon, Jan 21, 2019 at 04:51:41PM +0530, Alok Chauhan wrote:

Get the interconnect paths for SPI based Serial Engine device
and vote accordingly based on maximum supported SPI frequency.


I don't have any of the other patches in this series or a cover letter 
-

what's going on with dependencies here?


I am extremely sorry to waste your time. Looks like I missed some 
mailing list while sending patches upstream. I will resend patches 
today.


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,a Linux Foundation Collaborative Project

Re: [PATCH] drivers: extcon: Add support for ptn5150

[Chanwoo Choi]

Hi Vijai,

This patch looks better. But theare are comments about code clean.
I added the comments.

On 19. 1. 21. 오후 6:09, Vijai Kumar K wrote:
> PTN5150A is a small thin low power CC Logic chip supporting
> the USB Type-C connector application with Configurationn Channel(CC)
> control logic detection and indication functions.
> 
> Add driver, Kconfig and Makefile entries.
> 
> Change-Id: I3b2da147a33b913b9ec60cd914b20acd955950c7

Remove it of gerrit system.

> Signed-off-by: Vijai Kumar K 
> ---
>  .../devicetree/bindings/extcon/extcon-ptn5150.txt  |  22 ++
>  drivers/extcon/Kconfig |   8 +
>  drivers/extcon/Makefile|   1 +
>  drivers/extcon/extcon-ptn5150.c| 327 
> +
>  drivers/extcon/extcon-ptn5150.h|  51 
>  5 files changed, 409 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
>  create mode 100644 drivers/extcon/extcon-ptn5150.c
>  create mode 100644 drivers/extcon/extcon-ptn5150.h
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> new file mode 100644
> index 000..8ea33bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> @@ -0,0 +1,22 @@
> +
> +* PTN5150 CC logic device

You better to specify the full name as following:
: PTN5150 CC (Configuration Channel) Logic device

> +PTN5150A is a small thin low power CC Logic chip supporting the USB Type-C

s/Logic/logic

> +connector application with Configuration Channel (CC) control logic 
> detection and
> +indication functions. It is Interfaced to the host controller using an I2C 
> interface.

s/Interfaced/interfaced

> +
> +Required properties:
> +- compatible: Should be "nxp,ptn5150"
> +- reg: Specifies the I2C slave address of the device
> +- int-gpio: GPIO to which INTB is connected

What is meaning of 'INTB'?

> +- vbus-gpio: GPIO which controls VBUS on/off
> +
> +Example:
> + ptn5150@1d  {
> + compatible = "nxp,ptn5150";
> + reg = <0x1d>;
> + int-gpio = < 78 GPIO_ACTIVE_HIGH>;
> + vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_default>;

You need to add some description why pinctrl properties are needed.
For example, some hwmon device driver[1] explained the properties
related to pinctrl. Please add the description as following.

- pinctrl-names : a pinctrl state named "default" must be defined.  
- pinctrl-0 : phandle referencing pin configuration of the PWM ports.   

[1] Documentation/devicetree/hwmon/aspeed-pwm-tacho.txt


> + status = "okay";
> + };

Remove the one tab in front of dt node.

ptn5150@1d  {
compatible = "nxp,ptn5150";
reg = <0x1d>;
int-gpio = < 78 GPIO_ACTIVE_HIGH>;
vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_default>;
status = "okay";
};



> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index a7bca42..6adc797 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -113,6 +113,14 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>  
> +config EXTCON_PTN5150
> + tristate "PTN5150 CC LOGIC USB EXTCON support"

PTN5150 CC (Configuration Channel) LOGIC USB EXTCON support

> + depends on I2C
> + select REGMAP_I2C
> + help
> +   Say Y here to enable support for USB peripheral and USB host
> +   detection by ptn5150 cc logic chip.

cc -> CC (Configuration Channel)

> +
>  config EXTCON_QCOM_SPMI_MISC
>   tristate "Qualcomm USB extcon support"
>   depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0888fde..261ce4c 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_EXTCON_MAX77693)   += extcon-max77693.o
>  obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_PTN5150) += extcon-ptn5150.o
>  obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> new file mode 100644
> index 000..bc00874
> --- /dev/null
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -0,0 +1,327 @@
> +/*
> + * extcon-ptn5150.c - PTN5150 CC logic extcon driver to support USB detection
> + *
> + * Copyright (c) 

Re: [PATCH RFC 02/24] mm: userfault: return VM_FAULT_RETRY on signals

[Peter Xu]

On Mon, Jan 21, 2019 at 10:40:18AM -0500, Jerome Glisse wrote:
> On Mon, Jan 21, 2019 at 03:57:00PM +0800, Peter Xu wrote:
> > There was a special path in handle_userfault() in the past that we'll
> > return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting
> > for userfault handling.  We did that by reacquiring the mmap_sem before
> > returning.  However that brings a risk in that the vmas might have
> > changed when we retake the mmap_sem and even we could be holding an
> > invalid vma structure.  The problem was reported by syzbot.
> 
> This is confusing this should be a patch on its own ie changes to
> fs/userfaultfd.c where you remove that path.

Sure I will.

> 
> > 
> > This patch removes the special path and we'll return a VM_FAULT_RETRY
> > with the common path even if we have got such signals.  Then for all the
> > architectures that is passing in VM_FAULT_ALLOW_RETRY into
> > handle_mm_fault(), we check not only for SIGKILL but for all the rest of
> > userspace pending signals right after we returned from
> > handle_mm_fault().
> > 
> > The idea comes from the upstream discussion between Linus and Andrea:
> > 
> >   https://lkml.org/lkml/2017/10/30/560
> > 
> > (This patch contains a potential fix for a double-free of mmap_sem on
> >  ARC architecture; please see https://lkml.org/lkml/2018/11/1/723 for
> >  more information)
> 
> This patch should only be about changing the return to userspace rule.
> Before this patch the arch fault handler returned to userspace only
> for fatal signal, after this patch it returns to userspace for any
> signal.

Ok.  I'll make the first patch to do the signal changes, then the
second patch to remove the userfault path explicitly.

> 
> It would be a lot better to have a fix for arc as a separate patch so
> that we can focus on reviewing only one thing.

I just noticed that it was fixed just a few days ago in commit
4d447455e73b.  Then I'll just simply rebase to Linus master and use
the upstream fix, then I can drop this paragraph.

Thanks for the review!

-- 
Peter Xu

Re: [PATCH] ARM: dts: colibri: use valid range configuration for weim

[Shawn Guo]

On Mon, Jan 21, 2019 at 04:53:27PM +0100, Stefan Agner wrote:
> A valid WEIM range configuration must specify range entries for
> all four chip selects. This fixes an error on boot:
>   imx-weim: probe of 21b8000.weim failed with error -22
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

Re: [PATCH v3 1/2] dt-bindings: Add vendor prefix for Catalyst Semiconductor

[Shawn Guo]

On Mon, Jan 21, 2019 at 09:57:04AM +, Martyn Welch wrote:
> Add vendor prefix "catalyst" for Catalyst Semiconductor which is
> already in use but undocumented.
> 
> Signed-off-by: Martyn Welch 
> Reviewed-by: Rob Herring 

Applied both, thanks.

[PATCH v3 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains

[Bjorn Andersson]

From: Rajendra Nayak 

With rpmh ARC resources being modelled as power domains with performance
state, we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating mutliple power domains to a device.

Tested-by: Sibi Sankar 
Reviewed-by: Sibi Sankar 
Signed-off-by: Rajendra Nayak 
[bjorn: Drop device link, improve error handling, name things "proxy"]
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Disable proxy pds if handover did not arrived before stop

 drivers/remoteproc/qcom_q6v5_mss.c | 117 -
 1 file changed, 113 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c
index 01be7314e176..003186ce56c7 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
char **proxy_clk_names;
char **reset_clk_names;
char **active_clk_names;
+   char **proxy_pd_names;
int version;
bool need_mem_protection;
bool has_alt_reset;
@@ -156,9 +159,11 @@ struct q6v5 {
struct clk *active_clks[8];
struct clk *reset_clks[4];
struct clk *proxy_clks[4];
+   struct device *proxy_pds[3];
int active_clk_count;
int reset_clk_count;
int proxy_clk_count;
+   int proxy_pd_count;
 
struct reg_info active_regs[1];
struct reg_info proxy_regs[3];
@@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
clk_disable_unprepare(clks[i]);
 }
 
+static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
+  size_t pd_count)
+{
+   int ret;
+   int i;
+
+   for (i = 0; i < pd_count; i++) {
+   dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+   ret = pm_runtime_get_sync(pds[i]);
+   if (ret < 0)
+   goto unroll_pd_votes;
+   }
+
+   return 0;
+
+unroll_pd_votes:
+   for (i--; i >= 0; i--) {
+   dev_pm_genpd_set_performance_state(pds[i], 0);
+   pm_runtime_put(pds[i]);
+   }
+
+   return ret;
+};
+
+static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
+size_t pd_count)
+{
+   int i;
+
+   for (i = 0; i < pd_count; i++) {
+   dev_pm_genpd_set_performance_state(pds[i], 0);
+   pm_runtime_put(pds[i]);
+   }
+}
+
 static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
   bool remote_owner, phys_addr_t addr,
   size_t size)
@@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
qcom_q6v5_prepare(>q6v5);
 
+   ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+   if (ret < 0) {
+   dev_err(qproc->dev, "failed to enable proxy power domains\n");
+   goto disable_irqs;
+   }
+
ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
qproc->proxy_reg_count);
if (ret) {
dev_err(qproc->dev, "failed to enable proxy supplies\n");
-   goto disable_irqs;
+   goto disable_proxy_pds;
}
 
ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 disable_proxy_reg:
q6v5_regulator_disable(qproc, qproc->proxy_regs,
   qproc->proxy_reg_count);
+disable_proxy_pds:
+   q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 disable_irqs:
qcom_q6v5_unprepare(>q6v5);
 
@@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 
ret = qcom_q6v5_unprepare(>q6v5);
if (ret) {
+   q6v5_pds_disable(qproc, qproc->proxy_pds,
+qproc->proxy_pd_count);
q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
 qproc->proxy_clk_count);
q6v5_regulator_disable(qproc, qproc->proxy_regs,
@@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
 qproc->proxy_clk_count);
q6v5_regulator_disable(qproc, qproc->proxy_regs,
   qproc->proxy_reg_count);
+   q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 }
 
 static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
@@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device *dev, struct 
clk **clks,
return i;
 }
 
+static int q6v5_pds_attach(struct device *dev, struct device **devs,
+  char **pd_names)
+{
+   size_t num_pds = 0;
+   int ret;
+   int i;
+
+   if 

[PATCH v3 04/10] dt-bindings: soc: qcom: Add AOSS QMP binding

[Bjorn Andersson]

Add binding for the QMP based side-channel communication mechanism to
the AOSS, which is used to control resources not exposed through the
RPMh interface.

Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Update indentation of example
- Add colling device subnodes to the description

 .../bindings/soc/qcom/qcom,aoss-qmp.txt   | 75 +++
 include/dt-bindings/power/qcom-aoss-qmp.h | 15 
 2 files changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
 create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
new file mode 100644
index ..881dc8c7907a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -0,0 +1,75 @@
+Qualcomm Always-On Subsystem side channel binding
+
+This binding describes the hardware component responsible for side channel
+requests to the always-on subsystem (AOSS), used for certain power management
+requests that is not handled by the standard RPMh interface. Each client in the
+SoC has it's own block of message RAM and IRQ for communication with the AOSS.
+The protocol used to communicate in the message RAM is known as QMP.
+
+The AOSS side channel exposes control over a set of resources, used to control
+a set of debug related clocks and to affect the low power state of resources
+related to the secondary subsystems. These resources are exposed as a set of
+power-domains.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,sdm845-aoss-qmp"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the message RAM for this
+   client's communication with the AOSS
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the AOSS message IRQ for this client
+
+- mboxes:
+   Usage: required
+   Value type: 
+   Definition: reference to the mailbox representing the outgoing doorbell
+   in APCS for this client, as described in mailbox/mailbox.txt
+
+- #power-domain-cells:
+   Usage: optional
+   Value type: 
+   Definition: must be 1
+   The provided power-domains are:
+   QDSS clock-domain (0), CDSP state (1), LPASS state (2),
+   modem state (3), SLPI state (4), SPSS state (5) and Venus
+   state (6).
+
+= SUBNODES
+The AOSS side channel also provides the controls for three cooling devices,
+these are expressed as subnodes of the QMP node. The name of the node is used
+to identify the resource and must therefor be "cx", "mx" or "ebi".
+
+- #cooling-cells:
+   Usage: optional
+   Value type: 
+   Definition: must be 2
+
+= EXAMPLE
+
+The following example represents the AOSS side-channel message RAM and the
+mechanism exposing the power-domains, as found in SDM845.
+
+  aoss_qmp: qmp@c30 {
+ compatible = "qcom,sdm845-aoss-qmp";
+ reg = <0x0c30 0x10>;
+ interrupts = ;
+ mboxes = <_shared 0>;
+
+ #power-domain-cells = <1>;
+
+ cx_cdev: cx {
+   #cooling-cells = <2>;
+ };
+
+ mx_cdev: mx {
+   #cooling-cells = <2>;
+ };
+  };
diff --git a/include/dt-bindings/power/qcom-aoss-qmp.h 
b/include/dt-bindings/power/qcom-aoss-qmp.h
new file mode 100644
index ..7d8ac1a4f90c
--- /dev/null
+++ b/include/dt-bindings/power/qcom-aoss-qmp.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Linaro Ltd. */
+
+#ifndef __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+#define __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+
+#define AOSS_QMP_QDSS_CLK  0
+#define AOSS_QMP_LS_CDSP   1
+#define AOSS_QMP_LS_LPASS  2
+#define AOSS_QMP_LS_MODEM  3
+#define AOSS_QMP_LS_SLPI   4
+#define AOSS_QMP_LS_SPSS   5
+#define AOSS_QMP_LS_VENUS  6
+
+#endif
-- 
2.18.0

[PATCH v3 01/10] arm64: dts: qcom: sdm845: Update PIL region memory map

[Bjorn Andersson]

Update existing and add all missing PIL regions to the reserved memory
map, as described in version 10.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New patch

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 61 ++--
 1 file changed, 58 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0ec827394e92..cdcac3704c13 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -89,12 +89,47 @@
};
 
memory@8620 {
-   reg = <0 0x8620 0 0x2d0>;
+   reg = <0 0x8620 0 0x10>;
no-map;
};
 
-   wlan_msa_mem: memory@9670 {
-   reg = <0 0x9670 0 0x10>;
+   memory@8630 {
+   reg = <0 0x8630 0 0x480>;
+   no-map;
+   };
+
+   memory@8ab0 {
+   reg = <0 0x8ab0 0 0x140>;
+   no-map;
+   };
+
+   memory@8bf0 {
+   reg = <0 0x8bf0 0 0x50>;
+   no-map;
+   };
+
+   ipa_fw_mem: memory@8c40 {
+   reg = <0 0x8c40 0 0x1>;
+   no-map;
+   };
+
+   ipa_gsi_mem: memory@8c41 {
+   reg = <0 0x8c41 0 0x5000>;
+   no-map;
+   };
+
+   memory@8c415000 {
+   reg = <0 0x8c415000 0 0x2000>;
+   no-map;
+   };
+
+   adsp_mem: memory@8c50 {
+   reg = <0 0x8c50 0 0x1a0>;
+   no-map;
+   };
+
+   wlan_msa_mem: memory@8df0 {
+   reg = <0 0x8df0 0 0x10>;
no-map;
};
 
@@ -103,10 +138,30 @@
no-map;
};
 
+   venus_mem: memory@9580 {
+   reg = <0 0x9580 0 0x50>;
+   no-map;
+   };
+
+   cdsp_mem: memory@95d0 {
+   reg = <0 0x95d0 0 0x80>;
+   no-map;
+   };
+
mba_region: memory@9650 {
reg = <0 0x9650 0 0x20>;
no-map;
};
+
+   slpi_mem: memory@9670 {
+   reg = <0 0x9670 0 0x140>;
+   no-map;
+   };
+
+   spss_mem: memory@97b0 {
+   reg = <0 0x97b0 0 0x10>;
+   no-map;
+   };
};
 
cpus {
-- 
2.18.0

[PATCH v3 03/10] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes

[Bjorn Andersson]

Add the ADSP and CDSP nodes for PAS-based remoteproc, supporting booting
these cores on e.g. the MTP, and enable the same for the MTP.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New patch

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  8 
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 58 +
 2 files changed, 66 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index af8c6a2445a2..02b8357c8ce8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -48,6 +48,10 @@
};
 };
 
+_pas {
+   status = "okay";
+};
+
 _rsc {
pm8998-rpmh-regulators {
compatible = "qcom,pm8998-rpmh-regulators";
@@ -344,6 +348,10 @@
};
 };
 
+_pas {
+   status = "okay";
+};
+
  {
protected-clocks = ,
   ,
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 64f57cc5c61a..1033b77856e6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -319,6 +319,64 @@
};
};
 
+   adsp_pas: remoteproc-adsp {
+   compatible = "qcom,sdm845-adsp-pas";
+
+   interrupts-extended = < GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+   label = "lpass";
+   qcom,remote-pid = <2>;
+   mboxes = <_shared 8>;
+   };
+   };
+
+   cdsp_pas: remoteproc-cdsp {
+   compatible = "qcom,sdm845-cdsp-pas";
+
+   interrupts-extended = < GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+   label = "turing";
+   qcom,remote-pid = <5>;
+   mboxes = <_shared 4>;
+   };
+   };
+
tcsr_mutex: hwlock {
compatible = "qcom,tcsr-mutex";
syscon = <_mutex_regs 0 0x1000>;
-- 
2.18.0

[PATCH v3 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845

[Bjorn Andersson]

The SDM845 MSS needs the load_state powerdomain voted for during the
duration of the MSS being powered on, to let the AOSS know that it may
not perform certain power save measures. So vote for this.

Tested-by: Sibi Sankar 
Reviewed-by: Sibi Sankar 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

 drivers/remoteproc/qcom_q6v5_mss.c | 31 --
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c
index 003186ce56c7..3e25016954d9 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -133,6 +133,7 @@ struct rproc_hexagon_res {
char **proxy_clk_names;
char **reset_clk_names;
char **active_clk_names;
+   char **active_pd_names;
char **proxy_pd_names;
int version;
bool need_mem_protection;
@@ -159,10 +160,12 @@ struct q6v5 {
struct clk *active_clks[8];
struct clk *reset_clks[4];
struct clk *proxy_clks[4];
+   struct device *active_pds[1];
struct device *proxy_pds[3];
int active_clk_count;
int reset_clk_count;
int proxy_clk_count;
+   int active_pd_count;
int proxy_pd_count;
 
struct reg_info active_regs[1];
@@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
qcom_q6v5_prepare(>q6v5);
 
+   ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
+   if (ret < 0) {
+   dev_err(qproc->dev, "failed to enable active power domains\n");
+   goto disable_irqs;
+   }
+
ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
if (ret < 0) {
dev_err(qproc->dev, "failed to enable proxy power domains\n");
-   goto disable_irqs;
+   goto disable_active_pds;
}
 
ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
@@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
   qproc->proxy_reg_count);
 disable_proxy_pds:
q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+disable_active_pds:
+   q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 disable_irqs:
qcom_q6v5_unprepare(>q6v5);
 
@@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 qproc->active_clk_count);
q6v5_regulator_disable(qproc, qproc->active_regs,
   qproc->active_reg_count);
+   q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 
/* In case of failure or coredump scenario where reclaiming MBA memory
 * could not happen reclaim it here.
@@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
}
qproc->active_reg_count = ret;
 
+   ret = q6v5_pds_attach(>dev, qproc->active_pds,
+ desc->active_pd_names);
+   if (ret < 0) {
+   dev_err(>dev, "Failed to attach active power domains\n");
+   goto free_rproc;
+   }
+   qproc->active_pd_count = ret;
+
ret = q6v5_pds_attach(>dev, qproc->proxy_pds,
  desc->proxy_pd_names);
if (ret < 0) {
dev_err(>dev, "Failed to init power domains\n");
-   goto free_rproc;
+   goto detach_active_pds;
}
qproc->proxy_pd_count = ret;
 
@@ -1448,6 +1468,8 @@ static int q6v5_probe(struct platform_device *pdev)
 
 detach_proxy_pds:
q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+detach_active_pds:
+   q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 free_rproc:
rproc_free(rproc);
 
@@ -1465,6 +1487,7 @@ static int q6v5_remove(struct platform_device *pdev)
qcom_remove_smd_subdev(qproc->rproc, >smd_subdev);
qcom_remove_ssr_subdev(qproc->rproc, >ssr_subdev);
 
+   q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 
rproc_free(qproc->rproc);
@@ -1491,6 +1514,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
"mnoc_axi",
NULL
},
+   .active_pd_names = (char*[]){
+   "load_state",
+   NULL
+   },
.proxy_pd_names = (char*[]){
"cx",
"mx",
-- 
2.18.0

[PATCH v3 02/10] arm64: dts: qcom: sdm845: Define rmtfs memory

[Bjorn Andersson]

Define the rmtfs memory node, as described in version 10 of the memory
map.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New patch

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdcac3704c13..64f57cc5c61a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -72,6 +72,15 @@
#size-cells = <2>;
ranges;
 
+   rmtfs@85d0 {
+   compatible = "qcom,rmtfs-mem";
+   reg = <0 0x85d0 0 0x20>;
+   no-map;
+
+   qcom,client-id = <1>;
+   qcom,vmid = <15>;
+   };
+
memory@85fc {
reg = <0 0x85fc 0 0x2>;
no-map;
-- 
2.18.0

[PATCH v3 00/10] Qualcomm AOSS QMP driver and modem dts

[Bjorn Andersson]

Update the reserved memory map for SDM845, add the ADSP and CDSP nodes,
introduce a communication driver for the AOSS and a PD driver for this and
finally add the modem remoteproc driver.

Bjorn Andersson (8):
  arm64: dts: qcom: sdm845: Update PIL region memory map
  arm64: dts: qcom: sdm845: Define rmtfs memory
  arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes
  dt-bindings: soc: qcom: Add AOSS QMP binding
  soc: qcom: Add AOSS QMP communication driver
  soc: qcom: Add AOSS QMP genpd provider
  remoteproc: q6v5-mss: Active powerdomain for SDM845
  arm64: dts: qcom: Add AOSS QMP node

Rajendra Nayak (1):
  remoteproc: q6v5-mss: Vote for rpmh power domains

Sibi Sankar (1):
  arm64: dts: qcom: sdm845: Add Q6V5 MSS node

 .../bindings/soc/qcom/qcom,aoss-qmp.txt   |  75 +
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts   |   8 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 196 ++-
 drivers/remoteproc/qcom_q6v5_mss.c| 144 +++-
 drivers/soc/qcom/Kconfig  |  18 +
 drivers/soc/qcom/Makefile |   2 +
 drivers/soc/qcom/aoss-qmp-pd.c| 138 
 drivers/soc/qcom/aoss-qmp.c   | 317 ++
 include/dt-bindings/power/qcom-aoss-qmp.h |  15 +
 include/linux/soc/qcom/aoss-qmp.h |  14 +
 10 files changed, 920 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
 create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c
 create mode 100644 drivers/soc/qcom/aoss-qmp.c
 create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h
 create mode 100644 include/linux/soc/qcom/aoss-qmp.h

-- 
2.18.0

[PATCH v3 06/10] soc: qcom: Add AOSS QMP genpd provider

[Bjorn Andersson]

The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.

Tested-by: Sai Prakash Ranjan 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Add define for request array size

 drivers/soc/qcom/Kconfig   |   9 +++
 drivers/soc/qcom/Makefile  |   1 +
 drivers/soc/qcom/aoss-qmp-pd.c | 138 +
 3 files changed, 148 insertions(+)
 create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index e2c859121b88..9d71e23005ad 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -12,6 +12,15 @@ config QCOM_AOSS_QMP
  micro-controller in the AOSS, using QMP, to control certain resource
  that are not exposed through RPMh.
 
+config QCOM_AOSS_QMP_PD
+   tristate "Qualcomm AOSS Messaging Power Domain driver"
+   depends on QCOM_AOSS_QMP
+   select PM_GENERIC_DOMAINS
+   help
+ This driver provides the means of controlling the AOSS's handling of
+ low-power state for resources related to the remoteproc subsystems as
+ well as controlling the debug clocks.
+
 config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 2c04d27fbf9e..16913e73fddf 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 CFLAGS_rpmh-rsc.o := -I$(src)
 obj-$(CONFIG_QCOM_AOSS_QMP) += aoss-qmp.o
+obj-$(CONFIG_QCOM_AOSS_QMP_PD) += aoss-qmp-pd.o
 obj-$(CONFIG_QCOM_GENI_SE) +=  qcom-geni-se.o
 obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/aoss-qmp-pd.c b/drivers/soc/qcom/aoss-qmp-pd.c
new file mode 100644
index ..82dd569a2bc9
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp-pd.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Requests are expected to be 96 bytes long */
+#define AOSS_QMP_PD_MSG_LEN96
+
+struct qmp_pd {
+   struct qmp *qmp;
+
+   struct generic_pm_domain pd;
+
+   const char *name;
+};
+
+#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
+
+struct qmp_pd_resource {
+   const char *name;
+   int (*on)(struct generic_pm_domain *domain);
+   int (*off)(struct generic_pm_domain *domain);
+};
+
+static int qmp_pd_clock_toggle(struct qmp_pd *res, bool enable)
+{
+   char buf[AOSS_QMP_PD_MSG_LEN];
+
+   snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
+res->name, !!enable);
+   return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_clock_on(struct generic_pm_domain *domain)
+{
+   return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_clock_off(struct generic_pm_domain *domain)
+{
+   return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static int qmp_pd_image_toggle(struct qmp_pd *res, bool enable)
+{
+   char buf[AOSS_QMP_PD_MSG_LEN];
+
+   snprintf(buf, sizeof(buf),
+"{class: image, res: load_state, name: %s, val: %s}",
+res->name, enable ? "on" : "off");
+   return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_image_on(struct generic_pm_domain *domain)
+{
+   return qmp_pd_image_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_image_off(struct generic_pm_domain *domain)
+{
+   return qmp_pd_image_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static const struct qmp_pd_resource sdm845_resources[] = {
+   [AOSS_QMP_QDSS_CLK] = { "qdss", qmp_pd_clock_on, qmp_pd_clock_off },
+   [AOSS_QMP_LS_CDSP] = { "cdsp", qmp_pd_image_on, qmp_pd_image_off },
+   [AOSS_QMP_LS_LPASS] = { "adsp", qmp_pd_image_on, qmp_pd_image_off },
+   [AOSS_QMP_LS_MODEM] = { "modem", qmp_pd_image_on, qmp_pd_image_off },
+   [AOSS_QMP_LS_SLPI] = { "slpi", qmp_pd_image_on, qmp_pd_image_off },
+   [AOSS_QMP_LS_SPSS] = { "spss", qmp_pd_image_on, qmp_pd_image_off },
+   [AOSS_QMP_LS_VENUS] = { "venus", qmp_pd_image_on, qmp_pd_image_off },
+};
+
+static int qmp_pd_probe(struct platform_device *pdev)
+{
+   struct genpd_onecell_data *data;
+   struct device *parent = pdev->dev.parent;
+   struct qmp_pd *res;
+   struct qmp *qmp;
+   size_t num = ARRAY_SIZE(sdm845_resources);
+   int i;
+
+   qmp = dev_get_drvdata(pdev->dev.parent);
+   if (!qmp)
+   return -EINVAL;
+
+   res = devm_kcalloc(>dev, num, sizeof(*res), GFP_KERNEL);
+   if (!res)
+   return -ENOMEM;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   

[PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node

[Bjorn Andersson]

From: Sibi Sankar 

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar 
Reviewed-by: Douglas Anderson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Picked up Sibi's patch
- Fixed reg to work with address/size-cells as 2

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5cc2615461da..78df5f1bce2d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1617,6 +1617,64 @@
clock-names = "xo";
};
 
+   mss_pil: remoteproc@408 {
+   compatible = "qcom,sdm845-mss-pil";
+   reg = <0 0x0408 0 0x408>, <0 0x0418 0 0x48>;
+   reg-names = "qdsp6", "rmb";
+
+   interrupts-extended =
+   < GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack",
+ "shutdown-ack";
+
+   clocks = < GCC_MSS_CFG_AHB_CLK>,
+< GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+< GCC_BOOT_ROM_AHB_CLK>,
+< GCC_MSS_GPLL0_DIV_CLK_SRC>,
+< GCC_MSS_SNOC_AXI_CLK>,
+< GCC_MSS_MFAB_AXIS_CLK>,
+< GCC_PRNG_AHB_CLK>,
+< RPMH_CXO_CLK>;
+   clock-names = "iface", "bus", "mem", "gpll0_mss",
+ "snoc_axi", "mnoc_axi", "prng", "xo";
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   resets = <_reset AOSS_CC_MSS_RESTART>,
+<_reset PDC_MODEM_SYNC_RESET>;
+   reset-names = "mss_restart", "pdc_reset";
+
+   qcom,halt-regs = <_mutex_regs 0x23000 0x25000 
0x24000>;
+
+   power-domains = <_qmp AOSS_QMP_LS_MODEM>,
+   < SDM845_CX>,
+   < SDM845_MX>,
+   < SDM845_MSS>;
+   power-domain-names = "load_state", "cx", "mx", "mss";
+
+   mba {
+   memory-region = <_region>;
+   };
+
+   mpss {
+   memory-region = <_region>;
+   };
+
+   glink-edge {
+   interrupts = ;
+   label = "modem";
+   qcom,remote-pid = <1>;
+   mboxes = <_shared 12>;
+   };
+   };
+
sdhc_2: sdhci@8804000 {
compatible = "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5";
reg = <0 0x08804000 0 0x1000>;
-- 
2.18.0

[PATCH v3 05/10] soc: qcom: Add AOSS QMP communication driver

[Bjorn Andersson]

The AOSS QMP driver is used to communicate with the AOSS for certain
side-channel requests, that are not enabled through the RPMh interface.

The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.

Reviewed-by: Arun Kumar Neelakantam 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Free mbox channel on failure and remove

 drivers/soc/qcom/Kconfig  |   9 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/aoss-qmp.c   | 317 ++
 include/linux/soc/qcom/aoss-qmp.h |  14 ++
 4 files changed, 341 insertions(+)
 create mode 100644 drivers/soc/qcom/aoss-qmp.c
 create mode 100644 include/linux/soc/qcom/aoss-qmp.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 6241d3e3b115..e2c859121b88 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,15 @@
 #
 menu "Qualcomm SoC drivers"
 
+config QCOM_AOSS_QMP
+   tristate "Qualcomm AOSS Messaging Driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on MAILBOX
+   help
+ This driver provides the means for communicating with the
+ micro-controller in the AOSS, using QMP, to control certain resource
+ that are not exposed through RPMh.
+
 config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..2c04d27fbf9e 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += aoss-qmp.o
 obj-$(CONFIG_QCOM_GENI_SE) +=  qcom-geni-se.o
 obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/aoss-qmp.c b/drivers/soc/qcom/aoss-qmp.c
new file mode 100644
index ..86ee622cdadf
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION   0x4
+#define QMP_DESC_FEATURES  0x8
+
+#define QMP_DESC_UCORE_LINK_STATE  0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK  0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE   0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+#define QMP_DESC_MCORE_LINK_STATE  0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK  0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE   0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP   0x
+#define QMP_STATE_DOWN 0x
+
+#define QMP_MAGIC  0x4d41494c
+#define QMP_VERSION1
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
+ * @pd_pdev: platform device for the power-domain child device
+ */
+struct qmp {
+   void __iomem *msgram;
+   struct device *dev;
+
+   struct mbox_client mbox_client;
+   struct mbox_chan *mbox_chan;
+
+   size_t offset;
+   size_t size;
+
+   wait_queue_head_t event;
+
+   struct mutex tx_lock;
+
+   struct platform_device *pd_pdev;
+};
+
+static void qmp_kick(struct qmp *qmp)
+{
+   mbox_send_message(qmp->mbox_chan, NULL);
+   mbox_client_txdone(qmp->mbox_chan, 0);
+}
+
+static bool qmp_magic_valid(struct qmp *qmp)
+{
+   return readl(qmp->msgram + QMP_DESC_MAGIC) == QMP_MAGIC;
+}
+
+static bool qmp_link_acked(struct qmp *qmp)
+{
+   return readl(qmp->msgram + QMP_DESC_MCORE_LINK_STATE_ACK) == 
QMP_STATE_UP;
+}
+
+static bool qmp_mcore_channel_acked(struct qmp *qmp)
+{
+   return readl(qmp->msgram + QMP_DESC_MCORE_CH_STATE_ACK) == QMP_STATE_UP;
+}
+
+static bool qmp_ucore_channel_up(struct qmp *qmp)
+{
+   return readl(qmp->msgram + QMP_DESC_UCORE_CH_STATE) == QMP_STATE_UP;
+}
+
+static int qmp_open(struct qmp *qmp)
+{
+   int ret;
+   u32 val;
+
+   ret = wait_event_timeout(qmp->event, qmp_magic_valid(qmp), HZ);
+   if (!ret) {
+   dev_err(qmp->dev, "QMP magic doesn't 

[PATCH v3 09/10] arm64: dts: qcom: Add AOSS QMP node

[Bjorn Andersson]

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New patch

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 1033b77856e6..5cc2615461da 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2070,6 +2071,15 @@
#reset-cells = <1>;
};
 
+   aoss_qmp: qmp@c30 {
+   compatible = "qcom,sdm845-aoss-qmp";
+   reg = <0 0x0c30 0 0x10>;
+   interrupts = ;
+   mboxes = <_shared 0>;
+
+   #power-domain-cells = <1>;
+   };
+
spmi_bus: spmi@c44 {
compatible = "qcom,spmi-pmic-arb";
reg = <0 0x0c44 0 0x1100>,
-- 
2.18.0

Re: [PATCH 2/2] iommu/arm-smmu: Add support for non-coherent page table mappings

[Will Deacon]

On Mon, Jan 21, 2019 at 11:35:30AM +0530, Vivek Gautam wrote:
> On Sun, Jan 20, 2019 at 5:31 AM Will Deacon  wrote:
> > On Thu, Jan 17, 2019 at 02:57:18PM +0530, Vivek Gautam wrote:
> > > Adding a device tree option for arm smmu to enable non-cacheable
> > > memory for page tables.
> > > We already enable a smmu feature for coherent walk based on
> > > whether the smmu device is dma-coherent or not. Have an option
> > > to enable non-cacheable page table memory to force set it for
> > > particular smmu devices.
> >
> > Hmm, I must be missing something here. What is the difference between this
> > new property, and simply omitting dma-coherent on the SMMU?
> 
> So, this is what I understood from the email thread for Last level
> cache support -
> Robin pointed to the fact that we may need to add support for setting
> non-cacheable
> mappings in the TCR.
> Currently, we don't do that for SMMUs that omit dma-coherent.
> We rely on the interconnect to handle the configuration set in TCR,
> and let interconnect
> ignore the cacheability if it can't support.

I think that's a bug. With that fixed, can you get what you want by omitting
"dma-coherent"?

Will

Re: [PATCH 1/5] locking/qspinlock: Safely handle > 4 nesting levels

[Will Deacon]

On Mon, Jan 21, 2019 at 10:12:34AM +0100, Peter Zijlstra wrote:
> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> index 8a8c3c208c5e..983b49a75826 100644
> --- a/kernel/locking/qspinlock.c
> +++ b/kernel/locking/qspinlock.c
> @@ -412,6 +412,12 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, 
> u32 val)
>   idx = node->count++;
>   tail = encode_tail(smp_processor_id(), idx);
>  
> + if (idx >= MAX_NODES) {
> + while (!queued_spin_trylock(lock))
> + cpu_relax();
> + goto release;
> + }
> +
>   node = grab_mcs_node(node, idx);

With an unlikely() and a comment, I /much/ prefer this approach!

Will

Re: [Qestion] Softlockup when send IPI to other CPUs

[Will Deacon]

Hi Catalin,

On Mon, Jan 21, 2019 at 02:21:28PM +, Catalin Marinas wrote:
> On Sat, Jan 19, 2019 at 11:58:27PM +, Will Deacon wrote:
> > On Thu, Jan 17, 2019 at 07:42:44AM +, chenwandun wrote:
> > > Recently, I do some tests on linux-4.19 and hit a softlockup issue.
> > > 
> > > I find some CPUs get the spinlock in the __split_huge_pmd function and
> > > then send IPI to other CPUs, waiting the response, while several CPUs
> > > enter the __split_huge_pmd function, want to get the spinlock, but always
> > > in queued_spin_lock_slowpath,
> > > 
> > > Because long time no response to the IPI, that results in a softlockup.
> > > 
> > > As to sending IPI, it was in the patch
> > > 3b8c9f1cdfc506e94e992ae66b68bbe416f89610.  The patch is mean to send IPI
> > > to each CPU after invalidating the I-cache for kernel mappings.  In this
> > > case, after modify pmd, it sends IPI to other CPUS to sync memory
> > > mappings.
> > > 
> > > No stable test case to repeat the result, it is hard to repeat the test 
> > > procedure.
> > > 
> > > The environment is arm64, 64 CPUs. Except for idle CPU, there are 6 kind
> > > of callstacks in total.
> > 
> > This looks like another lockup that would be solved if we deferred our
> > I-cache invalidation when mapping user-executable pages, and instead
> > performed the invalidation off the back of a UXN permission fault, where we
> > could avoid holding any locks.
> 
> Looking back at commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after
> invalidating the I-cache for kernel mappings"), the text implies that it
> should only do this for kernel mappings. I don't think we need this for
> user mappings. We have a few scenarios where we invoke set_pte_at() with
> exec permission:

Yes, I think you're right. I got confused because in this case we are
invalidating lines written by the kernel, but actually it's not about who
writes the data, but about whether or not the page table is being changed.

> 1. Page faulted in - the pte was not previously accessible and the CPU
>should not have stale decoded instructions (my interpretation of the
>ARM ARM).
> 
> 2. huge pmd splitting - there is no change to the underlying data. I
>have a suspicion here that we shouldn't even call
>sync_icache_aliases() but probably the PG_arch_1 isn't carried over
>from the head compound page to the small pages (needs checking).
> 
> 3. page migration - there is no change to the underlying data and
>instructions, so I don't think we need the all CPUs sync.
> 
> 4. mprotect() setting exec permission - that's normally the
>responsibility of the user to ensure cache maintenance
> 
> (I can add more text to the patch below but need to get to the bottom of
> this first)
> 
> -8<-
> arm64: Do not issue IPIs for user executable ptes
> 
> From: Catalin Marinas 
> 
> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> for kernel mappings") was aimed at fixing the I-cache invalidation for
> kernel mappings. However, it inadvertently caused all cache maintenance
> for user mappings via set_pte_at() -> __sync_icache_dcache() to call
> kick_all_cpus_sync().
> 
> Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for 
> kernel mappings")
> Cc:  # 4.19.x-
> Signed-off-by: Catalin Marinas 
> ---
>  arch/arm64/include/asm/cacheflush.h |2 +-
>  arch/arm64/kernel/probes/uprobes.c  |2 +-
>  arch/arm64/mm/flush.c   |   14 ++
>  3 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cacheflush.h 
> b/arch/arm64/include/asm/cacheflush.h
> index 19844211a4e6..18e92d9dacd4 100644
> --- a/arch/arm64/include/asm/cacheflush.h
> +++ b/arch/arm64/include/asm/cacheflush.h
> @@ -80,7 +80,7 @@ extern void __clean_dcache_area_poc(void *addr, size_t len);
>  extern void __clean_dcache_area_pop(void *addr, size_t len);
>  extern void __clean_dcache_area_pou(void *addr, size_t len);
>  extern long __flush_cache_user_range(unsigned long start, unsigned long end);
> -extern void sync_icache_aliases(void *kaddr, unsigned long len);
> +extern void sync_icache_aliases(void *kaddr, unsigned long len, bool sync);

I'd much prefer just adding something like sync_user_icache_aliases(), which
would avoid the IPI, since bool arguments tend to make the callsites
unreadable imo.

With that:

Acked-by: Will Deacon 

Will

Re: [RFC PATCH 3/5] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

Hi Heikki,
Heikki Krogerus  于2018年10月24日周三 下午11:06写道：
>
> When the connections are defined in firmware, struct
> device_connection will have the fwnode member pointing to
> the device node (struct fwnode_handle) of the requested
> device, and the endpoint will not be used at all in that
> case.
>
> Signed-off-by: Heikki Krogerus 
> ---
>  drivers/usb/common/roles.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
> index 99116af07f1d..bb52e006d203 100644
> --- a/drivers/usb/common/roles.c
> +++ b/drivers/usb/common/roles.c
> @@ -8,6 +8,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct 
> usb_role_switch *sw)
>  }
>  EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
>
> -static int __switch_match(struct device *dev, const void *name)
> +static int switch_fwnode_match(struct device *dev, const void *fwnode)
> +{
> +   return dev_fwnode(dev) == fwnode;

Seems this should be dev_fwnode(dev->parent) == fwnode;
The role switch is the child dev of the caller of usb_role_switch_register().

Li Jun

> +}
> +
> +static int switch_name_match(struct device *dev, const void *name)
>  {
> return !strcmp((const char *)name, dev_name(dev));
>  }
> @@ -94,8 +100,12 @@ static void *usb_role_switch_match(struct 
> device_connection *con, int ep,
>  {
> struct device *dev;
>
> -   dev = class_find_device(role_class, NULL, con->endpoint[ep],
> -   __switch_match);
> +   if (con->fwnode)
> +   dev = class_find_device(role_class, NULL, con->fwnode,
> +   switch_fwnode_match);
> +   else
> +   dev = class_find_device(role_class, NULL, con->endpoint[ep],
> +   switch_name_match);
>
> return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
>  }
> --
> 2.19.1
>

Re: [v3] arm64: dts: lx2160a: add sata node support

[Shawn Guo]

On Thu, Jan 17, 2019 at 02:12:24AM +, Peng Ma wrote:
> Add SATA device nodes for fsl-lx2160a and enable support
> for QDS and RDB boards.
> 
> Signed-off-by: Peng Ma 
> ---
> changed for V3:
>   - updated the commit log 
> 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |   16 +++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   16 +++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   44 
> +
>  3 files changed, 76 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index 99a22ab..1a5acf6 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -95,6 +95,22 @@
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 6481e5f..5b6799e 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -102,6 +102,22 @@
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index a79f5c1..592034b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -671,6 +671,50 @@
>   status = "disabled";
>   };
>  
> + sata0: sata@320 {
> + compatible = "fsl,lx2160a-ahci";

I can not find this compatible in any bindings doc.

Shawn

> + reg = <0x0 0x320 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata1: sata@321 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x321 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata2: sata@322 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x322 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata3: sata@323 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x323 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
>   smmu: iommu@500 {
>   compatible = "arm,mmu-500";
>   reg = <0 0x500 0 0x80>;
> -- 
> 1.7.1
> 

Re: [PATCH] ARM: dts: imx6*-apalis/-colibri: mark I2C recovery GPIOs as open drain

[Shawn Guo]

On Fri, Jan 18, 2019 at 02:31:13PM +0100, Stefan Agner wrote:
> Since commit d2d0ad2aec4a ("i2c: imx: use open drain for recovery
> GPIO") GPIO lib expects this GPIO to be configured as open drain.
> Make sure we define this GPIO as open drain in the device tree.
> This gets rid of the following warning:
>   gpio-81 (scl): enforced open drain please flag it properly in DT/ACPI 
> DSDT/board file
> 
> Note that currently the i.MX pinctrl driver does not support
> enabling open drain directly, so this patch has no effect in
> practice. Open drain is enabled by the fixed pinmux entry.
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

RE: [PATCH v3] PCI: avoid bridge feature re-probing on hotplug

[xuyandong]

Hi Bjorn and Michael

After trying to reproduce the problem for a whole day, the bug did not show up
any more. So I think the new patch does solve this problem.

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Sunday, January 20, 2019 4:13 AM
> To: Michael S. Tsirkin 
> Cc: linux-kernel@vger.kernel.org; xuyandong ;
> Yinghai Lu ; Jesse Barnes ;
> linux-...@vger.kernel.org; Sagi Grimberg ; Ofer Hayut
> ; Roy Shterman ; Keith
> Busch ; Wangzhou (B) 
> Subject: [PATCH v3] PCI: avoid bridge feature re-probing on hotplug
> 
> I gave up trying to reproduce the problem and test this patch with qemu; can
> you guys (Michael and Xu (sorry if I mangled your name)) give this a try?
> 
> I cc'd a few other people who have noticed this issue in the past, so just 
> FYI for
> them.
> 
> Bjorn
> 
> 
> commit dd21b922db366ba069291b6fef2a8ce6768756a2
> Author: Bjorn Helgaas 
> Date:   Sat Jan 19 11:35:04 2019 -0600
> 
> PCI: Probe bridge window attributes once at enumeration-time
> 
> pci_bridge_check_ranges() determines whether a bridge supports the
> optional
> I/O and prefetchable memory windows and sets the flag bits in the bridge
> resources.  This could be done once during enumeration except that the
> resource allocation code completely clears the flag bits, e.g., in the
> pci_assign_unassigned_bridge_resources() path.
> 
> The problem was that in some cases pci_bridge_check_ranges() *changes*
> the
> window registers to determine whether they're writable, and this may break
> concurrent accesses to devices behind the bridge.
> 
> Add a new pci_read_bridge_windows() to determine whether a bridge
> supports
> the optional windows, call it once during enumeration, remember the
> results, and change pci_bridge_check_ranges() to set the flag bits based 
> on
> those remembered results.
> 
> Link: 
> https://lore.kernel.org/linux-pci/1506151482-113560-1-git-send-email-
> wangzh...@hisilicon.com
> Link: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02082.html
> Reported-by: xuyandong 
> Cc: Sagi Grimberg 
> Cc: Ofer Hayut 
> Cc: Roy Shterman 
> Cc: Keith Busch 
> Cc: Zhou Wang 
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> 257b9f6f2ebb..2ef8b954c65a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -348,6 +348,57 @@ static void pci_read_bases(struct pci_dev *dev,
> unsigned int howmany, int rom)
>   }
>  }
> 
> +static void pci_read_bridge_windows(struct pci_dev *bridge) {
> + u16 io;
> + u32 pmem, tmp;
> +
> + pci_read_config_word(bridge, PCI_IO_BASE, );
> + if (!io) {
> + pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
> + pci_read_config_word(bridge, PCI_IO_BASE, );
> + pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
> + }
> + if (io)
> + bridge->io_window = 1;
> +
> + /*
> +  * DECchip 21050 pass 2 errata: the bridge may miss an address
> +  * disconnect boundary by one PCI data phase.  Workaround: do not
> +  * use prefetching on this device.
> +  */
> + if (bridge->vendor == PCI_VENDOR_ID_DEC && bridge->device ==
> 0x0001)
> + return;
> +
> + pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE, );
> + if (!pmem) {
> + pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> +0xffe0fff0);
> + pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> );
> + pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> 0x0);
> + }
> + if (!pmem)
> + return;
> +
> + bridge->pref_window = 1;
> +
> + if ((pmem & PCI_PREF_RANGE_TYPE_MASK) ==
> PCI_PREF_RANGE_TYPE_64) {
> +
> + /*
> +  * Bridge claims to have a 64-bit prefetchable memory
> +  * window; verify that the upper bits are actually
> +  * writable.
> +  */
> + pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> );
> + pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> +0x);
> + pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> );
> + pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> pmem);
> + if (tmp)
> + bridge->pref_64_window = 1;
> + }
> +}
> +
>  static void pci_read_bridge_io(struct pci_bus *child)  {
>   struct pci_dev *dev = child->self;
> @@ -1739,6 +1790,7 @@ int pci_setup_device(struct pci_dev *dev)
>   pci_read_irq(dev);
>   dev->transparent = ((dev->class & 0xff) == 1);
>   pci_read_bases(dev, 2, PCI_ROM_ADDRESS1);
> + pci_read_bridge_windows(dev);
>   set_pcie_hotplug_bridge(dev);
>   pos = pci_find_capability(dev, PCI_CAP_ID_SSVID);
>   if (pos) {
> diff --git 

Re: linux-next: manual merge of the akpm tree with the kbuild tree

[Masahiro Yamada]

On Tue, Jan 22, 2019 at 1:06 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
>   Makefile
>
> between commit:
>
>   b57304bb03de ("kbuild: remove meaningless prepare2 target")
>
> from the kbuild tree and patch:
>
>   "locking/atomics: build atomic headers as required"


This has been sitting around since the previous development cycle.
The relevant patches were not sent to Linus in the previous MW.

I believe those should be dropped entirely,
and re-implemented cleanly/correctly if Mark Rutland wants this change.

People already pointed out the scripts are so slow,
but that is not the only problem.

[1] I see annoying log message
"Nothing to be done for 'all'"
for every incremental build

[2] Dependencies might not be sufficient.
For example, nothing is rebuilt when scripts/atomic/fallbacks/* is touched.

[3] I do not understand why scripts/Makefile.genheader must be added.






> from the akpm tree.
>
> I fixed it up (I hope - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc Makefile
> index 004a190e3ece,bd0f79d8295e..
> --- a/Makefile
> +++ b/Makefile
> @@@ -1077,8 -1077,12 +1077,8 @@@ ifneq ($(KBUILD_SRC),
> fi;
>   endif
>
> - prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
> -   include/generated/utsrelease.h
>  -# prepare2 creates a makefile if using a separate output directory.
>  -# From this point forward, .config has been reprocessed, so any rules
>  -# that need to depend on updated CONFIG_* values can be checked here.
>  -prepare2: prepare3 outputmakefile asm-generic genheader
>  -
>  -prepare1: prepare2 $(version_h) $(autoksyms_h) 
> include/generated/utsrelease.h
> ++prepare1: prepare3 outputmakefile asm-generic genheader $(version_h) \
> ++  $(autoksyms_h) include/generated/utsrelease.h
> $(cmd_crmodverdir)
>
>   archprepare: archheaders archscripts prepare1 scripts



-- 
Best Regards
Masahiro Yamada

Re: /proc//status: incorrect format breaks userland tool

[Konrad Rzeszutek Wilk]

On Tue, Jan 22, 2019 at 11:29:16AM +0800, Lei Chen wrote:
> Hi Konrad,

Hi,

CC-ing stable,Greg,and LKML. Pls see attached and inline patch and explanation
at bottom.

> I'm running kernel 4.4.153. When running iotop, I got such failure:
>  # iotop -P
> Traceback (most recent call last):
>   File "/sbin/iotop", line 17, in 
> main()
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 620, in main
> main_loop()
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 610, in 
> main_loop = lambda: run_iotop(options)
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 508, in
> run_iotop
> return curses.wrapper(run_iotop_window, options)
>   File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 501, in
> run_iotop_window
> ui.run()
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 155, in run
> self.process_list.duration)
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 434, in
> refresh_display
> lines = self.get_data()
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 415, in get_data
> return list(map(format, processes))
>   File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 388, in format
> cmdline = p.get_cmdline()
>   File "/usr/lib/python2.7/site-packages/iotop/data.py", line 292, in
> get_cmdline
> proc_status = parse_proc_pid_status(self.pid)
>   File "/usr/lib/python2.7/site-packages/iotop/data.py", line 196, in
> parse_proc_pid_status
> key, value = line.split(':\t', 1)
> ValueError: need more than 1 value to unpack
> 
> Having a little further debug, I found this error is caused by the
> unexpected blank line in /proc//status file, like below:
> 
> CapBnd: 003f
> CapAmb: 
> 
> Speculation_Store_Bypass:   vulnerable
> Cpus_allowed:   ff
> 
> Checking the git history, I see you touched the line "seq_printf(m,
> "\nSpeculation_Store_Bypass:\t");". Do you think this additional blank line
> is caused by the leading "\n" of "Speculation_Store_Bypass"?

That is correct.
It looks that the backport missed the change. The v4.4 has:

static inline void task_seccomp(struct seq_file *m, struct task_struct *p)  
   
{   
   
#ifdef CONFIG_SECCOMP   
   
seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);   
   
#endif  
   
seq_printf(m, "\nSpeculation_Store_Bypass:\t");  

Upstream has:

tatic inline void task_seccomp(struct seq_file *m, struct task_struct *p)   
  
{   
   
seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));  
   
#ifdef CONFIG_SECCOMP   
   
seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);
   
#endif  
   
seq_printf(m, "\nSpeculation_Store_Bypass:\t"); 

The af884cd4a5ae6 is the one that removed the '\n' from the end and put it in 
the
front of 'Seccomp '.

Greg, I am not sure how one would fix this in a stable tree. But the fix is 
simple
(hadn't tested it..)

>From 9e1909f29e1162f2fba190dbab88d1bbcaf0365d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 22 Jan 2019 00:27:55 -0500
Subject: [PATCH] Fix: proc: Use underscores for SSBD in 'status'

Upstream af884cd4a5ae6 (not backported) added a '\n' in front
of 'Seccomp' but we have the old format with '\n' at the end.
This causes mayhem with 'Speculation_Store_Bypass' adding an extra
newline breaking tools.

Reported-by:Lei Chen 
CC: sta...@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk 
---
 fs/proc/array.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index cb71cbae606d..60cbaa821164 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -333,7 +333,7 @@ static inline void task_seccomp(struct seq_file *m, struct 
task_struct *p)
 #ifdef CONFIG_SECCOMP
seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
 #endif
-   seq_printf(m, "\nSpeculation_Store_Bypass:\t");
+   seq_printf(m, "Speculation_Store_Bypass:\t");
switch (arch_prctl_spec_ctrl_get(p, PR_SPEC_STORE_BYPASS)) {
case -EINVAL:
seq_printf(m, "unknown");
-- 
2.13.4


> 
> Thanks,
> Lei Chen
>From 9e1909f29e1162f2fba190dbab88d1bbcaf0365d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 22 Jan 2019 00:27:55 -0500
Subject: [PATCH] Fix: proc: Use underscores for SSBD in 'status'

Upstream af884cd4a5ae6 (not backported) added a '\n' in front
of 'Seccomp' but we 

Re: [PATCH] drivers: extcon: Add support for ptn5150

[Chanwoo Choi]

Hi Vijai,

On 19. 1. 22. 오후 1:42, Vijai Kumar K wrote:
> Hi Chanwoo Choi,
> 
> This is the first time I am sending a driver to LKML. I have a few doubts. Can
> you please clarify them when you are free?
> 
> 1. I have developed and tested this patch on 4.14.89 kernel. When trying to 
> mainline the driver should I rebase and send the patch on top of current 
> tree(v5.0-rc2)?

You better to rebase your patch on extcon-next branch (v5.0-rc1).
because the extcon.git[1] keep the v5.0-rc1 version. But, if you use over 
v5.0-rc1 version,
it doesn't matter. Maybe, this patch doesn't get the any impact from the 
modification
of v5.0-rcX.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git

> 
> 2. Is there any specific git on which I should test this driver on? Like 
> below?
> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git

Yes.

> 
> Thanks,
> Vijai Kumar K
> 
> On Tue, Jan 22, 2019 at 08:05:33AM +0800, kbuild test robot wrote:
>> Hi Vijai,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on chanwoo-extcon/extcon-next]
>> [also build test ERROR on v5.0-rc2]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Vijai-Kumar-K/drivers-extcon-Add-support-for-ptn5150/20190122-041153
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
>> extcon-next
>> config: sh-allyesconfig (attached as .config)
>> compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
>> reproduce:
>> wget 
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
>> ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> GCC_VERSION=8.2.0 make.cross ARCH=sh 
>>
>> All error/warnings (new ones prefixed by >>):
>>
>>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_irq_work':
 drivers//extcon/extcon-ptn5150.c:93:5: error: implicit declaration of 
 function 'extcon_set_state_sync'; did you mean 'extcon_get_state'? 
 [-Werror=implicit-function-declaration]
>> extcon_set_state_sync(info->edev,
>> ^
>> extcon_get_state
>>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_i2c_probe':
 drivers//extcon/extcon-ptn5150.c:255:15: error: implicit declaration of 
 function 'devm_extcon_dev_allocate'; did you mean 'extcon_get_state'? 
 [-Werror=implicit-function-declaration]
>>  info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
>>   ^~~~
>>   extcon_get_state
 drivers//extcon/extcon-ptn5150.c:255:13: warning: assignment to 'struct 
 extcon_dev *' from 'int' makes pointer from integer without a cast 
 [-Wint-conversion]
>>  info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
>> ^
 drivers//extcon/extcon-ptn5150.c:262:8: error: implicit declaration of 
 function 'devm_extcon_dev_register'; did you mean 'devm_pinctrl_register'? 
 [-Werror=implicit-function-declaration]
>>  ret = devm_extcon_dev_register(info->dev, info->edev);
>>^~~~
>>devm_pinctrl_register
>>cc1: some warnings being treated as errors
>>
>> vim +93 drivers//extcon/extcon-ptn5150.c
>>
>> 51   
>> 52   static void ptn5150_irq_work(struct work_struct *work)
>> 53   {
>> 54   struct ptn5150_info *info = container_of(work,
>> 55   struct ptn5150_info, irq_work);
>> 56   int ret = 0;
>> 57   unsigned int reg_data;
>> 58   unsigned int port_status;
>> 59   unsigned int vbus;
>> 60   unsigned int cable_attach;
>> 61   unsigned int int_status;
>> 62   
>> 63   if (!info->edev)
>> 64   return;
>> 65   
>> 66   mutex_lock(>mutex);
>> 67   
>> 68   ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS, 
>> _data);
>> 69   if (ret) {
>> 70   dev_err(info->dev,
>> 71   "failed to read CC STATUS %d\n", ret);
>> 72   mutex_unlock(>mutex);
>> 73   return;
>> 74   }
>> 75   /* Clear interrupt. Read would clear the register */
>> 76   ret = regmap_read(info->regmap, PTN5150_REG_INT_STATUS, 
>> _status);
>> 77   if (ret) {
>> 78   dev_err(info->dev,
>> 79   "failed to read INT STATUS %d\n", ret);
>> 80   mutex_unlock(>mutex);
>> 81   return;
>> 82   }
>> 83   
>> 84 

[PATCH v1 0/2] ARM: dts: am335x-shc.dts: small updates for shc board

[Heiko Schocher]

small updates for am335x based shc board:
- switch DTS to SPDX identifier
- fix wrong gpio level for mmc1 cd pin


Heiko Schocher (2):
  ARM: dts: am335x-shc.dts: Switch to SPDX identifier
  ARM: dts: am335x-shc.dts: fix wrong cd pin level

 arch/arm/boot/dts/am335x-shc.dts | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.17.2

[PATCH v1 1/2] ARM: dts: am335x-shc.dts: Switch to SPDX identifier

[Heiko Schocher]

Adopt the SPDX license identifier headers to ease license
compliance management.

Signed-off-by: Heiko Schocher 
---

 arch/arm/boot/dts/am335x-shc.dts | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index d0fd68873689..5cdaf0cd9401 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -1,11 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * support for the bosch am335x based shc c3 board
  *
  * Copyright, C) 2015 Heiko Schocher 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 /dts-v1/;
 
-- 
2.17.2

[PATCH v1 2/2] ARM: dts: am335x-shc.dts: fix wrong cd pin level

[Heiko Schocher]

cd pin on mmc1 is GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH

Signed-off-by: Heiko Schocher 
---

 arch/arm/boot/dts/am335x-shc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index 5cdaf0cd9401..bfbe27a80006 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -213,7 +213,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
bus-width = <0x4>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
cd-inverted;
max-frequency = <2600>;
vmmc-supply = <_fixed>;
-- 
2.17.2

Re: kernel BUG at kernel/cred.c:825!

[Santosh Kumar Pradhan]

Hi Laura,

On 17/01/19, 12:39 AM, "linux-nfs-ow...@vger.kernel.org on behalf of Laura 
Abbott"  wrote:

On 1/7/19 11:18 AM, Dave Jones wrote:
> [   53.980701] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state 
recovery directory
> [   53.981216] NFSD: starting 45-second grace period (net f098)
> [   54.006802] CRED: Invalid credentials
> [   54.006880] CRED: At ./include/linux/cred.h:253
> [   54.006899] CRED: Specified credentials: 5daa4529
> [   54.006916] CRED: ->magic=0, put_addr=  (null)
> [   54.006927] CRED: ->usage=1, subscr=0
> [   54.006935] CRED: ->*uid = { 0,0,0,0 }
> [   54.006944] CRED: ->*gid = { 0,0,0,0 }
> [   54.006954] [ cut here ]
> [   54.006964] kernel BUG at kernel/cred.c:825!

 > 

Fedora still seems to be hitting this as of -rc2

The FIX is made into –rc3.

Best R,
Santosh

Re: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD

[Guenter Roeck]

On 1/21/19 6:30 PM, Rajendra Nayak wrote:



On 1/18/2019 11:09 PM, Stephen Boyd wrote:

Quoting Rajendra Nayak (2019-01-17 20:48:01)

  drivers/soc/qcom/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a5d5167c3f16..1ee298f6bf17 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -109,7 +109,7 @@ config QCOM_RPMHPD
  config QCOM_RPMPD
 bool "Qualcomm RPM Power domain driver"


Just curious, does it need to be bool for some reason?


Here's the link to the discussion around it on the v3 patchset of this series
https://lkml.org/lkml/2018/6/12/111



I think you were missing the implication of "if possible", the implication
being that the driver can now not be used in a multi-platform image, and that
having a bool driver depend on tristate drivers doesn't make much if any sense.

The argument in the exchange is odd - one can not remove any driver as long
there are client drivers / devices attached to it. This is true for all
drivers, not just for this one, and handled quite nicely by the driver core.
Just run "lsmod" and try to remove a driver with any attached users.

Guenter

Re: [PATCH] ARM: dts: n900: fix mmc1 card detect gpio polarity

[Arthur D.]

Signed-off-by: Arthur Demchenkov 

RE: Re: [PATCH] drivers: extcon: Add support for ptn5150

[MyungJoo Ham]

>Hi Chanwoo Choi,
>
>This is the first time I am sending a driver to LKML. I have a few doubts. Can
>you please clarify them when you are free?

Although I'm not Chanwoo, but a guy who's about 50ft away from his cubicle,
as he appears to be busy today... :)

>
>1. I have developed and tested this patch on 4.14.89 kernel. When trying to 
>mainline the driver should I rebase and send the patch on top of current 
>tree(v5.0-rc2)?

Yes, you are supposed to be based on the most recent RC.

>
>2. Is there any specific git on which I should test this driver on? Like below?
>https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git

I'd recommend to pull torvald's master with RC tag.


Cheers,
MyungJoo

>
>Thanks,
>Vijai Kumar K

Re: linux-next: Fixes tag needs some work in the pinctrl tree

[Stephen Rothwell]

Hi Chen-Yu,

On Tue, 22 Jan 2019 10:20:28 +0800 Chen-Yu Tsai  wrote:
>
> Sorry about that. I've been doing for some time now.
> Should none of the tags be wrapped?

Generally they should be single lines (in my opinion) ... it makes
grepping for things a lot harder if they are split.

-- 
Cheers,
Stephen Rothwell


pgpaq5gJGpKQT.pgp
Description: OpenPGP digital signature

Re: [PATCH] drivers: extcon: Add support for ptn5150

[Vijai Kumar K]

Hi Chanwoo Choi,

This is the first time I am sending a driver to LKML. I have a few doubts. Can
you please clarify them when you are free?

1. I have developed and tested this patch on 4.14.89 kernel. When trying to 
mainline the driver should I rebase and send the patch on top of current 
tree(v5.0-rc2)?

2. Is there any specific git on which I should test this driver on? Like below?
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git

Thanks,
Vijai Kumar K

On Tue, Jan 22, 2019 at 08:05:33AM +0800, kbuild test robot wrote:
> Hi Vijai,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on chanwoo-extcon/extcon-next]
> [also build test ERROR on v5.0-rc2]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Vijai-Kumar-K/drivers-extcon-Add-support-for-ptn5150/20190122-041153
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> extcon-next
> config: sh-allyesconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=sh 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_irq_work':
> >> drivers//extcon/extcon-ptn5150.c:93:5: error: implicit declaration of 
> >> function 'extcon_set_state_sync'; did you mean 'extcon_get_state'? 
> >> [-Werror=implicit-function-declaration]
> extcon_set_state_sync(info->edev,
> ^
> extcon_get_state
>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_i2c_probe':
> >> drivers//extcon/extcon-ptn5150.c:255:15: error: implicit declaration of 
> >> function 'devm_extcon_dev_allocate'; did you mean 'extcon_get_state'? 
> >> [-Werror=implicit-function-declaration]
>  info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
>   ^~~~
>   extcon_get_state
> >> drivers//extcon/extcon-ptn5150.c:255:13: warning: assignment to 'struct 
> >> extcon_dev *' from 'int' makes pointer from integer without a cast 
> >> [-Wint-conversion]
>  info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
> ^
> >> drivers//extcon/extcon-ptn5150.c:262:8: error: implicit declaration of 
> >> function 'devm_extcon_dev_register'; did you mean 'devm_pinctrl_register'? 
> >> [-Werror=implicit-function-declaration]
>  ret = devm_extcon_dev_register(info->dev, info->edev);
>^~~~
>devm_pinctrl_register
>cc1: some warnings being treated as errors
> 
> vim +93 drivers//extcon/extcon-ptn5150.c
> 
> 51
> 52static void ptn5150_irq_work(struct work_struct *work)
> 53{
> 54struct ptn5150_info *info = container_of(work,
> 55struct ptn5150_info, irq_work);
> 56int ret = 0;
> 57unsigned int reg_data;
> 58unsigned int port_status;
> 59unsigned int vbus;
> 60unsigned int cable_attach;
> 61unsigned int int_status;
> 62
> 63if (!info->edev)
> 64return;
> 65
> 66mutex_lock(>mutex);
> 67
> 68ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS, 
> _data);
> 69if (ret) {
> 70dev_err(info->dev,
> 71"failed to read CC STATUS %d\n", ret);
> 72mutex_unlock(>mutex);
> 73return;
> 74}
> 75/* Clear interrupt. Read would clear the register */
> 76ret = regmap_read(info->regmap, PTN5150_REG_INT_STATUS, 
> _status);
> 77if (ret) {
> 78dev_err(info->dev,
> 79"failed to read INT STATUS %d\n", ret);
> 80mutex_unlock(>mutex);
> 81return;
> 82}
> 83
> 84if (int_status) {
> 85cable_attach = int_status & 
> PTN5150_REG_INT_CABLE_ATTACH_MASK;
> 86if (cable_attach) {
> 87port_status = ((reg_data &
> 88
> PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
> 89
> PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
> 90
> 

Re: [GIT PULL] XArray for 5.0-rc3

[pr-tracker-bot]

The pull request you sent on Mon, 21 Jan 2019 19:31:35 -0800:

> git://git.infradead.org/users/willy/linux-dax.git tags/xarray-5.0-rc3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/48b161983ae5266ffa42f0ccaf7224eaeda38e59

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

linux-next: Tree for Jan 22

[Stephen Rothwell]

Hi all,

Changes since 20190121:

The vfs tree still had its build failure for which I applied a patch.

The netfilter-next tree still had its build failures but I applied some
supplied patches.

The mali-dp tree still had its failure for which I applied a merge
fix patch.

The pidfd tree changed its conflict against the y2038 tree.

The akpm tree gained a conflict against the kbuild tree.

Non-merge commits (relative to Linus' tree): 2882
 3171 files changed, 98258 insertions(+), 63840 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 295 trees (counting Linus' and 69 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (52e60b754438 Merge tag 'iommu-fixes-v5.0-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch 
fall-throughs)
Merging kbuild-current/fixes (49a57857aeea Linux 5.0-rc3)
Merging arc-current/for-curr (e6a72b7daeeb ARCv2: lib: memeset: fix doing 
prefetchw outside of buffer)
Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential 
uninitialized return)
Merging arm64-fixes/for-next/fixes (7fa1e2e6afa7 kasan, arm64: remove redundant 
ARCH_SLAB_MINALIGN define)
Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes)
Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing)
Merging sparc/master (b71acb0e3721 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (49a57857aeea Linux 5.0-rc3)
Merging bpf/master (e7c87bd6cc4e bpf: in __bpf_redirect_no_mac pull mac only if 
present)
Merging ipsec/master (e2612cd496e7 xfrm: Make set-mark default behavior 
backward compatible)
Merging netfilter/master (b2e3d68d1251 netfilter: nft_compat: destroy function 
must not have side effects)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (ec5aecc0b227 iwlwifi: make IWLWIFI depend on 
CFG80211)
Merging mac80211/master (f9d672f1c2ca virt_wifi: fix error return code in 
virt_wifi_newlink())
Merging rdma-fixes/for-rc (d6f4a21f309d RDMA/uverbs: Mark ioctl responses with 
UVERBS_ATTR_F_VALID_OUTPUT)
Merging sound-current/for-linus (699390381a7b ALSA: hda - Add mute LED support 
for HP ProBook 470 G5)
Merging sound-asoc-fixes/for-linus (e19eb57017b2 Merge branch 'asoc-5.0' into 
asoc-linus)
Merging regmap-fixes/for-linus (b3ffce399349 Merge branch 'regmap-5.0' into 
regmap-linus)
Merging regulator-fixes/for-linus (1c386468e824 Merge branch 'regulator-5.0' 
into regulator-linus)
Merging spi-fixes/for-linus (e63f389c18de Merge branch 'spi-5.0' into spi-linus)
Merging pci-current/for-linus (d2fd6e81912a PCI: Fix __initdata issue with 
"pci=disable_acs_redir" parameter)
Merging driver-core.current/driver-core-linus (1c7fc5cbc339 Linux 5.0-rc2)
Merging tty.current/tty-linus (27cfb3a53be4 tty: Handle problem if line 
discipline does not have receive_buf)
Merging usb.current/usb-linus (4f9b83892781 Merge tag 'usb-serial-5.0-rc3' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (

Re: [PATCH] net: sun: cassini: Cleanup license conflict

[Yanjun Zhu]

On 2019/1/19 0:30, Shannon Nelson wrote:

On Fri, Jan 18, 2019 at 2:51 AM Thomas Gleixner  wrote:

The recent addition of SPDX license identifiers to the files in
drivers/net/ethernet/sun created a licensing conflict.

The cassini driver files contain a proper license notice:

   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License as
   * published by the Free Software Foundation; either version 2 of the
   * License, or (at your option) any later version.

but the SPDX change added:

SPDX-License-Identifier: GPL-2.0

So the file got tagged GPL v2 only while in fact it is licensed under GPL
v2 or later.

It's nice that people care about the SPDX tags, but they need to be more
careful about it. Not everything under (the) sun belongs to ...

Fix up the SPDX identifier and remove the boiler plate text as it is
redundant.

Fixes: c861ef83d771 ("sun: Add SPDX license tags to Sun network drivers")
Signed-off-by: Thomas Gleixner 
Cc: Shannon Nelson 
Cc: Zhu Yanjun 


Thanks.

Reviewed-by: Zhu Yanjun 


Cc: David S. Miller 
Cc: net...@vger.kernel.org
Cc: sta...@vger.kernel.org

Thanks, Thomas.

Acked-by: Shannon Nelson 


---
  drivers/net/ethernet/sun/cassini.c |   15 +--
  drivers/net/ethernet/sun/cassini.h |   15 +--
  2 files changed, 2 insertions(+), 28 deletions(-)

--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -1,22 +1,9 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0+
  /* cassini.c: Sun Microsystems Cassini(+) ethernet driver.
   *
   * Copyright (C) 2004 Sun Microsystems Inc.
   * Copyright (C) 2003 Adrian Sun (a...@darksunrising.com)
   *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- *
   * This driver uses the sungem driver (c) David Miller
   * (da...@redhat.com) as its basis.
   *
--- a/drivers/net/ethernet/sun/cassini.h
+++ b/drivers/net/ethernet/sun/cassini.h
@@ -1,23 +1,10 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0+ */
  /* $Id: cassini.h,v 1.16 2004/08/17 21:15:16 zaumen Exp $
   * cassini.h: Definitions for Sun Microsystems Cassini(+) ethernet driver.
   *
   * Copyright (C) 2004 Sun Microsystems Inc.
   * Copyright (c) 2003 Adrian Sun (a...@darksunrising.com)
   *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- *
   * vendor id: 0x108E (Sun Microsystems, Inc.)
   * device id: 0xabba (Cassini)
   * revision ids: 0x01 = Cassini

[PATCH v3 5/5] arm64: dts: freescale: Add devicetree for Oxalis

[Manivannan Sadhasivam]

Add devicetree support for Oxalis SoM board from EBS-SYSTART. This
board is one of the 96Boards Enterprise Edition platform. Below are some
of the key features of this board:

* SoC: NXP Layerscape LS1012A
* RAM: 1GB DDR3L
* PMU: NXP VR5100
* Storage: 64MByte SPI Flash for bootloader and RCW, MicroSD Card, SATA
* Connectivity: 2x Ethernet
* USB: 2x USB3.0

More information about this board can be found in 96Boards product
page: https://www.96boards.org/product/oxalis/

Ethernet and SPI flash are not supported yet!

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/freescale/Makefile|  1 +
 .../boot/dts/freescale/fsl-ls1012a-oxalis.dts | 96 +++
 2 files changed, 97 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f9be2426f83c..d8152cc06b3f 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frwy.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-oxalis.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
new file mode 100644
index ..7c726267ec8f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for Oxalis
+ *
+ * Copyright (c) 2019 Manivannan Sadhasivam
+ *
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1012a.dtsi"
+
+/ {
+   model = "Oxalis";
+   compatible = "ebs-systart,oxalis", "fsl,ls1012a";
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,widgets =
+   "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack",
+   "Speaker", "Speaker Ext",
+   "Line", "Line In Jack";
+   simple-audio-card,routing =
+   "MIC_IN", "Microphone Jack",
+   "Microphone Jack", "Mic Bias",
+   "LINE_IN", "Line In Jack",
+   "Headphone Jack", "HP_OUT",
+   "Speaker Ext", "LINE_OUT";
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   frame-master;
+   bitclock-master;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   frame-master;
+   bitclock-master;
+   system-clock-frequency = <2500>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   codec: audio-codec@a {
+   #sound-dai-cells = <0>;
+   compatible = "fsl,sgtl5000";
+   reg = <0xa>;
+   VDDA-supply = <_1p8v>;
+   VDDIO-supply = <_1p8v>;
+   clocks = <_mclk>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1

[PATCH] devlink: Use DIV_ROUND_UP_ULL in DEVLINK_HEALTH_SIZE_TO_BUFFERS

[Nathan Chancellor]

When building this code on a 32-bit platform such as ARM, there is a
link time error (lld error shown, happpens with ld.bfd too):

ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by devlink.c
>>>   net/core/devlink.o:(devlink_health_buffers_create) in archive 
>>> built-in.a

This happens when using a regular division symbol with a u64 dividend.
Use DIV_ROUND_UP_ULL, which wraps do_div, to avoid this situation.

Fixes: cb5ccfbe73b3 ("devlink: Add health buffer support")
Signed-off-by: Nathan Chancellor 
---
 net/core/devlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/devlink.c b/net/core/devlink.c
index 60248a53c0ad..9ee25dfbc09d 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -3599,7 +3599,7 @@ static int devlink_nl_cmd_region_read_dumpit(struct 
sk_buff *skb,
 
 #define DEVLINK_HEALTH_BUFFER_SIZE (4096 - GENL_HDRLEN)
 #define DEVLINK_HEALTH_BUFFER_DATA_SIZE (DEVLINK_HEALTH_BUFFER_SIZE / 2)
-#define DEVLINK_HEALTH_SIZE_TO_BUFFERS(size) DIV_ROUND_UP(size, 
DEVLINK_HEALTH_BUFFER_DATA_SIZE)
+#define DEVLINK_HEALTH_SIZE_TO_BUFFERS(size) DIV_ROUND_UP_ULL(size, 
DEVLINK_HEALTH_BUFFER_DATA_SIZE)
 #define DEVLINK_HEALTH_BUFFER_MAX_CHUNK 1024
 
 struct devlink_health_buffer {
-- 
2.20.1

[PATCH v3 0/5] Add Oxalis board support

[Manivannan Sadhasivam]

Hello,

This patchset adds Oxalis board support. This board is one of the
96Boards Enterprise Edition platform from EBS-SYSTART GmbH. Below are some
of the key features of this board:

* SoC: NXP Layerscape LS1012A
* RAM: 1GB DDR3L
* PMU: NXP VR5100
* Storage: 64MByte SPI Flash for bootloader and RCW, MicroSD Card, SATA
* Connectivity: 2x Ethernet
* USB: 2x USB3.0

More information about this board can be found in 96Boards product
page: https://www.96boards.org/product/oxalis/

Ethernet and SPI flash are not supported yet!

Thanks,
Mani

Changes in v3:

* Fixed LS1012A and LS1021A bindings
* Added missing devicetree compatibles for LS1021A based boards
* Added Rob's Reviewed-by tag for Vendor prefix patch

Changes in v2:

As per Rob's review:

* Adopted the Oxalis board binding to JSON format.
* Sorted the EBS-SYSTART vendor prefix alphabetically.
* Used the generic node name for audio codec.

Manivannan Sadhasivam (5):
  dt-bindings: arm: fsl: Fix bindings for LS1012A and LS1021A based
boards
  ARM: dts: Add devicetree compatibles for LS1021A based boards
  dt-bindings: vendor-prefixes: Add EBS-SYSTART GmbH Vendor Prefix
  dt-bindings: arm: fsl: Add devicetree binding for Oxalis
  arm64: dts: freescale: Add devicetree for Oxalis

 .../devicetree/bindings/arm/fsl.yaml  | 11 ++-
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts   |  1 +
 arch/arm/boot/dts/ls1021a-qds.dts |  1 +
 arch/arm/boot/dts/ls1021a-twr.dts |  1 +
 arch/arm64/boot/dts/freescale/Makefile|  1 +
 .../boot/dts/freescale/fsl-ls1012a-oxalis.dts | 96 +++
 7 files changed, 111 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts

-- 
2.17.1

[PATCH v3 3/5] dt-bindings: vendor-prefixes: Add EBS-SYSTART GmbH Vendor Prefix

[Manivannan Sadhasivam]

Add vendor prefix for EBS-SYSTART GmbH.

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389508584f48..38693105b5c6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -108,6 +108,7 @@ dongwoonDongwoon Anatech
 dptechnics DPTechnics
 draginoDragino Technology Co., Limited
 ea Embedded Artists AB
+ebs-systart EBS-SYSTART GmbH
 ebvEBV Elektronik
 eckelmann  Eckelmann AG
 edtEmerging Display Technologies
-- 
2.17.1

[PATCH v3 4/5] dt-bindings: arm: fsl: Add devicetree binding for Oxalis

[Manivannan Sadhasivam]

Add devicetree binding for LS1012A SoC based Oxalis board.

Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 20fb61006f2b..6f85965e9fb4 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -176,6 +176,7 @@ properties:
   - description: LS1012A based Boards
 items:
   - enum:
+  - ebs-systart,oxalis
   - fsl,ls1012a-rdb
   - fsl,ls1012a-frdm
   - fsl,ls1012a-qds
-- 
2.17.1

[PATCH v3 1/5] dt-bindings: arm: fsl: Fix bindings for LS1012A and LS1021A based boards

[Manivannan Sadhasivam]

Fix devicetree bindings for Freescale LS1012A and LS1021A SoC based boards.

Fixes: a1a38e1f4d1d ("dt-bindings: arm: Convert FSL board/soc bindings to 
json-schema")
Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index d34fe0749199..20fb61006f2b 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -173,12 +173,20 @@ properties:
   - fsl,vf610
   - fsl,vf610m4
 
-  - description: LS1021A based Boards
+  - description: LS1012A based Boards
 items:
   - enum:
   - fsl,ls1012a-rdb
   - fsl,ls1012a-frdm
   - fsl,ls1012a-qds
+  - const: fsl,ls1012a
+
+  - description: LS1021A based Boards
+items:
+  - enum:
+  - fsl,ls1021a-moxa-uc-8410a
+  - fsl,ls1021a-qds
+  - fsl,ls1021a-twr
   - const: fsl,ls1021a
 
   - description: LS1043A based Boards
-- 
2.17.1