Re: [PATCH] Use default .cfg file name for RTL8723BS devices with id of OBDA8723

[Marcel Holtmann]

Hi Ian,

> For RTL8723BS devices the current config file name is a composite of
> both the config name (rtl8723bs) and a postfix of the device-id.
> 
> Given the majority of RTL8723BS devices use a device-id of OBDA8723
> this simplifies the config file name to use "rtl8723bs_config.bin"
> as a default of for these devices.
> 
> Signed-off-by: Ian W MORRISON 
> ---
> drivers/bluetooth/hci_h5.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
> index 8eede1197cd2..cce422dc1b8d 100644
> --- a/drivers/bluetooth/hci_h5.c
> +++ b/drivers/bluetooth/hci_h5.c
> @@ -852,7 +852,9 @@ static int h5_btrtl_setup(struct h5 *h5)
>   bool flow_control;
>   int err;
> 
> - btrtl_dev = btrtl_initialize(h5->hu->hdev, h5->id);
> + btrtl_dev = strcmp("OBDA8723", h5->id) ?
> + btrtl_initialize(h5->hu->hdev, h5->id) :
> + btrtl_initialize(h5->hu->hdev, NULL);

I am not letting you duplicate the PNPID here. This needs to be done cleanly 
with the device table that is already present.

Regards

Marcel

Re: [PATCH] bluetooth: hci_h5: avoid unused variable warnings

[Marcel Holtmann]

Hi Arnd,

> When CONFIG_BT_HCIUART_RTL is disabled, the hci_h5 driver produces a build
> warning because of an incorrect set of #ifdef guards:
> 
> drivers/bluetooth/hci_h5.c:920:22: error: 'rtl_vnd' defined but not used 
> [-Werror=unused-variable]
> 
> Replacing the #ifdef with an IS_ENABLED() check shuts up the error
> and simplifies the logic.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> drivers/bluetooth/hci_h5.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
> index 8eede1197cd2..b10e64ba0ff4 100644
> --- a/drivers/bluetooth/hci_h5.c
> +++ b/drivers/bluetooth/hci_h5.c
> @@ -841,7 +841,6 @@ static void h5_serdev_remove(struct serdev_device *serdev)
>   hci_uart_unregister_device(&h5->serdev_hu);
> }
> 
> -#ifdef CONFIG_BT_HCIUART_RTL
> static int h5_btrtl_setup(struct h5 *h5)
> {
>   struct btrtl_device_info *btrtl_dev;
> @@ -923,24 +922,21 @@ static struct h5_vnd rtl_vnd = {
>   .close  = h5_btrtl_close,
>   .acpi_gpio_map  = acpi_btrtl_gpios,
> };
> -#endif
> 
> -#ifdef CONFIG_ACPI
> static const struct acpi_device_id h5_acpi_match[] = {
> -#ifdef CONFIG_BT_HCIUART_RTL
>   { "OBDA8723", (kernel_ulong_t)&rtl_vnd },
> -#endif
>   { },
> };
> MODULE_DEVICE_TABLE(acpi, h5_acpi_match);
> -#endif
> 
> static struct serdev_device_driver h5_serdev_driver = {
>   .probe = h5_serdev_probe,
>   .remove = h5_serdev_remove,
>   .driver = {
>   .name = "hci_uart_h5",
> - .acpi_match_table = ACPI_PTR(h5_acpi_match),
> + .acpi_match_table = (IS_ENABLED(CONFIG_BT_HCIUART_RTL) &&
> +  IS_ENABLED(CONFIG_ACPI)) ?
> + h5_acpi_match : 0,
>   },

I do not like this construct at all. It will also blow up once we have a second 
vendor with H:5 support. We need to find another way to solve this.

Regards

Marcel

Re: [PATCH] perf tools: Add struct ordered_events_buffer layer

[Stephane Eranian]

Jiri,
On Mon, Aug 13, 2018 at 6:04 AM Jiri Olsa  wrote:
>
> On Fri, Aug 10, 2018 at 01:54:31PM +0200, Jiri Olsa wrote:
> > On Fri, Aug 10, 2018 at 01:21:18AM -0700, Stephane Eranian wrote:
> > > On Thu, Aug 9, 2018 at 1:07 AM Jiri Olsa  wrote:
> > > >
> > > > On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> > > > > This patch fixes a bug in ordered_event.c:alloc_event().
> > > > > An ordered_event struct was not initialized properly potentially
> > > > > causing crashes later on in free_dup_event() depending on the
> > > > > content of the memory. If it was NULL, then it would work fine,
> > > > > otherwise, it could cause crashes such as:
> > > >
> > > > I'm now little puzzled what do we use this first event for..
> > > > I can't see anything special about it, other than it's added
> > > > on the list uninitialized ;-)
> > > >
> > > > it seems to work properly when we ditch it.. might be some
> > > > prehistoric leftover or I'm terribly missing something
> > > >
> > > You need to keep track of the buffers to free. You do not free the
> > > ordered_event structs
> > > individually. For each oe->buffer, you need one free(). Each buffer is
> > > put in the to_free
> > > list. But to link it into the list it needs a list_head. This is what
> > > buffer[0] is used for.
> > > But the logic is broken in  ordered_events__free(). It does not free 
> > > individual
> > > ordered_event structs, but a buffer with many. Yet, it is missing
> > > freeing all of the duped
> > > events.
> > >
> > >  void ordered_events__free(struct ordered_events *oe)
> > > {
> > > while (!list_empty(&oe->to_free)) {
> > > struct ordered_event *buffer;
> > >
> > > buffer = list_entry(oe->to_free.next, struct
> > > ordered_event, list);
> > > list_del(&buffer->list);
> > > > free_dup_event(oe, event->event);
> > > free(buffer);
> > > }
> > > }
> > > This only frees the dup_event of buffer[0] which we know is NULL (well, 
> > > now).
> > > It needs to walk all the entries in buffer[] to free buffer[x].event.
> >
> > yes.. if there's copy_on_queue set, we need to do that,
> > otherwise we're leaking all the events
> >
> > >
> > > I think the goal was likely to avoid adding another list_head field to
> > > each ordered_event
> > > and instead use one per allocated buffer.
> > > This is very convoluted and prone to errors and we are seeing right
> > > now. This should
> > > be cleaned. So either you add a list_head to ordered_event or you
> > > would buffer[x] in
> > > ordered_events_free().
> > >
> > > At this point, this is my understanding.
> > > Do you agree?
> >
> > yea, I see it now.. thanks for pointing this out
> >
> > how about something like below? haven't tested properly yet
>
> attaching full patch
>
> thanks,
> jirka
>
>
> ---
> When ordering events, we use preallocated buffers to store separated
> events. Those buffers currently don't have their own struct, but since
> they are basically array of 'struct ordered_event' objects, we use the
> first event to hold buffers data - list head, that holds all buffers
> together:
>
>struct ordered_events {
>  ...
>  struct ordered_event *buffer;
>  ...
>};
>
>struct ordered_event {
>  u64   timestamp;
>  u64   file_offset;
>  union perf_event  *event;
>  struct list_head  list;
>};
>
> This is quite convoluted and error prone as demonstrated by
> free-ing issue discovered and fixed by Stephane in here [1].
>
> This patch adds the 'struct ordered_events_buffer' object,
> that holds the buffer data and frees it up properly.
>
> [1] - https://marc.info/?l=linux-kernel&m=153376761329335&w=2
>
> Reported-by: Stephane Eranian 
> Link: http://lkml.kernel.org/n/tip-qrkcqm5m1sugy4q83pfn5...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/util/ordered-events.c | 44 ++--
>  tools/perf/util/ordered-events.h | 37 +++
>  2 files changed, 52 insertions(+), 29 deletions(-)
>
> diff --git a/tools/perf/util/ordered-events.c 
> b/tools/perf/util/ordered-events.c
> index bad9e0296e9a..038515a52e2c 100644
> --- a/tools/perf/util/ordered-events.c
> +++ b/tools/perf/util/ordered-events.c
> @@ -80,14 +80,20 @@ static union perf_event *dup_event(struct ordered_events 
> *oe,
> return oe->copy_on_queue ? __dup_event(oe, event) : event;
>  }
>
> -static void free_dup_event(struct ordered_events *oe, union perf_event 
> *event)
> +static void __free_dup_event(struct ordered_events *oe, union perf_event 
> *event)
>  {
> -   if (event && oe->copy_on_queue) {
> +   if (event) {
> oe->cur_alloc_size -= event->header.size;
> free(event);
> }
>  }
>
> +static void free_dup_event(struct ordered_events *oe, union perf_event 
> *event)
> +{
> +   if (oe->copy_on_queue)
> +   __free_dup_event(oe, event);
> +}
> +

Re: [PATCH] mmc: Move the mmc driver init earlier

[Greg Kroah-Hartman]

On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> Hi Greg, Ulf
> 
> Could you help to review this? many thanks!

Review what?  I see no patch here.  And why would I need to review a mmc
patch in the middle of the merge window?

totally confused,

greg k-h

Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds]

[Uwe Kleine-König]

Hello Tomas,

On 05/25/2018 04:02 PM, Tomas Hlavacek wrote:
>> Talking about firmware, I wonder if there is firmware supported needed
>> to solve
>> https://wiki.debian.org/InstallingDebianOn/TurrisOmnia#Power_Management
>> . Didn't look into that deeply yet and probably not high prio given that
>> normally the Turris Omnia will just run 7x24h.
> 
> That's right, there is no power-down signalization from the CPU right
> now. Btw. is there any mechanism in kernel to signal over arbitrary
> bus (like I2C) that the host is shutting down and the power can/should
> be cut to CPU in N seconds?

I think there is no interface for "in N seconds" and currently the i2c
core isn't prepared to do such stuff "late" (i.e. when the system is
going down and irqs are already off). But there is some work ongoing to
address that:

https://marc.info/?l=linux-i2c&m=153419498527890&w=2

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] bluetooth: hci_h5: avoid unused variable warnings

[Hans de Goede]

Hi Arnd,

On 14-08-18 00:04, Arnd Bergmann wrote:

When CONFIG_BT_HCIUART_RTL is disabled, the hci_h5 driver produces a build
warning because of an incorrect set of #ifdef guards:

drivers/bluetooth/hci_h5.c:920:22: error: 'rtl_vnd' defined but not used 
[-Werror=unused-variable]

Replacing the #ifdef with an IS_ENABLED() check shuts up the error
and simplifies the logic.

Signed-off-by: Arnd Bergmann 


Hmm, so now you're counting on dead code elimination to remove
references to unavailable symbols. I'm not sure I like this and
since Marcel has also indicated the does not like this fix I
believe we need another fix.

I will write another fix for this.

Regards,

Hans




---
  drivers/bluetooth/hci_h5.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..b10e64ba0ff4 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -841,7 +841,6 @@ static void h5_serdev_remove(struct serdev_device *serdev)
hci_uart_unregister_device(&h5->serdev_hu);
  }
  
-#ifdef CONFIG_BT_HCIUART_RTL

  static int h5_btrtl_setup(struct h5 *h5)
  {
struct btrtl_device_info *btrtl_dev;
@@ -923,24 +922,21 @@ static struct h5_vnd rtl_vnd = {
.close  = h5_btrtl_close,
.acpi_gpio_map  = acpi_btrtl_gpios,
  };
-#endif
  
-#ifdef CONFIG_ACPI

  static const struct acpi_device_id h5_acpi_match[] = {
-#ifdef CONFIG_BT_HCIUART_RTL
{ "OBDA8723", (kernel_ulong_t)&rtl_vnd },
-#endif
{ },
  };
  MODULE_DEVICE_TABLE(acpi, h5_acpi_match);
-#endif
  
  static struct serdev_device_driver h5_serdev_driver = {

.probe = h5_serdev_probe,
.remove = h5_serdev_remove,
.driver = {
.name = "hci_uart_h5",
-   .acpi_match_table = ACPI_PTR(h5_acpi_match),
+   .acpi_match_table = (IS_ENABLED(CONFIG_BT_HCIUART_RTL) &&
+IS_ENABLED(CONFIG_ACPI)) ?
+   h5_acpi_match : 0,
},
  };
  

Re: [PATCH 1/2] perf tools: Make check-headers.sh check based on kernel dir

[Jiri Olsa]

On Tue, Aug 14, 2018 at 11:47:39AM +1000, Michael Ellerman wrote:
> Jiri Olsa  writes:
> > diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> > index ea48aa6f8d19..9d466e853aec 100755
> > --- a/tools/perf/check-headers.sh
> > +++ b/tools/perf/check-headers.sh
> > @@ -88,6 +88,8 @@ check () {
> >  # differences.
> >  test -d ../../include || exit 0
> >  
> > +pushd ../.. > /dev/null
> > +
> >  # simple diff check
> >  for i in $HEADERS; do
> >check $i -B
> 
> This breaks the build when sh is not bash:
> 
>   ./check-headers.sh: 91: ./check-headers.sh: pushd: not found
>   ./check-headers.sh: 107: ./check-headers.sh: popd: not found
>   Makefile.perf:205: recipe for target 'sub-make' failed

sry.. Arnaldo, would you change it for simple cd (attached below)
or should I send the fix?

thanks,
jirka


---
diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
index 80bf84803677..466540ee8ea7 100755
--- a/tools/perf/check-headers.sh
+++ b/tools/perf/check-headers.sh
@@ -88,7 +88,7 @@ check () {
 # differences.
 test -d ../../include || exit 0
 
-pushd ../.. > /dev/null
+cd ../..
 
 # simple diff check
 for i in $HEADERS; do
@@ -104,4 +104,4 @@ check include/uapi/linux/mman.h   '-I "^#include 
<\(uapi/\)*asm/mman.h>"'
 # diff non-symmetric files
 check_2 tools/perf/arch/x86/entry/syscalls/syscall_64.tbl 
arch/x86/entry/syscalls/syscall_64.tbl
 
-popd > /dev/null
+cd tools/perf

Re: [PATCH] Use default .cfg file name for RTL8723BS devices with id of OBDA8723

[Hans de Goede]

Hi,

On 14-08-18 08:47, Ian W MORRISON wrote:

For RTL8723BS devices the current config file name is a composite of
both the config name (rtl8723bs) and a postfix of the device-id.

Given the majority of RTL8723BS devices use a device-id of OBDA8723
this simplifies the config file name to use "rtl8723bs_config.bin"
as a default of for these devices.


NACK, the device id is in there for a reason, once someone writes
support for it we will also need a rtl8723bs_config file on ARM
boards, which will definitely be board specific. I don't want us
to pretend there is one config to rule them all.

Specifically I plan to submit both the firmware and
rtl8723bs_config-OBDA8723.bin to linux-firmware soon, if the kernel
instead looks for just rtl8723bs_config.bin then I need to give
it that name in linux-firmware and then when we get ARM support
and the kernel complains about e.g. rtl8723bs_config-NextThingCo-CHIP.bin
not being there people may be tempted to think they can just link
to the "generic" one from linux-firmware which then turns out
to not be generic at all.

Regards,

Hans





Signed-off-by: Ian W MORRISON 
---
  drivers/bluetooth/hci_h5.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..cce422dc1b8d 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -852,7 +852,9 @@ static int h5_btrtl_setup(struct h5 *h5)
bool flow_control;
int err;
  
-	btrtl_dev = btrtl_initialize(h5->hu->hdev, h5->id);

+   btrtl_dev = strcmp("OBDA8723", h5->id) ?
+   btrtl_initialize(h5->hu->hdev, h5->id) :
+   btrtl_initialize(h5->hu->hdev, NULL);
if (IS_ERR(btrtl_dev))
return PTR_ERR(btrtl_dev);
  

RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array

[Anson Huang]

Hi, Peng

Anson Huang
Best Regards!


> -Original Message-
> From: Peng Fan
> Sent: Monday, August 13, 2018 9:16 AM
> To: Anson Huang ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; mturque...@baylibre.com; sb...@kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Rob Herring 
> Cc: dl-linux-imx 
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> 
> Hi Anson,
> 
> > > > -Original Message-
> > > > From: Anson Huang
> > > > Sent: 2018年8月8日 12:39
> > > > To: shawn...@kernel.org; s.ha...@pengutronix.de;
> > > > ker...@pengutronix.de; Fabio Estevam ;
> > > > mturque...@baylibre.com; sb...@kernel.org;
> > > > linux-arm-ker...@lists.infradead.org;
> > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Cc: dl-linux-imx 
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks = "
> > > or "init-on-arrary="
> > > and enable those clocks?
> >
> > Parsing the clocks arrays from dtb is another way of enabling critical
> > clocks, but for current i.MX6/7 platforms, we implement it in same way
> > as most of other SoCs, currently I did NOT see any necessity of
> > putting them in dtb, just adding flag during clock registering is more
> > simple, if there is any special requirement for different clocks set
> > to be enabled, then we can add support to enable the method of parsing
> critical-clocks from dtb. Just my two cents.
> 
> Thinking about OP-TEE want to use one device, but it's clocks are registered 
> by
> Linux, because there is no module in Linux side use it, it will shutdown the 
> clock,
> which cause OP-TEE could not access the device.
> 
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> the clocks are not shutdown by Linux.
> 
> However adding a new property in clk node and let driver code parse the dts,
> there is no need to modify clk driver code when OP-TEE needs another device
> clock.
For supporting OP-TEE or other features which has special requirement about 
clock
settings, I think we can have another patch to add parsing critical clocks from 
dtb in
common place of i.MX clock drivers. 

Anson.

> 
> Regards,
> Peng.
> 
> >
> > Anson.
> >
> > >
> > > Regards,
> > > Peng.
> > >
> > > >
> > > > Signed-off-by: Anson Huang 
> > > > ---
> > > >  drivers/clk/imx/clk-imx7d.c | 27 ---
> > > >  drivers/clk/imx/clk.h   |  7 +++
> > > >  2 files changed, 15 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-imx7d.c
> > > > b/drivers/clk/imx/clk-imx7d.c index c4518d7..076460b 100644
> > > > --- a/drivers/clk/imx/clk-imx7d.c
> > > > +++ b/drivers/clk/imx/clk-imx7d.c
> > > > @@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
> > > > "pll_enet_main", "pll_enet_main_src  static const char
> > > > *pll_audio_bypass_sel[] = { "pll_audio_main",
> > > > "pll_audio_main_src", }; static const char *pll_video_bypass_sel[]
> > > > = { "pll_video_main", "pll_video_main_src", };
> > > >
> > > > -static int const clks_init_on[] __initconst = {
> > > > -   IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
> > > > -   IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
> > > > -   IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
> > > > -   IMX7D_DRAM_PHYM_ALT_ROOT_CLK,
> IMX7D_DRAM_ALT_ROOT_CLK,
> > > > -};
> > > > -
> > > >  static struct clk_onecell_data clk_data;
> > > >
> > > >  static struct clk ** const uart_clks[] __initconst = { @@ -403,7
> > > > +396,6 @@ static void __init imx7d_clocks_init(struct device_node
> > > *ccm_node)  {
> > > > struct device_node *np;
> > > > void __iomem *base;
> > > > -   int i;
> > > >
> > > > clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > > > clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node,
> "osc");
> > > @@
> > > > -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct
> > > > device_node
> > > > *ccm_node)
> > > > clks[IMX7D_PLL_SYS_MAIN_120M] =
> > > > imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
> > > > clks[IMX7D_PLL_DRAM_MAIN_533M] =
> > > > imx_clk_fixed_factor("pll_dram_533m", "pll_dram_main_clk", 1, 2);
> > > >
> > > > -   clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m",
> > > > base
> > > > + 0xb0, 4);
> > > > +   clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > +imx_clk_gate_dis_flags("pll_sys_main_480m_clk",
> > > > +"pll_sys_main_480m", base + 0xb0, 4, CLK_IS_CRITICAL);
> > > > clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main

Re: [PATCH] mmc: Move the mmc driver init earlier

[Feng Tang]

Hi Greg,

On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> > Hi Greg, Ulf
> > 
> > Could you help to review this? many thanks!
> 
> Review what?  I see no patch here.  And why would I need to review a mmc
> patch in the middle of the merge window?
> 
> totally confused,

Sorry for the confusion! I didn't noticed the 4.19 merge window.

The patch was originally posted in June, and has gone through some
review discussions with mmc maintainers, my last mail was trying
to keep some discussion info.

Thanks,
Feng


The original patch is:
-

>From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001
From: Feng Tang 
Date: Fri, 8 Jun 2018 17:10:30 +0800
Subject: [PATCH] mmc: Move the mmc driver init earlier

When doing some boot time optimization for an eMMC rootfs NUCs,
we found the rootfs may spend around 100 microseconds waiting
for eMMC card to be initialized, then the rootfs could be
mounted.
[1.216561] Waiting for root device /dev/mmcblk1p1...
[1.289262] mmc1: new HS400 MMC card at address 0001
[1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
[1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB
[1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB
[1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB
[1.292798]  mmcblk1: p1 p2 p3
[1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to 
feature incompatibilities
[1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to 
feature incompatibilities

And this is a common problem for smartphones, tablets, embedded
devices and automotive products. This patch will make the eMMC/SD
card  start initializing earlier, by changing its order in drivers/Makefile.

On our platform, the waiting for eMMC card is almost eliminated with the patch,
which is critical to boot time. And it should benefit other non-x86 platforms
which see the similar waiting for emmc rootfs.

Signed-off-by: Feng Tang 
---
 drivers/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 24cd47014657..c473afd3c688 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR)   += regulator/
 # reset controllers early, since gpu drivers might rely on them to initialize
 obj-$(CONFIG_RESET_CONTROLLER) += reset/
 
+# put mmc early as many morden devices use emm/sd card as rootfs storage
+obj-y  += mmc/
+
 # tty/ comes before char/ so that the VT console is the boot-time
 # default.
 obj-y  += tty/
@@ -128,7 +131,6 @@ obj-$(CONFIG_EISA)  += eisa/
 obj-$(CONFIG_PM_OPP)   += opp/
 obj-$(CONFIG_CPU_FREQ) += cpufreq/
 obj-$(CONFIG_CPU_IDLE) += cpuidle/
-obj-y  += mmc/
 obj-$(CONFIG_MEMSTICK) += memstick/
 obj-$(CONFIG_NEW_LEDS) += leds/
 obj-$(CONFIG_INFINIBAND)   += infiniband/
-- 
2.14.1

Re: [PATCH] mmc: Move the mmc driver init earlier

[Greg Kroah-Hartman]

On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote:
> Hi Greg,
> 
> On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> > > Hi Greg, Ulf
> > > 
> > > Could you help to review this? many thanks!
> > 
> > Review what?  I see no patch here.  And why would I need to review a mmc
> > patch in the middle of the merge window?
> > 
> > totally confused,
> 
> Sorry for the confusion! I didn't noticed the 4.19 merge window.
> 
> The patch was originally posted in June, and has gone through some
> review discussions with mmc maintainers, my last mail was trying
> to keep some discussion info.

Ok, then why ask me?  I'm not the mmc maintainer.

> The original patch is:
> -
> 
> >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001
> From: Feng Tang 
> Date: Fri, 8 Jun 2018 17:10:30 +0800
> Subject: [PATCH] mmc: Move the mmc driver init earlier
> 
> When doing some boot time optimization for an eMMC rootfs NUCs,
> we found the rootfs may spend around 100 microseconds waiting
> for eMMC card to be initialized, then the rootfs could be
> mounted.
>   [1.216561] Waiting for root device /dev/mmcblk1p1...
>   [1.289262] mmc1: new HS400 MMC card at address 0001
>   [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
>   [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB
>   [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB
>   [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB
>   [1.292798]  mmcblk1: p1 p2 p3
>   [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to 
> feature incompatibilities
>   [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to 
> feature incompatibilities
> 
> And this is a common problem for smartphones, tablets, embedded
> devices and automotive products. This patch will make the eMMC/SD
> card  start initializing earlier, by changing its order in drivers/Makefile.
> 
> On our platform, the waiting for eMMC card is almost eliminated with the 
> patch,
> which is critical to boot time. And it should benefit other non-x86 platforms
> which see the similar waiting for emmc rootfs.
> 
> Signed-off-by: Feng Tang 
> ---
>  drivers/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 24cd47014657..c473afd3c688 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR) += regulator/
>  # reset controllers early, since gpu drivers might rely on them to initialize
>  obj-$(CONFIG_RESET_CONTROLLER)   += reset/
>  
> +# put mmc early as many morden devices use emm/sd card as rootfs storage

Spelling error :)

> +obj-y+= mmc/
> +
>  # tty/ comes before char/ so that the VT console is the boot-time
>  # default.
>  obj-y+= tty/

Everyone wants to be first.  Watch out if you try to put stuff before
tty, you have to be very careful.  There are sd serial devices, right?

Anyway, nothing we can do now until after 4.19-rc1 is out.

thanks,

greg k-h

[PATCH v2] ARM: dts: spear: fix stmpe811 interrupt properties

[Marcel Ziswiler]

From: Marcel Ziswiler 

The property "irq-over-gpio" simply does not exist (this is nowadays
actually auto detected) and the property "irq-gpios" is actually called
"irq-gpio".

Signed-off-by: Marcel Ziswiler 

---

Changes in v2:
- Fix commit message as pointed out by Viresh.

 arch/arm/boot/dts/spear320-hmi.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/spear320-hmi.dts 
b/arch/arm/boot/dts/spear320-hmi.dts
index 0d0da1f65f0e..d2d1fe944407 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -241,8 +241,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x41>;
-   irq-over-gpio;
-   irq-gpios = <&gpiopinctrl 29 0x4>;
+   irq-gpio = <&gpiopinctrl 29 0x4>;
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
-- 
2.14.4

general protection fault in kvm_ioapic_scan_entry

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:1c2f2531cf8b Add linux-next specific files for 20180809
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16016cf840
kernel config:  https://syzkaller.appspot.com/x/.config?x=44657afb75515c8b
dashboard link: https://syzkaller.appspot.com/bug?extid=20eae20afcbd851b8601
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12038e2240
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=163caee240

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+20eae20afcbd851b8...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
urandom_read: 1 callbacks suppressed
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
CPU: 1 PID: 4332 Comm: syz-executor255 Not tainted  
4.18.0-rc8-next-20180809+ #35
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54  
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48  
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b

RSP: 0018:8801cf1a7430 EFLAGS: 00010286
RAX: dc00 RBX: 01b0 RCX: 
RDX: 0036 RSI:  RDI: 01b4
RBP: 8801cf1a7458 R08: 0001 R09: 
R10: ed0035c51089 R11: 8801ae28844f R12: 8801ae288430
R13:  R14: dc00 R15: 
FS:  014a5880() GS:8801db10() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2000 CR3: 0001b4a66000 CR4: 001426e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
 _raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
 spin_lock include/linux/spinlock.h:329 [inline]
 kvm_ioapic_scan_entry+0x7f/0x3c0 arch/x86/kvm/ioapic.c:246
 vcpu_scan_ioapic arch/x86/kvm/x86.c:7253 [inline]
 vcpu_enter_guest+0x494b/0x6360 arch/x86/kvm/x86.c:7389
 vcpu_run arch/x86/kvm/x86.c:7660 [inline]
 kvm_arch_vcpu_ioctl_run+0x33e/0x1690 arch/x86/kvm/x86.c:7837
 kvm_vcpu_ioctl+0x7b8/0x1300 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2590
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:501 [inline]
 do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
 __do_sys_ioctl fs/ioctl.c:709 [inline]
 __se_sys_ioctl fs/ioctl.c:707 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4402f9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ffdb31251d8 EFLAGS: 0213 ORIG_RAX: 0010
RAX: ffda RBX: 004002c8 RCX: 004402f9
RDX:  RSI: ae80 RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10: 004002c8 R11: 0213 R12: 00401b80
R13: 00401c10 R14:  R15: 
Modules linked in:
Dumping ftrace buffer:
   (ftrace buffer empty)
---[ end trace c89a962150abb5ce ]---
RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54  
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48  
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b

RSP: 0018:8801cf1a7430 EFLAGS: 00010286
RAX: dc00 RBX: 01b0 RCX: 
RDX: 0036 RSI:  RDI: 01b4
RBP: 8801cf1a7458 R08: 0001 R09: 
R10: ed0035c51089 R11: 8801ae28844f R12: 8801ae288430
R13:  R14: dc00 R15: 
FS:  014a5880() GS:8801db10() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2000 CR3: 0001b4a66000 CR4: 001426e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug rep

[PATCH] arm64: lib: use c string functions for KASAN support

[Kyeongdon Kim]

Assembly optimized string functions cannot detect KASan bug.
This might have been the intention of the original author.
(not too much important to catch)

But, I found the obvious uaf problem in strcmp() function.
 - in this case, using 32bit KASan patchset helps

Since I used c string function, I believe I could find this bug.
After using the patch, can see the report & backtrace the below:

==
BUG: KASAN: use-after-free in strcmp+0x1c/0x5c at addr ffc0ad313500
Read of size 1 by task swapper/0/1
CPU: 3 PID: 1 Comm: swapper/0 Tainted: GB   4.9.77+ #1
Hardware name: Generic (DT) based system
Call trace:
[] dump_backtrace+0x0/0x2e0
[] show_stack+0x14/0x1c
[] dump_stack+0x88/0xb0
[] kasan_object_err+0x24/0x7c
[] kasan_report+0x2f0/0x484
[] __asan_load1+0x24/0x50
[] strcmp+0x1c/0x5c
[] platform_match+0x40/0xe4
[] __driver_attach+0x40/0x130
[] bus_for_each_dev+0xc4/0xe0
[] driver_attach+0x30/0x3c
[] bus_add_driver+0x2dc/0x328
[] driver_register+0x118/0x160
[] __platform_driver_register+0x7c/0x88
[] alarmtimer_init+0x154/0x1e4
[] do_one_initcall+0x184/0x1a4
[] kernel_init_freeable+0x2ec/0x2f0
[] kernel_init+0x18/0x10c
[] ret_from_fork+0x10/0x50
Object at ffc0ad313500, in cache kmalloc-64 size: 64
Allocated:
PID = 1
 save_stack_trace_tsk+0x0/0x194
 save_stack_trace+0x18/0x20
 kasan_kmalloc+0xa8/0x154
 kasan_slab_alloc+0x14/0x1c
 __kmalloc_track_caller+0x178/0x2a0
 kvasprintf+0x80/0x104
 kvasprintf_const+0xcc/0xd0
 kobject_set_name_vargs+0x54/0xd4
 dev_set_name+0x64/0x84
 of_device_make_bus_id+0xc4/0x140
 of_device_alloc+0x1e0/0x200
 of_platform_device_create_pdata+0x70/0xf4
 of_platform_bus_create+0x448/0x508
 of_platform_populate+0xf4/0x104
 of_platform_default_populate+0x20/0x28
 of_platform_default_populate_init+0x68/0x78
Freed:
PID = 1
 save_stack_trace_tsk+0x0/0x194
 save_stack_trace+0x18/0x20
 kasan_slab_free+0xa0/0x14c
 kfree+0x174/0x288
 kfree_const+0x2c/0x38
 kobject_rename+0x12c/0x160
 device_rename+0xa8/0x110
 mt_usb_probe+0x218/0x760
 platform_drv_probe+0x74/0xd0
 driver_probe_device+0x3d4/0x614
 __driver_attach+0xc8/0x130
 bus_for_each_dev+0xc4/0xe0
 driver_attach+0x30/0x3c
 bus_add_driver+0x2dc/0x328
 driver_register+0x118/0x160
 __platform_driver_register+0x7c/0x88
Memory state around the buggy address:
 ffc0ad313300: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
 ffc0ad313400: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
>ffc0ad313500: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
   ^
 ffc0ad313600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
 ffc0ad313700: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
==

Signed-off-by: Kyeongdon Kim 
---
 arch/arm64/include/asm/string.h | 2 ++
 arch/arm64/kernel/arm64ksyms.c  | 2 ++
 arch/arm64/lib/Makefile | 8 +---
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
index dd95d33..5c5219a 100644
--- a/arch/arm64/include/asm/string.h
+++ b/arch/arm64/include/asm/string.h
@@ -16,6 +16,7 @@
 #ifndef __ASM_STRING_H
 #define __ASM_STRING_H
 
+#if !defined(CONFIG_KASAN)
 #define __HAVE_ARCH_STRRCHR
 extern char *strrchr(const char *, int c);
 
@@ -33,6 +34,7 @@ extern __kernel_size_t strlen(const char *);
 
 #define __HAVE_ARCH_STRNLEN
 extern __kernel_size_t strnlen(const char *, __kernel_size_t);
+#endif
 
 #define __HAVE_ARCH_MEMCPY
 extern void *memcpy(void *, const void *, __kernel_size_t);
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index d894a20..eb9bf20 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -44,12 +44,14 @@ EXPORT_SYMBOL(__arch_copy_in_user);
 EXPORT_SYMBOL(memstart_addr);
 
/* string / mem functions */
+#if !defined(CONFIG_KASAN)
 EXPORT_SYMBOL(strchr);
 EXPORT_SYMBOL(strrchr);
 EXPORT_SYMBOL(strcmp);
 EXPORT_SYMBOL(strncmp);
 EXPORT_SYMBOL(strlen);
 EXPORT_SYMBOL(strnlen);
+#endif
 EXPORT_SYMBOL(memset);
 EXPORT_SYMBOL(memcpy);
 EXPORT_SYMBOL(memmove);
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 68755fd..aa2d457 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -2,9 +2,11 @@
 lib-y  := clear_user.o delay.o copy_from_user.o\
   copy_to_user.o copy_in_user.o copy_page.o\
   clear_page.o memchr.o memcpy.o memmove.o memset.o\
-  memcmp.o strcmp.o strncmp.o strlen.o strnlen.o   \
-  strchr.o strrchr.o tishift.o
-
+  memcmp.o tishift.o
+ifndef CONFIG_KASAN
+lib-y  := strcmp.o strncmp.o strlen.o strnlen.o\
+  strchr.o strrchr.o
+endif
 # Tell the compiler to treat all general purpose registers (with the
 # exception of the IP registers, which are already handled by the caller
 # in case of a PLT) as

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[Johannes Berg]

On Tue, 2018-08-14 at 08:57 +0900, Masahiro Yamada wrote:
> 2018-08-14 7:09 GMT+09:00 Arnd Bergmann :
> > Passing an enum into FIELD_GET() produces a long but harmless warning on
> > newer compilers:
> > 
> >  from include/linux/linkage.h:7,
> >  from include/linux/kernel.h:7,
> >  from include/linux/skbuff.h:17,
> >  from include/linux/if_ether.h:23,
> >  from include/linux/etherdevice.h:25,
> >  from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:63:
> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 
> > 'iwl_mvm_rx_mpdu_mq':
> > include/linux/bitfield.h:56:20: error: enum constant in boolean context 
> > [-Werror=int-in-bool-context]
> >BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero"); \
> > ^
> > ...
> > include/linux/bitfield.h:103:3: note: in expansion of macro 
> > '__BF_FIELD_CHECK'
> >__BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
> >^~~~
> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1025:21: note: in expansion 
> > of macro 'FIELD_GET'
> > le16_encode_bits(FIELD_GET(IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK,
> 
> 
> How about fixing the root cause
> in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
> 
> 
> #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL
> 
> 
> enum iwl_rx_he_phy looks really strange.

Why? I don't think this is a problem, the enum is used here to get
constants so that we can also have documentation for them. That's a
common and accepted technique.


> Passing enum to FIELD_GET is odd,
> so I prefer keeping this warned.

What for?

I think we should go with Arend's patch, and I hope Andrew will pick it
up, but otherwise I guess we can also put it through any other tree.

johannes

Re: [PATCH] mmc: Move the mmc driver init earlier

[Feng Tang]

Hi Greg,

Thanks for the prompt review.

On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote:
> > Hi Greg,
> > 
> > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> > > > Hi Greg, Ulf
> > > > 
> > > > Could you help to review this? many thanks!
> > > 
> > > Review what?  I see no patch here.  And why would I need to review a mmc
> > > patch in the middle of the merge window?
> > > 
> > > totally confused,
> > 
> > Sorry for the confusion! I didn't noticed the 4.19 merge window.
> > 
> > The patch was originally posted in June, and has gone through some
> > review discussions with mmc maintainers, my last mail was trying
> > to keep some discussion info.
> 
> Ok, then why ask me?  I'm not the mmc maintainer.

The reason is this patch not only touches the mmc, but also affects many other
subsystems in drivers/ as the init order is changed. And the get_maintainer.pl
shows you are the first suggested reviewer for changes to drivers/Makefile :)

> 
> > The original patch is:
> > -
> > 
> > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001
> > From: Feng Tang 
> > Date: Fri, 8 Jun 2018 17:10:30 +0800
> > Subject: [PATCH] mmc: Move the mmc driver init earlier
> > 
> > When doing some boot time optimization for an eMMC rootfs NUCs,
> > we found the rootfs may spend around 100 microseconds waiting
> > for eMMC card to be initialized, then the rootfs could be
> > mounted.
> > [1.216561] Waiting for root device /dev/mmcblk1p1...
> > [1.289262] mmc1: new HS400 MMC card at address 0001
> > [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
> > [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB
> > [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB
> > [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB
> > [1.292798]  mmcblk1: p1 p2 p3
> > [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to 
> > feature incompatibilities
> > [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to 
> > feature incompatibilities
> > 
> > And this is a common problem for smartphones, tablets, embedded
> > devices and automotive products. This patch will make the eMMC/SD
> > card  start initializing earlier, by changing its order in drivers/Makefile.
> > 
> > On our platform, the waiting for eMMC card is almost eliminated with the 
> > patch,
> > which is critical to boot time. And it should benefit other non-x86 
> > platforms
> > which see the similar waiting for emmc rootfs.
> > 
> > Signed-off-by: Feng Tang 
> > ---
> >  drivers/Makefile | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 24cd47014657..c473afd3c688 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR)   += regulator/
> >  # reset controllers early, since gpu drivers might rely on them to 
> > initialize
> >  obj-$(CONFIG_RESET_CONTROLLER) += reset/
> >  
> > +# put mmc early as many morden devices use emm/sd card as rootfs storage
> 
> Spelling error :)

Will change it.

> 
> > +obj-y  += mmc/
> > +
> >  # tty/ comes before char/ so that the VT console is the boot-time
> >  # default.
> >  obj-y  += tty/
> 
> Everyone wants to be first.  Watch out if you try to put stuff before
> tty, you have to be very careful.  There are sd serial devices, right?

As the eMMC/SD card initialization takes quite some time, the SDHCI
host controller's module init function will quickly return, while leaving 
a worker to do the real card detection/initialization, so other subsystems
should not be blocked.

And yes, it is safer to move it after tty/

> 
> Anyway, nothing we can do now until after 4.19-rc1 is out.

Understood, will send v2 after the merge window. Thanks again.

- Feng

Re: [PATCH v2] ASoC: wm9712: fix replace codec to component

[Charles Keepax]

On Tue, Aug 14, 2018 at 12:35:56AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
> "wm9712-codec" got renamed to "wm9712-component", however, this change
> never got propagated down to the actual board/platform drivers. E.g. on
> Colibri T20 this lead to the following spew upon boot with sound/touch
> being broken:
> 
> [2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not 
> registered
> [2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not 
> registered
> [2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not 
> registered
> [2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not 
> registered
> [3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not 
> registered
> [3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [   14.970443] ALSA device list:
> [   14.996628]   No soundcards found.
> 
> This commit finally fixes this again.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---

Acked-by: Charles Keepax 

Thanks,
Charles

linux-next: Tree for Aug 14

[Stephen Rothwell]

Hi all,

Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.

Changes since 20180813:

Non-merge commits (relative to Linus' tree): 12053
 10771 files changed, 512108 insertions(+), 210583 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 286 trees (counting Linus' and 65 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 (94710cac0ef4 Linux 4.18)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5)
Merging arc-current/for-curr (7945121f56a2 ARC: [plat-axs*]: Enable SWAP)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (c7513c2a2714 crypto/arm64: aes-ce-gcm - add 
missing kernel_neon_begin/end pair)
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (ec0c96714e7d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging bpf/master (9c9542011739 Merge branch 'bpf-fix-cpu-and-devmap-teardown')
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (16e98cec49a4 ipvs: don't show negative times in 
ip_vs_conn)
Merging ipvs/master (16e98cec49a4 ipvs: don't show negative times in ip_vs_conn)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (e31f6456c01c cfg80211: never ignore user regulatory 
hint)
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (f5b6c1fcb42f Merge tag 'asoc-v4.19' of 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging sound-asoc-fixes/for-linus (6c0848398776 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (1ffaddd029c8 Linux 4.18-rc8)
Merging regulator-fixes/for-linus (a8afa92ec0d9 Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (c3c7126248a0 Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (acb1872577b3 Linux 4.18-rc7)
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (acb1872577b3 Linux 4.18-rc7)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.18-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
status lines)
Merging staging.current/staging-linus (acb1872577b3 Linux 4.18-rc7)
Merging char-misc.current/char-misc-linus (3d27c4de8d4f Revert "uio: use 
request_thread

[PATCH 2/2] bcache: add undef for macro in function

[Dongbo Cao]

add undef for macro d_strtoul,d_strtoul_nonzero and d_strtoi_h

Signed-off-by: Dongbo Cao 
---
 drivers/md/bcache/sysfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 225b15aa..ed67a290 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -349,6 +349,9 @@ STORE(__cached_dev)
if (attr == &sysfs_stop)
bcache_device_stop(&dc->disk);
 
+#undef d_strtoul
+#undef d_strtoul_nonzero
+#undef d_strtoi_h
return size;
 }
 
-- 
2.17.1

Re: [PATCH 1/3] arm64: implement ftrace with regs

[Julien Thierry]

On 14/08/18 03:03, Steven Rostedt wrote:

On Mon, 13 Aug 2018 11:54:06 +0100
Julien Thierry  wrote:


--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -78,6 +78,15 @@ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
   KBUILD_LDFLAGS_MODULE+= -T $(srctree)/arch/arm64/kernel/module.lds
   endif
   
+ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS

+  CC_FLAGS_FTRACE := -fpatchable-function-entry=2
+  KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
+  ifeq ($(call cc-option,-fpatchable-function-entry=2),)
+$(warning Cannot use CONFIG_DYNAMIC_FTRACE_WITH_REGS: \
+ -fpatchable-function-entry not supported by compiler)


Shouldn't this be an error? The option -fpatchable-function-entry has
been added to the CC_FLAGS_FTRACE, so any call to the compiler is gonna
break anyway. Or am I missing something?


I'm guessing this adds a more informative message on that error. One
will know why -fpatchable-function-entry was added to the CFLAGS. I'm
for more informative error messages being a victim of poor error
messages causing me to dig deep into the guts of the build
infrastructure to figure out simple issues.



Yes, I agree it is better to have this message. My point was that we 
could have "$error" instead of "$warning" to stop the compilation right 
away since we know everything is gonna break (and on parallel builds 
this warning is gonna be drowned in compiler errors).


--
Julien Thierry

Re: [PATCH] mmc: Move the mmc driver init earlier

[Greg Kroah-Hartman]

On Tue, Aug 14, 2018 at 04:08:51PM +0800, Feng Tang wrote:
> Hi Greg,
> 
> Thanks for the prompt review.
> 
> On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote:
> > > Hi Greg,
> > > 
> > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> > > > > Hi Greg, Ulf
> > > > > 
> > > > > Could you help to review this? many thanks!
> > > > 
> > > > Review what?  I see no patch here.  And why would I need to review a mmc
> > > > patch in the middle of the merge window?
> > > > 
> > > > totally confused,
> > > 
> > > Sorry for the confusion! I didn't noticed the 4.19 merge window.
> > > 
> > > The patch was originally posted in June, and has gone through some
> > > review discussions with mmc maintainers, my last mail was trying
> > > to keep some discussion info.
> > 
> > Ok, then why ask me?  I'm not the mmc maintainer.
> 
> The reason is this patch not only touches the mmc, but also affects many other
> subsystems in drivers/ as the init order is changed. And the get_maintainer.pl
> shows you are the first suggested reviewer for changes to drivers/Makefile :)

Fair enough, but then I could not make that change without the mmc
maintainer agreeing with it.

> 
> > 
> > > The original patch is:
> > > -
> > > 
> > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001
> > > From: Feng Tang 
> > > Date: Fri, 8 Jun 2018 17:10:30 +0800
> > > Subject: [PATCH] mmc: Move the mmc driver init earlier
> > > 
> > > When doing some boot time optimization for an eMMC rootfs NUCs,
> > > we found the rootfs may spend around 100 microseconds waiting
> > > for eMMC card to be initialized, then the rootfs could be
> > > mounted.
> > >   [1.216561] Waiting for root device /dev/mmcblk1p1...
> > >   [1.289262] mmc1: new HS400 MMC card at address 0001
> > >   [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
> > >   [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB
> > >   [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB
> > >   [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB
> > >   [1.292798]  mmcblk1: p1 p2 p3
> > >   [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to 
> > > feature incompatibilities
> > >   [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to 
> > > feature incompatibilities
> > > 
> > > And this is a common problem for smartphones, tablets, embedded
> > > devices and automotive products. This patch will make the eMMC/SD
> > > card  start initializing earlier, by changing its order in 
> > > drivers/Makefile.
> > > 
> > > On our platform, the waiting for eMMC card is almost eliminated with the 
> > > patch,
> > > which is critical to boot time. And it should benefit other non-x86 
> > > platforms
> > > which see the similar waiting for emmc rootfs.
> > > 
> > > Signed-off-by: Feng Tang 
> > > ---
> > >  drivers/Makefile | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/Makefile b/drivers/Makefile
> > > index 24cd47014657..c473afd3c688 100644
> > > --- a/drivers/Makefile
> > > +++ b/drivers/Makefile
> > > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR) += regulator/
> > >  # reset controllers early, since gpu drivers might rely on them to 
> > > initialize
> > >  obj-$(CONFIG_RESET_CONTROLLER)   += reset/
> > >  
> > > +# put mmc early as many morden devices use emm/sd card as rootfs storage
> > 
> > Spelling error :)
> 
> Will change it.
> 
> > 
> > > +obj-y+= mmc/
> > > +
> > >  # tty/ comes before char/ so that the VT console is the boot-time
> > >  # default.
> > >  obj-y+= tty/
> > 
> > Everyone wants to be first.  Watch out if you try to put stuff before
> > tty, you have to be very careful.  There are sd serial devices, right?
> 
> As the eMMC/SD card initialization takes quite some time, the SDHCI
> host controller's module init function will quickly return, while leaving 
> a worker to do the real card detection/initialization, so other subsystems
> should not be blocked.
> 
> And yes, it is safer to move it after tty/

Again, everyone wants to be first, saving 100ms is great, but make sure
this will not break anything else.  It's a huge change to a
long-standing "we know this works" linker order.  Personally, I would
not want to accept this patch for that reason alone.

Also given you ignored the comment for the tty line doesn't make me feel
comfortable either.

If you really really need this, I would suggest just doing it in your
device-specific tree for a few years and when this is the only
out-of-tree patch you are carrying, then revisit it :)

thanks,

greg k-h

Re: [PATCH] bluetooth: hci_h5: avoid unused variable warnings

[Arnd Bergmann]

On Tue, Aug 14, 2018 at 9:22 AM Hans de Goede  wrote:
>
> Hi Arnd,
>
> On 14-08-18 00:04, Arnd Bergmann wrote:
> > When CONFIG_BT_HCIUART_RTL is disabled, the hci_h5 driver produces a build
> > warning because of an incorrect set of #ifdef guards:
> >
> > drivers/bluetooth/hci_h5.c:920:22: error: 'rtl_vnd' defined but not used 
> > [-Werror=unused-variable]
> >
> > Replacing the #ifdef with an IS_ENABLED() check shuts up the error
> > and simplifies the logic.
> >
> > Signed-off-by: Arnd Bergmann 
>
> Hmm, so now you're counting on dead code elimination to remove
> references to unavailable symbols.

Generally depending on dead code elimination is very reliable, as this
is easy for gcc to get right. However, you are right that this is actually
an exception since the MODULE_DEVICE_TABLE() entry will keep
a reference around that prevents the compiler from eliminating it.

> I'm not sure I like this and
> since Marcel has also indicated the does not like this fix I
> believe we need another fix.
>
> I will write another fix for this.
>

Ok, thanks!

  Arnd

Re: [PATCH v9 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Cornelia Huck]

On Mon, 13 Aug 2018 17:48:01 -0400
Tony Krowiak  wrote:

> From: Harald Freudenberger 
> 
> Move all the inline functions from the ap bus header
> file ap_asm.h into the in-kernel api header file
> arch/s390/include/asm/ap.h so that KVM can make use
> of all the low level AP functions.
> 
> Signed-off-by: Harald Freudenberger 
> Signed-off-by: Christian Borntraeger 
> Signed-off-by: Tony Krowiak 
> ---
>  arch/s390/include/asm/ap.h |  284 
> 
>  drivers/s390/crypto/ap_bus.c   |   23 +---
>  drivers/s390/crypto/ap_bus.h   |1 +
>  drivers/s390/crypto/ap_card.c  |1 -
>  drivers/s390/crypto/ap_queue.c |1 -
>  5 files changed, 260 insertions(+), 50 deletions(-)
> 
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index c1bedb4..887494a 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -47,6 +47,50 @@ struct ap_queue_status {
>  };
>  
>  /**
> + * ap_intructions_available() - Test if AP instructions are available.
> + *
> + * Returns 1 if the AP instructions are installed, otherwise 0.
> + */
> +static inline int ap_instructions_available(void)
> +{
> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> + register unsigned long reg1 asm ("1") = 0;
> + register unsigned long reg2 asm ("2") = 0;
> +
> + asm volatile(
> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> + "0: la%0,1\n"
> + "1:\n"
> + EX_TABLE(0b, 1b)
> + : "+d" (reg1), "+d" (reg2)
> + : "d" (reg0)
> + : "cc");
> + return reg1;
> +}

I think upstream this change (have this function return !0 when the
instructions are installed) will be an addon patch to the one which has
already made its way into master. Not really relevant for the remainder
of this patch series, though.

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[Arnd Bergmann]

On Tue, Aug 14, 2018 at 9:57 AM Johannes Berg  wrote:
> On Tue, 2018-08-14 at 08:57 +0900, Masahiro Yamada wrote:
> > 2018-08-14 7:09 GMT+09:00 Arnd Bergmann :

> > > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1025:21: note: in expansion 
> > > of macro 'FIELD_GET'
> > > le16_encode_bits(FIELD_GET(IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK,
> >
> >
> > How about fixing the root cause
> > in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
> >
> >
> > #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL
> >
> >
> > enum iwl_rx_he_phy looks really strange.
>
> Why? I don't think this is a problem, the enum is used here to get
> constants so that we can also have documentation for them. That's a
> common and accepted technique.

I think using #define is more common overall, but I also prefer using enum
for this in my own code.

   Arnd

[PATCH] perf auxtrace: Fix queue resize

[Adrian Hunter]

When the number of queues grows beyond 32, the array of queues is resized
but not all members were being copied. Fix by also copying 'tid', 'cpu' and
'set'.

Fixes: e502789302a6e ("perf auxtrace: Add helpers for queuing AUX area tracing 
data")
Cc: sta...@vger.kernel.org
Signed-off-by: Adrian Hunter 
---
 tools/perf/util/auxtrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index ae8c37b219c9..db1511359c5e 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -203,6 +203,9 @@ static int auxtrace_queues__grow(struct auxtrace_queues 
*queues,
for (i = 0; i < queues->nr_queues; i++) {
list_splice_tail(&queues->queue_array[i].head,
 &queue_array[i].head);
+   queue_array[i].tid = queues->queue_array[i].tid;
+   queue_array[i].cpu = queues->queue_array[i].cpu;
+   queue_array[i].set = queues->queue_array[i].set;
queue_array[i].priv = queues->queue_array[i].priv;
}
 
-- 
2.17.1

Re: [PATCH] mm: migration: fix migration of huge PMD shared pages

[Kirill A. Shutemov]

On Mon, Aug 13, 2018 at 11:21:41PM +, Mike Kravetz wrote:
> On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote:
> > On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote:
> >> The page migration code employs try_to_unmap() to try and unmap the
> >> source page.  This is accomplished by using rmap_walk to find all
> >> vmas where the page is mapped.  This search stops when page mapcount
> >> is zero.  For shared PMD huge pages, the page map count is always 1
> >> not matter the number of mappings.  Shared mappings are tracked via
> >> the reference count of the PMD page.  Therefore, try_to_unmap stops
> >> prematurely and does not completely unmap all mappings of the source
> >> page.
> >>
> >> This problem can result is data corruption as writes to the original
> >> source page can happen after contents of the page are copied to the
> >> target page.  Hence, data is lost.
> >>
> >> This problem was originally seen as DB corruption of shared global
> >> areas after a huge page was soft offlined.  DB developers noticed
> >> they could reproduce the issue by (hotplug) offlining memory used
> >> to back huge pages.  A simple testcase can reproduce the problem by
> >> creating a shared PMD mapping (note that this must be at least
> >> PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
> >> migrate_pages() to migrate process pages between nodes.
> >>
> >> To fix, have the try_to_unmap_one routine check for huge PMD sharing
> >> by calling huge_pmd_unshare for hugetlbfs huge pages.  If it is a
> >> shared mapping it will be 'unshared' which removes the page table
> >> entry and drops reference on PMD page.  After this, flush caches and
> >> TLB.
> >>
> >> Signed-off-by: Mike Kravetz 
> >> ---
> >> I am not %100 sure on the required flushing, so suggestions would be
> >> appreciated.  This also should go to stable.  It has been around for
> >> a long time so still looking for an appropriate 'fixes:'.
> > 
> > I believe we need flushing. And huge_pmd_unshare() usage in
> > __unmap_hugepage_range() looks suspicious: I don't see how we flush TLB in
> > that case.
> 
> Thanks Kirill,
> 
> __unmap_hugepage_range() has two callers:
> 1) unmap_hugepage_range, which wraps the call with tlb_gather_mmu and
>tlb_finish_mmu on the range.  IIUC, this should cause an appropriate
>TLB flush.
> 2) __unmap_hugepage_range_final via unmap_single_vma.  unmap_single_vma
>   has three callers:
>   - unmap_vmas which assumes the caller will flush the whole range after
> return.
>   - zap_page_range wraps the call with tlb_gather_mmu/tlb_finish_mmu
>   - zap_page_range_single wraps the call with tlb_gather_mmu/tlb_finish_mmu
> 
> So, it appears we are covered.  But, I could be missing something.

My problem here is that the mapping that moved by huge_pmd_unshare() in
not accounted into mmu_gather and can be missed on tlb_finish_mmu().

-- 
 Kirill A. Shutemov

Re: [PATCH v9 05/22] KVM: s390: vsie: simulate VCPU SIE entry/exit

[Cornelia Huck]

On Mon, 13 Aug 2018 17:48:02 -0400
Tony Krowiak  wrote:

> From: David Hildenbrand 
> 
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
> 
> So let's simulate a SIE entry when entering the vSIE loop and check
> for PROG_ flags. The existing infrastructure (e.g. exit_sie()) will then
> detect that the SIE (in form of the vSIE execution loop) is running and
> properly kick the vSIE CPU, resulting in it leaving the vSIE loop and
> therefore the vSIE interception handler, allowing it to handle VCPU
> requests.
> 
> E.g. if we want to modify the crycb of the VCPU and make sure that any
> masks also get applied to the VSIE crycb shadow (which uses masks from the
> VCPU crycb), we will need a way to hinder the vSIE from running and make
> sure to process the updated crycb before reentering the vSIE again.
> 
> Signed-off-by: David Hildenbrand 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Pierre Morel 
> ---
>  arch/s390/kvm/kvm-s390.c |9 -
>  arch/s390/kvm/kvm-s390.h |1 +
>  arch/s390/kvm/vsie.c |   20 ++--
>  3 files changed, 27 insertions(+), 3 deletions(-)

I think that is the RFC version of David's patch, not the v1? Again,
not really relevant for reviewing, but I hope that you test the final
version.

Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

> +static int delayed_uprobe_install(struct vm_area_struct *vma)
> +{
> + struct list_head *pos, *q;
> + struct delayed_uprobe *du;
> + unsigned long vaddr;
> + int ret = 0, err = 0;
> +
> + mutex_lock(&delayed_uprobe_lock);
> + list_for_each_safe(pos, q, &delayed_uprobe_list) {
> + du = list_entry(pos, struct delayed_uprobe, list);
> +
> + if (!valid_ref_ctr_vma(du->uprobe, vma))
> + continue;

I think we should compare mm here. I.e.:

if (du->mm != vma->vm_mm || !valid_ref_ctr_vma(du->uprobe, vma))
continue;

Otherwise things can mess up.

> +
> + vaddr = offset_to_vaddr(vma, du->uprobe->ref_ctr_offset);
> + ret = __update_ref_ctr(vma->vm_mm, vaddr, 1);
> + /* Record an error and continue. */
> + if (ret && !err)
> + err = ret;
> + delayed_uprobe_delete(du);
> + }
> + mutex_unlock(&delayed_uprobe_lock);
> + return err;
> +}

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[dkota]

On 2018-08-10 22:16, Mark Brown wrote:

On Fri, Aug 10, 2018 at 09:59:46PM +0530, dk...@codeaurora.org wrote:

Now the need is, how to communicate the SPI controller maximum 
frequency to

SPI core framework?
Is it by DTSI entry or hardcoding in the SPI controller driver?


If you've got a limit that exists in the IP the hard code it in the
driver.


My stand is for providing the DTSI entry.
Why because, this keeps SPI controller driver generic across the 
boards and

portable.
Also it is not against to Device tree usage because maximum frequency
is describing the property of the hardware.


If the limit the controller has is not coming from the clock tree then
presumably it's a physical limitation of the silicon and isn't going to
vary per board.  If the limit is coming from the board then it should 
be

specified per slave since different slaves may have different
requirements on different boards.


Agree with you guys, will hard code the controller maximum frequency in 
the driver.

I will address this change in the next patchset.


Could you all please comment on the other points too:


Do you mean spi-rx-delay-us and spi-tx-delay-us properties? Those are
documented but don't seem to be used. There's also the delay_usecs
part
of the spi_transfer structure, which may be what you're talking
about.


delay_usecs is for inter-transfer delays within a message rather than
after the initial chip select assert (it can be used to keep chip
select
asserted for longer after the final transfer too).  Obviously this is
also something that shouldn't be configured in a driver specific
fashion.



Hmmm ok, so you mean don't send these as controller_data, rather add
new
members to the spi_device struct ?


spi_cs_clk_delay -> Adds Delay from CS line toggle to Clock line toggle
spi_inter_words_delay -> Adds inter-word delay for each transfer.

Could you please provide more information on accommodating these
parameters in SPI core structures like spi_device or spi_transfer? Why 
because these are very

specific to Qualcomm SPI GENI controller.

If we define them in spi core framework structures, SPI Slave driver 
will program and expect it in the SPI transfers.



+   mas->cur_speed_hz = spi_slv->max_speed_hz;


Why can't you use clk_get_rate() instead? Or call clk_set_rate() with
the rate you want the master clk to run at and then divide that down
from there?



> Not sure I follow, the intention is to run the controller clock based on
> the slave's max frequency.



That's good. The problem I see is that we have to specify the max
frequency in the controller/bus node, and also in the child/slave
node.
It should only need to be specified in the slave node, so making the
cur_speed_hz equal the max_speed_hz is problematic. The current speed
of
the master should be determined by calling clk_get_rate().


We don't require that the slaves all individually set a speed since it
gets a bit redundant, it should be enough to just use the default the
controller provides.  A bigger problem with this is that the driver
will
never see a transfer which doesn't explicitly have a speed set as the
core will ensure something is set, open coding this logic in every
driver would obviously be tiresome.


clock_get_rate() will returns the rate which got set as per the clock 
plan(which was the rounded up frequency) which can be less than or equal 
to the requested frequency. For that reason using the cur_speed_hz to 
store the requested frequency and skip clock configuration for the 
consecutive transfers with same frequency.



--Dilip

Re: [PATCH] arm64: lib: use c string functions for KASAN support

[Andrey Ryabinin]

On 08/14/2018 10:55 AM, Kyeongdon Kim wrote:
> Assembly optimized string functions cannot detect KASan bug.
> This might have been the intention of the original author.
> (not too much important to catch)
> 
> But, I found the obvious uaf problem in strcmp() function.
>  - in this case, using 32bit KASan patchset helps
> 
> Since I used c string function, I believe I could find this bug.
> After using the patch, can see the report & backtrace the below:
> 
..
> 
> Signed-off-by: Kyeongdon Kim 
> ---
>  arch/arm64/include/asm/string.h | 2 ++
>  arch/arm64/kernel/arm64ksyms.c  | 2 ++
>  arch/arm64/lib/Makefile | 8 +---
>  3 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
> index dd95d33..5c5219a 100644
> --- a/arch/arm64/include/asm/string.h
> +++ b/arch/arm64/include/asm/string.h
> @@ -16,6 +16,7 @@
>  #ifndef __ASM_STRING_H
>  #define __ASM_STRING_H
>  
> +#if !defined(CONFIG_KASAN)
>  #define __HAVE_ARCH_STRRCHR
>  extern char *strrchr(const char *, int c);
>  
> @@ -33,6 +34,7 @@ extern __kernel_size_t strlen(const char *);
>  
>  #define __HAVE_ARCH_STRNLEN
>  extern __kernel_size_t strnlen(const char *, __kernel_size_t);
> +#endif
>  
>  #define __HAVE_ARCH_MEMCPY
>  extern void *memcpy(void *, const void *, __kernel_size_t);
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index d894a20..eb9bf20 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -44,12 +44,14 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>  EXPORT_SYMBOL(memstart_addr);
>  
>   /* string / mem functions */
> +#if !defined(CONFIG_KASAN)
>  EXPORT_SYMBOL(strchr);
>  EXPORT_SYMBOL(strrchr);
>  EXPORT_SYMBOL(strcmp);
>  EXPORT_SYMBOL(strncmp);
>  EXPORT_SYMBOL(strlen);
>  EXPORT_SYMBOL(strnlen);
> +#endif
>  EXPORT_SYMBOL(memset);
>  EXPORT_SYMBOL(memcpy);
>  EXPORT_SYMBOL(memmove);
> diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
> index 68755fd..aa2d457 100644
> --- a/arch/arm64/lib/Makefile
> +++ b/arch/arm64/lib/Makefile
> @@ -2,9 +2,11 @@
>  lib-y:= clear_user.o delay.o copy_from_user.o
> \
>  copy_to_user.o copy_in_user.o copy_page.o\
>  clear_page.o memchr.o memcpy.o memmove.o memset.o\
> -memcmp.o strcmp.o strncmp.o strlen.o strnlen.o   \
> -strchr.o strrchr.o tishift.o
> -
> +memcmp.o tishift.o
> +ifndef CONFIG_KASAN
> +lib-y:= strcmp.o strncmp.o strlen.o strnlen.o\
> +strchr.o strrchr.o
> +endif

I think, this won't even compile. EFI needs some of these functions, and it 
can't use
instrumented and not position independent variants.

The easiest solution I see, is to not exclude these sting functions, but 
declare them as weak.
In that case, EFI stub should pick up assembly variant and the kernel will use 
the C one.

[PATCH v2] clk: tegra: probe deferral error reporting

[Marcel Ziswiler]

From: Marcel Ziswiler 

Actually report the error code from devm_regulator_get() which may as
well just be a probe deferral.

Signed-off-by: Marcel Ziswiler 

---

Changes in v2:
- Silence probe deferral as discussed between Peter, Stefan and Stephen.
- Fix line over 80 characters as reported by checkpatch.

 drivers/clk/tegra/clk-dfll.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 48ee43734e05..ebb0e1b6bf01 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -1609,8 +1609,12 @@ int tegra_dfll_register(struct platform_device *pdev,
 
td->vdd_reg = devm_regulator_get(td->dev, "vdd-cpu");
if (IS_ERR(td->vdd_reg)) {
-   dev_err(td->dev, "couldn't get vdd_cpu regulator\n");
-   return PTR_ERR(td->vdd_reg);
+   ret = PTR_ERR(td->vdd_reg);
+   if (ret != -EPROBE_DEFER)
+   dev_err(td->dev, "couldn't get vdd_cpu regulator: %d\n",
+   ret);
+
+   return ret;
}
 
td->dvco_rst = devm_reset_control_get(td->dev, "dvco");
-- 
2.14.4

[PATCH 1/2] x86: apm: mark proc_apm_show as __maybe_unused

[Arnd Bergmann]

A new build error appeared with CONFIG_PROC_FS disabled:

arch/x86/kernel/apm_32.c:1643:12: error: 'proc_apm_show' defined but not used 
[-Werror=unused-function]

This marks the function as __maybe_unused to let the compiler drop
it silently.

Fixes: 3f3942aca6da ("proc: introduce proc_create_single{,_data}")
Signed-off-by: Arnd Bergmann 
---
 arch/x86/kernel/apm_32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index ec00d1ff5098..79b5ed518471 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -1640,7 +1640,7 @@ static int do_open(struct inode *inode, struct file *filp)
return 0;
 }
 
-static int proc_apm_show(struct seq_file *m, void *v)
+static int __maybe_unused proc_apm_show(struct seq_file *m, void *v)
 {
unsigned short  bx;
unsigned short  cx;
-- 
2.18.0

[PATCH 2/2] ARM: rpc: mark ecard_devices_proc_show as __maybe_unused

[Arnd Bergmann]

A new build error appeared with CONFIG_PROC_FS disabled:

arch/arm/mach-rpc/ecard.c:646:12: error: 'ecard_devices_proc_show' defined but 
not used [-Werror=unused-function]

This marks the function as __maybe_unused to let the compiler drop
it silently.

Fixes: 3f3942aca6da ("proc: introduce proc_create_single{,_data}")
Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-rpc/ecard.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index 6fb51d49ad26..761a629f9e9d 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -643,7 +643,7 @@ static int ecard_prints(struct seq_file *m, ecard_t *ec)
return 0;
 }
 
-static int ecard_devices_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused ecard_devices_proc_show(struct seq_file *m, void *v)
 {
ecard_t *ec = cards;
 
-- 
2.18.0

Re: [PATCH v5 2/2] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec

[Johan Hovold]

On Wed, Jul 25, 2018 at 11:21:22AM +0530, Keerthy wrote:
> Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
> over try again.
> 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v5:
> 
>   * Added an additional check to see if ALARM2 status is not set
> before retrying.
>   * Cleaned up comments
>   * Also reduced mdelay to 1S lesser as per this commit
> 
>  drivers/rtc/rtc-omap.c | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 44ff4cc..caa6da6 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -421,12 +421,6 @@ static int omap_rtc_set_alarm(struct device *dev, struct 
> rtc_wkalrm *alm)
>   * The RTC can be used to control an external PMIC via the pmic_power_en pin,
>   * which can be configured to transition to OFF on ALARM2 events.
>   *
> - * Notes:
> - * The two-second alarm offset is the shortest offset possible as the alarm
> - * registers must be set before the next timer update and the offset
> - * calculation is too heavy for everything to be done within a single access
> - * period (~15 us).
> - *
>   * Called with local interrupts disabled.
>   */
>  static void omap_rtc_power_off(void)
> @@ -435,17 +429,20 @@ static void omap_rtc_power_off(void)
>   struct rtc_time tm;
>   unsigned long now;
>   u32 val;
> + int seconds;

Nit: I'd place this above val to maintain the reverse xmas-tree style.

>  
>   rtc->type->unlock(rtc);
>   /* enable pmic_power_en control */
>   val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
>   rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
>  
> - /* set alarm two seconds from now */
> +again:
> + /* set alarm one second from now */
>   omap_rtc_read_time_raw(rtc, &tm);
> + seconds = tm.tm_sec;
>   bcd2tm(&tm);
>   rtc_tm_to_time(&tm, &now);
> - rtc_time_to_tm(now + 2, &tm);
> + rtc_time_to_tm(now + 1, &tm);
>  
>   if (tm2bcd(&tm) < 0) {
>   dev_err(&rtc->rtc->dev, "power off failed\n");
> @@ -470,14 +467,25 @@ static void omap_rtc_power_off(void)
>   val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>   rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>   val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> +
> + /*
> +  * first check if ALARM2 has fired, if not then check if
> +  * our calculations started right before the rollover, try again
> +  * in case of rollover
> +  */

This is unnecessarily verbose; I'd rephrase it as something like:

/* Retry in case roll over happened before alarm was armed. */

> + if (!(OMAP_RTC_STATUS_ALARM2 && rtc_read(omap_rtc_power_off_rtc,
> +  OMAP_RTC_STATUS_REG)) &&
> + seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
> + goto again;

And this is clearly broken. First, you use boolean && instead of the &
bit operation.

Second, you need to check the status register *after* checking for
roll-over, as I already mentioned.

Also, use the rtc pointer rather than omap_rtc_power_off_rtc, which will
allow for more readable code.

I also strongly suggest you split the conditional, and use val to store
the status register value, that is:

if (rtc_read(rtc, OMAP_RTC_SECONDS_REG) != seconds) {
val = rtc_read(rtc, OMAP_RTC_STATUS_REG);
if (!(val & OMAP_RTC_STATUS_ALARM2))
goto again;
}

> +
>   rtc->type->lock(rtc);
>  
>   /*
> -  * Wait for alarm to trigger (within two seconds) and external PMIC to
> +  * Wait for alarm to trigger (within one second) and external PMIC to
>* power off the system. Add a 500 ms margin for external latencies
>* (e.g. debounce circuits).
>*/
> - mdelay(2500);
> + mdelay(1500);
>  }
>  
>  static const struct rtc_class_ops omap_rtc_ops = {

Johan

Re: [PATCH RESEND RFC 2/4] drivers: pinctrl: qcom: add wakeup gpio map for sdm845

[Marc Zyngier]

On 13/08/18 20:41, Lina Iyer wrote:
> On Wed, Aug 01 2018 at 14:04 -0600, Lina Iyer wrote:
>> On Wed, Aug 01 2018 at 02:42 -0600, Marc Zyngier wrote:
>>> On Wed, 01 Aug 2018 03:00:19 +0100,
>>> Lina Iyer  wrote:

 Add GPIO to PDC pin map for the SDM845 SoC.

 Signed-off-by: Lina Iyer 
 ---
 drivers/pinctrl/qcom/pinctrl-sdm845.c | 76 +++
 1 file changed, 76 insertions(+)

 diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c 
 b/drivers/pinctrl/qcom/pinctrl-sdm845.c
 index 2ab7a8885757..e93660922dc2 100644
 --- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
 +++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
 @@ -1277,6 +1277,80 @@ static const struct msm_pingroup sdm845_groups[] = {
UFS_RESET(ufs_reset, 0x99f000),
 };

 +static struct msm_pinctrl_pdc_map sdm845_wakeup_gpios[] = {
>>>
>>> [huge array]
>>>
 +};
>>>
>>> Why isn't that array part of the DT? I'd expect other SoCs to
>>> eventually use a similar mechanism, no?
>>>
>> I agree and it should be.
>>
>> One place I am thinking is to add it to the DT definition of PDC
>> controller as a data argument -
>>
>>  tlmm: pinctrl@00{
>>  [...]
>>  interrupts-extended = <&pdc 30 IRQ_TYPE_LEVEL_HIGH 1>,
>> <&pdc 31 IRQ_TYPE_LEVEL_HIGH 3>,
>><&pdc 32 IRQ_TYPE_LEVEL_HIGH 5>,
>> ^
>> |--- Provide the GPIO
>> for the PDC pin here.
>>  };
>>
>>  pdc: interrupt-controller@b22 {
>>  compatible = "qcom,sdm845-pdc";
>>  reg = <0xb22 0x3>;
>>  qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
>>  #interrupt-cells = <3>; < Increase this from 2 ?
>>  interrupt-parent = <&intc>;
>>  interrupt-controller;
>>  };
>>
>> Would that be acceptable?
>>
> Any ideas on how to do this better?

I don't think adding an extra argument to the PDC interrupt specifier is
that great. I'd rather see some associated array in the PDC binding
mapping an interrupt to a pin on which special treatment must be applied.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v5 2/2] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec

[Johan Hovold]

On Wed, Jul 25, 2018 at 11:30:18AM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 25/07/2018 11:21:22+0530, Keerthy wrote:
> > Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
> > over try again.
> > 
> > Signed-off-by: Keerthy 

> >  static void omap_rtc_power_off(void)
> > @@ -435,17 +429,20 @@ static void omap_rtc_power_off(void)
> > struct rtc_time tm;
> > unsigned long now;
> > u32 val;
> > +   int seconds;
> >  
> > rtc->type->unlock(rtc);
> > /* enable pmic_power_en control */
> > val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
> > rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
> >  
> > -   /* set alarm two seconds from now */
> > +again:
> > +   /* set alarm one second from now */
> > omap_rtc_read_time_raw(rtc, &tm);
> > +   seconds = tm.tm_sec;
> > bcd2tm(&tm);
> > rtc_tm_to_time(&tm, &now);
> > -   rtc_time_to_tm(now + 2, &tm);
> > +   rtc_time_to_tm(now + 1, &tm);
> >  
> > if (tm2bcd(&tm) < 0) {
> > dev_err(&rtc->rtc->dev, "power off failed\n");
> > @@ -470,14 +467,25 @@ static void omap_rtc_power_off(void)
> > val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> > rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> > val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> > +
> > +   /*
> > +* first check if ALARM2 has fired, if not then check if
> > +* our calculations started right before the rollover, try again
> > +* in case of rollover
> > +*/
> > +   if (!(OMAP_RTC_STATUS_ALARM2 && rtc_read(omap_rtc_power_off_rtc,
> > +OMAP_RTC_STATUS_REG)) &&
> > +   seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
> > +   goto again;
> > +
> 
> Can you use a while loop instead of goto?

I think a goto is warranted here as it allows for more readable code
with less indentation. And the exception case it is used for is truly an
exception that a single retry would take care of.

Johan

Re: [PATCH v2 1/3] mm/memory-hotplug: Drop unused args from remove_memory_section

[David Hildenbrand]

On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> From: Oscar Salvador 
> 
> unregister_memory_section() calls remove_memory_section()
> with three arguments:
> 
> * node_id
> * section
> * phys_device
> 
> Neither node_id nor phys_device are used.
> Let us drop them from the function.
> 
> Signed-off-by: Oscar Salvador 
> ---
>  drivers/base/memory.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index c8a1cb0b6136..2c622a9a7490 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -752,8 +752,7 @@ unregister_memory(struct memory_block *memory)
>   device_unregister(&memory->dev);
>  }
>  
> -static int remove_memory_section(unsigned long node_id,
> -struct mem_section *section, int phys_device)
> +static int remove_memory_section(struct mem_section *section)
>  {
>   struct memory_block *mem;
>  
> @@ -785,7 +784,7 @@ int unregister_memory_section(struct mem_section *section)
>   if (!present_section(section))
>   return -EINVAL;
>  
> - return remove_memory_section(0, section, 0);
> + return remove_memory_section(section);
>  }
>  #endif /* CONFIG_MEMORY_HOTREMOVE */
>  
> 

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 2/3] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[David Hildenbrand]

On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> From: Oscar Salvador 
> 
> Before calling to unregister_mem_sect_under_nodes(),
> remove_memory_section() already checks if we got a valid
> memory_block.
> 
> No need to check that again in unregister_mem_sect_under_nodes().
> 
> Signed-off-by: Oscar Salvador 
> ---
>  drivers/base/node.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 1ac4c36e13bb..dd3bdab230b2 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -455,10 +455,6 @@ int unregister_mem_sect_under_nodes(struct memory_block 
> *mem_blk,
>   NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
>   unsigned long pfn, sect_start_pfn, sect_end_pfn;
>  
> - if (!mem_blk) {
> - NODEMASK_FREE(unlinked_nodes);
> - return -EFAULT;
> - }
>   if (!unlinked_nodes)
>   return -ENOMEM;
>   nodes_clear(*unlinked_nodes);
> 

While it is correct in current code, I wonder if this sanity check
should stay. I would completely agree if it would be a static function.

-- 

Thanks,

David / dhildenb

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[Masahiro Yamada]

2018-08-14 16:56 GMT+09:00 Johannes Berg :
> On Tue, 2018-08-14 at 08:57 +0900, Masahiro Yamada wrote:
>> 2018-08-14 7:09 GMT+09:00 Arnd Bergmann :
>> > Passing an enum into FIELD_GET() produces a long but harmless warning on
>> > newer compilers:
>> >
>> >  from include/linux/linkage.h:7,
>> >  from include/linux/kernel.h:7,
>> >  from include/linux/skbuff.h:17,
>> >  from include/linux/if_ether.h:23,
>> >  from include/linux/etherdevice.h:25,
>> >  from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:63:
>> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 
>> > 'iwl_mvm_rx_mpdu_mq':
>> > include/linux/bitfield.h:56:20: error: enum constant in boolean context 
>> > [-Werror=int-in-bool-context]
>> >BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero"); \
>> > ^
>> > ...
>> > include/linux/bitfield.h:103:3: note: in expansion of macro 
>> > '__BF_FIELD_CHECK'
>> >__BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
>> >^~~~
>> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1025:21: note: in expansion 
>> > of macro 'FIELD_GET'
>> > le16_encode_bits(FIELD_GET(IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK,
>>
>>
>> How about fixing the root cause
>> in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
>>
>>
>> #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL
>>
>>
>> enum iwl_rx_he_phy looks really strange.
>
> Why? I don't think this is a problem, the enum is used here to get
> constants so that we can also have documentation for them. That's a
> common and accepted technique.


I do not see any variable declared as 'enum iwl_rx_he_phy'.

This is not legitimate usage of enum.


The mask macros must have a particular value,
hence

#define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL

is a straightforward way.


>
>> Passing enum to FIELD_GET is odd,
>> so I prefer keeping this warned.
>
> What for?


If you pass enum to FIELD_GET,
it is very like to be _abuse_ of enum.




> I think we should go with Arend's patch, and I hope Andrew will pick it
> up, but otherwise I guess we can also put it through any other tree.
>
> johannes



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v5 2/2] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec

[Keerthy]

On Wednesday 25 July 2018 03:00 PM, Alexandre Belloni wrote:
> Hi,
> 
> On 25/07/2018 11:21:22+0530, Keerthy wrote:
>> Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
>> over try again.
>>
>> Signed-off-by: Keerthy 
>> ---
>>
>> Changes in v5:
>>
>>   * Added an additional check to see if ALARM2 status is not set
>> before retrying.
>>   * Cleaned up comments
>>   * Also reduced mdelay to 1S lesser as per this commit
>>
>>  drivers/rtc/rtc-omap.c | 28 ++--
>>  1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>> index 44ff4cc..caa6da6 100644
>> --- a/drivers/rtc/rtc-omap.c
>> +++ b/drivers/rtc/rtc-omap.c
>> @@ -421,12 +421,6 @@ static int omap_rtc_set_alarm(struct device *dev, 
>> struct rtc_wkalrm *alm)
>>   * The RTC can be used to control an external PMIC via the pmic_power_en 
>> pin,
>>   * which can be configured to transition to OFF on ALARM2 events.
>>   *
>> - * Notes:
>> - * The two-second alarm offset is the shortest offset possible as the alarm
>> - * registers must be set before the next timer update and the offset
>> - * calculation is too heavy for everything to be done within a single access
>> - * period (~15 us).
>> - *
>>   * Called with local interrupts disabled.
>>   */
>>  static void omap_rtc_power_off(void)
>> @@ -435,17 +429,20 @@ static void omap_rtc_power_off(void)
>>  struct rtc_time tm;
>>  unsigned long now;
>>  u32 val;
>> +int seconds;
>>  
>>  rtc->type->unlock(rtc);
>>  /* enable pmic_power_en control */
>>  val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
>>  rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
>>  
>> -/* set alarm two seconds from now */
>> +again:
>> +/* set alarm one second from now */
>>  omap_rtc_read_time_raw(rtc, &tm);
>> +seconds = tm.tm_sec;
>>  bcd2tm(&tm);
>>  rtc_tm_to_time(&tm, &now);
>> -rtc_time_to_tm(now + 2, &tm);
>> +rtc_time_to_tm(now + 1, &tm);
>>  
>>  if (tm2bcd(&tm) < 0) {
>>  dev_err(&rtc->rtc->dev, "power off failed\n");
>> @@ -470,14 +467,25 @@ static void omap_rtc_power_off(void)
>>  val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>>  rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>>  val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
>> +
>> +/*
>> + * first check if ALARM2 has fired, if not then check if
>> + * our calculations started right before the rollover, try again
>> + * in case of rollover
>> + */
>> +if (!(OMAP_RTC_STATUS_ALARM2 && rtc_read(omap_rtc_power_off_rtc,
>> + OMAP_RTC_STATUS_REG)) &&
>> +seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
>> +goto again;
>> +
> 
> Can you use a while loop instead of goto?

Apologies for the late reply. A one time retry should be able to take
care of the exception case.

> 
>>  rtc->type->lock(rtc);
>>  
>>  /*
>> - * Wait for alarm to trigger (within two seconds) and external PMIC to
>> + * Wait for alarm to trigger (within one second) and external PMIC to
>>   * power off the system. Add a 500 ms margin for external latencies
>>   * (e.g. debounce circuits).
>>   */
>> -mdelay(2500);
>> +mdelay(1500);
>>  }
>>  
>>  static const struct rtc_class_ops omap_rtc_ops = {
>> -- 
>> 1.9.1
>>
> 

Re: [PATCH v2 2/3] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[Oscar Salvador]

On Tue, Aug 14, 2018 at 11:30:51AM +0200, David Hildenbrand wrote:

> 
> While it is correct in current code, I wonder if this sanity check
> should stay. I would completely agree if it would be a static function.

Hi David,

Well, unregister_mem_sect_under_nodes() __only__ gets called from 
remove_memory_section().
But remove_memory_section() only calls unregister_mem_sect_under_nodes() IFF 
mem_blk
is not NULL:

static int remove_memory_section
{
...
mem = find_memory_block(section);
if (!mem)
goto out_unlock;

unregister_mem_sect_under_nodes(mem, __section_nr(section));
...
}

So, to me keeping the check is redundant, as we already check for it before 
calling in.

Thanks
-- 
Oscar Salvador
SUSE L3

Re: [PATCH v2 3/3] mm/memory_hotplug: Refactor unregister_mem_sect_under_nodes

[David Hildenbrand]

On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> From: Oscar Salvador 
> 
> unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
> in order to check whithin the loop which nodes have already been unlinked,
> so we do not repeat the operation on them.
> 
> NODEMASK_ALLOC calls kmalloc() if NODES_SHIFT > 8, otherwise
> it just declares a nodemask_t variable whithin the stack.
> 
> Since kamlloc() can fail, we actually check whether NODEMASK_ALLOC failed or
> not, and we return -ENOMEM accordingly.
> remove_memory_section() does not check for the return value though.
> 
> The problem with this is that if we return -ENOMEM, it means that
> unregister_mem_sect_under_nodes will not be able to remove the symlinks,
> but since we do not check the return value, we go ahead and we call 
> unregister_memory(),
> which will remove all the mem_blks directories.
> 
> This will leave us with dangled symlinks.
> 
> The easiest way to overcome this is to fallback by calling sysfs_remove_link()
> unconditionally in case NODEMASK_ALLOC failed.
> This means that we will call sysfs_remove_link on nodes that have been 
> already unlinked,
> but nothing wrong happens as sysfs_remove_link() backs off somewhere down the 
> chain in case
> the link has already been removed.
> 
> I think that this is better than
> 
> a) dangled symlinks
> b) having to recovery from such error in remove_memory_section
> 
> Since from now on we will not need to take care about return values, we can 
> make the function void.
> 
> While at it, we can also drop the node_online() check, as a node can only be
> offline if all the memory/cpus associated with it have been removed.

I would prefer splitting this change out into a separate patch.

> 
> As we have a safe fallback, one thing that could also be done is to add 
> __GFP_NORETRY
> in the flags when calling NODEMASK_ALLOC, so we do not retry.
> 
> Signed-off-by: Oscar Salvador 
> ---
>  drivers/base/node.c  | 26 +++---
>  include/linux/node.h |  5 ++---
>  2 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index dd3bdab230b2..0a3ca62687ea 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -449,35 +449,39 @@ int register_mem_sect_under_node(struct memory_block 
> *mem_blk, void *arg)
>  }
>  
>  /* unregister memory section under all nodes that it spans */
> -int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> +void unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
>   unsigned long phys_index)
>  {
>   NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
>   unsigned long pfn, sect_start_pfn, sect_end_pfn;
>  
> - if (!unlinked_nodes)
> - return -ENOMEM;
> - nodes_clear(*unlinked_nodes);
> + if (unlinked_nodes)
> + nodes_clear(*unlinked_nodes);
>  
>   sect_start_pfn = section_nr_to_pfn(phys_index);
>   sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
>   for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> - int nid;
> + int nid = get_nid_for_pfn(pfn);;
>  
> - nid = get_nid_for_pfn(pfn);
>   if (nid < 0)
>   continue;
> - if (!node_online(nid))
> - continue;
> - if (node_test_and_set(nid, *unlinked_nodes))
> + /*
> +  * It is possible that NODEMASK_ALLOC fails due to memory 
> pressure.
> +  * If that happens, we fallback to call sysfs_remove_link 
> unconditionally.
> +  * Nothing wrong will happen as sysfs_remove_link will back off
> +  * somewhere down the chain in case the link has already been 
> removed.
> +  */
> + if (unlinked_nodes && node_test_and_set(nid, *unlinked_nodes))
>   continue;
> +
>   sysfs_remove_link(&node_devices[nid]->dev.kobj,
>kobject_name(&mem_blk->dev.kobj));
>   sysfs_remove_link(&mem_blk->dev.kobj,
>kobject_name(&node_devices[nid]->dev.kobj));
>   }
> - NODEMASK_FREE(unlinked_nodes);
> - return 0;
> +
> + if (unlinked_nodes)
> + NODEMASK_FREE(unlinked_nodes);

NODEMASK_FEEE/kfree can deal with NULL pointers.

>  }
>  
>  int link_mem_sections(int nid, unsigned long start_pfn, unsigned long 
> end_pfn)
> diff --git a/include/linux/node.h b/include/linux/node.h
> index 257bb3d6d014..1203378e596a 100644
> --- a/include/linux/node.h
> +++ b/include/linux/node.h
> @@ -72,7 +72,7 @@ extern int register_cpu_under_node(unsigned int cpu, 
> unsigned int nid);
>  extern int unregister_cpu_under_node(unsigned int cpu, unsigned int nid);
>  extern int register_mem_sect_under_node(struct memory_block *mem_blk,
>   void *arg);
> -extern int unregister_mem_sect_under_nodes(struct m

Re: [PATCH RFC 1/3] cgroup: list all subsystem states in debugfs files

[Konstantin Khlebnikov]

On 13.08.2018 20:53, Roman Gushchin wrote:

On Mon, Aug 13, 2018 at 01:11:19PM -0400, Johannes Weiner wrote:

On Mon, Aug 13, 2018 at 06:48:42AM -0700, Tejun Heo wrote:

Hello, Konstantin.

On Mon, Aug 13, 2018 at 09:58:05AM +0300, Konstantin Khlebnikov wrote:

After removing cgroup subsystem state could leak or live in background
forever because it is pinned by some reference. For example memory cgroup
could be pinned by pages in cache or tmpfs.

This patch adds common debugfs interface for listing basic state for each
controller. Controller could define callback for dumping own attributes.

In file /sys/kernel/debug/cgroup/ each line shows state in
format: =... [-- =... ]


Seems pretty useful to me.  Roman, Johannes, what do you guys think?


Totally agree with the idea and was about to suggest something similar.


Generally I like the idea of having more introspection into offlined
cgroups, but I wonder if having only memory= and swap= could be a
little too terse to track down what exactly is pinning the groups.

Roman has more experience debugging these pileups, but it seems to me
that unless we add a breakdown off memory, and maybe make slabinfo
available for these groups, that in practice this might not provide
that much more insight than per-cgroup stat counters of dead children.


I agree here.


I don't think that we could cover all cases with single interface.

This debugfs just gives simple entry point for debugging:
- paths for guessing user
- pointers for looking with gdb via kcore
- inode numbers for page-types - see second and third patch

For slab: this could show one of remaining slab. Anyway each of them pins css.



It's hard to say in advance what numbers are useful, so let's export
these numbers, but also make the format more extendable, so we can
easily add new information later. Maybe, something like:

cgroup {
   path = ...
   ino = ...
   main css {
 refcnt = ...
 key = value
 ...
   }
   memcg css {
 refcnt = ...
 ...
   }
   some other controller css {
   }
   ...
}

Also, because we do batch charges, printing numbers without draining stocks
is not that useful. All stats are also per-cpu cached, what adds some
inaccuracy.


Seems too verbose. And one-line key=value format is more grep/awk friendly.

Anyway such extended debugging could be implemented as gdb plugin.
While simple list of pointers gives enough information for dumping structures
with gdb alone without extra plugins.



Thanks!

Re: [PATCH v2 2/3] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[David Hildenbrand]

On 14.08.2018 11:36, Oscar Salvador wrote:
> On Tue, Aug 14, 2018 at 11:30:51AM +0200, David Hildenbrand wrote:
> 
>>
>> While it is correct in current code, I wonder if this sanity check
>> should stay. I would completely agree if it would be a static function.
> 
> Hi David,
> 
> Well, unregister_mem_sect_under_nodes() __only__ gets called from 
> remove_memory_section().
> But remove_memory_section() only calls unregister_mem_sect_under_nodes() IFF 
> mem_blk
> is not NULL:
> 
> static int remove_memory_section
> {
>   ...
>   mem = find_memory_block(section);
>   if (!mem)
>   goto out_unlock;
> 
>   unregister_mem_sect_under_nodes(mem, __section_nr(section));
>   ...
> }

Yes I know, as I said, if it would be local to a file I would not care.
Making this functions never return an error is nice, though (and as you
noted, the return value is never checked).

I am a friend of stating which conditions a function expects to hold if
a function can be called from other parts of the system. Usually I
prefer to use BUG_ONs for that (whoever decides to call it can directly
see what he as to check before calling) or comments. But comments tend
to become obsolete.

> 
> So, to me keeping the check is redundant, as we already check for it before 
> calling in.
> 
> Thanks
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH] mmc: Move the mmc driver init earlier

[Feng Tang]

Hi Greg,

On Tue, Aug 14, 2018 at 10:42:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 14, 2018 at 04:08:51PM +0800, Feng Tang wrote:
> > Hi Greg,
> > 
> > Thanks for the prompt review.
> > 
> > On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote:
> > > > Hi Greg,
> > > > 
> > > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote:
> > > > > > Hi Greg, Ulf
> > > > > > 
> > > > > > Could you help to review this? many thanks!
> > > > > 
> > > > > Review what?  I see no patch here.  And why would I need to review a 
> > > > > mmc
> > > > > patch in the middle of the merge window?
> > > > > 
> > > > > totally confused,
> > > > 
> > > > Sorry for the confusion! I didn't noticed the 4.19 merge window.
> > > > 
> > > > The patch was originally posted in June, and has gone through some
> > > > review discussions with mmc maintainers, my last mail was trying
> > > > to keep some discussion info.
> > > 
> > > Ok, then why ask me?  I'm not the mmc maintainer.
> > 
> > The reason is this patch not only touches the mmc, but also affects many 
> > other
> > subsystems in drivers/ as the init order is changed. And the 
> > get_maintainer.pl
> > shows you are the first suggested reviewer for changes to drivers/Makefile 
> > :)
> 
> Fair enough, but then I could not make that change without the mmc
> maintainer agreeing with it.
> 
> > 
> > > 
> > > > The original patch is:
> > > > -
> > > > 
> > > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001
> > > > From: Feng Tang 
> > > > Date: Fri, 8 Jun 2018 17:10:30 +0800
> > > > Subject: [PATCH] mmc: Move the mmc driver init earlier
> > > > 
> > > > When doing some boot time optimization for an eMMC rootfs NUCs,
> > > > we found the rootfs may spend around 100 microseconds waiting
> > > > for eMMC card to be initialized, then the rootfs could be
> > > > mounted.
> > > > [1.216561] Waiting for root device /dev/mmcblk1p1...
> > > > [1.289262] mmc1: new HS400 MMC card at address 0001
> > > > [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
> > > > [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 
> > > > MiB
> > > > [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 
> > > > MiB
> > > > [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 
> > > > MiB
> > > > [1.292798]  mmcblk1: p1 p2 p3
> > > > [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due 
> > > > to feature incompatibilities
> > > > [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due 
> > > > to feature incompatibilities
> > > > 
> > > > And this is a common problem for smartphones, tablets, embedded
> > > > devices and automotive products. This patch will make the eMMC/SD
> > > > card  start initializing earlier, by changing its order in 
> > > > drivers/Makefile.
> > > > 
> > > > On our platform, the waiting for eMMC card is almost eliminated with 
> > > > the patch,
> > > > which is critical to boot time. And it should benefit other non-x86 
> > > > platforms
> > > > which see the similar waiting for emmc rootfs.
> > > > 
> > > > Signed-off-by: Feng Tang 
> > > > ---
> > > >  drivers/Makefile | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/Makefile b/drivers/Makefile
> > > > index 24cd47014657..c473afd3c688 100644
> > > > --- a/drivers/Makefile
> > > > +++ b/drivers/Makefile
> > > > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR)   += regulator/
> > > >  # reset controllers early, since gpu drivers might rely on them to 
> > > > initialize
> > > >  obj-$(CONFIG_RESET_CONTROLLER) += reset/
> > > >  
> > > > +# put mmc early as many morden devices use emm/sd card as rootfs 
> > > > storage
> > > 
> > > Spelling error :)
> > 
> > Will change it.
> > 
> > > 
> > > > +obj-y  += mmc/
> > > > +
> > > >  # tty/ comes before char/ so that the VT console is the boot-time
> > > >  # default.
> > > >  obj-y  += tty/
> > > 
> > > Everyone wants to be first.  Watch out if you try to put stuff before
> > > tty, you have to be very careful.  There are sd serial devices, right?
> > 
> > As the eMMC/SD card initialization takes quite some time, the SDHCI
> > host controller's module init function will quickly return, while leaving 
> > a worker to do the real card detection/initialization, so other subsystems
> > should not be blocked.
> > 
> > And yes, it is safer to move it after tty/
> 
> Again, everyone wants to be first, saving 100ms is great, but make sure
> this will not break anything else.  It's a huge change to a
> long-standing "we know this works" linker order.  Personally, I would
> not want to accept this patch for that reason alone.

Valid concern.

> 
> Also given you ignored the

Re: [PATCH v2 3/3] mm/memory_hotplug: Refactor unregister_mem_sect_under_nodes

[Oscar Salvador]

On Tue, Aug 14, 2018 at 11:39:34AM +0200, David Hildenbrand wrote:
> On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> > From: Oscar Salvador 
> > While at it, we can also drop the node_online() check, as a node can only be
> > offline if all the memory/cpus associated with it have been removed.
> 
> I would prefer splitting this change out into a separate patch.

Yes, I guess it is better as it is not really related to the changes in this 
patch.
I will wait for more feedback and I will split it up in v3.

> > +
> > +   if (unlinked_nodes)
> > +   NODEMASK_FREE(unlinked_nodes);
> 
> NODEMASK_FEEE/kfree can deal with NULL pointers.

Good point, I missed that.
I will fix it up in v3.

Thanks for reviewing.
-- 
Oscar Salvador
SUSE L3

Re: [PATCH v5 2/2] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec

[Keerthy]

On Tuesday 14 August 2018 02:53 PM, Johan Hovold wrote:
> On Wed, Jul 25, 2018 at 11:21:22AM +0530, Keerthy wrote:
>> Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
>> over try again.
>>
>> Signed-off-by: Keerthy 
>> ---
>>
>> Changes in v5:
>>
>>   * Added an additional check to see if ALARM2 status is not set
>> before retrying.
>>   * Cleaned up comments
>>   * Also reduced mdelay to 1S lesser as per this commit
>>
>>  drivers/rtc/rtc-omap.c | 28 ++--
>>  1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>> index 44ff4cc..caa6da6 100644
>> --- a/drivers/rtc/rtc-omap.c
>> +++ b/drivers/rtc/rtc-omap.c
>> @@ -421,12 +421,6 @@ static int omap_rtc_set_alarm(struct device *dev, 
>> struct rtc_wkalrm *alm)
>>   * The RTC can be used to control an external PMIC via the pmic_power_en 
>> pin,
>>   * which can be configured to transition to OFF on ALARM2 events.
>>   *
>> - * Notes:
>> - * The two-second alarm offset is the shortest offset possible as the alarm
>> - * registers must be set before the next timer update and the offset
>> - * calculation is too heavy for everything to be done within a single access
>> - * period (~15 us).
>> - *
>>   * Called with local interrupts disabled.
>>   */
>>  static void omap_rtc_power_off(void)
>> @@ -435,17 +429,20 @@ static void omap_rtc_power_off(void)
>>  struct rtc_time tm;
>>  unsigned long now;
>>  u32 val;
>> +int seconds;
> 
> Nit: I'd place this above val to maintain the reverse xmas-tree style.

okay

> 
>>  
>>  rtc->type->unlock(rtc);
>>  /* enable pmic_power_en control */
>>  val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
>>  rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
>>  
>> -/* set alarm two seconds from now */
>> +again:
>> +/* set alarm one second from now */
>>  omap_rtc_read_time_raw(rtc, &tm);
>> +seconds = tm.tm_sec;
>>  bcd2tm(&tm);
>>  rtc_tm_to_time(&tm, &now);
>> -rtc_time_to_tm(now + 2, &tm);
>> +rtc_time_to_tm(now + 1, &tm);
>>  
>>  if (tm2bcd(&tm) < 0) {
>>  dev_err(&rtc->rtc->dev, "power off failed\n");
>> @@ -470,14 +467,25 @@ static void omap_rtc_power_off(void)
>>  val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>>  rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>>  val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
>> +
>> +/*
>> + * first check if ALARM2 has fired, if not then check if
>> + * our calculations started right before the rollover, try again
>> + * in case of rollover
>> + */
> 
> This is unnecessarily verbose; I'd rephrase it as something like:
> 
>   /* Retry in case roll over happened before alarm was armed. */

Okay

> 
>> +if (!(OMAP_RTC_STATUS_ALARM2 && rtc_read(omap_rtc_power_off_rtc,
>> + OMAP_RTC_STATUS_REG)) &&
>> +seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
>> +goto again;
> 
> And this is clearly broken. First, you use boolean && instead of the &
> bit operation.

Ah my bad. I will fix it.

> 
> Second, you need to check the status register *after* checking for
> roll-over, as I already mentioned.
> 
> Also, use the rtc pointer rather than omap_rtc_power_off_rtc, which will
> allow for more readable code.

Okay

> 
> I also strongly suggest you split the conditional, and use val to store
> the status register value, that is:
> 
>   if (rtc_read(rtc, OMAP_RTC_SECONDS_REG) != seconds) {
>   val = rtc_read(rtc, OMAP_RTC_STATUS_REG);
>   if (!(val & OMAP_RTC_STATUS_ALARM2))
>   goto again;
>   }
> 
>> +
>>  rtc->type->lock(rtc);
>>  
>>  /*
>> - * Wait for alarm to trigger (within two seconds) and external PMIC to
>> + * Wait for alarm to trigger (within one second) and external PMIC to
>>   * power off the system. Add a 500 ms margin for external latencies
>>   * (e.g. debounce circuits).
>>   */
>> -mdelay(2500);
>> +mdelay(1500);
>>  }
>>  
>>  static const struct rtc_class_ops omap_rtc_ops = {
> 
> Johan
> 

RE: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[David Laight]

From: Johannes Berg
> Sent: 14 August 2018 08:57
...
> > How about fixing the root cause
> > in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
> >
> >
> > #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL
> >
> >
> > enum iwl_rx_he_phy looks really strange.
> 
> Why? I don't think this is a problem, the enum is used here to get
> constants so that we can also have documentation for them. That's a
> common and accepted technique.

It would be much more useful to indicate where the values are used.
Such a field/parameter could (probably) have the type of the enum.
But, at some point, the compiler might start barfing at that at well.

There are also a whole load of crappy __packed in that header file.
There might be one or two 64bit items on 32bit boundaries but
that can be solved without using __packed.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH v2 2/3] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[Oscar Salvador]

On Tue, Aug 14, 2018 at 11:44:50AM +0200, David Hildenbrand wrote:
> 
> Yes I know, as I said, if it would be local to a file I would not care.
> Making this functions never return an error is nice, though (and as you
> noted, the return value is never checked).
> 
> I am a friend of stating which conditions a function expects to hold if
> a function can be called from other parts of the system. Usually I
> prefer to use BUG_ONs for that (whoever decides to call it can directly
> see what he as to check before calling) or comments. But comments tend
> to become obsolete.

Uhm, I think a BUG_ON is too much here.
We could replace the check with a WARN_ON, just in case
a new function decides to call unregister_mem_sect_under_nodes() in the future.

Something like:

WARN_ON(!mem_blk)
return;

In that case, we should get a nice splat in the logs that should tell us
who is calling it with an invalid mem_blk.

-- 
Oscar Salvador
SUSE L3

Re: [PATCH v2 2/3] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[David Hildenbrand]

On 14.08.2018 12:06, Oscar Salvador wrote:
> On Tue, Aug 14, 2018 at 11:44:50AM +0200, David Hildenbrand wrote:
>>
>> Yes I know, as I said, if it would be local to a file I would not care.
>> Making this functions never return an error is nice, though (and as you
>> noted, the return value is never checked).
>>
>> I am a friend of stating which conditions a function expects to hold if
>> a function can be called from other parts of the system. Usually I
>> prefer to use BUG_ONs for that (whoever decides to call it can directly
>> see what he as to check before calling) or comments. But comments tend
>> to become obsolete.
> 
> Uhm, I think a BUG_ON is too much here.
> We could replace the check with a WARN_ON, just in case
> a new function decides to call unregister_mem_sect_under_nodes() in the 
> future.
> 
> Something like:
> 
> WARN_ON(!mem_blk)
>   return;
> 
> In that case, we should get a nice splat in the logs that should tell us
> who is calling it with an invalid mem_blk.
> 

Whatever you think is best. I have no idea what the general rules in MM
code are. Maybe dropping this check is totally fine.

-- 

Thanks,

David / dhildenb

Re: [PATCH] ACPICA: Clear status of all events when entering sleep states

[Rafael J. Wysocki]

On Monday, August 13, 2018 7:15:19 PM CEST Schmauss, Erik wrote:
> 
> > -Original Message-
> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > Sent: Sunday, August 12, 2018 3:50 AM
> > To: Linux ACPI 
> > Cc: Paul Menzel ; Linux PM  > p...@vger.kernel.org>; LKML ; Schmauss, Erik
> > 
> > Subject: [PATCH] ACPICA: Clear status of all events when entering sleep 
> > states
> > 
> > From: Rafael J. Wysocki 
> > 
> > Commit fa85015c0d95 (ACPICA: Clear status of all events when entering
> > S5) made the sleep state entry code in ACPICA clear the status of all ACPI 
> > events
> > when entering S5 to fix a functional regression reported against commit
> > 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during
> > suspend/resume).  However, it is reported now that the regression also 
> > affects
> > system states other than S5 on some systems and causes them to wake up from
> > sleep prematurely.
> > 
> > For this reason, make the code in question clear the status of all ACPI 
> > events
> > when entering all sleep states (in addition to S5) to avoid the premature
> > wakeups (this may cause some wakeup events to be missed in theory, but the
> > likelihood of that is small and the change here simply restores the previous
> > behavior of the code).
> > 
> > Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs
> > during suspend/resume)
> > Reported-by: Paul Menzel 
> > Tested-by: Paul Menzel 
> > Cc: 4.17+  # 4.17+: fa85015c0d95 ACPICA: Clear
> > status ...
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/acpi/acpica/hwsleep.c |   11 +++
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > Index: linux-pm/drivers/acpi/acpica/hwsleep.c
> > =
> > ==
> > --- linux-pm.orig/drivers/acpi/acpica/hwsleep.c
> > +++ linux-pm/drivers/acpi/acpica/hwsleep.c
> > @@ -56,14 +56,9 @@ acpi_status acpi_hw_legacy_sleep(u8 slee
> > if (ACPI_FAILURE(status)) {
> > return_ACPI_STATUS(status);
> > }
> > -   /*
> > -* If the target sleep state is S5, clear all GPEs and fixed events too
> > -*/
> > -   if (sleep_state == ACPI_STATE_S5) {
> > -   status = acpi_hw_clear_acpi_status();
> > -   if (ACPI_FAILURE(status)) {
> > -   return_ACPI_STATUS(status);
> > -   }
> > +   status = acpi_hw_clear_acpi_status();
> > +   if (ACPI_FAILURE(status)) {
> > +   return_ACPI_STATUS(status);
> > }
> > acpi_gbl_system_awake_and_running = FALSE;
> > 
> 
> I'll backport this for the next ACPICA release

Thanks!

Re: [PATCH v3 15/17] driver/cpufreq: enable Hygon support to cpufreq driver

[Rafael J. Wysocki]

On Monday, August 13, 2018 6:22:16 PM CEST Pu Wen wrote:
> On 2018/8/12 17:55, Rafael J. Wysocki wrote:
> > On Sat, Aug 11, 2018 at 3:36 PM Pu Wen  wrote:
> >>
> >> Enable ACPI cpufreq driver support for Hygon by adding family ID check
> >> along with AMD.
> >>
> >> As Hygon platforms have SMBus device(PCI device ID 0x790b), enable Hygon
> >> support to function amd_freq_sensitivity_init().
> >>
> >> Signed-off-by: Pu Wen 
> > 
> > Is there any technical difference between HYGON and AMD?
> 
> For ACPI cpufreq patch, you are right. But for the whole point of view,
> there has some technical difference between Hygon Dhyana and AMD Family
> 17h.
> For cpufreq if not added X86_VENDOR_HYGON codes, this driver will not
> work functionally on Hygon platforms.
> 
> > 
> > You seem to be mechanically adding X86_VENDOR_HYGON wherever
> > X86_VENDOR_AMD is used.
> 
> X86_VENDOR_HYGON is not mechanically added wherever X86_VENDOR_AMD is
> used, we have reviewed and tested the features wherever X86_VENDOR_HYGON
> is needed.
> 
> As Hygon Dhyana can share code path with AMD family 17h, to minimize the
> code duplication, we choose to reuse the AMD's codes here.

OK

The cpufreq changes are fine by me.

Thanks!

Re: [PATCH v3 15/17] driver/cpufreq: enable Hygon support to cpufreq driver

[Rafael J. Wysocki]

On Saturday, August 11, 2018 3:29:52 PM CEST Pu Wen wrote:
> Enable ACPI cpufreq driver support for Hygon by adding family ID check
> along with AMD.
> 
> As Hygon platforms have SMBus device(PCI device ID 0x790b), enable Hygon
> support to function amd_freq_sensitivity_init().
> 
> Signed-off-by: Pu Wen 
> ---
>  drivers/cpufreq/acpi-cpufreq.c | 5 +
>  drivers/cpufreq/amd_freq_sensitivity.c | 9 +++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index b61f4ec..d62fd37 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -61,6 +61,7 @@ enum {
>  
>  #define INTEL_MSR_RANGE  (0x)
>  #define AMD_MSR_RANGE(0x7)
> +#define HYGON_MSR_RANGE  (0x7)
>  
>  #define MSR_K7_HWCR_CPB_DIS  (1ULL << 25)
>  
> @@ -95,6 +96,7 @@ static bool boost_state(unsigned int cpu)
>   rdmsr_on_cpu(cpu, MSR_IA32_MISC_ENABLE, &lo, &hi);
>   msr = lo | ((u64)hi << 32);
>   return !(msr & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
> + case X86_VENDOR_HYGON:
>   case X86_VENDOR_AMD:
>   rdmsr_on_cpu(cpu, MSR_K7_HWCR, &lo, &hi);
>   msr = lo | ((u64)hi << 32);
> @@ -113,6 +115,7 @@ static int boost_set_msr(bool enable)
>   msr_addr = MSR_IA32_MISC_ENABLE;
>   msr_mask = MSR_IA32_MISC_ENABLE_TURBO_DISABLE;
>   break;
> + case X86_VENDOR_HYGON:
>   case X86_VENDOR_AMD:
>   msr_addr = MSR_K7_HWCR;
>   msr_mask = MSR_K7_HWCR_CPB_DIS;
> @@ -225,6 +228,8 @@ static unsigned extract_msr(struct cpufreq_policy 
> *policy, u32 msr)
>  
>   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
>   msr &= AMD_MSR_RANGE;
> + else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> + msr &= HYGON_MSR_RANGE;
>   else
>   msr &= INTEL_MSR_RANGE;
>  
> diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
> b/drivers/cpufreq/amd_freq_sensitivity.c
> index be926d9..4ac7c3c 100644
> --- a/drivers/cpufreq/amd_freq_sensitivity.c
> +++ b/drivers/cpufreq/amd_freq_sensitivity.c
> @@ -111,11 +111,16 @@ static int __init amd_freq_sensitivity_init(void)
>  {
>   u64 val;
>   struct pci_dev *pcidev;
> + unsigned int pci_vendor;
>  
> - if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
> + pci_vendor = PCI_VENDOR_ID_AMD;
> + else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> + pci_vendor = PCI_VENDOR_ID_HYGON;
> + else
>   return -ENODEV;
>  
> - pcidev = pci_get_device(PCI_VENDOR_ID_AMD,
> + pcidev = pci_get_device(pci_vendor,
>   PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, NULL);
>  
>   if (!pcidev) {
> 

Acked-by: Rafael J. Wysocki 

[GIT PULL] Power management updates for v4.19-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.19-rc1

with top-most commit 7425ecd5e3e8c9d84f399a102282a23a90a19278

 Merge branch 'pm-cpufreq'

on top of commit 9b7c19e96cededec6b0435933adefbd56cad37ab

 Merge branch 'pm-tools'

to receive the first batch of power management updates for 4.19-rc1.

These add a new framework for CPU idle time injection, to be used
by all of the idle injection code in the kernel in the future, fix
some issues and add a number of relatively small extensions in
multiple places.

Specifics:

 - Add a new framework for CPU idle time injection (Daniel Lezcano).

 - Add AVS support to the armada-37xx cpufreq driver (Gregory CLEMENT).

 - Add support for current CPU frequency reporting to the ACPI CPPC
   cpufreq driver (George Cherian).

 - Rework the cooling device registration in the imx6q/thermal
   driver (Bastian Stender).

 - Make the pcc-cpufreq driver refuse to work with dynamic
   scaling governors on systems with many CPUs to avoid
   scalability issues with it (Rafael Wysocki).

 - Fix the intel_pstate driver to report different maximum CPU
   frequencies on systems where they really are different and to
   ignore the turbo active ratio if hardware-managend P-states (HWP)
   are in use; make it use the match_string() helper (Xie Yisheng,
   Srinivas Pandruvada).

 - Fix a minor deferred probe issue in the qcom-kryo cpufreq
   driver (Niklas Cassel).

 - Add a tracepoint for the tracking of frequency limits changes
   (from Andriod) to the cpufreq core (Ruchi Kandoi).

 - Fix a circular lock dependency between CPU hotplug and sysfs
   locking in the cpufreq core reported by lockdep (Waiman Long).

 - Avoid excessive error reports on driver registration failures
   in the ARM cpuidle driver (Sudeep Holla).

 - Add a new device links flag to the driver core to make links go
   away automatically on supplier driver removal (Vivek Gautam).

 - Eliminate potential race condition between system-wide power
   management transitions and system shutdown (Pingfan Liu).

 - Add a quirk to save NVS memory on system suspend for the ASUS
   1025C laptop (Willy Tarreau).

 - Make more systems use suspend-to-idle (instead of ACPI S3) by
   default (Tristian Celestin).

 - Get rid of stack VLA usage in the low-level hibernation code on
   64-bit x86 (Kees Cook).

 - Fix error handling in the hibernation core and mark an expected
   fall-through switch in it (Chengguang Xu, Gustavo Silva).

 - Extend the generic power domains (genpd) framework to support
   attaching a device to a power domain by name (Ulf Hansson).

 - Fix device reference counting and user limits initialization in
   the devfreq core (Arvind Yadav, Matthias Kaehlcke).

 - Fix a few issues in the rk3399_dmc devfreq driver and improve its
   documentation (Enric Balletbo i Serra, Lin Huang, Nick Milner).

 - Drop a redundant error message from the exynos-ppmu devfreq driver
   (Markus Elfring).

Thanks!


---

Arvind Yadav (1):
  PM / devfreq: use put_device() instead of kfree()

Bastian Stender (1):
  cpufreq: imx6q/thermal: imx: register cooling device depending on OF

Chengguang Xu (1):
  PM / hibernate: cast PAGE_SIZE to int when comparing with error code

Daniel Lezcano (1):
  powercap / idle_inject: Add an idle injection framework

Enric Balletbo i Serra (5):
  dt-bindings: clock: add rk3399 DDR3 standard speed bins.
  PM / devfreq: rk3399_dmc: remove wait for dcf irq event.
  dt-bindings: devfreq: rk3399_dmc: move interrupts to be optional.
  PM / devfreq: rk3399_dmc: fix spelling mistakes.
  PM / devfreq: rk3399_dmc: Fix duplicated opp table on reload.

George Cherian (1):
  cpufreq / CPPC: Add cpuinfo_cur_freq support for CPPC

Gregory CLEMENT (2):
  dt-bindings: marvell: Add documentation for the Armada 3700 AVS binding
  cpufreq: armada-37xx: Add AVS support

Gustavo A. R. Silva (1):
  PM / hibernate: Mark expected switch fall-through

Kees Cook (1):
  x86/power/hibernate_64: Remove VLA usage

Lin Huang (1):
  PM / devfreq: rk3399_dmc: do not print error when get supply and
clk defer.

Markus Elfring (1):
  PM / devfreq: exynos-ppmu: Delete an error message for a failed
memory allocation in exynos_ppmu_probe()

Matthias Kaehlcke (1):
  PM / devfreq: Init user limits from OPP limits, not viceversa

Nick Milner (1):
  dt-bindings: devfreq: rk3399_dmc: improve binding documentation.

Niklas Cassel (1):
  cpufreq: qcom-kryo: Silently error out on EPROBE_DEFER

Pingfan Liu (1):
  PM / reboot: Eliminate race between reboot and suspend

Rafael J. Wysocki (1):
  cpufreq: pcc-cpufreq: Disable dynamic scaling on many-CPU systems

Ruchi Kandoi (1):
  cpufreq: trace frequency limits change

Srinivas Pandruvada (2):
  cpufreq: intel_pstate: Show different max frequency with turbo 3 and HWP
  cpufreq: intel_pstate: Ignore turbo active ratio in HWP

Sudee

[GIT PULL] ACPI updates for v4.19-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.19-rc1

with top-most commit 76f7d6c07acd7a694ccc97355d37637f6677de51

 Merge branches 'acpi-button', 'acpi-battery' and 'acpi-osi'

on top of commit 1ffaddd029c867d134a1dde39f540dcc8c52e274

 Linux 4.18-rc8

to receive the first batch of ACPI updates for 4.19-rc1.

These revert two ACPICA commits that are not needed any more, rework
the property graphs support in ACPI to be more aligned with the
analogous DT code, add some new quirks and remove one that isn't
needed any more, add a special platform driver to enumerate multiple
I2C devices hooked up to the same device object in the ACPI tables
and update the battery and button drivers.

Specifics:

 - Revert two ACPICA commits that are not needed any more (Erik
   Schmauss).

 - Rework property graph support in the ACPI device properties
   framework to make it behave more like the analogous DT code
   and update the documentation of it (Sakari Ailus).

 - Change the default ACPI device status after initialization
   to ACPI_STA_DEFAULT instead of 0 (Hans de Goede).

 - Add a special platform driver for enumerating multiple I2C devices
   hooked up to the same object in the ACPI tables (Hans de Goede).

 - Fix the ACPI battery driver to avoid reporting full capacity on
   systems without support for that and clean it up (Hans de Goede,
   Dmitry Rozhkov, Lucas Rangit Magasweran).

 - Add two system wakeup quirks to the ACPI EC driver (Aaron Ma,
   Mika Westerberg).

 - Add the touchscreen on Dell Venue Pro 7139 to the list of "always
   present" devices to make it work (Tristian Celestin).

 - Revert a special tables handling quirk for Dell XPS 9570 and
   Precision M5530 which is not needed any more (Kai Heng Feng).

 - Add support for a new OEM _OSI string to allow system vendors to
   work around issues with NVidia HDMI audio (Alex Hung).

 - Prevent the ACPI button driver from reporting excessive system
   wakeup events and clean it up (Ravi Chandra Sadineni, Randy Dunlap).

 - Clean up two minor code style issues in the ACPI core and GHES
   handling on ARM64 (Dongjiu Geng, John Garry, Tom Todd).

Thanks!


---

Aaron Ma (1):
  ACPI / EC: Use ec_no_wakeup on ThinkPad X1 Yoga 3rd

Alex Hung (1):
  ACPI / OSI: Add OEM _OSI string to enable NVidia HDMI audio

Bob Moore (1):
  ACPICA: Update version to 20180629

Dmitry Rozhkov (4):
  ACPI / battery: drop inclusion of init.h
  ACPI / battery: reorder headers alphabetically
  ACPI / battery: use specialized print macros
  ACPI / battery: get rid of negations in conditions

Dongjiu Geng (1):
  arm64 / ACPI: clean the additional checks before calling ghes_notify_sea()

Erik Schmauss (2):
  ACPICA: Revert "iASL: change processing of external op namespace
nodes for correctness"
  ACPICA: Revert "iASL compiler: allow compilation of externals
with paths that refer to existing names"

Hans de Goede (5):
  ACPI / battery: Do not export energy_full[_design] on devices
without full_charge_capacity
  ACPI / scan: Initialize status to ACPI_STA_DEFAULT
  ACPI / scan: Create platform device for fwnodes with multiple i2c devices
  ACPI / x86: utils: Remove status workaround from
acpi_device_always_present()
  platform/x86: Add ACPI i2c-multi-instantiate pseudo driver

John Garry (1):
  ACPI / scan: Add static attribute to indirect_io_hosts[]

Kai Heng Feng (1):
  Revert "ACPI / bus: Parse tables as term_list for Dell XPS 9570
and Precision M5530"

Lucas Rangit Magasweran (1):
  ACPI: battery: remove redundant old_present check on insertion

Mika Westerberg (1):
  ACPI / EC: Add another entry for Thinkpad X1 Carbon 6th

Randy Dunlap (1):
  ACPI / button: fix defined but not used warning

Ravi Chandra Sadineni (1):
  ACPI / button: increment wakeup count only when notified

Sakari Ailus (11):
  ACPI: Convert ACPI reference args to generic fwnode reference args
  ACPI: property: Allow making references to non-device nodes
  ACPI: property: Document hierarchical data extension references
  ACPI: property: Make the ACPI graph API private
  ACPI: property: Allow direct graph endpoint references
  ACPI: property: Use data node name and reg property for graphs
  ACPI: property: Document key numbering for hierarchical data
extension refs
  ACPI: property: Update documentation for hierarchical data extension 1.1
  ACPI: property: graph: Fix graph documentation
  ACPI: property: graph: Improve graph documentation for port/ep numbering
  ACPI: property: graph: Update graph documentation to use generic
references

Tom Todd (1):
  ACPI: bus: Fix a pointer coding style issue

Tristian Celestin (1):
  ACPI / x86: enable touchscreen on Dell Venue Pro 7139

---

 Documentation/acpi/dsd/data-node-references.txt   |  89 +
 Documentation/acpi/dsd/graph.txt  

Re: [PATCH 4/5] perf/hw_breakpoint: Enable breakpoint in modify_user_hw_breakpoint

[Oleg Nesterov]

On 08/10, Jiri Olsa wrote:
>
> --- a/kernel/events/hw_breakpoint.c
> +++ b/kernel/events/hw_breakpoint.c
> @@ -523,13 +523,11 @@ int modify_user_hw_breakpoint(struct perf_event *bp, 
> struct perf_event_attr *att
>   perf_event_disable(bp);
>  
>   err = modify_user_hw_breakpoint_check(bp, attr, false);
> - if (err)
> - return err;
>  
> - if (!attr->disabled)
> + if (!bp->attr.disabled)
>   perf_event_enable(bp);
>  
> - return 0;
> + return err;
>  }

Acked-by: Oleg Nesterov 

Re: [PATCH 5/5] perf/hw_breakpoint: Simplify breakpoint enable in perf_event_modify_breakpoint

[Oleg Nesterov]

On 08/10, Jiri Olsa wrote:
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2867,16 +2867,11 @@ static int perf_event_modify_breakpoint(struct 
> perf_event *bp,
>   _perf_event_disable(bp);
>  
>   err = modify_user_hw_breakpoint_check(bp, attr, true);
> - if (err) {
> - if (!bp->attr.disabled)
> - _perf_event_enable(bp);
>  
> - return err;
> - }
> -
> - if (!attr->disabled)
> + if (!bp->attr.disabled)
>   _perf_event_enable(bp);
> - return 0;
> +
> + return err;
>  }

Acked-by: Oleg Nesterov 

[PATCH v5] cpuidle: menu: Handle stopped tick more aggressively

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
with stopped tick) missed the case when the target residencies of
deep idle states of CPUs are above the tick boundary which may cause
the CPU to get stuck in a shallow idle state for a long time.

Say there are two CPU idle states available: one shallow, with the
target residency much below the tick boundary and one deep, with
the target residency significantly above the tick boundary.  In
that case, if the tick has been stopped already and the expected
next timer event is relatively far in the future, the governor will
assume the idle duration to be equal to TICK_USEC and it will select
the idle state for the CPU accordingly.  However, that will cause the
shallow state to be selected even though it would have been more
energy-efficient to select the deep one.

To address this issue, modify the governor to always use the time
till the closest timer event instead of the predicted idle duration
if the latter is less than the tick period length and the tick has
been stopped already.  Also make it extend the search for a matching
idle state if the tick is stopped to avoid settling on a shallow
state if deep states with target residencies above the tick period
length are available.

In addition, make it always indicate that the tick should be stopped
if it has been stopped already for consistency.

Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped 
tick)
Reported-by: Leo Yan 
Signed-off-by: Rafael J. Wysocki 
---
-> v2: Initialize first_idx properly in the stopped tick case.
 
v2 -> v3: Compute data->bucket before checking whether or not the tick has been
  stopped already to prevent it from becoming stale.

v3 -> v4: Allow the usual state selection to be carried out if the tick has been
  stopped in case the predicted idle duration is greater than the tick
  period length and a matching state can be found without overriding
  the prediction result.

v4 -> v5: Rework code to be more straightforward.  Functionally, it should
  behave like the v4.
---
 drivers/cpuidle/governors/menu.c |   36 
 1 file changed, 24 insertions(+), 12 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -349,14 +349,12 @@ static int menu_select(struct cpuidle_dr
 * If the tick is already stopped, the cost of possible short
 * idle duration misprediction is much higher, because the CPU
 * may be stuck in a shallow idle state for a long time as a
-* result of it.  In that case say we might mispredict and try
-* to force the CPU into a state for which we would have stopped
-* the tick, unless a timer is going to expire really soon
-* anyway.
+* result of it.  In that case say we might mispredict and use
+* the known time till the closest timer event for the idle
+* state selection.
 */
if (data->predicted_us < TICK_USEC)
-   data->predicted_us = min_t(unsigned int, TICK_USEC,
-  ktime_to_us(delta_next));
+   data->predicted_us = ktime_to_us(delta_next);
} else {
/*
 * Use the performance multiplier and the user-configurable
@@ -381,8 +379,22 @@ static int menu_select(struct cpuidle_dr
continue;
if (idx == -1)
idx = i; /* first enabled state */
-   if (s->target_residency > data->predicted_us)
-   break;
+   if (s->target_residency > data->predicted_us) {
+   if (!tick_nohz_tick_stopped())
+   break;
+
+   /*
+* If the state selected so far is shallow and this
+* state's target residency matches the time till the
+* closest timer event, select this one to avoid getting
+* stuck in the shallow one for too long.
+*/
+   if (drv->states[idx].target_residency < TICK_USEC &&
+   s->target_residency <= ktime_to_us(delta_next))
+   idx = i;
+
+   goto out;
+   }
if (s->exit_latency > latency_req) {
/*
 * If we break out of the loop for latency reasons, use
@@ -403,14 +415,13 @@ static int menu_select(struct cpuidle_dr
 * Don't stop the tick if the selected state is a polling one or if the
 

[PATCH v3 0/2] arm64: dts: meson-g12a: Introduce new DT files for Meson-G12A SoC

[Jianxin Pan]

This attempt will try to add new DT files to support Meson-G12A SoC.

1) first, Please notice that, in this patch series, the DT node about 16M 
reserved
memory for hwrom is removed, since it's not needed by G12A SoC.
2) second, the pclk for uart_AO need to be fixed once G12A clock_ao driver is
merged. In this version, it rely on bootloader to enable the pclk gate which 
belong to AO clock domain. Please add clk_ignore_unused to bootargs.

Changes since v2 [1]:
 - reorder subnodes
 - collect Rob's Reviewed-by

Changes since v1 [0]:
 - fix signoff typo
 - order subnodes by addresses when there is one and alphabetically when there 
is none

[0] 
https://lore.kernel.org/lkml/1533802951-49919-2-git-send-email-jianxin@amlogic.com/

Jianxin Pan (2):
  dt-bindings: arm: amlogic: Add Meson G12A binding
  arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT support

 Documentation/devicetree/bindings/arm/amlogic.txt |   6 +
 arch/arm64/boot/dts/amlogic/Makefile  |   1 +
 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts   |  22 +++
 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi   | 172 ++
 4 files changed, 201 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi

-- 
1.9.1

[PATCH v3 2/2] arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT support

[Jianxin Pan]

Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.

Signed-off-by: Jianxin Pan 
---
 arch/arm64/boot/dts/amlogic/Makefile|   1 +
 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts |  22 +++
 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 172 
 3 files changed, 195 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index a97c0e2..c31f29d6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_MESON) += meson-axg-s400.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nanopi-k2.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nexbox-a95x.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-odroidc2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
new file mode 100644
index 000..d267a37
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-g12a.dtsi"
+
+/ {
+   compatible = "amlogic,u200", "amlogic,g12a";
+   model = "Amlogic Meson G12A U200 Development Board";
+
+   aliases {
+   serial0 = &uart_AO;
+   };
+};
+
+&uart_AO {
+   status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
new file mode 100644
index 000..3b82a97
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "amlogic,g12a";
+
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <0x2>;
+   #size-cells = <0x0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   };
+
+   l2: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@500 {
+   reg = <0x0 0x0500 0x0 0x30>;
+   no-map;
+   };
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   periphs: periphs@ff634000 {
+   compatible = "simple-bus";
+   reg = <0x0 0xff634000 0x0 0x2000>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x0 0x0 0x0 0xff634000 0x0 0x2000>;
+   };
+
+   hiubus: bus@ff63c000 {
+   compatible = "simple-bus";
+   reg = <0x0 0xff63c000 0x0 0x1c00>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x0 0x0 0x0 0xff63c000 0x0 0x1c00>;
+   };
+
+   

[PATCH v3 1/2] dt-bindings: arm: amlogic: Add Meson G12A binding

[Jianxin Pan]

Introduce new bindings for the Meson G12A SoC

Signed-off-by: Jianxin Pan 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt 
b/Documentation/devicetree/bindings/arm/amlogic.txt
index b5c2b5c..cf4bbc7 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -57,6 +57,10 @@ Boards with the Amlogic Meson AXG A113D SoC shall have the 
following properties:
   Required root node property:
 compatible: "amlogic,a113d", "amlogic,meson-axg";
 
+Boards with the Amlogic Meson G12A S905D2 SoC shall have the following 
properties:
+  Required root node property:
+compatible: "amlogic,g12a";
+
 Board compatible values (alphabetically, grouped by SoC):
 
   - "geniatech,atv1200" (Meson6)
@@ -101,6 +105,8 @@ Board compatible values (alphabetically, grouped by SoC):
 
   - "amlogic,s400" (Meson axg a113d)
 
+  - "amlogic,u200" (Meson g12a s905d2)
+
 Amlogic Meson Firmware registers Interface
 --
 
-- 
1.9.1

Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes

[Daniel Vetter]

On Tue, Aug 14, 2018 at 12:48:08PM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
> 
> Thank you for the patch.
> 
> On Tuesday, 7 August 2018 20:22:01 EEST Dmitry Osipenko wrote:
> > From: Laurent Pinchart 
> > 
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent or gain adjustment
> > of the pixels component values.
> > 
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds new generic DRM plane
> > properties related to the color keying, providing initial color keying
> > support.
> > 
> > Signed-off-by: Laurent Pinchart 
> > Signed-off-by: Dmitry Osipenko 
> > ---
> >  drivers/gpu/drm/drm_atomic.c |  20 +
> >  drivers/gpu/drm/drm_blend.c  | 150 +++
> >  include/drm/drm_blend.h  |   3 +
> >  include/drm/drm_plane.h  |  91 +
> >  4 files changed, 264 insertions(+)
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d7e15e..13c61dd0d9b7 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,11 @@
> >   * planes. Without this property the primary plane is always below the
> > cursor *plane, and ordering between all other planes is undefined.
> >   *
> > + * colorkey:
> > + * Color keying is set up with drm_plane_create_colorkey_properties().
> > + * It adds support for actions like replacing a range of colors with a
> > + * transparent color in the plane. Color keying is disabled by default.
> > + *
> >   * Note that all the property extensions described here apply either to the
> > * plane or the CRTC (e.g. for the background color, which currently is not
> > * exposed and assumed to be black).
> > @@ -448,3 +453,148 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> > return 0;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_normalize_zpos);
> > +
> > +static const char * const plane_colorkey_mode_name[] = {
> > +   [DRM_PLANE_COLORKEY_MODE_DISABLED] = "disabled",
> > +   [DRM_PLANE_COLORKEY_MODE_TRANSPARENT] = "transparent",
> > +};
> > +
> > +/**
> > + * drm_plane_create_colorkey_properties - create colorkey properties
> > + * @plane: drm plane
> > + * @supported_modes: bitmask of supported color keying modes
> > + *
> > + * This function creates the generic color keying properties and attaches
> > them
> > + * to the @plane to enable color keying control for blending operations.
> > + *
> > + * Glossary:
> > + *
> > + * Destination plane:
> > + * Plane to which color keying properties are applied, this planes takes
> > + * the effect of color keying operation. The effect is determined by a
> > + * given color keying mode.
> > + *
> > + * Source plane:
> > + * Pixels of this plane are the source for color key matching operation.
> > + *
> > + * Color keying is controlled by these properties:
> > + *
> > + * colorkey.plane_mask:
> > + * The mask property specifies which planes participate in color key
> > + * matching process, these planes are the color key sources.
> > + *
> > + * Drivers return an error from their plane atomic check if plane can't be
> > + * handled.
> 
> This seems fragile to me. We don't document how userspace determines which 
> planes need to be specified here, and we don't document what happens if a 
> plane underneath the destination plane is not specified in the mask. More 
> precise documentation is needed if we want to use such a property.
> 
> It also seems quite complex. Is an explicit plane mask really the best option 
> ? What's the reason why planes couldn't be handled ? How do drivers determine 
> that ?

General comment: This is why we need the reference userspace. I also
think that any feature throwing up so many tricky questions should come
with a full set of igt testcases. Since the reference userspace cannot
answer how the new uapi should work in all corner-cases (failures and
stuff like that).
-Daniel

> 
> > + * colorkey.mode:
> > + * The mode is an enumerated property that controls how color keying
> > + * operates.
> 
> A link to the drm_plane_colorkey_mode enum documentation would be useful.
> 
> > + * colorkey.mask:
> > + * This property specifies the pixel components mask. Unmasked pixel
> > + * components are not participating in the matching. This mask value is
> > + * applied to colorkey.min / max values. The mask value is given in a
> > + * 64-bit integer in ARGB16161616 format, where A is the alpha value and
> > + * R, G and B correspond to the color components. Drivers shall convert
> > + * ARGB16161616 value into appropriate format within planes atomic check.
> > + *
> > + * Drivers return an error from their plane atomic check if m

Re: [PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

[Will Deacon]

Hi Greg,

On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
> before seeing if the PFN is valid.  This leads to false positives when
> some of the upper bits are set, but the lower bits match a valid PFN.
> 
> For example, the following userspace code looks up a bogus entry in
> /proc/kpageflags:
> 
> int pagemap = open("/proc/self/pagemap", O_RDONLY);
> int pageflags = open("/proc/kpageflags", O_RDONLY);
> uint64_t pfn, val;
> 
> lseek64(pagemap, [...], SEEK_SET);
> read(pagemap, &pfn, sizeof(pfn));
> if (pfn & (1UL << 63)) {/* valid PFN */
> pfn &= ((1UL << 55) - 1);   /* clear flag bits */
> pfn |= (1UL << 55);
> lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET);
> read(pageflags, &val, sizeof(val));
> }
> 
> On ARM64 this causes the userspace process to crash with SIGSEGV rather
> than reading (1 << KPF_NOPAGE).  kpageflags_read() treats the offset as
> valid, and stable_page_flags() will try to access an address between the
> user and kernel address ranges.
> 
> Signed-off-by: Greg Hackmann 
> ---
>  arch/arm64/mm/init.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Thanks, this looks like a sensible fix to me. Do you think it warrants a
CC stable?

Will

> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9abf8a1e7b25..787e27964ab9 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -287,7 +287,11 @@ static void __init zone_sizes_init(unsigned long min, 
> unsigned long max)
>  #ifdef CONFIG_HAVE_ARCH_PFN_VALID
>  int pfn_valid(unsigned long pfn)
>  {
> - return memblock_is_map_memory(pfn << PAGE_SHIFT);
> + phys_addr_t addr = pfn << PAGE_SHIFT;
> +
> + if ((addr >> PAGE_SHIFT) != pfn)
> + return 0;
> + return memblock_is_map_memory(addr);
>  }
>  EXPORT_SYMBOL(pfn_valid);
>  #endif
> -- 
> 2.18.0.597.ga71716f1ad-goog
> 

Re: [PATCH 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller

[Jerome Brunet]

On Tue, 2018-08-14 at 02:18 -0400, Hanjie Lin wrote:
> From: Yue Wang 
> 
> The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
> PCI core. This patch adds documentation for the DT bindings in Meson PCIe
> controller.
> 
> Signed-off-by: Yue Wang 
> Signed-off-by: Hanjie Lin 
> ---
>  .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 57 
> ++
>  1 file changed, 57 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt 
> b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> new file mode 100644
> index 000..48233e4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> @@ -0,0 +1,57 @@
> +Amlogic Meson AXG DWC PCIE SoC controller
> +
> +Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI 
> core.
> +It shares common functions with the PCIe DesignWare core driver and
> +inherits common properties defined in
> +Documentation/devicetree/bindings/pci/designware-pci.txt.
> +
> +Additional properties are described here:
> +
> +Required properties:
> +- compatible:
> + should contain "amlogic,axg-pcie" to identify the core.
> +- reg:
> + Should contain the configuration address space.
> +- reg-names: Must be
> + - "elbi"External local bus interface registers
> + - "cfg" Meson specific registers
> + - "config"  PCIe configuration space
> +- clocks: Must contain an entry for each entry in clock-names.
> +- clock-names: Must include the following entries:
> + - "pcie"
> + - "pcie_bus"
> + - "pcie_general"
> + - "pcie_mipi_en"

Could you briefly describe what each clock is needed for ?

> +
> +Example configuration:
> +
> + pcie: pcie@d000 {
> + compatible = "amlogic,axg-pcie", "snps,dw-pcie";
> + reg = <0x0 0xf980 0x0 0x40
> + 0x0 0xff646000 0x0 0x2000
> + 0x0 0xf9f0 0x0 0x10>;
> + reg-names = "elbi", "cfg", "config";
> + reset-gpio = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
> + interrupts = <0 177 IRQ_TYPE_EDGE_RISING>;

replace 0 with GIC_SPI please

> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 &gic GIC_SPI 179 
> IRQ_TYPE_EDGE_RISING>;
> + bus-range = <0x0 0xff>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + phys = <&pcie_phy>;
> + ranges = <0x8200 0 0 0x0 0xf9c0 0 0x0030>;
> + num-lanes = <1>;
> + pcie-num = <1>;
> +
> + clocks = <&clkc CLKID_USB
> + &clkc CLKID_MIPI_ENABLE
> + &clkc CLKID_PCIE_A
> + &clkc CLKID_PCIE_CML_EN0>;
> + clock-names = "pcie_general",
> + "pcie_refpll",
> + "pcie_mipi_en",
> + "pcie",
> + "port";

Several things are disturbing above:
* pcie_general is provided by the USB clock gate ???
* pcie_refpll: I suppose this is a copy/paste error, not used in your driver
(and shouldn't be need BTW)

suggested names:
* pcie_general -> general
* pcie_mipi_en -> mipi
* pcie -> pclk
* port (OK)

> + };

Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe controller driver

[Jerome Brunet]

On Tue, 2018-08-14 at 02:18 -0400, Hanjie Lin wrote:
> From: Yue Wang 
> 
> The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
> PCI core. This patch adds the driver support for Meson PCIe controller.
> 
> Signed-off-by: Yue Wang 
> Signed-off-by: Hanjie Lin 
> ---
>  drivers/pci/controller/dwc/Kconfig |  12 +
>  drivers/pci/controller/dwc/Makefile|   1 +
>  drivers/pci/controller/dwc/pci-meson.c | 588 
> +
>  3 files changed, 601 insertions(+)
>  create mode 100644 drivers/pci/controller/dwc/pci-meson.c
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig 
> b/drivers/pci/controller/dwc/Kconfig
> index 91b0194..6cb36f6 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -193,4 +193,16 @@ config PCIE_HISI_STB
>   help
>Say Y here if you want PCIe controller support on HiSilicon STB 
> SoCs
>  
> +config PCI_MESON
> + bool "MESON PCIe controller"
> + depends on PCI
> + depends on PCI_MSI_IRQ_DOMAIN
> + select PCIEPORTBUS
> + select PCIE_DW_HOST
> + help
> +   Say Y here if you want to enable PCI controller support on Amlogic
> +   SoCs. The PCI controller on Amlogic is based on DesignWare hardware
> +   and therefore the driver re-uses the DesignWare core functions to
> +   implement the driver.
> +
>  endmenu
> diff --git a/drivers/pci/controller/dwc/Makefile 
> b/drivers/pci/controller/dwc/Makefile
> index 5d2ce72..cf676bd 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>  obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
>  obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
>  obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
> +obj-$(CONFIG_PCI_MESON) += pci-meson.o
>  
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/controller/dwc/pci-meson.c 
> b/drivers/pci/controller/dwc/pci-meson.c
> new file mode 100644
> index 000..1e96e45
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pci-meson.c
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe host controller driver for Amlogic MESON SoCs
> + *
> + * Copyright (c) 2018 Amlogic, inc.
> + * Author: Yue Wang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pcie-designware.h"
> +
> +#define to_meson_pcie(x) dev_get_drvdata((x)->dev)
> +
> +/* External local bus interface registers */
> +#define PLR_OFFSET   0x700
> +#define PCIE_PORT_LINK_CTRL_OFF  (PLR_OFFSET + 0x10)
> +#define FAST_LINK_MODE   BIT(7)
> +#define LINK_CAPABLE_MASKGENMASK(21, 16)
> +#define LINK_CAPABLE_X1  BIT(16)
> +
> +#define PCIE_GEN2_CTRL_OFF   (PLR_OFFSET + 0x10c)
> +#define NUM_OF_LANES_MASKGENMASK(12, 8)
> +#define NUM_OF_LANES_X1  BIT(8)
> +#define DIRECT_SPEED_CHANGE  BIT(17)
> +
> +#define TYPE1_HDR_OFFSET 0x0
> +#define PCIE_STATUS_COMMAND  (TYPE1_HDR_OFFSET + 0x04)
> +#define PCI_IO_ENBIT(0)
> +#define PCI_MEM_SPACE_EN BIT(1)
> +#define PCI_BUS_MASTER_ENBIT(2)
> +
> +#define PCIE_BASE_ADDR0  (TYPE1_HDR_OFFSET + 0x10)
> +#define PCIE_BASE_ADDR1  (TYPE1_HDR_OFFSET + 0x14)
> +
> +#define PCIE_CAP_OFFSET  0x70
> +#define PCIE_DEV_CTRL_DEV_STUS   (PCIE_CAP_OFFSET + 0x08)
> +#define PCIE_CAP_MAX_PAYLOAD_MASKGENMASK(7, 5)
> +#define PCIE_CAP_MAX_PAYLOAD_SIZE(x) ((x) << 5)
> +#define PCIE_CAP_MAX_READ_REQ_MASK   GENMASK(14, 12)
> +#define PCIE_CAP_MAX_READ_REQ_SIZE(x)((x) << 12)
> +
> +#define PCI_CLASS_REVISION_MASK  GENMASK(7, 0)
> +
> +/* PCIe specific config registers */
> +#define PCIE_CFG00x0
> +#define APP_LTSSM_ENABLE BIT(7)
> +
> +#define PCIE_CFG_STATUS120x30
> +#define IS_SMLH_LINK_UP(x)   ((x) & (1 << 6) ? 1 : 0)
> +#define IS_RDLH_LINK_UP(x)   ((x) & (1 << 16) ? 1 : 0)
> +#define IS_LTSSM_UP(x)   x) >> 10) & 0x1f) == 0x11 ? 
> 1 : 0)

those ternary ops are overkill

> +
> +#define PCIE_CFG_STATUS170x44
> +#define PM_CURRENT_STATE(x)  (((x) >> 7) & 0x1)
> +
> +#define WAIT_LINKUP_TIMEOUT  2000
> +#define PORT_CLK_RATE1UL
> +#define MAX_PAYLOAD_SIZE 256
> +#define MAX_READ_REQ_SIZE256
> +
> +enum pcie_data_rate {
> + PCIE_GEN1,
> + PCIE_GEN2,
> + PCIE_GEN3,
> + PCIE_GEN4
> +};
> +
> +struct meson_pcie_mem_res {
> + void __iomem *elbi_base; /* DT 0th resource */
> + void __iomem *cfg_base; /* DT 2nd resource */
>

[PATCH] cpuidle: menu: Fix white space

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Fix some damaged white space in menu_select().

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpuidle/governors/menu.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -429,8 +429,8 @@ static int menu_select(struct cpuidle_dr
 * tick, so try to correct that.
 */
for (i = idx - 1; i >= 0; i--) {
-   if (drv->states[i].disabled ||
-   dev->states_usage[i].disable)
+   if (drv->states[i].disabled ||
+   dev->states_usage[i].disable)
continue;
 
idx = i;

Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver

[Jerome Brunet]

On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
> From: Yue Wang 
> 
> The Meson-PCIE-PHY controller supports the 5-Gbps data rate
> of the PCI Express Gen 2 specification and is backwardcompatible
> with the 2.5-Gbps Gen 1.1 specification with only
> inferred idle detection supported on AMLOGIC SoCs.

It looks like the sole purpose of this driver is to provide the reset lines to
pcie driver.

I wonder why we need this ? Can't the pcie driver claim the reset lines itself.

Also, an init of this phy will always reset both port. What will happen if the
first port is in use and the 2nd port comes up ?? 

Looks the the pcie driver should claim 'apb' and 'phy' reset lines as "shared"
reset and the required 'port' as 'exclusive'

> 
> Signed-off-by: Yue Wang 
> Signed-off-by: Hanjie Lin 
> ---
>  drivers/phy/amlogic/Kconfig  |   8 ++
>  drivers/phy/amlogic/Makefile |   1 +
>  drivers/phy/amlogic/phy-meson-axg-pcie.c | 160 
> +++
>  3 files changed, 169 insertions(+)
>  create mode 100644 drivers/phy/amlogic/phy-meson-axg-pcie.c
> 
> diff --git a/drivers/phy/amlogic/Kconfig b/drivers/phy/amlogic/Kconfig
> index 23fe1cd..3ab07f9 100644
> --- a/drivers/phy/amlogic/Kconfig
> +++ b/drivers/phy/amlogic/Kconfig
> @@ -36,3 +36,11 @@ config PHY_MESON_GXL_USB3
> Enable this to support the Meson USB3 PHY and OTG detection
> IP block found in Meson GXL and GXM SoCs.
> If unsure, say N.
> +
> +config PHY_MESON_AXG_PCIE
> + bool "Meson AXG PCIe PHY driver"
> + depends on OF && (ARCH_MESON || COMPILE_TEST)
> + select GENERIC_PHY
> + help
> +   Enable PCIe PHY support for Meson AXG SoC series.
> +   This driver provides PHY interface for Meson PCIe controller.
> \ No newline at end of file
> diff --git a/drivers/phy/amlogic/Makefile b/drivers/phy/amlogic/Makefile
> index 4fd8848..5ab8578 100644
> --- a/drivers/phy/amlogic/Makefile
> +++ b/drivers/phy/amlogic/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_PHY_MESON8B_USB2)   += phy-meson8b-usb2.o
>  obj-$(CONFIG_PHY_MESON_GXL_USB2) += phy-meson-gxl-usb2.o
>  obj-$(CONFIG_PHY_MESON_GXL_USB3) += phy-meson-gxl-usb3.o
> +obj-$(CONFIG_PHY_MESON_AXG_PCIE) += phy-meson-axg-pcie.o
> diff --git a/drivers/phy/amlogic/phy-meson-axg-pcie.c 
> b/drivers/phy/amlogic/phy-meson-axg-pcie.c
> new file mode 100644
> index 000..8bc5c49
> --- /dev/null
> +++ b/drivers/phy/amlogic/phy-meson-axg-pcie.c
> @@ -0,0 +1,160 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Amlogic MESON SoC series PCIe PHY driver
> + *
> + * Phy provider for PCIe controller on MESON SoC series
> + *
> + * Copyright (c) 2018 Amlogic, inc.
> + * Yue Wang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct meson_pcie_phy_data {
> + const struct phy_ops*ops;
> +};
> +
> +struct meson_pcie_reset {
> + struct reset_control*port_a;
> + struct reset_control*port_b;
> + struct reset_control*phy;
> + struct reset_control*apb;
> +};
> +
> +struct meson_pcie_phy {
> + const struct meson_pcie_phy_data*data;
> + struct meson_pcie_reset reset;
> + void __iomem*phy_base;
> +};
> +
> +static int meson_pcie_phy_init(struct phy *phy)
> +{
> + struct meson_pcie_phy *mphy = phy_get_drvdata(phy);
> + struct meson_pcie_reset *mrst = &mphy->reset;
> +
> + writel(0x1c, mphy->phy_base);
> + reset_control_assert(mrst->port_a);
> + reset_control_assert(mrst->port_b);
> + reset_control_assert(mrst->phy);
> + reset_control_assert(mrst->apb);
> + udelay(400);
> + reset_control_deassert(mrst->port_a);
> + reset_control_deassert(mrst->port_b);
> + reset_control_deassert(mrst->phy);
> + reset_control_deassert(mrst->apb);
> + udelay(500);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops meson_phy_ops = {
> + .init   = meson_pcie_phy_init,
> + .owner  = THIS_MODULE,
> +};
> +
> +static const struct meson_pcie_phy_data meson_pcie_phy_data = {
> + .ops= &meson_phy_ops,
> +};
> +
> +static const struct of_device_id meson_pcie_phy_match[] = {
> + {
> + .compatible = "amlogic,axg-pcie-phy",
> + .data = &meson_pcie_phy_data,
> + },
> + {},
> +};
> +
> +static int meson_pcie_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct meson_pcie_phy *mphy;
> + struct meson_pcie_reset *mrst;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + const struct meson_pcie_phy_data *data;
> +
> + data = of_device_get_match_data(dev);
> + if (!data)
> + return -ENODEV;
> +
> + mphy = devm_kzalloc(dev, sizeof(*mphy), GFP_KERNEL);
> + if (!mphy)
> + return -ENOMEM;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>

Re: [PATCH v9 08/22] s390: vfio-ap: base implementation of VFIO AP device driver

[Cornelia Huck]

On Mon, 13 Aug 2018 17:48:05 -0400
Tony Krowiak  wrote:


> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> b/drivers/s390/crypto/vfio_ap_drv.c
> new file mode 100644
> index 000..5069580
> --- /dev/null
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -0,0 +1,118 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * VFIO based AP device driver
> + *
> + * Copyright IBM Corp. 2018
> + *
> + * Author(s): Tony Krowiak 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "vfio_ap_private.h"
> +
> +#define VFIO_AP_ROOT_NAME "vfio_ap"
> +#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
> +#define VFIO_AP_DEV_NAME "matrix"
> +
> +MODULE_AUTHOR("IBM Corporation");
> +MODULE_DESCRIPTION("VFIO AP device driver, Copyright IBM Corp. 2018");
> +MODULE_LICENSE("GPL v2");
> +
> +static struct ap_driver vfio_ap_drv;
> +
> +static struct device_type vfio_ap_dev_type = {
> + .name = VFIO_AP_DEV_TYPE_NAME,
> +};
> +
> +struct ap_matrix_dev matrix_dev;

Please don't add new statically allocated devices, but allocate it
dynamically (see the comment in device_add()).

> +
> +/* Only type 10 adapters (CEX4 and later) are supported
> + * by the AP matrix device driver
> + */
> +static struct ap_device_id ap_queue_ids[] = {
> + { .dev_type = AP_DEVICE_TYPE_CEX4,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX5,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX6,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { /* end of sibling */ },
> +};
> +
> +MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
> +
> +static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
> +{
> + return 0;
> +}
> +
> +static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
> +{
> + /* Nothing to do yet */
> +}

You need a release callback as well.

> +
> +static int vfio_ap_matrix_dev_init(void)
> +{
> + int ret;
> + struct device *root_device;
> +
> + root_device = root_device_register(VFIO_AP_ROOT_NAME);
> + if (IS_ERR(root_device)) {
> + ret = PTR_ERR(root_device);
> + return ret;
> + }
> +
> + matrix_dev.device.type = &vfio_ap_dev_type;
> + dev_set_name(&matrix_dev.device, "%s", VFIO_AP_DEV_NAME);
> + matrix_dev.device.type = &vfio_ap_dev_type;
> + matrix_dev.device.parent = root_device;
> + matrix_dev.device.driver = &vfio_ap_drv.driver;
> +
> + ret = device_register(&matrix_dev.device);
> + if (ret) {
> + root_device_unregister(root_device);

And this needs a put_device() for the matrix device. (It is getting
ugly with a statically allocated device.)

> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void vfio_ap_matrix_dev_destroy(void)
> +{
> + device_unregister(&matrix_dev.device);

This one already does a put_device(). Didn't the driver core complain?

> + root_device_unregister(matrix_dev.device.parent);
> +}

Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'

[Dirk Gouders]

Masahiro Yamada  writes:

> Currently, Kconfig does not report anything about the recursive
> dependency where 'imply' keywords are involved.
>
> [Test Code]
>
>   config A
>   bool "a"
>
>   config B
>   bool "b"
>   imply A
>   depends on A

Hello Masahiro,

obviously, it is hard to find a reason why one wants to use dependencies
like above but I also wonder how e.g. menuconfig handles this case:

First, only "a" is visible, if I then select "a", "b" does not become
visible but when I then reset "a" to "n", "b" becomes visible.  If I then
try to select "b", it becomes invisible...

Perhaps it would be better to just error out instead of giving users the
impression, Kconfig thinks such questionable behavior is OK.

Side note: perhaps, the documentation could be better when it comes to
   recursive dependencies.  The documentation says "select" and
   "imply" can be used to specify lower limits whereas direct
   dependencies specify upper limits for symbol values and with
   this in mind, one might wonder why it is a problem to work
   with both limits in a recursive way.

   Not very unlikely that it is just me who still has to
   understand recursive dependencies or problems with reading
   English text, though.

What definitely seems to get void with your patches is item c) in
"Practical solutions to kconfig recursive issue" in
Documentation/kbuild/kconfig-language:

c) Consider the use of "imply" instead of "select"

Dirk

> In the code above, Kconfig cannot calculate the symbol values correctly
> due to the circular dependency.  For example, allyesconfig followed by
> syncconfig results in an odd behavior because CONFIG_B becomes visible
> in syncconfig.
>
>   $ make allyesconfig
>   scripts/kconfig/conf  --allyesconfig Kconfig
>   #
>   # configuration written to .config
>   #
>   $ cat .config
>   #
>   # Automatically generated file; DO NOT EDIT.
>   # Main menu
>   #
>   CONFIG_A=y
>   $ make syncconfig
>   scripts/kconfig/conf  --syncconfig Kconfig
>   *
>   * Restart config...
>   *
>   *
>   * Main menu
>   *
>   a (A) [Y/n/?] y
> b (B) [N/y/?] (NEW)
>
> To report this correctly, sym_check_expr_deps() should recurse to
> not only sym->rev_dep.expr but also sym->implied.expr .
>
> At this moment, sym_check_print_recursive() cannot distinguish
> 'select' and 'imply' since it does not know the precise context
> where the recursive dependency is hit.  This will be solved by
> the next commit.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/kconfig/symbol.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 4ec8b1f..7de7463a 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol 
> *last_sym)
>   sym->name ? sym->name : "",
>   next_sym->name ? next_sym->name : "");
>   } else {
> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or 
> implied by %s\n",
>   prop->file->name, prop->lineno,
>   sym->name ? sym->name : "",
>   next_sym->name ? next_sym->name : "");
> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol 
> *sym)
>   if (sym2)
>   goto out;
>  
> + sym2 = sym_check_expr_deps(sym->implied.expr);
> + if (sym2)
> + goto out;
> +
>   for (prop = sym->prop; prop; prop = prop->next) {
> - if (prop->type == P_CHOICE || prop->type == P_SELECT)
> + if (prop->type == P_CHOICE || prop->type == P_SELECT ||
> + prop->type == P_IMPLY)
>   continue;
>   stack.prop = prop;
>   sym2 = sym_check_expr_deps(prop->visible.expr);

[PATCH v2] ia64: Use ARRAY_SIZE to replace its implementation

[zhong jiang]

We prefer to ARRAY_SIZE rather than duplicating its implementation.
And just one place use the #define variable, therefore, remove
PFM_CMD_COUNT definition altogether.

Signed-off-by: zhong jiang 
---
v1->v2:
  -  According to Joe's suggestion. remove the #define variable,
 and use ARRAY_SIZE to replace directly.

 arch/ia64/kernel/perfmon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index a9d4dc6..bfe0094c 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -4645,7 +4645,6 @@ static char *pfmfs_dname(struct dentry *dentry, char 
*buffer, int buflen)
 /* 32 */PFM_CMD(pfm_write_ibrs, PFM_CMD_PCLRWS, PFM_CMD_ARG_MANY, 
pfarg_dbreg_t, NULL),
 /* 33 */PFM_CMD(pfm_write_dbrs, PFM_CMD_PCLRWS, PFM_CMD_ARG_MANY, 
pfarg_dbreg_t, NULL)
 };
-#define PFM_CMD_COUNT  (sizeof(pfm_cmd_tab)/sizeof(pfm_cmd_desc_t))
 
 static int
 pfm_check_task_state(pfm_context_t *ctx, int cmd, unsigned long flags)
@@ -4770,7 +4769,7 @@ static char *pfmfs_dname(struct dentry *dentry, char 
*buffer, int buflen)
 */
if (unlikely(pmu_conf == NULL)) return -ENOSYS;
 
-   if (unlikely(cmd < 0 || cmd >= PFM_CMD_COUNT)) {
+   if (unlikely(cmd < 0 || cmd >= ARRAY_SIZE(pfm_cmd_tab))) {
DPRINT(("invalid cmd=%d\n", cmd));
return -EINVAL;
}
-- 
1.7.12.4

[PATCH] fix ifnullfree.cocci warnings

[Julia Lawall]

From: kbuild test robot 

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

Fixes: 0099cc17a399 ("ASoC:topology:avoid error log and oops during topology 
free.")
Signed-off-by: kbuild test robot 
Signed-off-by: Julia Lawall 
---

Feel free to ignore this if the null test is useful in some way.

 topology.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -2165,8 +2165,7 @@ void snd_sof_free_topology(struct snd_so
/* free sroute and its private data */
kfree(sroute->route->source);
kfree(sroute->route->sink);
-   if (sroute->route->control)
-   kfree(sroute->route->control);
+   kfree(sroute->route->control);
kfree(sroute->route);
kfree(sroute->private);
kfree(sroute);

Re: [Regression] usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201

[Daniel Thompson]

On Fri, Aug 10, 2018 at 12:13:53PM -0400, Joseph Salisbury wrote:
> Hi Daniel,
> 
> A kernel bug report was opened against Ubuntu [0].  It was found the
> following patch introduced the regression:
> 
> da9970668948 ("usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201")

I can see nothing in http://pad.lv/1773704 that indicates a regression
in this patch. How could there be? The patch does not not alter the
behaviour of uPD720202 devices (pdev->device == 0x0015).

 
> The bug reporter claims there is a typo in the patch that caused the
> regression.  I built a test kernel with a change to the suspected typo
> and the bug reporter claims it resolved the regression.  My test kernel
> had the following change:
> 
> -   pdev->device == 0x0014)
> +   pdev->device == 0x0015)
> 
> I was hoping to get your feedback, since you are the patch author.  Do
> you think this is an actual typo, or maybe there really needs to be two
> quirks?

No, it is a not a typo (and the change above *does* introduce a regression
;-) ). From this git logs I believe that:

  0x0014 -> uPD720201
  0x0015 -> uPD720202


Daniel.

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[Arnd Bergmann]

On Tue, Aug 14, 2018 at 12:04 PM David Laight  wrote:
>
> From: Johannes Berg
> > Sent: 14 August 2018 08:57
> ...
> > > How about fixing the root cause
> > > in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
> > >
> > >
> > > #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK   0x1eULL
> > >
> > >
> > > enum iwl_rx_he_phy looks really strange.
> >
> > Why? I don't think this is a problem, the enum is used here to get
> > constants so that we can also have documentation for them. That's a
> > common and accepted technique.
>
> It would be much more useful to indicate where the values are used.
> Such a field/parameter could (probably) have the type of the enum.
> But, at some point, the compiler might start barfing at that at well.

I think the compiler warning here only happens because one uses
a compile-time constant expression that is not a numeric literal value
into a boolean operator. That doesn't mean that there is something
wrong with the enum in particular, or that enums cause a lot of
issues elsewhere.

I would also argue that generally speaking the BUILD_BUG_ON_MSG()
should try to either produce the specific build failure it was designed
for, or not produce any output at all, rather than something
that is more confusing to developers. If we want to enforce
passing in number literals here, we should make that an explicit
check, or otherwise allow any compile-time constant values.

> There are also a whole load of crappy __packed in that header file.
> There might be one or two 64bit items on 32bit boundaries but
> that can be solved without using __packed.

Agreed, this likely causes problems on architectures without unaligned
load/store instructions that end up doing byte accesses to the descriptor
fields, which in turn can confuse the hardware, and can become very
slow when they live in dma_alloc_coherent() memory. That looks
like a completely unrelated issue though.

  Arnd

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

[Johannes Berg]

On Tue, 2018-08-14 at 13:08 +0200, Arnd Bergmann wrote:

> > It would be much more useful to indicate where the values are used.
> > Such a field/parameter could (probably) have the type of the enum.
> > But, at some point, the compiler might start barfing at that at well.
> 
> I think the compiler warning here only happens because one uses
> a compile-time constant expression that is not a numeric literal value
> into a boolean operator. That doesn't mean that there is something
> wrong with the enum in particular, or that enums cause a lot of
> issues elsewhere.
> 
> I would also argue that generally speaking the BUILD_BUG_ON_MSG()
> should try to either produce the specific build failure it was designed
> for, or not produce any output at all, rather than something
> that is more confusing to developers. If we want to enforce
> passing in number literals here, we should make that an explicit
> check, or otherwise allow any compile-time constant values.

I don't see why we should only be allowed to pass a number literal
(perhaps after pre-processing), rather than any constant integer value.
Clearly it needs to be a constant for all the constant-folding to work,
but nothing else is required.

> > There are also a whole load of crappy __packed in that header file.
> > There might be one or two 64bit items on 32bit boundaries but
> > that can be solved without using __packed.
> 
> Agreed, this likely causes problems on architectures without unaligned
> load/store instructions that end up doing byte accesses to the descriptor
> fields, which in turn can confuse the hardware, and can become very
> slow when they live in dma_alloc_coherent() memory. That looks
> like a completely unrelated issue though.

We know about this, but it doesn't cause issues apart from perhaps
somewhat slower access on some architectures, since all of the
structures live only in DRAM and are not usually used with coherent
memory, just sent to/from the device.

Since the devices really only ship on x86 systems, we decided to ignore
that slight performance issue (for now).

johannes

Re: [PATCH v9 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework

[Cornelia Huck]

On Mon, 13 Aug 2018 17:48:06 -0400
Tony Krowiak  wrote:

> From: Tony Krowiak 
> 
> Registers the matrix device created by the VFIO AP device
> driver with the VFIO mediated device framework.
> Registering the matrix device will create the sysfs
> structures needed to create mediated matrix devices
> each of which will be used to configure the AP matrix
> for a guest and connect it to the VFIO AP device driver.
> 
> Registering the matrix device with the VFIO mediated device
> framework will create the following sysfs structures:
> 
> /sys/devices/vfio_ap/matrix/
> .. [mdev_supported_types]
> . [vfio_ap-passthrough]
>  create
> 
> To create a mediated device for the AP matrix device, write a UUID
> to the create file:
> 
>   uuidgen > create
> 
> A symbolic link to the mediated device's directory will be created in the
> devices subdirectory named after the generated $uuid:
> 
> /sys/devices/vfio_ap/matrix/
> .. [mdev_supported_types]
> . [vfio_ap-passthrough]
>  [devices]
> ... [$uuid]
> 
> A symbolic link to the mediated device will also be created
> in the vfio_ap matrix's directory:
> 
> /sys/devices/vfio_ap/matrix/[$uuid]
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Halil Pasic 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  MAINTAINERS   |1 +
>  drivers/s390/crypto/Makefile  |2 +-
>  drivers/s390/crypto/vfio_ap_drv.c |   23 ++
>  drivers/s390/crypto/vfio_ap_ops.c |  124 
> +
>  drivers/s390/crypto/vfio_ap_private.h |   45 
>  include/uapi/linux/vfio.h |1 +
>  6 files changed, 195 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/s390/crypto/vfio_ap_ops.c
> 


> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
> b/drivers/s390/crypto/vfio_ap_ops.c
> new file mode 100644
> index 000..8018c2d
> --- /dev/null
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Adjunct processor matrix VFIO device driver callbacks.
> + *
> + * Copyright IBM Corp. 2018
> + *
> + * Author(s): Tony Krowiak 
> + * Halil Pasic 
> + * Pierre Morel 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "vfio_ap_private.h"
> +
> +#define VFIO_AP_MDEV_TYPE_HWVIRT "passthrough"
> +#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
> +
> +static void vfio_ap_matrix_init(struct ap_config_info *info,
> + struct ap_matrix *matrix)
> +{
> + matrix->apm_max = info->apxa ? info->Na : 63;
> + matrix->aqm_max = info->apxa ? info->Nd : 15;
> + matrix->adm_max = info->apxa ? info->Nd : 15;
> +}
> +
> +static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device 
> *mdev)
> +{
> + struct ap_matrix_mdev *matrix_mdev;
> +
> + matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
> + if (!matrix_mdev)
> + return -ENOMEM;
> +
> + matrix_mdev->name = dev_name(mdev_dev(mdev));
> + vfio_ap_matrix_init(&matrix_dev.info, &matrix_mdev->matrix);
> + mdev_set_drvdata(mdev, matrix_mdev);
> +
> + if (atomic_dec_if_positive(&matrix_dev.available_instances) < 0) {
> + kfree(matrix_mdev);
> + return -EPERM;
> + }

Maybe move this check to the top of the function?

> +
> + mutex_lock(&matrix_dev.lock);
> + list_add(&matrix_mdev->list, &matrix_dev.mdev_list);
> + mutex_unlock(&matrix_dev.lock);
> +
> + return 0;
> +}

Re: [PATCH v3 02/14] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups

[Pavan Kondeti]

On Mon, Aug 06, 2018 at 05:39:34PM +0100, Patrick Bellasi wrote:
> Utilization clamping requires each CPU to know which clamp values are
> assigned to tasks that are currently RUNNABLE on that CPU.
> Multiple tasks can be assigned the same clamp value and tasks with
> different clamp values can be concurrently active on the same CPU.
> Thus, a proper data structure is required to support a fast and
> efficient aggregation of the clamp values required by the currently
> RUNNABLE tasks.
> 
> For this purpose we use a per-CPU array of reference counters,
> where each slot is used to account how many tasks require a certain
> clamp value are currently RUNNABLE on each CPU.
> Each clamp value corresponds to a "clamp index" which identifies the
> position within the array of reference couters.
> 
>  :
>(user-space changes)  :  (kernel space / scheduler)
>  :
>  SLOW PATH   : FAST PATH
>  :
> task_struct::uclamp::value   : sched/core::enqueue/dequeue
>  : cpufreq_schedutil
>  :
>   ++++ +---+
>   |  TASK  || CLAMP GROUP| |CPU CLAMPS |
>   ++++ +---+
>   |||   clamp_{min,max}  | |  clamp_{min,max}  |
>   | util_{min,max} ||  se_count  | |tasks count|
>   ++++ +---+
>  :
>+-->  :  +--->
> group_id = map(clamp_value)  :  ref_count(group_id)
>  :
>  :
> 
> Let's introduce the support to map tasks to "clamp groups".
> Specifically we introduce the required functions to translate a
> "clamp value" into a clamp's "group index" (group_id).
> 
> Only a limited number of (different) clamp values are supported since:
> 1. there are usually only few classes of workloads for which it makes
>sense to boost/limit to different frequencies,
>e.g. background vs foreground, interactive vs low-priority
> 2. it allows a simpler and more memory/time efficient tracking of
>the per-CPU clamp values in the fast path.
> 
> The number of possible different clamp values is currently defined at
> compile time. Thus, setting a new clamp value for a task can result into
> a -ENOSPC error in case this will exceed the number of maximum different
> clamp values supported.
> 

I see that we drop reference on the previous clamp group when a task changes
its clamp limits. What about exiting tasks which claimed clamp groups? should
not we drop the reference?

Thanks,
Pavan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 5/7] drivers: misc: ad525x_dpot: Update MODULE AUTHOR email address

[michael.hennerich]

From: Michael Hennerich 

no functional changes

Signed-off-by: Michael Hennerich 
---
 drivers/misc/ad525x_dpot-i2c.c | 2 +-
 drivers/misc/ad525x_dpot-spi.c | 2 +-
 drivers/misc/ad525x_dpot.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/ad525x_dpot-i2c.c b/drivers/misc/ad525x_dpot-i2c.c
index 4f83200..1827c69 100644
--- a/drivers/misc/ad525x_dpot-i2c.c
+++ b/drivers/misc/ad525x_dpot-i2c.c
@@ -114,6 +114,6 @@ static struct i2c_driver ad_dpot_i2c_driver = {
 
 module_i2c_driver(ad_dpot_i2c_driver);
 
-MODULE_AUTHOR("Michael Hennerich ");
+MODULE_AUTHOR("Michael Hennerich ");
 MODULE_DESCRIPTION("digital potentiometer I2C bus driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/misc/ad525x_dpot-spi.c b/drivers/misc/ad525x_dpot-spi.c
index 39a7f51..0383ec1 100644
--- a/drivers/misc/ad525x_dpot-spi.c
+++ b/drivers/misc/ad525x_dpot-spi.c
@@ -140,7 +140,7 @@ static struct spi_driver ad_dpot_spi_driver = {
 
 module_spi_driver(ad_dpot_spi_driver);
 
-MODULE_AUTHOR("Michael Hennerich ");
+MODULE_AUTHOR("Michael Hennerich ");
 MODULE_DESCRIPTION("digital potentiometer SPI bus driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("spi:ad_dpot");
diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
index bc591b7..a0afade 100644
--- a/drivers/misc/ad525x_dpot.c
+++ b/drivers/misc/ad525x_dpot.c
@@ -1,7 +1,7 @@
 /*
  * ad525x_dpot: Driver for the Analog Devices digital potentiometers
  * Copyright (c) 2009-2010 Analog Devices, Inc.
- * Author: Michael Hennerich 
+ * Author: Michael Hennerich 
  *
  * DEVID   #Wipers #Positions  Resistor Options (kOhm)
  * AD5258  1   64  1, 10, 50, 100
@@ -64,7 +64,7 @@
  * Author: Chris Verges 
  *
  * derived from ad5252.c
- * Copyright (c) 2006-2011 Michael Hennerich 
+ * Copyright (c) 2006-2011 Michael Hennerich 
  *
  * Licensed under the GPL-2 or later.
  */
@@ -760,6 +760,6 @@ EXPORT_SYMBOL(ad_dpot_remove);
 
 
 MODULE_AUTHOR("Chris Verges , "
- "Michael Hennerich ");
+ "Michael Hennerich ");
 MODULE_DESCRIPTION("Digital potentiometer driver");
 MODULE_LICENSE("GPL");
-- 
2.7.4

[PATCH 7/7] drivers: mfd: adp5520: Update MODULE AUTHOR email address

[michael.hennerich]

From: Michael Hennerich 

no functional changes

Signed-off-by: Michael Hennerich 
---
 drivers/mfd/adp5520.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index d817f20..be0497b 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -360,6 +360,6 @@ static struct i2c_driver adp5520_driver = {
 
 module_i2c_driver(adp5520_driver);
 
-MODULE_AUTHOR("Michael Hennerich ");
+MODULE_AUTHOR("Michael Hennerich ");
 MODULE_DESCRIPTION("ADP5520(01) PMIC-MFD Driver");
 MODULE_LICENSE("GPL");
-- 
2.7.4

[GIT PULL] arm64: updates for 4.19

[Will Deacon]

Hi Linus,

Please pull these arm64 updates for 4.19. Details in the tag, but please be
aware that we've pulled in the x86/mm branch from -tip so that we can make
use of the core ioremap changes which allow us to put down huge mappings
in the vmalloc area without screwing up the TLB. Much of the positive
diffstat is because of the rseq selftest for arm64.

There is a trivial conflict in arch/arm64/Makefile with your tree, since
we effectively rewrote a fix that was merged in -rc5 [96f95a17c1cf]. The
correct resolution is therefore to prefer the code using ld-option, which
is what we have here. We also ran into a couple of trivial conflicts that
were resolved in -next with the KVM and EFI trees.

Cheers,

Will

--->8

The following changes since commit 5e0fb5df2ee871b841f96f9cb6a7f2784e96aa4e:

  x86/mm: Add TLB purge to free pmd/pte page interfaces (2018-07-04 21:37:09 
+0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
tags/arm64-upstream

for you to fetch changes up to 3c4d9137eefecf273a520d392071ffc9df0a9a7a:

  arm64: alternative: Use true and false for boolean values (2018-08-08 
11:20:54 +0100)


arm64 updates for 4.19

A bunch of good stuff in here:

- Wire up support for qspinlock, replacing our trusty ticket lock code

- Add an IPI to flush_icache_range() to ensure that stale instructions
  fetched into the pipeline are discarded along with the I-cache lines

- Support for the GCC "stackleak" plugin

- Support for restartable sequences, plus an arm64 port for the selftest

- Kexec/kdump support on systems booting with ACPI

- Rewrite of our syscall entry code in C, which allows us to zero the
  GPRs on entry from userspace

- Support for chained PMU counters, allowing 64-bit event counters to be
  constructed on current CPUs

- Ensure scheduler topology information is kept up-to-date with CPU
  hotplug events

- Re-enable support for huge vmalloc/IO mappings now that the core code
  has the correct hooks to use break-before-make sequences

- Miscellaneous, non-critical fixes and cleanups


AKASHI Takahiro (3):
  drivers: acpi: add dependency of EFI for arm64
  efi/arm: map UEFI memory map even w/o runtime services enabled
  arm64: acpi: fix alignment fault in accessing ACPI

Ard Biesheuvel (2):
  efi/arm: preserve early mapping of UEFI memory map longer for BGRT
  arm64: drop unused kernel_neon_begin_partial() macro

Arnd Bergmann (2):
  arm64: make flatmem depend on !NUMA
  arm64: fix ACPI dependencies

Ben Hutchings (1):
  arm64: mm: Export __sync_icache_dcache() for xen-privcmd

Bhupesh Sharma (1):
  arm64, kaslr: export offset in VMCOREINFO ELF notes

Chintan Pandya (2):
  arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
  arm64: Implement page table free interfaces

Dave Kleikamp (1):
  arm64: kexec: machine_kexec should call __flush_icache_range

Gustavo A. R. Silva (1):
  arm64: alternative: Use true and false for boolean values

James Morse (1):
  arm64: export memblock_reserve()d regions via /proc/iomem

Kees Cook (1):
  perf/arm-cci: Remove VLA usage

Laura Abbott (3):
  arm64: Add stack information to on_accessible_stack
  arm64: Add support for STACKLEAK gcc plugin
  efi/libstub: Only disable stackleak plugin for arm64

Lorenzo Pieralisi (1):
  arm64: numa: rework ACPI NUMA initialization

Mark Rutland (30):
  arm64: kexec: always reset to EL2 if present
  arm64: add PSR_AA32_* definitions
  arm64: don't zero DIT on signal return
  arm64: compat: map SPSR_ELx<->PSR for signals
  arm64: ptrace: map SPSR_ELx<->PSR for compat tasks
  arm64: use PSR_AA32 definitions
  kvm/arm: use PSR_AA32 definitions
  arm64: remove unused COMPAT_PSR definitions
  arm64: consistently use unsigned long for thread flags
  arm64: move SCTLR_EL{1,2} assertions to 
  arm64: kill config_sctlr_el1()
  arm64: kill change_cpacr()
  arm64: move sve_user_{enable,disable} to 
  arm64: remove sigreturn wrappers
  arm64: introduce syscall_fn_t
  arm64: convert raw syscall invocation to C
  arm64: convert syscall trace logic to C
  arm64: convert native/compat syscall entry to C
  arm64: don't restore GPRs when context tracking
  arm64: don't reload GPRs after apply_ssbd
  arm64: zero GPRs upon entry from EL0
  arm64: drop alignment from syscall tables
  kernel: add ksys_personality()
  kernel: add kcompat_sys_{f,}statfs64()
  arm64: remove in-kernel call to sys_personality()
  arm64: use {COMPAT,}SYSCALL_DEFINE0 for sigreturn
  arm64: use SYSCALL_DEFINE6() for mmap
  arm64: convert compat wrappers to C
  arm64: implement syscall wrappers
  arm64: fix possible spectre-v1 write in ptrace_hbp_set_event()

Michael O'Farrell (1):
  arm6

Re: [PATCH V4 4/7] mmc: sdhci: add 32-bit block count support for v4 mode

[Adrian Hunter]

On 07/08/18 04:58, Jason Wu (吴霁爽) wrote:
>  
> 
> According the information of following picture, in this case I think, we
> just have 2 choice in sdio v4.1:
> 
> 1 do not define SDHCI_AUTO_CMD23: argument of cmd23 will define in register
> 0x8(Argument register)

That would only need to be done for requests that use the upper bits. i.e.
Perhaps hook host->mmc_host_ops->request() and check if sbc argument is ok.
Then toggle SDHCI_AUTO_CMD23 accordingly.

> 
> 2 or define SDHCI_USE_ADMA: block count of cmd18/28 will be get in “Command
> Descriptor for SD Mod”of ADMA. And block cnt register will be used as
> parameter of auto cmd23.
> 
> -Original Message-
> From: Chunyan Zhang [mailto:zhang.l...@gmail.com]
> Sent: Monday, August 06, 2018 7:29 PM
> To: Adrian Hunter
> Cc: Chunyan Zhang; Ulf Hansson; linux-...@vger.kernel.org; Linux Kernel
> Mailing List; Orson Zhai; Baolin Wang; Billows Wu (武洪涛); Jason Wu (吴霁爽)
> Subject: Re: [PATCH V4 4/7] mmc: sdhci: add 32-bit block count support for
> v4 mode
> 
>  
> 
> Hi Adrian,
> 
>  
> 
> On 30 July 2018 at 21:05, Adrian Hunter  > wrote:
> 
>> On 24/07/18 05:51, Chunyan Zhang wrote:
> 
>>> Host Controller Version 4.10 re-defines SDMA System Address register
> 
>>> as 32-bit Block Count for v4 mode, and SDMA uses ADMA System Address
> 
>>> register (05Fh-058h) instead if v4 mode is enabled. Also when using
> 
>>> 32-bit block count, 16-bit block count register need to be set to
> 
>>> zero.
> 
>>> 
> 
>>> Signed-off-by: Chunyan Zhang >> >
> 
>>> ---
> 
>>>  drivers/mmc/host/sdhci.c | 14 +- 
> 
>>> drivers/mmc/host/sdhci.h |  1 +
> 
>>>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
>>> 
> 
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> 
>>> index 920d8ec..c272a2b 100644
> 
>>> --- a/drivers/mmc/host/sdhci.c
> 
>>> +++ b/drivers/mmc/host/sdhci.c
> 
>>> @@ -1070,7 +1070,19 @@ static void sdhci_prepare_data(struct sdhci_host 
>>> *host, struct mmc_command *cmd)
> 
>>>   /* Set the DMA boundary value and block size */
> 
>>>   sdhci_writew(host, SDHCI_MAKE_BLKSZ(host->sdma_boundary, data->blksz),
> 
>>>    SDHCI_BLOCK_SIZE);
> 
>>> - sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
> 
>>> +
> 
>>> + /*
> 
>>> +  * For Version 4.10 onwards, if v4 mode is enabled, 16-bit Block Count
> 
>>> +  * register need to be set to zero, 32-bit Block Count register would
> 
>>> +  * be selected.
> 
>>> +  */
> 
>>> + if (host->version >= SDHCI_SPEC_410 && host->v4_mode) {
> 
>>> + if (sdhci_readw(host, SDHCI_BLOCK_COUNT))
> 
>>> + sdhci_writew(host, 0, SDHCI_BLOCK_COUNT);
> 
>>> + sdhci_writew(host, data->blocks, SDHCI_32BIT_BLK_CNT);
> 
>> 
> 
>> So this is also SDHCI_ARGUMENT2 which is why there is a conflict with
> 
>> auto-CMD23.  We need to write SDHCI_32BIT_BLK_CNT only once, but also
> 
>> cater for eMMC which uses the CMD23 argument for more than just block count.
> 
>> 
> 
>  
> 
> What you would suggest on how should we change here?
> 
>  
> 
> I've double checked with the hardware fellow within the company, the sd host
> controller v4 (on our platform at least) would  use this register as block
> count only, that's saying that it would not deal with the flags (i.e.
> reliable write and data tag) of CMD23.
> 
>  
> 
> Thanks,
> 
> Chunyan
> 
>  
> 
>>> + } else {
> 
>>> + sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
> 
>>> + }
> 
>>>  }
> 
>>> 
> 
>>>  static inline bool sdhci_auto_cmd12(struct sdhci_host *host, diff
> 
>>> --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index
> 
>>> 23318ff..81aae07 100644
> 
>>> --- a/drivers/mmc/host/sdhci.h
> 
>>> +++ b/drivers/mmc/host/sdhci.h
> 
>>> @@ -28,6 +28,7 @@
> 
>>> 
> 
>>>  #define SDHCI_DMA_ADDRESS    0x00
> 
>>>  #define SDHCI_ARGUMENT2  SDHCI_DMA_ADDRESS
> 
>>> +#define SDHCI_32BIT_BLK_CNT  SDHCI_DMA_ADDRESS
> 
>>> 
> 
>>>  #define SDHCI_BLOCK_SIZE 0x04
> 
>>>  #define  SDHCI_MAKE_BLKSZ(dma, blksz) (((dma & 0x7) << 12) | (blksz
> 
>>> & 0xFFF))
> 
>>> 
> 
>> 
> 

Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe controller driver

[kbuild test robot]

Hi Yue,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pci/next]
[also build test WARNING on v4.18 next-20180813]
[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/Hanjie-Lin/dt-bindings-PCI-meson-add-DT-bindings-for-Amlogic-Meson-PCIe-controller/20180814-180019
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/pci/controller/dwc/pci-meson.c:121:1-3: WARNING: PTR_ERR_OR_ZERO can 
>> be used

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

[PATCH] PCI: meson: fix ptr_ret.cocci warnings

[kbuild test robot]

From: kbuild test robot 

drivers/pci/controller/dwc/pci-meson.c:121:1-3: WARNING: PTR_ERR_OR_ZERO can be 
used


 Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Fixes: b43bb00f7533 ("PCI: meson: add the Amlogic Meson PCIe controller driver")
CC: Yue Wang 
Signed-off-by: kbuild test robot 
---

 pci-meson.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -118,10 +118,7 @@ static int meson_pcie_get_mem(struct pla
return -ENODEV;
 
mp->mem_res.cfg_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mp->mem_res.cfg_base))
-   return PTR_ERR(mp->mem_res.cfg_base);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(mp->mem_res.cfg_base);
 }
 
 static int meson_pcie_init_clk(struct meson_pcie *mp)

Re: [PATCH v3 0/2] arm64: dts: meson-g12a: Introduce new DT files for Meson-G12A SoC

[Jerome Brunet]

On Tue, 2018-08-14 at 18:38 +0800, Jianxin Pan wrote:
> This attempt will try to add new DT files to support Meson-G12A SoC.
> 
> 1) first, Please notice that, in this patch series, the DT node about 16M 
> reserved
> memory for hwrom is removed, since it's not needed by G12A SoC.
> 2) second, the pclk for uart_AO need to be fixed once G12A clock_ao driver is
> merged. In this version, it rely on bootloader to enable the pclk gate which 
> belong to AO clock domain. Please add clk_ignore_unused to bootargs.
> 
> Changes since v2 [1]:
>  - reorder subnodes
>  - collect Rob's Reviewed-by
> 
> Changes since v1 [0]:
>  - fix signoff typo
>  - order subnodes by addresses when there is one and alphabetically when 
> there is none
> 
> [0] 
> https://lore.kernel.org/lkml/1533802951-49919-2-git-send-email-jianxin@amlogic.com/
> 
> Jianxin Pan (2):
>   dt-bindings: arm: amlogic: Add Meson G12A binding
>   arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT support
> 
>  Documentation/devicetree/bindings/arm/amlogic.txt |   6 +
>  arch/arm64/boot/dts/amlogic/Makefile  |   1 +
>  arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts   |  22 +++
>  arch/arm64/boot/dts/amlogic/meson-g12a.dtsi   | 172 
> ++
>  4 files changed, 201 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
> 

Series looks good as far as I can tell

Reviewed-by: Jerome Brunet 

[PATCH v12 03/14] clk: qcom: Add HFPLL driver

[Sricharan R]

From: Stephen Boyd 

On some devices (MSM8974 for example), the HFPLLs are
instantiated within the Krait processor subsystem as separate
register regions. Add a driver for these PLLs so that we can
provide HFPLL clocks for use by the system.

Cc: 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/Kconfig  |  8 
 drivers/clk/qcom/Makefile |  1 +
 drivers/clk/qcom/hfpll.c  | 96 +++
 3 files changed, 105 insertions(+)
 create mode 100644 drivers/clk/qcom/hfpll.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0647686..21aec10 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -272,3 +272,11 @@ config SPMI_PMIC_CLKDIV
  Technologies, Inc. SPMI PMIC. It configures the frequency of
  clkdiv outputs of the PMIC. These clocks are typically wired
  through alternate functions on GPIO pins.
+
+config QCOM_HFPLL
+   tristate "High-Frequency PLL (HFPLL) Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the high-frequency PLLs present on Qualcomm devices.
+ Say Y if you want to support CPU frequency scaling on devices
+ such as MSM8974, APQ8084, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7818e6c..f82eeac 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
 obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
 obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
+obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
new file mode 100644
index 000..a6de7101
--- /dev/null
+++ b/drivers/clk/qcom/hfpll.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-regmap.h"
+#include "clk-hfpll.h"
+
+static const struct hfpll_data hdata = {
+   .mode_reg = 0x00,
+   .l_reg = 0x04,
+   .m_reg = 0x08,
+   .n_reg = 0x0c,
+   .user_reg = 0x10,
+   .config_reg = 0x14,
+   .config_val = 0x430405d,
+   .status_reg = 0x1c,
+   .lock_bit = 16,
+
+   .user_val = 0x8,
+   .user_vco_mask = 0x10,
+   .low_vco_max_rate = 124800,
+   .min_rate = 53760UL,
+   .max_rate = 29UL,
+};
+
+static const struct of_device_id qcom_hfpll_match_table[] = {
+   { .compatible = "qcom,hfpll" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_hfpll_match_table);
+
+static const struct regmap_config hfpll_regmap_config = {
+   .reg_bits   = 32,
+   .reg_stride = 4,
+   .val_bits   = 32,
+   .max_register   = 0x30,
+   .fast_io= true,
+};
+
+static int qcom_hfpll_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   struct device *dev = &pdev->dev;
+   void __iomem *base;
+   struct regmap *regmap;
+   struct clk_hfpll *h;
+   struct clk_init_data init = {
+   .parent_names = (const char *[]){ "xo" },
+   .num_parents = 1,
+   .ops = &clk_ops_hfpll,
+   };
+
+   h = devm_kzalloc(dev, sizeof(*h), GFP_KERNEL);
+   if (!h)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   regmap = devm_regmap_init_mmio(&pdev->dev, base, &hfpll_regmap_config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   if (of_property_read_string_index(dev->of_node, "clock-output-names",
+ 0, &init.name))
+   return -ENODEV;
+
+   h->d = &hdata;
+   h->clkr.hw.init = &init;
+   spin_lock_init(&h->lock);
+
+   return devm_clk_register_regmap(&pdev->dev, &h->clkr);
+}
+
+static struct platform_driver qcom_hfpll_driver = {
+   .probe  = qcom_hfpll_probe,
+   .driver = {
+   .name   = "qcom-hfpll",
+   .of_match_table = qcom_hfpll_match_table,
+   },
+};
+module_platform_driver(qcom_hfpll_driver);
+
+MODULE_DESCRIPTION("QCOM HFPLL Clock Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:qcom-hfpll");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 02/14] clk: qcom: Add support for High-Frequency PLLs (HFPLLs)

[Sricharan R]

From: Stephen Boyd 

HFPLLs are the main frequency source for Krait CPU clocks. Add
support for changing the rate of these PLLs.

Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-hfpll.c | 244 +++
 drivers/clk/qcom/clk-hfpll.h |  44 
 3 files changed, 289 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-hfpll.c
 create mode 100644 drivers/clk/qcom/clk-hfpll.h

diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 21a4503..7818e6c 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -11,6 +11,7 @@ clk-qcom-y += clk-branch.o
 clk-qcom-y += clk-regmap-divider.o
 clk-qcom-y += clk-regmap-mux.o
 clk-qcom-y += clk-regmap-mux-div.o
+clk-qcom-y += clk-hfpll.o
 clk-qcom-y += reset.o
 clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
 
diff --git a/drivers/clk/qcom/clk-hfpll.c b/drivers/clk/qcom/clk-hfpll.c
new file mode 100644
index 000..3c04805
--- /dev/null
+++ b/drivers/clk/qcom/clk-hfpll.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-regmap.h"
+#include "clk-hfpll.h"
+
+#define PLL_OUTCTRLBIT(0)
+#define PLL_BYPASSNL   BIT(1)
+#define PLL_RESET_NBIT(2)
+
+/* Initialize a HFPLL at a given rate and enable it. */
+static void __clk_hfpll_init_once(struct clk_hw *hw)
+{
+   struct clk_hfpll *h = to_clk_hfpll(hw);
+   struct hfpll_data const *hd = h->d;
+   struct regmap *regmap = h->clkr.regmap;
+
+   if (likely(h->init_done))
+   return;
+
+   /* Configure PLL parameters for integer mode. */
+   if (hd->config_val)
+   regmap_write(regmap, hd->config_reg, hd->config_val);
+   regmap_write(regmap, hd->m_reg, 0);
+   regmap_write(regmap, hd->n_reg, 1);
+
+   if (hd->user_reg) {
+   u32 regval = hd->user_val;
+   unsigned long rate;
+
+   rate = clk_hw_get_rate(hw);
+
+   /* Pick the right VCO. */
+   if (hd->user_vco_mask && rate > hd->low_vco_max_rate)
+   regval |= hd->user_vco_mask;
+   regmap_write(regmap, hd->user_reg, regval);
+   }
+
+   if (hd->droop_reg)
+   regmap_write(regmap, hd->droop_reg, hd->droop_val);
+
+   h->init_done = true;
+}
+
+static void __clk_hfpll_enable(struct clk_hw *hw)
+{
+   struct clk_hfpll *h = to_clk_hfpll(hw);
+   struct hfpll_data const *hd = h->d;
+   struct regmap *regmap = h->clkr.regmap;
+   u32 val;
+
+   __clk_hfpll_init_once(hw);
+
+   /* Disable PLL bypass mode. */
+   regmap_update_bits(regmap, hd->mode_reg, PLL_BYPASSNL, PLL_BYPASSNL);
+
+   /*
+* H/W requires a 5us delay between disabling the bypass and
+* de-asserting the reset. Delay 10us just to be safe.
+*/
+   udelay(10);
+
+   /* De-assert active-low PLL reset. */
+   regmap_update_bits(regmap, hd->mode_reg, PLL_RESET_N, PLL_RESET_N);
+
+   /* Wait for PLL to lock. */
+   if (hd->status_reg) {
+   do {
+   regmap_read(regmap, hd->status_reg, &val);
+   } while (!(val & BIT(hd->lock_bit)));
+   } else {
+   udelay(60);
+   }
+
+   /* Enable PLL output. */
+   regmap_update_bits(regmap, hd->mode_reg, PLL_OUTCTRL, PLL_OUTCTRL);
+}
+
+/* Enable an already-configured HFPLL. */
+static int clk_hfpll_enable(struct clk_hw *hw)
+{
+   unsigned long flags;
+   struct clk_hfpll *h = to_clk_hfpll(hw);
+   struct hfpll_data const *hd = h->d;
+   struct regmap *regmap = h->clkr.regmap;
+   u32 mode;
+
+   spin_lock_irqsave(&h->lock, flags);
+   regmap_read(regmap, hd->mode_reg, &mode);
+   if (!(mode & (PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL)))
+   __clk_hfpll_enable(hw);
+   spin_unlock_irqrestore(&h->lock, flags);
+
+   return 0;
+}
+
+static void __clk_hfpll_disable(struct clk_hfpll *h)
+{
+   struct hfpll_data const *hd = h->d;
+   struct regmap *regmap = h->clkr.regmap;
+
+   /*
+* Disable the PLL output, disable test mode, enable the bypass mode,
+* and assert the reset.
+*/
+   regmap_update_bits(regmap, hd->mode_reg,
+  PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL, 0);
+}
+
+static void clk_hfpll_disable(struct clk_hw *hw)
+{
+   struct clk_hfpll *h = to_clk_hfpll(hw);
+   unsigned long flags;
+
+   spin_lock_irqsave(&h->lock, flags);
+   __clk_hfpll_disable(h);
+   spin_unlock_irqrestore(&h->lock, flags);
+}
+
+static long clk_hfpll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct clk_hfpll *h = to_clk_hfpll(hw);
+   struct hfpll_data const *hd = h->d;

[PATCH V12 00/14] Krait clocks + Krait CPUfreq

[Sricharan R]

[v12]
  * Added my signed-off that was missing in some patches.
  * Added Bjorn's acked that i missed earlier.

[v11]
  * Dropped patch 13 and 14 from v10 and
merged the qcom-cpufreq-krait driver to the existing qcom-cpufreq-kryo.c
  * Rebased on top of clk-next
  * Fixed a bug while populating the pvs version for krait.

[v10]
  * Addressed Stephen's comments to add clocks bindings properties
to the newly introduced nodes.
  * Added a change to include opp-supported-hw to qcom-cpufreq.c
  * Rebased on top of clk-next
  * Although there were minor changes to bindings and the driver
retained the acked-by tags from Rob and Viresh respectively.

[v9]
  * Fixed a rebase issue in Makefile and added Tag from Robh.

[v8]
  * Fixed a bug in path#14 pointed out by Viresh and also added tags.
No change in any other patch.

[v7]
  * Fixed comments from Viresh for cleaning up the error handling
in qcom-cpufreq.c. Also changed the init function to lateinit
call. This is required because nvmem which gets initialised with
module_init needs to go first.
  * Fixed Rob's comments for bindings documentation
  * Fixed kbuild build issue in clk-lpc32xx.c
  * Rebased on top of clk-next

[v6]
  * Adrressed comments from Viresh for patch #14 in v5 [5]
  * Introduced a new binding operating-points-v2-krait-cpu
as per discussion with Rob
  * Added Review tags

[v5]
  * Addressed comments from Rob for bindings
  * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, accordingly
dropped patch #12 and corrected patch #11 from previous patch set in [4]
  * Converted to use #spdx tags for newly introduced files

Mostly a resend of the v3 posted by Stephen quite some time back [1]
except for few changes.
  Based on reading some feedback from list,
  * Dropped the patch "clk: Add safe switch hook" from v3 [2].
Now this is taken care by patch#10 in this series only for Krait.
  * Dropped the path "clk: Avoid sending high rates to downstream
  clocks during set_rate" from v3 [3].
  * Rebased on top of clk-next.
  * Dropped the DT update from the series. Will send separately
  * Now with cpufreq-dt+opp supporting voltage scaling, registering the
krait cpu supplies in DT should be sufficient. But one issue is,
the qcom-cpufreq drivers reads the efuse and based on that registers
the opp data and then registers the cpufreq-dt device. So when
cpufreq-dt driver probes and registers the regulator to the OPP framework,
it expects that the opp data for the device should not be registered before
the regulator. Will send a RFC patch removing that check, to find out the
right way of doing it.

These patches provide cpufreq scaling on devices with Krait CPUs.
In Krait CPU designs there's one PLL and two muxes per CPU, allowing
us to switch CPU frequencies independently.

 secondary
 +-++
 | QSB |---+|\
 +-+   || |-+
   |+---|/  |
   ||   +   |
 +-+   ||   |
 | PLL |+---+   |   primary
 +-+|  || +
|  |+-|\   +--+
 +---+  |  |  | \  |  |
 | HFPLL |--+-|  |-| CPU0 |
 +---+  |  || |  | |  |
|  || +-+ | /  +--+
|  |+-| / 2 |-|/
|  |  +-+ +
|  | secondary
|  |+
|  +|\
|   | |-+
+---|/  |   primary
+   | +
+-|\   +--+
 +---+| \  |  |
 | HFPLL ||  |-| CPU1 |
 +---+  | |  | |  |
| +-+ | /  +--+
+-| / 2 |-|/
  +-+ +

To support this in the common clock framework we model the muxes,
dividers, and PLLs as different clocks. CPUfreq only interacts
with the primary mux (farthest right in the diagram). When CPUfreq
sets a rate, the mux code finds the best parent that can provide the rate.
Due to the design, QSB and the top PLL are always a fixed rate and thus
only support one frequency each. These sources provide the lowest
frequencies for the CPUs. The HFPLLs are where we can make the CPU go
faster (GHz range). Sometimes we need to run the HFPLL twice as
fast and divide it by two to get a particular frequency.

When switching rates we can't leave 

[PATCH v12 04/14] dt-bindings: clock: Document qcom,hfpll

[Sricharan R]

From: Stephen Boyd 

Adds bindings document for qcom,hfpll instantiated within
the Krait processor subsystem as separate register region.

Reviewed-by: Rob Herring 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 .../devicetree/bindings/clock/qcom,hfpll.txt   | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt

diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt 
b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
new file mode 100644
index 000..ec02a02
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
@@ -0,0 +1,60 @@
+High-Frequency PLL (HFPLL)
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: :
+   shall contain only one of the following. The generic
+   compatible "qcom,hfpll" should be also included.
+
+"qcom,hfpll-ipq8064", "qcom,hfpll"
+"qcom,hfpll-apq8064", "qcom,hfpll"
+"qcom,hfpll-msm8974", "qcom,hfpll"
+"qcom,hfpll-msm8960", "qcom,hfpll"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: address and size of HPLL registers. An optional second
+   element specifies the address and size of the alias
+   register region.
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo".
+
+- clock-output-names:
+   Usage: required
+   Value type: 
+   Definition: Name of the PLL. Typically hfpllX where X is a CPU number
+   starting at 0. Otherwise hfpll_Y where Y is more specific
+   such as "l2".
+
+Example:
+
+1) An HFPLL for the L2 cache.
+
+   clock-controller@f9016000 {
+   compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
+   reg = <0xf9016000 0x30>;
+   clocks = <&xo_board>;
+   clock-names = "xo";
+   clock-output-names = "hfpll_l2";
+   };
+
+2) An HFPLL for CPU0. This HFPLL has the alias register region.
+
+   clock-controller@f908a000 {
+   compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
+   reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
+   clocks = <&xo_board>;
+   clock-names = "xo";
+   clock-output-names = "hfpll0";
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 01/14] ARM: Add Krait L2 register accessor functions

[Sricharan R]

From: Stephen Boyd 

Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection register (l2cpselr) to point the L2 'window'
register (l2cpdr) at what you want to read/write.  Then you
read/write the 'window' register to do what you want. The
l2cpselr register is not banked per-cpu so we must lock around
accesses to it to prevent other CPUs from re-pointing l2cpdr
underneath us.

Cc: Mark Rutland 
Cc: Russell King 
Acked-by: Bjorn Andersson 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 arch/arm/common/Kconfig   |  3 ++
 arch/arm/common/Makefile  |  1 +
 arch/arm/common/krait-l2-accessors.c  | 48 +++
 arch/arm/include/asm/krait-l2-accessors.h |  9 ++
 4 files changed, 61 insertions(+)
 create mode 100644 arch/arm/common/krait-l2-accessors.c
 create mode 100644 arch/arm/include/asm/krait-l2-accessors.h

diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index e5ad070..c8e1986 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -7,6 +7,9 @@ config DMABOUNCE
bool
select ZONE_DMA
 
+config KRAIT_L2_ACCESSORS
+   bool
+
 config SHARP_LOCOMO
bool
 
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 3157be4..219a260 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -7,6 +7,7 @@ obj-y   += firmware.o
 
 obj-$(CONFIG_SA)   += sa.o
 obj-$(CONFIG_DMABOUNCE)+= dmabounce.o
+obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
 obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
 obj-$(CONFIG_SHARP_PARAM)  += sharpsl_param.o
 obj-$(CONFIG_SHARP_SCOOP)  += scoop.o
diff --git a/arch/arm/common/krait-l2-accessors.c 
b/arch/arm/common/krait-l2-accessors.c
new file mode 100644
index 000..9a97dda
--- /dev/null
+++ b/arch/arm/common/krait-l2-accessors.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+
+#include 
+#include 
+
+static DEFINE_RAW_SPINLOCK(krait_l2_lock);
+
+void krait_set_l2_indirect_reg(u32 addr, u32 val)
+{
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&krait_l2_lock, flags);
+   /*
+* Select the L2 window by poking l2cpselr, then write to the window
+* via l2cpdr.
+*/
+   asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
+   isb();
+   asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val));
+   isb();
+
+   raw_spin_unlock_irqrestore(&krait_l2_lock, flags);
+}
+EXPORT_SYMBOL(krait_set_l2_indirect_reg);
+
+u32 krait_get_l2_indirect_reg(u32 addr)
+{
+   u32 val;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&krait_l2_lock, flags);
+   /*
+* Select the L2 window by poking l2cpselr, then read from the window
+* via l2cpdr.
+*/
+   asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
+   isb();
+   asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val));
+
+   raw_spin_unlock_irqrestore(&krait_l2_lock, flags);
+
+   return val;
+}
+EXPORT_SYMBOL(krait_get_l2_indirect_reg);
diff --git a/arch/arm/include/asm/krait-l2-accessors.h 
b/arch/arm/include/asm/krait-l2-accessors.h
new file mode 100644
index 000..a5f2cdd
--- /dev/null
+++ b/arch/arm/include/asm/krait-l2-accessors.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
+#define __ASMARM_KRAIT_L2_ACCESSORS_H
+
+extern void krait_set_l2_indirect_reg(u32 addr, u32 val);
+extern u32 krait_get_l2_indirect_reg(u32 addr);
+
+#endif
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 05/14] clk: qcom: Add MSM8960/APQ8064's HFPLLs

[Sricharan R]

From: Stephen Boyd 

Describe the HFPLLs present on MSM8960 and APQ8064 devices.

Acked-by: Rob Herring  (bindings)
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/gcc-msm8960.c   | 172 +++
 include/dt-bindings/clock/qcom,gcc-msm8960.h |   2 +
 2 files changed, 174 insertions(+)

diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index fd495e0..3994747 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -30,6 +30,7 @@
 #include "clk-pll.h"
 #include "clk-rcg.h"
 #include "clk-branch.h"
+#include "clk-hfpll.h"
 #include "reset.h"
 
 static struct clk_pll pll3 = {
@@ -86,6 +87,164 @@
},
 };
 
+static struct hfpll_data hfpll0_data = {
+   .mode_reg = 0x3200,
+   .l_reg = 0x3208,
+   .m_reg = 0x320c,
+   .n_reg = 0x3210,
+   .config_reg = 0x3204,
+   .status_reg = 0x321c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3214,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll0 = {
+   .d = &hfpll0_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll0",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll0.lock),
+};
+
+static struct hfpll_data hfpll1_8064_data = {
+   .mode_reg = 0x3240,
+   .l_reg = 0x3248,
+   .m_reg = 0x324c,
+   .n_reg = 0x3250,
+   .config_reg = 0x3244,
+   .status_reg = 0x325c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3254,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct hfpll_data hfpll1_data = {
+   .mode_reg = 0x3300,
+   .l_reg = 0x3308,
+   .m_reg = 0x330c,
+   .n_reg = 0x3310,
+   .config_reg = 0x3304,
+   .status_reg = 0x331c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3314,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll1 = {
+   .d = &hfpll1_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll1",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll1.lock),
+};
+
+static struct hfpll_data hfpll2_data = {
+   .mode_reg = 0x3280,
+   .l_reg = 0x3288,
+   .m_reg = 0x328c,
+   .n_reg = 0x3290,
+   .config_reg = 0x3284,
+   .status_reg = 0x329c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3294,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll2 = {
+   .d = &hfpll2_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll2",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll2.lock),
+};
+
+static struct hfpll_data hfpll3_data = {
+   .mode_reg = 0x32c0,
+   .l_reg = 0x32c8,
+   .m_reg = 0x32cc,
+   .n_reg = 0x32d0,
+   .config_reg = 0x32c4,
+   .status_reg = 0x32dc,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x32d4,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll3 = {
+   .d = &hfpll3_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll3",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll3.lock),
+};
+
+static struct hfpll_data hfpll_l2_8064_data = {
+   .mode_reg = 0x3300,
+   .l_reg = 0x3308,
+   .m_reg = 0x330c,
+   .n_reg = 0x3310,
+   .config_reg = 0x3304,
+   .status_reg = 0x331c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3314,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct hfpll_data hfpll_l2_data = {
+   .mode_reg = 0x3400,
+   .l_reg = 0x3408,
+   .m_reg = 0x340c,
+   .n_reg = 0x3410,
+   .config_reg = 0x3404,
+   .status_reg = 0x341c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3414,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll_l2 = {
+   .d = &hfpll_l2_data,
+   .

[PATCH v12 11/14] dt-bindings: clock: Document qcom,krait-cc

[Sricharan R]

From: Stephen Boyd 

The Krait clock controller controls the krait CPU and the L2 clocks
consisting a primary mux and secondary mux. Add document for that.

Reviewed-by: Rob Herring 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 .../devicetree/bindings/clock/qcom,krait-cc.txt| 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt

diff --git a/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt 
b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
new file mode 100644
index 000..030ba60
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
@@ -0,0 +1,34 @@
+Krait Clock Controller
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,krait-cc-v1"
+   "qcom,krait-cc-v2"
+
+- #clock-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the clock parents of hfpll, secondary muxes.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb".
+
+Example:
+
+   kraitcc: clock-controller {
+   compatible = "qcom,krait-cc-v1";
+   clocks = <&hfpll0>, <&hfpll1>, <&acpu0_aux>, <&acpu1_aux>, 
;
+   clock-names = "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", 
"qsb";
+   #clock-cells = <1>;
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 08/14] clk: qcom: Add KPSS ACC/GCC driver

[Sricharan R]

From: Stephen Boyd 

The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. For CPUfreq
purposes probe these devices and expose a mux clock that chooses
between PXO and PLL8.

Cc: 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/Kconfig|  8 +
 drivers/clk/qcom/Makefile   |  1 +
 drivers/clk/qcom/kpss-xcc.c | 87 +
 3 files changed, 96 insertions(+)
 create mode 100644 drivers/clk/qcom/kpss-xcc.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index ada4160..7a99627 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -281,6 +281,14 @@ config QCOM_HFPLL
  Say Y if you want to support CPU frequency scaling on devices
  such as MSM8974, APQ8084, etc.
 
+config KPSS_XCC
+   tristate "KPSS Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the Krait ACC and GCC clock controllers. Say Y
+ if you want to support CPU frequency scaling on devices such
+ as MSM8960, APQ8064, etc.
+
 config KRAIT_CLOCKS
bool
select KRAIT_L2_ACCESSORS
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 506c4cf..92310ee 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -45,4 +45,5 @@ obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
 obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
 obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
+obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
 obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
diff --git a/drivers/clk/qcom/kpss-xcc.c b/drivers/clk/qcom/kpss-xcc.c
new file mode 100644
index 000..8590b5e
--- /dev/null
+++ b/drivers/clk/qcom/kpss-xcc.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const char *aux_parents[] = {
+   "pll8_vote",
+   "pxo",
+};
+
+static unsigned int aux_parent_map[] = {
+   3,
+   0,
+};
+
+static const struct of_device_id kpss_xcc_match_table[] = {
+   { .compatible = "qcom,kpss-acc-v1", .data = (void *)1UL },
+   { .compatible = "qcom,kpss-gcc" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, kpss_xcc_match_table);
+
+static int kpss_xcc_driver_probe(struct platform_device *pdev)
+{
+   const struct of_device_id *id;
+   struct clk *clk;
+   struct resource *res;
+   void __iomem *base;
+   const char *name;
+
+   id = of_match_device(kpss_xcc_match_table, &pdev->dev);
+   if (!id)
+   return -ENODEV;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   if (id->data) {
+   if (of_property_read_string_index(pdev->dev.of_node,
+ "clock-output-names",
+ 0, &name))
+   return -ENODEV;
+   base += 0x14;
+   } else {
+   name = "acpu_l2_aux";
+   base += 0x28;
+   }
+
+   clk = clk_register_mux_table(&pdev->dev, name, aux_parents,
+ARRAY_SIZE(aux_parents), 0, base, 0, 0x3,
+0, aux_parent_map, NULL);
+
+   platform_set_drvdata(pdev, clk);
+
+   return PTR_ERR_OR_ZERO(clk);
+}
+
+static int kpss_xcc_driver_remove(struct platform_device *pdev)
+{
+   clk_unregister_mux(platform_get_drvdata(pdev));
+   return 0;
+}
+
+static struct platform_driver kpss_xcc_driver = {
+   .probe = kpss_xcc_driver_probe,
+   .remove = kpss_xcc_driver_remove,
+   .driver = {
+   .name = "kpss-xcc",
+   .of_match_table = kpss_xcc_match_table,
+   },
+};
+module_platform_driver(kpss_xcc_driver);
+
+MODULE_DESCRIPTION("Krait Processor Sub System (KPSS) Clock Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:kpss-xcc");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH] drivers: hwmon: pmbus: ltc2978: Add support for LTM4686 uModule

[michael.hennerich]

From: Michael Hennerich 

This patch adds support for LTM4686 Ultrathin Dual 10A or
Single 20A uModule Regulator with Digital Power System Management.

Datasheet: http://www.analog.com/ltm4686


Signed-off-by: Michael Hennerich 
---
 Documentation/devicetree/bindings/hwmon/ltc2978.txt | 2 ++
 Documentation/hwmon/ltc2978 | 5 +
 drivers/hwmon/pmbus/Kconfig | 3 ++-
 drivers/hwmon/pmbus/ltc2978.c   | 9 -
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/ltc2978.txt 
b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
index bf2a47b..b428a70 100644
--- a/Documentation/devicetree/bindings/hwmon/ltc2978.txt
+++ b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
@@ -15,6 +15,7 @@ Required properties:
   * "lltc,ltm2987"
   * "lltc,ltm4675"
   * "lltc,ltm4676"
+  * "lltc,ltm4686"
 - reg: I2C slave address
 
 Optional properties:
@@ -30,6 +31,7 @@ Valid names of regulators depend on number of supplies 
supported per device:
   * ltc3880, ltc3882, ltc3886 : vout0 - vout1
   * ltc3883 : vout0
   * ltm4676 : vout0 - vout1
+  * ltm4686 : vout0 - vout1
 
 Example:
 ltc2978@5e {
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index 9a49d3c..dfb2caa 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -55,6 +55,10 @@ Supported chips:
 Prefix: 'ltm4676'
 Addresses scanned: -
 Datasheet: http://www.linear.com/product/ltm4676
+  * Analog Devices LTM4686
+Prefix: 'ltm4686'
+Addresses scanned: -
+Datasheet: http://www.analog.com/ltm4686
 
 Author: Guenter Roeck 
 
@@ -76,6 +80,7 @@ additional components on a single die. The chip is 
instantiated and reported
 as two separate chips on two different I2C bus addresses.
 LTM4675 is a dual 9A or single 18A μModule regulator
 LTM4676 is a dual 13A or single 26A uModule regulator.
+LTM4686 is a dual 10A or single 20A uModule regulator.
 
 
 Usage Notes
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index e71aec6..28279a8 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -83,7 +83,8 @@ config SENSORS_LTC2978_REGULATOR
depends on SENSORS_LTC2978 && REGULATOR
help
  If you say yes here you get regulator support for Linear
- Technology LTC2974, LTC2977, LTC2978, LTC3880, LTC3883, and LTM4676.
+ Technology LTC2974, LTC2977, LTC2978, LTC3880, LTC3883, LTM4676
+ and LTM4686.
 
 config SENSORS_LTC3815
tristate "Linear Technologies LTC3815"
diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
index 58b789c..07afb92 100644
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -4,6 +4,7 @@
  * Copyright (c) 2011 Ericsson AB.
  * Copyright (c) 2013, 2014, 2015 Guenter Roeck
  * Copyright (c) 2015 Linear Technology
+ * Copyright (c) 2018 Analog Devices Inc.
  *
  * 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
@@ -28,7 +29,7 @@
 #include "pmbus.h"
 
 enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
-   ltc3883, ltc3886, ltc3887, ltm2987, ltm4675, ltm4676 };
+   ltc3883, ltc3886, ltc3887, ltm2987, ltm4675, ltm4676, ltm4686 };
 
 /* Common for all chips */
 #define LTC2978_MFR_VOUT_PEAK  0xdd
@@ -81,6 +82,7 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, 
ltc3880, ltc3882,
 #define LTM4676_ID_REV10x4400
 #define LTM4676_ID_REV20x4480
 #define LTM4676A_ID0x47e0
+#define LTM4686_ID 0x4770
 
 #define LTC2974_NUM_PAGES  4
 #define LTC2978_NUM_PAGES  8
@@ -512,6 +514,7 @@ static const struct i2c_device_id ltc2978_id[] = {
{"ltm2987", ltm2987},
{"ltm4675", ltm4675},
{"ltm4676", ltm4676},
+   {"ltm4686", ltm4686},
{}
 };
 MODULE_DEVICE_TABLE(i2c, ltc2978_id);
@@ -588,6 +591,8 @@ static int ltc2978_get_id(struct i2c_client *client)
else if (chip_id == LTM4676_ID_REV1 || chip_id == LTM4676_ID_REV2 ||
 chip_id == LTM4676A_ID)
return ltm4676;
+   else if (chip_id == LTM4686_ID)
+   return ltm4686;
 
dev_err(&client->dev, "Unsupported chip ID 0x%x\n", chip_id);
return -ENODEV;
@@ -684,6 +689,7 @@ static int ltc2978_probe(struct i2c_client *client,
case ltc3887:
case ltm4675:
case ltm4676:
+   case ltm4686:
data->features |= FEAT_CLEAR_PEAKS | FEAT_NEEDS_POLLING;
info->read_word_data = ltc3880_read_word_data;
info->pages = LTC3880_NUM_PAGES;
@@ -770,6 +776,7 @@ static const struct of_device_id ltc2978_of_match[] = {
{ .compatible = "lltc,ltm2987" },
{ .compatible = "lltc,ltm4675" },
{ .compatib

[PATCH v12 14/14] cpufreq: qcom: Add support for krait based socs

[Sricharan R]

In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974
that has KRAIT processors the voltage/current value of each OPP
varies based on the silicon variant in use.

The required OPP related data is determined based on
the efuse value. This is similar to the existing code for
kryo cores. So adding support for krait cores here.

Signed-off-by: Sricharan R 
---
 .../devicetree/bindings/opp/qcom-nvmem-cpufreq.txt |   3 +-
 drivers/cpufreq/Kconfig.arm|   2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c   |   5 +
 drivers/cpufreq/qcom-cpufreq-nvmem.c   | 151 +++--
 4 files changed, 149 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt 
b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
index 6dcdfcd..7bc0f1a 100644
--- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
+++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
@@ -19,7 +19,8 @@ In 'cpus' nodes:
 
 In 'operating-points-v2' table:
 - compatible: Should be
-   - 'operating-points-v2-qcom-cpu' for apq8096 and msm8996.
+   - 'operating-points-v2-qcom-cpu' for apq8096, msm8996, msm8974,
+apq8064, msm8960 and ipq8074.
 - nvmem-cells: A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the
speedbin that is used to select the right frequency/voltage
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 13fbd97..497ae89 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -126,7 +126,7 @@ config ARM_OMAP2PLUS_CPUFREQ
 
 config ARM_QCOM_CPUFREQ_NVMEM
tristate "Qualcomm nvmem based CPUFreq"
-   depends on ARM64
+   depends on ARCH_QCOM
depends on QCOM_QFPROM
depends on QCOM_SMEM
select PM_OPP
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index fe14c57..917cdc2 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -128,6 +128,11 @@
{ .compatible = "ti,am43", },
{ .compatible = "ti,dra7", },
 
+   { .compatible = "qcom,ipq8064", },
+   { .compatible = "qcom,apq8064", },
+   { .compatible = "qcom,msm8974", },
+   { .compatible = "qcom,msm8960", },
+
{ }
 };
 
diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c 
b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index 0ad8e5b..5f2add0 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -45,6 +45,82 @@ enum _msm8996_version {
 
 static struct platform_device *cpufreq_dt_pdev, *cpufreq_pdev;
 
+static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver,
+ struct nvmem_cell *pvs_nvmem, u8 *buf)
+{
+   u32 pte_efuse;
+
+   pte_efuse = *((u32 *)buf);
+
+   *speed = pte_efuse & 0xf;
+   if (*speed == 0xf)
+   *speed = (pte_efuse >> 4) & 0xf;
+
+   if (*speed == 0xf) {
+   *speed = 0;
+   pr_warn("Speed bin: Defaulting to %d\n", *speed);
+   } else {
+   pr_info("Speed bin: %d\n", *speed);
+   }
+
+   *pvs = (pte_efuse >> 10) & 0x7;
+   if (*pvs == 0x7)
+   *pvs = (pte_efuse >> 13) & 0x7;
+
+   if (*pvs == 0x7) {
+   *pvs = 0;
+   pr_warn("PVS bin: Defaulting to %d\n", *pvs);
+   } else {
+   pr_info("PVS bin: %d\n", *pvs);
+   }
+
+   kfree(buf);
+}
+
+static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver,
+ struct nvmem_cell *pvs_nvmem, u8 *buf)
+{
+   u32 pte_efuse, redundant_sel;
+
+   pte_efuse = *((u32 *)buf);
+   redundant_sel = (pte_efuse >> 24) & 0x7;
+   *speed = pte_efuse & 0x7;
+
+   /* 4 bits of PVS are in efuse register bits 31, 8-6. */
+   *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7);
+   *pvs_ver = (pte_efuse >> 4) & 0x3;
+
+   switch (redundant_sel) {
+   case 1:
+   *speed = (pte_efuse >> 27) & 0xf;
+   break;
+   case 2:
+   *pvs = (pte_efuse >> 27) & 0xf;
+   break;
+   }
+
+   /* Check SPEED_BIN_BLOW_STATUS */
+   if (pte_efuse & BIT(3)) {
+   pr_info("Speed bin: %d\n", *speed);
+   } else {
+   pr_warn("Speed bin not set. Defaulting to 0!\n");
+   *speed = 0;
+   }
+
+   /* Check PVS_BLOW_STATUS */
+   pte_efuse = *(((u32 *)buf) + 4);
+   pte_efuse &= BIT(21);
+   if (pte_efuse) {
+   pr_info("PVS bin: %d\n", *pvs);
+   } else {
+   pr_warn("PVS bin not set. Defaulting to 0!\n");
+   *pvs = 0;
+   }
+
+   pr_info("PVS version: %d\n", *pvs_ver);
+   kfree(buf);
+}
+
 static enum _msm8996_versi

[PATCH v12 10/14] clk: qcom: Add Krait clock controller driver

[Sricharan R]

From: Stephen Boyd 

The Krait CPU clocks are made up of a primary mux and secondary
mux for each CPU and the L2, controlled via cp15 accessors. For
Kraits within KPSSv1 each secondary mux accepts a different aux
source, but on KPSSv2 each secondary mux accepts the same aux
source.

Cc: 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/Kconfig |   8 +
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-krait.c |   4 +-
 drivers/clk/qcom/krait-cc.c  | 341 +++
 4 files changed, 352 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/qcom/krait-cc.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 7a99627..7c7ca65 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -289,6 +289,14 @@ config KPSS_XCC
  if you want to support CPU frequency scaling on devices such
  as MSM8960, APQ8064, etc.
 
+config KRAITCC
+   tristate "Krait Clock Controller"
+   depends on COMMON_CLK_QCOM && ARM
+   select KRAIT_CLOCKS
+   help
+ Support for the Krait CPU clocks on Qualcomm devices.
+ Say Y if you want to support CPU frequency scaling.
+
 config KRAIT_CLOCKS
bool
select KRAIT_L2_ACCESSORS
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 92310ee..949829b 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -47,3 +47,4 @@ obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
 obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
 obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
+obj-$(CONFIG_KRAITCC) += krait-cc.o
diff --git a/drivers/clk/qcom/clk-krait.c b/drivers/clk/qcom/clk-krait.c
index 2e41767..7ede744 100644
--- a/drivers/clk/qcom/clk-krait.c
+++ b/drivers/clk/qcom/clk-krait.c
@@ -44,7 +44,7 @@ static int krait_mux_set_parent(struct clk_hw *hw, u8 index)
struct krait_mux_clk *mux = to_krait_mux_clk(hw);
u32 sel;
 
-   sel = clk_mux_reindex(index, mux->parent_map, 0);
+   sel = clk_mux_index_to_val(mux->parent_map, 0, index);
mux->en_mask = sel;
/* Don't touch mux if CPU is off as it won't work */
if (__clk_is_enabled(hw->clk))
@@ -63,7 +63,7 @@ static u8 krait_mux_get_parent(struct clk_hw *hw)
sel &= mux->mask;
mux->en_mask = sel;
 
-   return clk_mux_get_parent(hw, sel, mux->parent_map, 0);
+   return clk_mux_val_to_index(hw, mux->parent_map, 0, sel);
 }
 
 const struct clk_ops krait_mux_clk_ops = {
diff --git a/drivers/clk/qcom/krait-cc.c b/drivers/clk/qcom/krait-cc.c
new file mode 100644
index 000..7c9dfb0
--- /dev/null
+++ b/drivers/clk/qcom/krait-cc.c
@@ -0,0 +1,341 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-krait.h"
+
+static unsigned int sec_mux_map[] = {
+   2,
+   0,
+};
+
+static unsigned int pri_mux_map[] = {
+   1,
+   2,
+   0,
+};
+
+static int
+krait_add_div(struct device *dev, int id, const char *s, unsigned int offset)
+{
+   struct krait_div2_clk *div;
+   struct clk_init_data init = {
+   .num_parents = 1,
+   .ops = &krait_div2_clk_ops,
+   .flags = CLK_SET_RATE_PARENT,
+   };
+   const char *p_names[1];
+   struct clk *clk;
+
+   div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
+   if (!div)
+   return -ENOMEM;
+
+   div->width = 2;
+   div->shift = 6;
+   div->lpl = id >= 0;
+   div->offset = offset;
+   div->hw.init = &init;
+
+   init.name = kasprintf(GFP_KERNEL, "hfpll%s_div", s);
+   if (!init.name)
+   return -ENOMEM;
+
+   init.parent_names = p_names;
+   p_names[0] = kasprintf(GFP_KERNEL, "hfpll%s", s);
+   if (!p_names[0]) {
+   kfree(init.name);
+   return -ENOMEM;
+   }
+
+   clk = devm_clk_register(dev, &div->hw);
+   kfree(p_names[0]);
+   kfree(init.name);
+
+   return PTR_ERR_OR_ZERO(clk);
+}
+
+static int
+krait_add_sec_mux(struct device *dev, int id, const char *s,
+ unsigned int offset, bool unique_aux)
+{
+   struct krait_mux_clk *mux;
+   static const char *sec_mux_list[] = {
+   "acpu_aux",
+   "qsb",
+   };
+   struct clk_init_data init = {
+   .parent_names = sec_mux_list,
+   .num_parents = ARRAY_SIZE(sec_mux_list),
+   .ops = &krait_mux_clk_ops,
+   .flags = CLK_SET_RATE_PARENT,
+   };
+   struct clk *clk;
+
+   mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+   if (!mux)
+   return -ENOMEM;
+
+   mux->offset = offset;
+   mux->lpl = id >= 0;
+   mux->mask = 0x3;
+   mux->shift = 2;
+   mux->paren

[PATCH v12 09/14] dt-bindings: arm: Document qcom,kpss-gcc

[Sricharan R]

From: Stephen Boyd 

The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. Documenting
the bindings here.

Reviewed-by: Rob Herring 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  | 19 ++
 .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  | 44 ++
 2 files changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
index 1333db9..7f69636 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
@@ -21,10 +21,29 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
 
+- clocks:
+Usage: required
+Value type: 
+Definition: reference to the pll parents.
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: must be "pll8_vote", "pxo".
+
+- clock-output-names:
+   Usage: optional
+   Value type: 
+   Definition: Name of the output clock. Typically acpuX_aux where X is a
+   CPU number starting at 0.
+
 Example:
 
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v2";
reg = <0x02088000 0x1000>,
  <0x02008000 0x1000>;
+   clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
+   clock-names = "pll8_vote", "pxo";
+   clock-output-names = "acpu0_aux";
};
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
new file mode 100644
index 000..e628758
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
@@ -0,0 +1,44 @@
+Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: should be one of the following. The generic compatible
+   "qcom,kpss-gcc" should also be included.
+   "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
+   "qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
+   "qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
+   "qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of the register region
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the pll parents.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "pll8_vote", "pxo".
+
+- clock-output-names:
+   Usage: required
+   Value type: 
+   Definition: Name of the output clock. Typically acpu_l2_aux indicating
+   an L2 cache auxiliary clock.
+
+Example:
+
+   l2cc: clock-controller@2011000 {
+   compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
+   reg = <0x2011000 0x1000>;
+   clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
+   clock-names = "pll8_vote", "pxo";
+   clock-output-names = "acpu_l2_aux";
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 07/14] clk: qcom: Add support for Krait clocks

[Sricharan R]

From: Stephen Boyd 

The Krait clocks are made up of a series of muxes and a divider
that choose between a fixed rate clock and dedicated HFPLLs for
each CPU. Instead of using mmio accesses to remux parents, the
Krait implementation exposes the remux control via cp15
registers. Support these clocks.

Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/Kconfig |   4 ++
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-krait.c | 124 +++
 drivers/clk/qcom/clk-krait.h |  37 +
 4 files changed, 166 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-krait.c
 create mode 100644 drivers/clk/qcom/clk-krait.h

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 21aec10..ada4160 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -280,3 +280,7 @@ config QCOM_HFPLL
  Support for the high-frequency PLLs present on Qualcomm devices.
  Say Y if you want to support CPU frequency scaling on devices
  such as MSM8974, APQ8084, etc.
+
+config KRAIT_CLOCKS
+   bool
+   select KRAIT_L2_ACCESSORS
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index f82eeac..506c4cf 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -11,6 +11,7 @@ clk-qcom-y += clk-branch.o
 clk-qcom-y += clk-regmap-divider.o
 clk-qcom-y += clk-regmap-mux.o
 clk-qcom-y += clk-regmap-mux-div.o
+clk-qcom-$(CONFIG_KRAIT_CLOCKS) += clk-krait.o
 clk-qcom-y += clk-hfpll.o
 clk-qcom-y += reset.o
 clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
diff --git a/drivers/clk/qcom/clk-krait.c b/drivers/clk/qcom/clk-krait.c
new file mode 100644
index 000..2e41767
--- /dev/null
+++ b/drivers/clk/qcom/clk-krait.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk-krait.h"
+
+/* Secondary and primary muxes share the same cp15 register */
+static DEFINE_SPINLOCK(krait_clock_reg_lock);
+
+#define LPL_SHIFT  8
+static void __krait_mux_set_sel(struct krait_mux_clk *mux, int sel)
+{
+   unsigned long flags;
+   u32 regval;
+
+   spin_lock_irqsave(&krait_clock_reg_lock, flags);
+   regval = krait_get_l2_indirect_reg(mux->offset);
+   regval &= ~(mux->mask << mux->shift);
+   regval |= (sel & mux->mask) << mux->shift;
+   if (mux->lpl) {
+   regval &= ~(mux->mask << (mux->shift + LPL_SHIFT));
+   regval |= (sel & mux->mask) << (mux->shift + LPL_SHIFT);
+   }
+   krait_set_l2_indirect_reg(mux->offset, regval);
+   spin_unlock_irqrestore(&krait_clock_reg_lock, flags);
+
+   /* Wait for switch to complete. */
+   mb();
+   udelay(1);
+}
+
+static int krait_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+   struct krait_mux_clk *mux = to_krait_mux_clk(hw);
+   u32 sel;
+
+   sel = clk_mux_reindex(index, mux->parent_map, 0);
+   mux->en_mask = sel;
+   /* Don't touch mux if CPU is off as it won't work */
+   if (__clk_is_enabled(hw->clk))
+   __krait_mux_set_sel(mux, sel);
+
+   return 0;
+}
+
+static u8 krait_mux_get_parent(struct clk_hw *hw)
+{
+   struct krait_mux_clk *mux = to_krait_mux_clk(hw);
+   u32 sel;
+
+   sel = krait_get_l2_indirect_reg(mux->offset);
+   sel >>= mux->shift;
+   sel &= mux->mask;
+   mux->en_mask = sel;
+
+   return clk_mux_get_parent(hw, sel, mux->parent_map, 0);
+}
+
+const struct clk_ops krait_mux_clk_ops = {
+   .set_parent = krait_mux_set_parent,
+   .get_parent = krait_mux_get_parent,
+   .determine_rate = __clk_mux_determine_rate_closest,
+};
+EXPORT_SYMBOL_GPL(krait_mux_clk_ops);
+
+/* The divider can divide by 2, 4, 6 and 8. But we only really need div-2. */
+static long krait_div2_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+   *parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), rate * 2);
+   return DIV_ROUND_UP(*parent_rate, 2);
+}
+
+static int krait_div2_set_rate(struct clk_hw *hw, unsigned long rate,
+  unsigned long parent_rate)
+{
+   struct krait_div2_clk *d = to_krait_div2_clk(hw);
+   unsigned long flags;
+   u32 val;
+   u32 mask = BIT(d->width) - 1;
+
+   if (d->lpl)
+   mask = mask << (d->shift + LPL_SHIFT) | mask << d->shift;
+
+   spin_lock_irqsave(&krait_clock_reg_lock, flags);
+   val = krait_get_l2_indirect_reg(d->offset);
+   val &= ~mask;
+   krait_set_l2_indirect_reg(d->offset, val);
+   spin_unlock_irqrestore(&krait_clock_reg_lock, flags);
+
+   return 0;
+}
+
+static unsigned long
+krait_div2_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+   struct krait_div2_clk *d = to_krait_div2_clk(hw);
+   u32 

[PATCH v12 13/14] cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs

[Sricharan R]

The kryo cpufreq driver reads the nvmem cell and uses that data to
populate the opps. There are other qcom cpufreq socs like krait which
does similar thing. Except for the interpretation of the read data,
rest of the driver is same for both the cases. So pull the common things
out for reuse.

Signed-off-by: Sricharan R 
---
 .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   6 +-
 drivers/cpufreq/Kconfig.arm|   4 +-
 drivers/cpufreq/Makefile   |   2 +-
 .../{qcom-cpufreq-kryo.c => qcom-cpufreq-nvmem.c}  | 124 -
 4 files changed, 80 insertions(+), 56 deletions(-)
 rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => 
qcom-nvmem-cpufreq.txt} (99%)
 rename drivers/cpufreq/{qcom-cpufreq-kryo.c => qcom-cpufreq-nvmem.c} (65%)

diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt 
b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
similarity index 99%
rename from Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
rename to Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
index c2127b9..6dcdfcd 100644
--- a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
+++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
@@ -19,7 +19,7 @@ In 'cpus' nodes:
 
 In 'operating-points-v2' table:
 - compatible: Should be
-   - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+   - 'operating-points-v2-qcom-cpu' for apq8096 and msm8996.
 - nvmem-cells: A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the
speedbin that is used to select the right frequency/voltage
@@ -127,7 +127,7 @@ Example 1:
};
 
cluster0_opp: opp_table0 {
-   compatible = "operating-points-v2-kryo-cpu";
+   compatible = "operating-points-v2-qcom-cpu";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
 
@@ -338,7 +338,7 @@ Example 1:
};
 
cluster1_opp: opp_table1 {
-   compatible = "operating-points-v2-kryo-cpu";
+   compatible = "operating-points-v2-qcom-cpu";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
 
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 52f5f1a..13fbd97 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,8 +124,8 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
 
-config ARM_QCOM_CPUFREQ_KRYO
-   tristate "Qualcomm Kryo based CPUFreq"
+config ARM_QCOM_CPUFREQ_NVMEM
+   tristate "Qualcomm nvmem based CPUFreq"
depends on ARM64
depends on QCOM_QFPROM
depends on QCOM_SMEM
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fb4a2ec..551 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7)   += mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
-obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO)+= qcom-cpufreq-kryo.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_NVMEM)   += qcom-cpufreq-nvmem.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
 obj-$(CONFIG_ARM_S3C2412_CPUFREQ)  += s3c2412-cpufreq.o
 obj-$(CONFIG_ARM_S3C2416_CPUFREQ)  += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c 
b/drivers/cpufreq/qcom-cpufreq-nvmem.c
similarity index 65%
rename from drivers/cpufreq/qcom-cpufreq-kryo.c
rename to drivers/cpufreq/qcom-cpufreq-nvmem.c
index efc9a7a..0ad8e5b 100644
--- a/drivers/cpufreq/qcom-cpufreq-kryo.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -9,7 +9,7 @@
  * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
  * defines the voltage and frequency value based on the msm-id in SMEM
  * and speedbin blown in the efuse combination.
- * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * The qcom-cpufreq driver reads the msm-id and efuse value from the SoC
  * to provide the OPP framework with required information.
  * This is used to determine the voltage and frequency value for each OPP of
  * operating-points-v2 table when it is parsed by the OPP framework.
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,9 +43,9 @@ enum _msm8996_version {
NUM_OF_MSM8996_VERSIONS,
 };
 
-struct platform_device *cpufreq_dt_pdev, *kryo_cpufreq_pdev;
+static struct platform_device *cpufreq_dt_pdev, *cpufreq_pdev;
 
-static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+static enum _msm8996_version __init qcom_cpufreq_get_msm_id(void)
 {
size_t len;
u32 *msm_id;
@@ -73,34 +74,70 @@ static enum _msm8996_version __init 
qcom_cpufreq_kryo_get_msm_id(void)
re

[PATCH v12 06/14] clk: qcom: Add IPQ806X's HFPLLs

[Sricharan R]

From: Stephen Boyd 

Describe the HFPLLs present on IPQ806X devices.

Signed-off-by: Stephen Boyd 
Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/gcc-ipq806x.c | 82 ++
 1 file changed, 82 insertions(+)

diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
index 5f61225..33d1bc5 100644
--- a/drivers/clk/qcom/gcc-ipq806x.c
+++ b/drivers/clk/qcom/gcc-ipq806x.c
@@ -30,6 +30,7 @@
 #include "clk-pll.h"
 #include "clk-rcg.h"
 #include "clk-branch.h"
+#include "clk-hfpll.h"
 #include "reset.h"
 
 static struct clk_pll pll0 = {
@@ -113,6 +114,84 @@
},
 };
 
+static struct hfpll_data hfpll0_data = {
+   .mode_reg = 0x3200,
+   .l_reg = 0x3208,
+   .m_reg = 0x320c,
+   .n_reg = 0x3210,
+   .config_reg = 0x3204,
+   .status_reg = 0x321c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3214,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll0 = {
+   .d = &hfpll0_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll0",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll0.lock),
+};
+
+static struct hfpll_data hfpll1_data = {
+   .mode_reg = 0x3240,
+   .l_reg = 0x3248,
+   .m_reg = 0x324c,
+   .n_reg = 0x3250,
+   .config_reg = 0x3244,
+   .status_reg = 0x325c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3314,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll1 = {
+   .d = &hfpll1_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll1",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll1.lock),
+};
+
+static struct hfpll_data hfpll_l2_data = {
+   .mode_reg = 0x3300,
+   .l_reg = 0x3308,
+   .m_reg = 0x330c,
+   .n_reg = 0x3310,
+   .config_reg = 0x3304,
+   .status_reg = 0x331c,
+   .config_val = 0x7845c665,
+   .droop_reg = 0x3314,
+   .droop_val = 0x0108c000,
+   .min_rate = 6UL,
+   .max_rate = 18UL,
+};
+
+static struct clk_hfpll hfpll_l2 = {
+   .d = &hfpll_l2_data,
+   .clkr.hw.init = &(struct clk_init_data){
+   .parent_names = (const char *[]){ "pxo" },
+   .num_parents = 1,
+   .name = "hfpll_l2",
+   .ops = &clk_ops_hfpll,
+   .flags = CLK_IGNORE_UNUSED,
+   },
+   .lock = __SPIN_LOCK_UNLOCKED(hfpll_l2.lock),
+};
+
 static struct clk_pll pll14 = {
.l_reg = 0x31c4,
.m_reg = 0x31c8,
@@ -2797,6 +2876,9 @@ enum {
[UBI32_CORE2_CLK_SRC] = &ubi32_core2_src_clk.clkr,
[NSSTCM_CLK_SRC] = &nss_tcm_src.clkr,
[NSSTCM_CLK] = &nss_tcm_clk.clkr,
+   [PLL9] = &hfpll0.clkr,
+   [PLL10] = &hfpll1.clkr,
+   [PLL12] = &hfpll_l2.clkr,
 };
 
 static const struct qcom_reset_map gcc_ipq806x_resets[] = {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH v12 12/14] clk: qcom: Add safe switch hook for krait mux clocks

[Sricharan R]

When the Hfplls are reprogrammed during the rate change,
the primary muxes which are sourced from the same hfpll
for higher frequencies, needs to be switched to the 'safe
secondary mux' as the parent for that small window. This
is done by registering a clk notifier for the muxes and
switching to the safe parent in the PRE_RATE_CHANGE notifier
and back to the original parent in the POST_RATE_CHANGE notifier.

Signed-off-by: Sricharan R 
---
 drivers/clk/qcom/clk-krait.c |  2 ++
 drivers/clk/qcom/clk-krait.h |  3 +++
 drivers/clk/qcom/krait-cc.c  | 56 
 3 files changed, 61 insertions(+)

diff --git a/drivers/clk/qcom/clk-krait.c b/drivers/clk/qcom/clk-krait.c
index 7ede744..59f1af4 100644
--- a/drivers/clk/qcom/clk-krait.c
+++ b/drivers/clk/qcom/clk-krait.c
@@ -50,6 +50,8 @@ static int krait_mux_set_parent(struct clk_hw *hw, u8 index)
if (__clk_is_enabled(hw->clk))
__krait_mux_set_sel(mux, sel);
 
+   mux->reparent = true;
+
return 0;
 }
 
diff --git a/drivers/clk/qcom/clk-krait.h b/drivers/clk/qcom/clk-krait.h
index 441ba1e..9120bd2 100644
--- a/drivers/clk/qcom/clk-krait.h
+++ b/drivers/clk/qcom/clk-krait.h
@@ -12,6 +12,9 @@ struct krait_mux_clk {
u32 shift;
u32 en_mask;
boollpl;
+   u8  safe_sel;
+   u8  old_index;
+   boolreparent;
 
struct clk_hw   hw;
struct notifier_block   clk_nb;
diff --git a/drivers/clk/qcom/krait-cc.c b/drivers/clk/qcom/krait-cc.c
index 7c9dfb0..4d4b657 100644
--- a/drivers/clk/qcom/krait-cc.c
+++ b/drivers/clk/qcom/krait-cc.c
@@ -26,6 +26,49 @@
0,
 };
 
+/*
+ * Notifier function for switching the muxes to safe parent
+ * while the hfpll is getting reprogrammed.
+ */
+static int krait_notifier_cb(struct notifier_block *nb,
+unsigned long event,
+void *data)
+{
+   int ret = 0;
+   struct krait_mux_clk *mux = container_of(nb, struct krait_mux_clk,
+clk_nb);
+   /* Switch to safe parent */
+   if (event == PRE_RATE_CHANGE) {
+   mux->old_index = krait_mux_clk_ops.get_parent(&mux->hw);
+   ret = krait_mux_clk_ops.set_parent(&mux->hw, mux->safe_sel);
+   mux->reparent = false;
+   /*
+* By the time POST_RATE_CHANGE notifier is called,
+* clk framework itself would have changed the parent for the new rate.
+* Only otherwise, put back to the old parent.
+*/
+   } else if (event == POST_RATE_CHANGE) {
+   if (!mux->reparent)
+   ret = krait_mux_clk_ops.set_parent(&mux->hw,
+  mux->old_index);
+   }
+
+   return notifier_from_errno(ret);
+}
+
+static int krait_notifier_register(struct device *dev, struct clk *clk,
+  struct krait_mux_clk *mux)
+{
+   int ret = 0;
+
+   mux->clk_nb.notifier_call = krait_notifier_cb;
+   ret = clk_notifier_register(clk, &mux->clk_nb);
+   if (ret)
+   dev_err(dev, "failed to register clock notifier: %d\n", ret);
+
+   return ret;
+}
+
 static int
 krait_add_div(struct device *dev, int id, const char *s, unsigned int offset)
 {
@@ -70,6 +113,7 @@
 krait_add_sec_mux(struct device *dev, int id, const char *s,
  unsigned int offset, bool unique_aux)
 {
+   int ret;
struct krait_mux_clk *mux;
static const char *sec_mux_list[] = {
"acpu_aux",
@@ -93,6 +137,7 @@
mux->shift = 2;
mux->parent_map = sec_mux_map;
mux->hw.init = &init;
+   mux->safe_sel = 0;
 
init.name = kasprintf(GFP_KERNEL, "krait%s_sec_mux", s);
if (!init.name)
@@ -108,6 +153,11 @@
 
clk = devm_clk_register(dev, &mux->hw);
 
+   ret = krait_notifier_register(dev, clk, mux);
+   if (ret)
+   goto unique_aux;
+
+unique_aux:
if (unique_aux)
kfree(sec_mux_list[0]);
 err_aux:
@@ -119,6 +169,7 @@
 krait_add_pri_mux(struct device *dev, int id, const char *s,
  unsigned int offset)
 {
+   int ret;
struct krait_mux_clk *mux;
const char *p_names[3];
struct clk_init_data init = {
@@ -139,6 +190,7 @@
mux->lpl = id >= 0;
mux->parent_map = pri_mux_map;
mux->hw.init = &init;
+   mux->safe_sel = 2;
 
init.name = kasprintf(GFP_KERNEL, "krait%s_pri_mux", s);
if (!init.name)
@@ -164,6 +216,10 @@
 
clk = devm_clk_register(dev, &mux->hw);
 
+   ret = krait_notifier_register(dev, clk, mux);
+   if (ret)
+   goto err_p3;
+err_p3:
kfree(p_names[2]);
 err_p2:
kfree(p_names[1]);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The L

Re: [PATCH 2/2] bcache: add undef for macro in function

[Coly Li]

On 2018/8/14 4:16 PM, Dongbo Cao wrote:
> add undef for macro d_strtoul,d_strtoul_nonzero and d_strtoi_h
> 
> Signed-off-by: Dongbo Cao 
> ---
>  drivers/md/bcache/sysfs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
> index 225b15aa..ed67a290 100644
> --- a/drivers/md/bcache/sysfs.c
> +++ b/drivers/md/bcache/sysfs.c
> @@ -349,6 +349,9 @@ STORE(__cached_dev)
>   if (attr == &sysfs_stop)
>   bcache_device_stop(&dc->disk);
>  
> +#undef d_strtoul
> +#undef d_strtoul_nonzero
> +#undef d_strtoi_h
>   return size;
>  }
>  
> 

Hi Dongbo,

Could you please to provide the motivation why you make this change ?

Thanks.

Coly Li