Re: [PATCH v2 16/22] mmc: tmio: fix never-detected card insertion bug

[Wolfram Sang]

> > The TMIO mmc cannot detect the card insertion in native_hotplug mode
> > if the driver is probed without a card inserted.
> 
> Hmm, it works for me without your patch just fine. Iam currently
> researching it...

It really doesn't work for you?

mmc_add_host -> mmc_start_host -> _mmc_detect_change ->
mmc_schedule_delayed_work -> mmc_rescan -> mmc_start_request



signature.asc
Description: PGP signature

Re: [PATCH v4 05/19] afs: convert to new i_version API

[David Howells]

Jeff Layton  wrote:

> Note that AFS has quite a different definition for this counter. AFS
> only increments it on changes to the data, not for the metadata.

This also applies to AFS directories: create, mkdir, unlink, rmdir, link,
symlink, rename, and mountpoint creation/removal all bump the data version
number on a directory by exactly one if they change it.

David

Re: [PATCH] [v2] ARM: B15: fix unused label warnings

[Florian Fainelli]

On 12/18/2017 05:21 PM, Florian Fainelli wrote:
> On 12/18/2017 08:52 AM, Arnd Bergmann wrote:
>> The new conditionally compiled code leaves some labels and one
>> variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
>> are disabled:
>>
>> arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
>> arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not 
>> used [-Werror=unused-label]
>>  out_unmap:
>>  ^
>> arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but 
>> not used [-Werror=unused-label]
>>  out_cpu_dead:
>>  ^~~~
>> At top level:
>> arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not 
>> used [-Werror=unused-variable]
>>
>> This replaces the existing #ifdef conditionals with IS_ENABLED()
>> checks that let the compiler figure out for itself which code to
>> drop.
>>
>> Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
>> Signed-off-by: Arnd Bergmann 
> 
> Acked-by: Florian Fainelli 
> 
> Thanks Arnd!

Arnd, if you have not done so already do you mind adding this to
Russell's patch tracker? Thanks!
-- 
Florian

Re: [PATCH] xen/input: do not advertise multi-touch pressure support

[Dmitry Torokhov]

On Tue, Jan 02, 2018 at 10:12:55AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Some user-space applications expect multi-touch pressure
> on contact to be reported if it is advertised in device
> properties. Otherwise, such applications may treat reports
> not as actual touches, but hovering. Currently this is
> only advertised, but not reported.
> Fix this by not advertising that ABS_MT_PRESSURE is supported.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Andrii Chepurnyi 

Applied, thank you.

> ---
>  drivers/input/misc/xen-kbdfront.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 6bf56bb5f8d9..d91f3b1c5375 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
>0, width, 0, 0);
>   input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>0, height, 0, 0);
> - input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> -  0, 255, 0, 0);
>  
>   ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
>   if (ret) {
> -- 
> 2.7.4
> 

-- 
Dmitry

Re: [PATCH] tools: usb: usbip: fix fd leak in case of 'fread' failure

[Shuah Khan]

On 12/30/2017 09:01 AM, Elad Wexler wrote:
> Fix possible resource leak: fd
> 
> Signed-off-by: Elad Wexler 

Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah

Re: [PATCH] PCI: exynos: remove the deprecated phy codes

[Jingoo Han]

On Tuesday, January 2, 2018 11:34 AM, Lorenzo Pieralisi wrote:
> On Wed, Dec 27, 2017 at 06:43:27PM +0900, Jaehoon Chung wrote:
> > pci-exynos had updated to use the PHY framework.
> > (drivers/phy/samsung/phy-exynos-pcie.c)
> > Removed the depreccated codes relevant to phy in pci-exynos.c.
> > Instead, use the phy-exynos-pcie.c file.
> >
> > Modified the binding documentation.
> >
> > Signed-off-by: Jaehoon Chung 
> > ---
> >  .../bindings/pci/samsung,exynos5440-pcie.txt   |  58 ++
> >  drivers/pci/dwc/pci-exynos.c   | 219
++-
> --
> >  2 files changed, 22 insertions(+), 255 deletions(-)
> 
> I have updated the commit log to the patch below, please
> check before I push it out.

I think that the commit message looks good.
Thank you.

Best regards,
Jingoo Han

> 
> Lorenzo
> 
> -- >8 --
> Subject: [PATCH] PCI: exynos: Remove deprecated PHY initialization code
> 
> Exynos platforms have a PCI PHY driver in the PHY framework that can be
> used by the PCI host bridge drivers to initialize and manage the PHY.
> 
> Remove the deprecated PHY initialization code in the Exynos PCI host
> bridge driver by updating the driver to use the PHY framework API;
> modify the DT binding documentation accordingly.
> 
> Signed-off-by: Jaehoon Chung 
> [lorenzo.pieral...@arm.com: updated commit log]
> Signed-off-by: Lorenzo Pieralisi 
> Acked-by: Jingoo Han 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/pci/samsung,exynos5440-pcie.txt   |  58 ++
>  drivers/pci/dwc/pci-exynos.c   | 219
++--
> -
>  2 files changed, 22 insertions(+), 255 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
>  Required properties:
>  - compatible: "samsung,exynos5440-pcie"
>  - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> -  Use the PHY framework.)
>  - reg-names : First name should be set to "elbi".
>   And use the "config" instead of getting the configuration address
> space
>   from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
> 
>  Example:
> 
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
> 
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> -   0x8100 0 0  0x40001000 0 0x0001
/*
> downstream I/O */
> -   0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0  GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> -   0x8100 0 0  0x60001000 0 0x0001
/*
> downstream I/O */
> -   0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0  GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> -With using PHY framework:
>   pcie_phy0: pcie-phy@27 {
>   ...
>   reg = <0x27 0x1000>, <0x271000 0x40>;
> @@ -74,13 +30,21 @@ With using PHY framework:
>   };
> 

Re: [PATCH] tools: usb: usbip_device_driver: prefer 'unsigned int' to 'unsigned'

[Shuah Khan]

On 12/30/2017 09:11 AM, Elad Wexler wrote:
> Fixup a coding style issue
> 
> Signed-off-by: Elad Wexler 


Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah

[PATCH v4 1/7] typec: tcpm: Add PD Rev 3.0 definitions to PD header

[Adam Thomson]

This commit adds definitions for PD Rev 3.0 messages, including
APDO PPS and extended message support for TCPM.

Signed-off-by: Adam Thomson 
---
 include/linux/usb/pd.h | 185 ++---
 1 file changed, 174 insertions(+), 11 deletions(-)

diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index b3d41d7..ff359bdf 100644
--- a/include/linux/usb/pd.h
+++ b/include/linux/usb/pd.h
@@ -35,6 +35,13 @@ enum pd_ctrl_msg_type {
PD_CTRL_WAIT = 12,
PD_CTRL_SOFT_RESET = 13,
/* 14-15 Reserved */
+   PD_CTRL_NOT_SUPP = 16,
+   PD_CTRL_GET_SOURCE_CAP_EXT = 17,
+   PD_CTRL_GET_STATUS = 18,
+   PD_CTRL_FR_SWAP = 19,
+   PD_CTRL_GET_PPS_STATUS = 20,
+   PD_CTRL_GET_COUNTRY_CODES = 21,
+   /* 22-31 Reserved */
 };
 
 enum pd_data_msg_type {
@@ -43,13 +50,39 @@ enum pd_data_msg_type {
PD_DATA_REQUEST = 2,
PD_DATA_BIST = 3,
PD_DATA_SINK_CAP = 4,
-   /* 5-14 Reserved */
+   PD_DATA_BATT_STATUS = 5,
+   PD_DATA_ALERT = 6,
+   PD_DATA_GET_COUNTRY_INFO = 7,
+   /* 8-14 Reserved */
PD_DATA_VENDOR_DEF = 15,
+   /* 16-31 Reserved */
+};
+
+enum pd_ext_msg_type {
+   /* 0 Reserved */
+   PD_EXT_SOURCE_CAP_EXT = 1,
+   PD_EXT_STATUS = 2,
+   PD_EXT_GET_BATT_CAP = 3,
+   PD_EXT_GET_BATT_STATUS = 4,
+   PD_EXT_BATT_CAP = 5,
+   PD_EXT_GET_MANUFACTURER_INFO = 6,
+   PD_EXT_MANUFACTURER_INFO = 7,
+   PD_EXT_SECURITY_REQUEST = 8,
+   PD_EXT_SECURITY_RESPONSE = 9,
+   PD_EXT_FW_UPDATE_REQUEST = 10,
+   PD_EXT_FW_UPDATE_RESPONSE = 11,
+   PD_EXT_PPS_STATUS = 12,
+   PD_EXT_COUNTRY_INFO = 13,
+   PD_EXT_COUNTRY_CODES = 14,
+   /* 15-31 Reserved */
 };
 
 #define PD_REV10   0x0
 #define PD_REV20   0x1
+#define PD_REV30   0x2
+#define PD_MAX_REV PD_REV30
 
+#define PD_HEADER_EXT_HDR  BIT(15)
 #define PD_HEADER_CNT_SHIFT12
 #define PD_HEADER_CNT_MASK 0x7
 #define PD_HEADER_ID_SHIFT 9
@@ -59,18 +92,19 @@ enum pd_data_msg_type {
 #define PD_HEADER_REV_MASK 0x3
 #define PD_HEADER_DATA_ROLEBIT(5)
 #define PD_HEADER_TYPE_SHIFT   0
-#define PD_HEADER_TYPE_MASK0xf
+#define PD_HEADER_TYPE_MASK0x1f
 
-#define PD_HEADER(type, pwr, data, id, cnt)\
+#define PD_HEADER(type, pwr, data, rev, id, cnt, ext_hdr)  \
type) & PD_HEADER_TYPE_MASK) << PD_HEADER_TYPE_SHIFT) | \
 ((pwr) == TYPEC_SOURCE ? PD_HEADER_PWR_ROLE : 0) | \
 ((data) == TYPEC_HOST ? PD_HEADER_DATA_ROLE : 0) | \
-(PD_REV20 << PD_HEADER_REV_SHIFT) |\
+(rev << PD_HEADER_REV_SHIFT) | \
 (((id) & PD_HEADER_ID_MASK) << PD_HEADER_ID_SHIFT) |   \
-(((cnt) & PD_HEADER_CNT_MASK) << PD_HEADER_CNT_SHIFT))
+(((cnt) & PD_HEADER_CNT_MASK) << PD_HEADER_CNT_SHIFT) |\
+((ext_hdr) ? PD_HEADER_EXT_HDR : 0))
 
 #define PD_HEADER_LE(type, pwr, data, id, cnt) \
-   cpu_to_le16(PD_HEADER((type), (pwr), (data), (id), (cnt)))
+   cpu_to_le16(PD_HEADER((type), (pwr), (data), PD_REV20, (id), (cnt), 
(0)))
 
 static inline unsigned int pd_header_cnt(u16 header)
 {
@@ -102,16 +136,75 @@ static inline unsigned int pd_header_msgid_le(__le16 
header)
return pd_header_msgid(le16_to_cpu(header));
 }
 
+static inline unsigned int pd_header_rev(u16 header)
+{
+   return (header >> PD_HEADER_REV_SHIFT) & PD_HEADER_REV_MASK;
+}
+
+static inline unsigned int pd_header_rev_le(__le16 header)
+{
+   return pd_header_rev(le16_to_cpu(header));
+}
+
+#define PD_EXT_HDR_CHUNKED BIT(15)
+#define PD_EXT_HDR_CHUNK_NUM_SHIFT 11
+#define PD_EXT_HDR_CHUNK_NUM_MASK  0xf
+#define PD_EXT_HDR_REQ_CHUNK   BIT(10)
+#define PD_EXT_HDR_DATA_SIZE_SHIFT 0
+#define PD_EXT_HDR_DATA_SIZE_MASK  0x1ff
+
+#define PD_EXT_HDR(data_size, req_chunk, chunk_num, chunked)   
\
+   data_size) & PD_EXT_HDR_DATA_SIZE_MASK) << 
PD_EXT_HDR_DATA_SIZE_SHIFT) |\
+((req_chunk) ? PD_EXT_HDR_REQ_CHUNK : 0) | 
\
+(((chunk_num) & PD_EXT_HDR_CHUNK_NUM_MASK) << 
PD_EXT_HDR_CHUNK_NUM_SHIFT) |\
+((chunked) ? PD_EXT_HDR_CHUNKED : 0))
+
+#define PD_EXT_HDR_LE(data_size, req_chunk, chunk_num, chunked) \
+   cpu_to_le16(PD_EXT_HDR((data_size), (req_chunk), (chunk_num), 
(chunked)))
+
+static inline unsigned int pd_ext_header_chunk_num(u16 ext_header)
+{
+   return (ext_header >> PD_EXT_HDR_CHUNK_NUM_SHIFT) &
+   PD_EXT_HDR_CHUNK_NUM_MASK;
+}
+
+static inline unsigned int pd_ext_header_data_size(u16 ext_header)
+{
+   return (ext_header >> PD_EXT_HDR_DATA_SIZE_SHIFT) &
+   PD_EXT_HDR_DATA_SIZE_MASK;
+}
+
+static inline unsigned int pd_ext_header_data_size_le(__le16 ext_header)
+{
+

Re: [PATCH v5 08/15] MIPS: ingenic: Use common cmdline handling code

[PrasannaKumar Muralidharan]

Hi Paul,

On 2 January 2018 at 20:38, Paul Cercueil  wrote:
> From: Paul Burton 
>
> jz4740_init_cmdline appends all arguments from argv (in fw_arg1) to
> arcs_cmdline, up to argc (in fw_arg0). The common code in
> fw_init_cmdline will do the exact same thing when run on a system where
> fw_arg0 isn't a pointer to kseg0 (it'll also set _fw_envp but we don't
> use it). Remove the custom implementation & use the generic code.
>
> Signed-off-by: Paul Burton 
> ---
>  arch/mips/jz4740/prom.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
>
>  v2: No change
>  v3: No change
>  v4: No change
>  v5: No change
>
> diff --git a/arch/mips/jz4740/prom.c b/arch/mips/jz4740/prom.c
> index 47e857194ce6..a62dd8e6ecf9 100644
> --- a/arch/mips/jz4740/prom.c
> +++ b/arch/mips/jz4740/prom.c
> @@ -20,33 +20,13 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
> -static __init void jz4740_init_cmdline(int argc, char *argv[])
> -{
> -   unsigned int count = COMMAND_LINE_SIZE - 1;
> -   int i;
> -   char *dst = &(arcs_cmdline[0]);
> -   char *src;
> -
> -   for (i = 1; i < argc && count; ++i) {
> -   src = argv[i];
> -   while (*src && count) {
> -   *dst++ = *src++;
> -   --count;
> -   }
> -   *dst++ = ' ';
> -   }
> -   if (i > 1)
> -   --dst;
> -
> -   *dst = 0;
> -}
> -
>  void __init prom_init(void)
>  {
> -   jz4740_init_cmdline((int)fw_arg0, (char **)fw_arg1);
> mips_machtype = MACH_INGENIC_JZ4740;
> +   fw_init_cmdline();
>  }
>
>  void __init prom_free_prom_memory(void)
> --
> 2.11.0
>
>

Looks good to me.
Reviewed-by: PrasannaKumar Muralidharan 

Re: [PATCH] scripts: Add device_attr_<rw|ro|wr>.pl scripts to convert DEVICE_ATTR uses

[Greg Kroah-Hartman]

On Tue, Jan 02, 2018 at 07:34:30AM -0800, Joe Perches wrote:
> On Sat, 2017-12-23 at 15:19 +0100, Greg Kroah-Hartman wrote:
> > On Fri, Dec 22, 2017 at 12:02:47PM -0800, Joe Perches wrote:
> > > There are many uses of the DEVICE_ATTR(var, perms, show, store)
> > > declaration macro that could use one of the convenience macros
> > > DEVICE_ATTR_RW, DEVICE_ATTR_RO, or DEVICE_ATTR_WO.
> > > 
> > > These scripts automate those conversions.
> 
> Hey Greg.  Are you going to use these scripts?

Yes, when I get a chance, kind of busy for the next few weeks with other
stuff though :(

greg k-h

Re: [PATCH v5 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

[PrasannaKumar Muralidharan]

On 2 January 2018 at 20:38, Paul Cercueil  wrote:
> Add a machtype ID for the JZ4780 SoC, which was missing, and one for the
> newly supported JZ4770 SoC.
>
> Signed-off-by: Paul Cercueil 
> ---
>  arch/mips/include/asm/bootinfo.h | 2 ++
>  1 file changed, 2 insertions(+)
>
>  v2: No change
>  v3: No change
>  v5: No change
>
> diff --git a/arch/mips/include/asm/bootinfo.h 
> b/arch/mips/include/asm/bootinfo.h
> index e26a093bb17a..a301a8f4bc66 100644
> --- a/arch/mips/include/asm/bootinfo.h
> +++ b/arch/mips/include/asm/bootinfo.h
> @@ -79,6 +79,8 @@ enum loongson_machine_type {
>   */
>  #define  MACH_INGENIC_JZ4730   0   /* JZ4730 SOC   */
>  #define  MACH_INGENIC_JZ4740   1   /* JZ4740 SOC   */
> +#define  MACH_INGENIC_JZ4770   2   /* JZ4770 SOC   */
> +#define  MACH_INGENIC_JZ4780   3   /* JZ4780 SOC   */
>
>  extern char *system_type;
>  const char *get_system_type(void);
> --
> 2.11.0
>
>

Reviewed-by: PrasannaKumar Muralidharan 

Re: [PATCH v2 0/2] Add efuse driver for Ingenic JZ4780 SoC

[PrasannaKumar Muralidharan]

Hi Srinivas,

On 2 January 2018 at 17:31, Srinivas Kandagatla
 wrote:
>
>
> On 28/12/17 21:29, Mathieu Malaterre wrote:
>>
>> This patchset bring support for read-only access to the JZ4780 efuse as
>> found
>> on MIPS Creator CI20.
>>
>> To keep the driver as simple as possible, it was not possible to re-use
>> most of
>> the nvmem core functionalities. This driver is not compatible with the
>> original
>
> Can you explain a bit more on not able to re-use nvmem core?
>
> If you are referring to adding nvmem cell entires in sysfs, This should
> probably go in to nvmem core, rather that in individual providers.
> This is one of the feature my todo list, will try to come up with some thing
> soon.

We could not find a way to expose different sized segments using nvmem
framework. Do you have any pointers for this?
We were not aware of the fact that nvmem does not expose individual
cell entries in sysfs.

Regards,
PrasannaKumar

Re: [PATCH 2/2] serial: imx: fix endless loop during suspend

[Martin Kaiser]

Hi Fabio,

thanks for testing my patch. Sorry for breaking suspend on your board.

Thus wrote Fabio Estevam (feste...@gmail.com):

> Which i.MX SoC did you use to test this patch?

I tested on an imx258.

> On a imx6q-cuboxi I am no longer able to enter in suspend with this
> path applied:

> # echo enabled > /sys/class/tty/ttymxc0/power/wakeup
> # echo mem > /sys/power/state
> [9.766903] PM: suspend entry (deep)
> [9.770658] PM: Syncing filesystems ... done.
> [9.815312] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [9.824744] OOM killer disabled.
> [9.827998] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [9.837351] Suspending console(s) (use no_console_suspend to debug)
> [9.915495] PM: suspend devices took 0.080 seconds
> [9.928746] PM: noirq suspend of devices failed
> [   10.196232] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
> [   10.198148] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [   10.200042] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [   10.203420] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [   10.206812] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [   10.263097] PM: resume devices took 0.330 seconds
> [   10.266639] ata1: SATA link down (SStatus 0 SControl 300)
> [   10.310305] OOM killer enabled.
> [   10.313458] Restarting tasks ... done.
> [   10.319568] PM: suspend exit
> sh: write error: Device or resource busy

> Even if I do not press anything in the console the system gets out of
> suspend automatically.

So the suspend_noirq step failed with -EBUSY.

My guess is that the following code path is taken

suspend_devices_and_enter()
   suspend_enter()
  dpm_suspend_noirq()
 dpm_noirq_suspend_devices()
device_suspend_noirq()
   __device_suspend_noirq()
  pm_wakeup_pending()

and pm_wakeup_pending() returns true. We'd then have an async_error
-EBUSY.

If that's the case, I don't understand why it happens for imx6q.
We should only have a pending wakeup event if wakeup_source_activate()
or ..._deactivate() has been called.

Seeing this kind of problem, I wonder if it's ok to move setting AWAKEN
from the suspend to the suspend_noirq step. The imx uart's interrupt is
now re-enabled and IRQD_WAKEUP_ARMED is set before we configure the uart
to generate such interrupts (by setting AWAKEN), whereas before, it was
the other way around. I'd be grateful if anyone could shed some light
on this. (Or more generally: When must the hardware be configured to
generate wakeup interrupts? Is it ok to do this in supend_noirq or must
it be done before?)

Fabio, could you post the output of

cat /sys/kernel/debug/suspend_stats

after supend failed, to confirm that we're failing below
device_suspend_noirq()?

Thanks,

   Martin

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

[Tejun Heo]

Hello,

On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
> task T is waiting for cpuset_mutex acquired
> by kworker/2:1
> 
> sh ==> cpuhp/2 ==> kworker/2:1 ==> sh 
> 
> kworker/2:3 ==> kthreadd ==> Task T ==> kworker/2:1
> 
> It seems that my earlier patch set should fix this scenario:
> 1) Inverting locking order of cpuset_mutex and cpu_hotplug_lock.
> 2) Make cpuset hotplug work synchronous.
>
> Could you please share your feedback.

Hmm... this can also be resolved by adding WQ_MEM_RECLAIM to the
synchronize rcu workqueue, right?  Given the wide-spread usages of
synchronize_rcu and friends, maybe that's the right solution, or at
least something we also need to do, for this particular deadlock?

Again, I don't have anything against making the domain rebuliding part
of cpuset operations synchronous and these tricky deadlock scenarios
do indicate that doing so would probably be beneficial.  That said,
tho, these scenarios seem more of manifestations of other problems
exposed through kthreadd dependency than anything else.

Thanks.

-- 
tejun

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

[PrasannaKumar Muralidharan]

Hi Srini,

On 2 January 2018 at 17:32, Srinivas Kandagatla
 wrote:
>
>
> On 28/12/17 21:29, Mathieu Malaterre wrote:
>>
>> From: PrasannaKumar Muralidharan 
>>
>> This patch brings support for the JZ4780 efuse. Currently it only expose
>> a read only access to the entire 8K bits efuse memory.
>>
>> Tested-by: Mathieu Malaterre 
>> Signed-off-by: PrasannaKumar Muralidharan 
>> Signed-off-by: Mathieu Malaterre 
>> ---
>
> Please split this patch, as you are mixing code, documentation, dts and
> MAINTAINER changes here.
>
> Without which patch can not be reviewed!!

Sure, will do it soon.

>
> Thanks,
> Srini
>
>>   .../ABI/testing/sysfs-driver-jz4780-efuse  |  16 ++
>
>
>>   .../bindings/nvmem/ingenic,jz4780-efuse.txt|  17 ++
>>   MAINTAINERS|   5 +
>>   arch/mips/boot/dts/ingenic/jz4780.dtsi |  40 ++-
>>   drivers/nvmem/Kconfig  |  10 +
>>   drivers/nvmem/Makefile |   2 +
>>   drivers/nvmem/jz4780-efuse.c   | 305
>> +
>>   7 files changed, 383 insertions(+), 12 deletions(-)
>
> ...

Regards,
PrasannaKumar

[PATCH] pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL

[Stefan Agner]

From: Bai Ping 

On i.MX 6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL registers
are available in a separate IOMUXC_SNVS module. Add support for the
IOMUXC_SNVS module to the i.MX 6UL pinctrl driver.

Signed-off-by: Bai Ping 
Signed-off-by: Stefan Agner 
---
 .../bindings/pinctrl/fsl,imx6ul-pinctrl.txt|  3 +-
 drivers/pinctrl/freescale/pinctrl-imx6ul.c | 52 +-
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
index a81bbf37ed66..7ca4f6118d9a 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
@@ -4,7 +4,8 @@ Please refer to fsl,imx-pinctrl.txt in this directory for 
common binding part
 and usage.
 
 Required properties:
-- compatible: "fsl,imx6ul-iomuxc"
+- compatible: "fsl,imx6ul-iomuxc" for main IOMUX controller or
+  "fsl,imx6ull-iomuxc-snvs" for i.MX 6ULL's SNVS IOMUX controller.
 - fsl,pins: each entry consists of 6 integers and represents the mux and config
   setting for one pin.  The first 5 integers  are specified using a PIN_FUNC_ID macro, which can be found in
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6ul.c 
b/drivers/pinctrl/freescale/pinctrl-imx6ul.c
index 1aeb840aae1d..cbad1c69226d 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6ul.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6ul.c
@@ -150,6 +150,21 @@ enum imx6ul_pads {
MX6UL_PAD_CSI_DATA07 = 128,
 };
 
+enum imx6ull_lpsr_pads {
+   MX6ULL_PAD_BOOT_MODE0 = 0,
+   MX6ULL_PAD_BOOT_MODE1 = 1,
+   MX6ULL_PAD_SNVS_TAMPER0 = 2,
+   MX6ULL_PAD_SNVS_TAMPER1 = 3,
+   MX6ULL_PAD_SNVS_TAMPER2 = 4,
+   MX6ULL_PAD_SNVS_TAMPER3 = 5,
+   MX6ULL_PAD_SNVS_TAMPER4 = 6,
+   MX6ULL_PAD_SNVS_TAMPER5 = 7,
+   MX6ULL_PAD_SNVS_TAMPER6 = 8,
+   MX6ULL_PAD_SNVS_TAMPER7 = 9,
+   MX6ULL_PAD_SNVS_TAMPER8 = 10,
+   MX6ULL_PAD_SNVS_TAMPER9 = 11,
+};
+
 /* Pad names for the pinmux subsystem */
 static const struct pinctrl_pin_desc imx6ul_pinctrl_pads[] = {
IMX_PINCTRL_PIN(MX6UL_PAD_RESERVE0),
@@ -283,20 +298,53 @@ static const struct pinctrl_pin_desc 
imx6ul_pinctrl_pads[] = {
IMX_PINCTRL_PIN(MX6UL_PAD_CSI_DATA07),
 };
 
+/* pad for i.MX6ULL lpsr pinmux */
+static struct pinctrl_pin_desc imx6ull_snvs_pinctrl_pads[] = {
+   IMX_PINCTRL_PIN(MX6ULL_PAD_BOOT_MODE0),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_BOOT_MODE1),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER0),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER1),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER2),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER3),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER4),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER5),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER6),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER7),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER8),
+   IMX_PINCTRL_PIN(MX6ULL_PAD_SNVS_TAMPER9),
+};
+
 static struct imx_pinctrl_soc_info imx6ul_pinctrl_info = {
.pins = imx6ul_pinctrl_pads,
.npins = ARRAY_SIZE(imx6ul_pinctrl_pads),
.gpr_compatible = "fsl,imx6ul-iomuxc-gpr",
 };
 
+static struct imx_pinctrl_soc_info imx6ull_snvs_pinctrl_info = {
+   .pins = imx6ull_snvs_pinctrl_pads,
+   .npins = ARRAY_SIZE(imx6ull_snvs_pinctrl_pads),
+   .flags = ZERO_OFFSET_VALID,
+};
+
 static struct of_device_id imx6ul_pinctrl_of_match[] = {
-   { .compatible = "fsl,imx6ul-iomuxc", },
+   { .compatible = "fsl,imx6ul-iomuxc", .data = _pinctrl_info, },
+   { .compatible = "fsl,imx6ull-iomuxc-snvs", .data = 
_snvs_pinctrl_info, },
{ /* sentinel */ }
 };
 
 static int imx6ul_pinctrl_probe(struct platform_device *pdev)
 {
-   return imx_pinctrl_probe(pdev, _pinctrl_info);
+   const struct of_device_id *match;
+   struct imx_pinctrl_soc_info *pinctrl_info;
+
+   match = of_match_device(imx6ul_pinctrl_of_match, >dev);
+
+   if (!match)
+   return -ENODEV;
+
+   pinctrl_info = (struct imx_pinctrl_soc_info *) match->data;
+
+   return imx_pinctrl_probe(pdev, pinctrl_info);
 }
 
 static struct platform_driver imx6ul_pinctrl_driver = {
-- 
2.15.1

Re: [PATCH 4.4 00/63] 4.4.109-stable review

[Guenter Roeck]

On Mon, Jan 01, 2018 at 03:24:18PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.109 release.
> There are 63 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 13:59:54 UTC 2018.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 118 pass: 118 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v3] gpio: winbond: add driver

[kbuild test robot]

Hi Maciej,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.15-rc6 next-20180102]
[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/Maciej-S-Szmigiero/gpio-winbond-add-driver/20180103-011623
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> drivers/gpio/Kconfig:13:error: recursive dependency detected!
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpio/Kconfig:13: symbol GPIOLIB is selected by STX104
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/iio/adc/Kconfig:659: symbol STX104 depends on ISA_BUS_API
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   arch/Kconfig:818:symbol ISA_BUS_API is selected by GPIO_WINBOND
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpio/Kconfig:701:symbol GPIO_WINBOND depends on GPIOLIB
   .config:9795:warning: symbol value '' invalid for MIPS_CPS_NS16550_BASE
   .config:9796:warning: symbol value '' invalid for MIPS_CPS_NS16550_SHIFT
--
>> drivers/gpio/Kconfig:13:error: recursive dependency detected!
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpio/Kconfig:13: symbol GPIOLIB is selected by STX104
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/iio/adc/Kconfig:659: symbol STX104 depends on ISA_BUS_API
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   arch/Kconfig:818:symbol ISA_BUS_API is selected by GPIO_WINBOND
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpio/Kconfig:701:symbol GPIO_WINBOND depends on GPIOLIB
   .config:9795:warning: symbol value '' invalid for MIPS_CPS_NS16550_BASE
   .config:9796:warning: symbol value '' invalid for MIPS_CPS_NS16550_SHIFT
   make[3]: *** [silentoldconfig] Error 1
   make[2]: *** [silentoldconfig] Error 2
   make[1]: *** No rule to make target 'include/config/auto.conf', needed by 
'include/config/kernel.release'.
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +13 drivers/gpio/Kconfig

a9c5fff5 David Brownell 2008-02-04   4  
7563bbf8 Mark Brown 2012-04-15   5  config ARCH_HAVE_CUSTOM_GPIO_H
7563bbf8 Mark Brown 2012-04-15   6  bool
7563bbf8 Mark Brown 2012-04-15   7  help
7563bbf8 Mark Brown 2012-04-15   8Selecting this config option 
from the architecture Kconfig allows
7563bbf8 Mark Brown 2012-04-15   9the architecture to provide a 
custom asm/gpio.h implementation
7563bbf8 Mark Brown 2012-04-15  10overriding the default 
implementations.  New uses of this are
7563bbf8 Mark Brown 2012-04-15  11strongly discouraged.
7563bbf8 Mark Brown 2012-04-15  12  
7444a72e Michael Buesch 2008-07-25 @13  menuconfig GPIOLIB
7444a72e Michael Buesch 2008-07-25  14  bool "GPIO Support"
60a5eaba Linus Walleij  2016-06-08  15  select ANON_INODES
7444a72e Michael Buesch 2008-07-25  16  help
7444a72e Michael Buesch 2008-07-25  17This enables GPIO support 
through the generic GPIO library.
7444a72e Michael Buesch 2008-07-25  18You only need to enable this, 
if you also want to enable
e849dc04 Linus Walleij  2011-05-20  19one or more of the GPIO 
drivers below.
7444a72e Michael Buesch 2008-07-25  20  
7444a72e Michael Buesch 2008-07-25  21If unsure, say N.
a9c5fff5 David Brownell 2008-02-04  22  

:: The code at line 13 was first introduced by commit
:: 7444a72effa632fcd8edc566f880d96fe213c73b gpiolib: allow user-selection

:: TO: Michael Buesch <m...@bu3sch.de>
:: CC: Linus Torvalds <torva...@linux-foundation.org>

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


.config.gz
Description: application/gzip

Re: [PATCH V4 25/26] i7300_idle: remove unused file

[Greg Kroah-Hartman]

On Tue, Jan 02, 2018 at 08:36:46AM -0500, Sinan Kaya wrote:
> Hi Greg,
> 
> On 12/19/2017 12:38 AM, Sinan Kaya wrote:
> > i7300_idle.h is not being called by any source file and contains calls to
> > pci_get_bus_and_slot() that we are trying to deprecate. Remove unused file.
> > 
> > Signed-off-by: Sinan Kaya 
> 
> Do you think you can pick this up?

Sure, will do so, thanks.

greg k-h

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Bob Peterson]

- Original Message -
| Drop newline at the end of a message string when the printing function adds
| a newline.

Hi Julia,

NACK.

As much as it's a pain when searching the source code for output strings,
this patch set goes against the accepted Linux coding style document. See:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings

Regards,

Bob Peterson

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Bob Peterson]

- Original Message -
| - Original Message -
| | Drop newline at the end of a message string when the printing function adds
| | a newline.
| 
| Hi Julia,
| 
| NACK.
| 
| As much as it's a pain when searching the source code for output strings,
| this patch set goes against the accepted Linux coding style document. See:
| 
| 
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings
| 
| Regards,
| 
| Bob Peterson
| 
| 
Hm. I guess I stand corrected. The document reads:

"However, never break user-visible strings such as printk messages, because 
that breaks the ability to grep for them."

Still, the GFS2 and DLM code has a plethora of broken-up printk messages,
and I don't like the thought of re-combining them all.

Regards,

Bob Peterson

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Julia Lawall]

On Tue, 2 Jan 2018, Bob Peterson wrote:

> - Original Message -
> | Drop newline at the end of a message string when the printing function adds
> | a newline.
>
> Hi Julia,
>
> NACK.
>
> As much as it's a pain when searching the source code for output strings,
> this patch set goes against the accepted Linux coding style document. See:
>
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings

I don't think that's the case:

"However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them."

julia

>
> Regards,
>
> Bob Peterson
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver

[Marcin Wojtas]

Hi Andrew,

2018-01-02 14:33 GMT+01:00 Andrew Lunn :
>> Apart from the phylink's SFP support that may require in-band
>> management, it's an alternative to the normal PHY handling. Once MDIO
>> bus + PHYs are supported for ACPI, phylib support will be used instead
>> of the IRQs, so there should be no problem here.
>
> Hi Marcin
>
> However, phylib and phylink can use IRQs. The PHY can interrupt when
> there is a change of state. This can be seen in the DT binding
> documentation example:
>
> ethernet-phy@0 {
> compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22";
> interrupt-parent = <>;
> interrupts = <35 IRQ_TYPE_EDGE_RISING>;
> reg = <0>;
>
> Whatever ACPI support you propose needs to include interrupts.
>
> May i suggest you take a look at
> arch/arm/boot/dts/vf610-zii-dev-rev-c.dts and ensure your ACPI work
> can support this. I know you tend to concentrate of Marvell parts.
> Although it is a Freescale SoC, the Ethernet parts are all Marvell.
>
> The SoC exports an MDIO bus. We then have an MDIO multiplexer, which
> exports 8 MDIO busses. Of these only 2 are used in this design. Each
> bus has an Ethernet switch. Each switch has an MDIO bus, which the
> embedded PHYs are on. The Ethernet switch is also an interrupt
> controller for the PHYs interrupts. So the PHYs have interrupt
> properties pointing back to the switch.
>

I thought you were pointing possible problems in mvpp2 with PHY/link
interrupts, sorry. Now I get it :)

Indeed in of_mdio_bus_register_phy, there is of_irq_get. This is more
a discussion for a MDIO bus / ACPI patchset, but we either find a way
to use IRQs with ACPI obtained from child nodes or for this world the
functionality will be limited (at least for the beginning).

Best regards,
Marcin

Re: [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver

[Andrew Lunn]

> Indeed in of_mdio_bus_register_phy, there is of_irq_get. This is more
> a discussion for a MDIO bus / ACPI patchset, but we either find a way
> to use IRQs with ACPI obtained from child nodes or for this world the
> functionality will be limited (at least for the beginning).

Hi Marcin

What i want to avoid is adding something which partially works, and
then have to throw it all away and start again in order to add full
support.

If ACPI really limits interrupts to devices, maybe we need a totally
different representation of MDIO and PHYs in ACPI to what it used in
device tree? The same may be true for the Ethernet ports of the mvpp2?
They might have to be represented as real devices, not children of a
device? Maybe trying to map DT to ACPI on a one-to-one basis is the
wrong approach?

Andrew

Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations

[Matthew Wilcox]

On Fri, Dec 22, 2017 at 04:49:11PM +0800, Wei Wang wrote:
> Thanks for the improvement. I also found a small bug in xb_zero. With the
> following changes, it has passed the current test cases and tested with the
> virtio-balloon usage without any issue.

Thanks; I applied the change.  Can you supply a test-case for testing
xb_zero please?

> > @@ -25,8 +26,11 @@ idr-test: idr-test.o $(CORE_OFILES)
> >   multiorder: multiorder.o $(CORE_OFILES)
> > +xbitmap: xbitmap.o $(CORE_OFILES)
> > +   $(CC) $(CFLAGS) $(LDFLAGS) $^ -o xbitmap
> > +
> 
> I think the "$(CC).." line should be removed, which will fix the build error
> when adding "xbitmap" to TARGET.

Not sure what build error you're talking about, but yes that CC line
should go.  Thanks, deleted.

[PATCH v1] ACPI / boot: Don't shadow error code in acpi_gsi_to_irq()

[Andy Shevchenko]

acpi_get_override_irq() followed by acpi_register_gsi() return negative
error code on failure.

Don't shadow them in acpi_gsi_to_irq().

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 290b6f5a2d50..cd5745e598fb 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -622,17 +622,17 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
}
 
rc = acpi_get_override_irq(gsi, , );
-   if (rc == 0) {
-   trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
-   polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
-   irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
-   if (irq >= 0) {
-   *irqp = irq;
-   return 0;
-   }
-   }
+   if (rc)
+   return rc;
 
-   return -1;
+   trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+   polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+   irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+   if (irq < 0)
+   return irq;
+
+   *irqp = irq;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
-- 
2.15.1

Re: [PATCH v2 0/3] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled

[Jarkko Sakkinen]

On Mon, Dec 25, 2017 at 03:22:48AM +0100, Javier Martinez Canillas wrote:
> Hello,
> 
> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
> added logic in the TPM TIS driver to disable the Low Pin Count CLKRUN
> signal during TPM transactions.
> 
> Unfortunately this breaks other devices that are attached to the LPC bus
> like for example PS/2 mouse and keyboards.
> 
> The bug was reported to the Fedora kernel [0] and the kernel bugzilla [1].
> This issue and the propossed solution were discussed in this [2] thread,
> and the reporter (Jame Ettle) confirmed that his system works again after
> the fix in this series.
> 
> The patches are based on top or Jarkko Sakkinen's linux-tpmdd [3] tree.
> 
> Changes since v1:
> - Add collected tags
> - Drop patch that fixed a bug in the error path since was already fixed.
> 
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1498987
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=197287
> [2]: https://patchwork.kernel.org/patch/10119417/
> [3]: git.infradead.org/users/jjs/linux-tpmdd.git
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   tpm: delete the TPM_TIS_CLK_ENABLE flag
>   tpm: follow coding style for variable declaration in
> tpm_tis_core_init()
>   tpm: only attempt to disable the LPC CLKRUN if is already enabled
> 
>  drivers/char/tpm/tpm_tis.c  | 15 ---
>  drivers/char/tpm/tpm_tis_core.c | 17 +
>  drivers/char/tpm/tpm_tis_core.h |  1 -
>  3 files changed, 13 insertions(+), 20 deletions(-)
> 
> -- 
> 2.14.3
> 

Thanks, these are now applied.

/Jarkko

[PATCH v5 10/20] firmware: arm_scmi: probe and initialise all the supported protocols

[Sudeep Holla]

Now that we have basic support for all the protocols in the
specification, let's probe them individually and initialise them.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/driver.c | 51 +-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scmi/driver.c 
b/drivers/firmware/arm_scmi/driver.c
index 20d083be474c..11c18ac9816f 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -494,6 +494,21 @@ void scmi_setup_protocol_implemented(const struct 
scmi_handle *handle,
info->protocols_imp = prot_imp;
 }
 
+static bool
+scmi_is_protocol_implemented(const struct scmi_handle *handle, u8 prot_id)
+{
+   int i;
+   struct scmi_info *info = handle_to_scmi_info(handle);
+
+   if (!info->protocols_imp)
+   return false;
+
+   for (i = 0; i < MAX_PROTOCOLS_IMP; i++)
+   if (info->protocols_imp[i] == prot_id)
+   return true;
+   return false;
+}
+
 /**
  * scmi_handle_get() - Get the  SCMI handle for a device
  *
@@ -691,6 +706,23 @@ static inline int scmi_mbox_chan_setup(struct scmi_info 
*info)
return 0;
 }
 
+static inline void
+scmi_create_protocol_device(struct device_node *np, struct scmi_info *info,
+   int prot_id)
+{
+   struct scmi_device *sdev;
+
+   sdev = scmi_device_create(np, info->dev, prot_id);
+   if (!sdev) {
+   dev_err(info->dev, "failed to create %d protocol device\n",
+   prot_id);
+   return;
+   }
+
+   /* setup handle now as the transport is ready */
+   scmi_set_handle(sdev);
+}
+
 static int scmi_probe(struct platform_device *pdev)
 {
int ret;
@@ -698,7 +730,7 @@ static int scmi_probe(struct platform_device *pdev)
const struct scmi_desc *desc;
struct scmi_info *info;
struct device *dev = >dev;
-   struct device_node *np = dev->of_node;
+   struct device_node *child, *np = dev->of_node;
 
/* Only mailbox method supported, check for the presence of one */
if (scmi_mailbox_check(np)) {
@@ -741,6 +773,23 @@ static int scmi_probe(struct platform_device *pdev)
list_add_tail(>node, _list);
mutex_unlock(_list_mutex);
 
+   for_each_available_child_of_node(np, child) {
+   u32 prot_id;
+
+   if (of_property_read_u32(child, "reg", _id))
+   continue;
+
+   prot_id &= MSG_PROTOCOL_ID_MASK;
+
+   if (!scmi_is_protocol_implemented(handle, prot_id)) {
+   dev_err(dev, "SCMI protocol %d not implemented\n",
+   prot_id);
+   continue;
+   }
+
+   scmi_create_protocol_device(child, info, prot_id);
+   }
+
return 0;
 }
 
-- 
2.7.4

[PATCH v5 07/20] firmware: arm_scmi: add initial support for clock protocol

[Sudeep Holla]

The clock protocol is intended for management of clocks. It is used to
enable or disable clocks, and to set and get the clock rates. This
protocol provides commands to describe the protocol version, discover
various implementation specific attributes, describe a clock, enable
and disable a clock and get/set the rate of the clock synchronously or
asynchronously.

This patch adds initial support for the clock protocol.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/Makefile |   2 +-
 drivers/firmware/arm_scmi/clock.c  | 353 +
 include/linux/scmi_protocol.h  |  41 +
 3 files changed, 395 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/clock.c

diff --git a/drivers/firmware/arm_scmi/Makefile 
b/drivers/firmware/arm_scmi/Makefile
index 687cbbfb3af6..2130ee9ac825 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -1,4 +1,4 @@
 obj-y  = scmi-bus.o scmi-driver.o scmi-protocols.o
 scmi-bus-y = bus.o
 scmi-driver-y = driver.o
-scmi-protocols-y = base.o perf.o
+scmi-protocols-y = base.o clock.o perf.o
diff --git a/drivers/firmware/arm_scmi/clock.c 
b/drivers/firmware/arm_scmi/clock.c
new file mode 100644
index ..0fac1d4b377b
--- /dev/null
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -0,0 +1,353 @@
+/*
+ * System Control and Management Interface (SCMI) Clock Protocol
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see .
+ */
+
+#include "common.h"
+
+enum scmi_clock_protocol_cmd {
+   CLOCK_ATTRIBUTES = 0x3,
+   CLOCK_DESCRIBE_RATES = 0x4,
+   CLOCK_RATE_SET = 0x5,
+   CLOCK_RATE_GET = 0x6,
+   CLOCK_CONFIG_SET = 0x7,
+};
+
+struct scmi_msg_resp_clock_protocol_attributes {
+   __le16 num_clocks;
+   u8 max_async_req;
+   u8 reserved;
+};
+
+struct scmi_msg_resp_clock_attributes {
+   __le32 attributes;
+#defineCLOCK_ENABLEBIT(0)
+   u8 name[SCMI_MAX_STR_SIZE];
+};
+
+struct scmi_clock_set_config {
+   __le32 id;
+   __le32 attributes;
+};
+
+struct scmi_msg_clock_describe_rates {
+   __le32 id;
+   __le32 rate_index;
+};
+
+struct scmi_msg_resp_clock_describe_rates {
+   __le32 num_rates_flags;
+#define NUM_RETURNED(x)((x) & 0xfff)
+#define RATE_DISCRETE(x)   !((x) & BIT(12))
+#define NUM_REMAINING(x)   ((x) >> 16)
+   struct {
+   __le32 value_low;
+   __le32 value_high;
+   } rate[0];
+#define RATE_TO_U64(X) \
+({ \
+   typeof(X) x = (X);  \
+   le32_to_cpu((x).value_low) | (u64)le32_to_cpu((x).value_high) << 32; \
+})
+};
+
+struct scmi_clock_set_rate {
+   __le32 flags;
+#define CLOCK_SET_ASYNCBIT(0)
+#define CLOCK_SET_DELAYED  BIT(1)
+#define CLOCK_SET_ROUND_UP BIT(2)
+#define CLOCK_SET_ROUND_AUTO   BIT(3)
+   __le32 id;
+   __le32 value_low;
+   __le32 value_high;
+};
+
+struct clock_info {
+   int num_clocks;
+   int max_async_req;
+   struct scmi_clock_info *clk;
+};
+
+static int scmi_clock_protocol_attributes_get(const struct scmi_handle *handle,
+ struct clock_info *ci)
+{
+   int ret;
+   struct scmi_xfer *t;
+   struct scmi_msg_resp_clock_protocol_attributes *attr;
+
+   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+SCMI_PROTOCOL_CLOCK, 0, sizeof(*attr), );
+   if (ret)
+   return ret;
+
+   attr = t->rx.buf;
+
+   ret = scmi_do_xfer(handle, t);
+   if (!ret) {
+   ci->num_clocks = le16_to_cpu(attr->num_clocks);
+   ci->max_async_req = attr->max_async_req;
+   }
+
+   scmi_one_xfer_put(handle, t);
+   return ret;
+}
+
+static int scmi_clock_attributes_get(const struct scmi_handle *handle,
+u32 clk_id, struct scmi_clock_info *clk)
+{
+   int ret;
+   struct scmi_xfer *t;
+   struct scmi_msg_resp_clock_attributes *attr;
+
+   ret = scmi_one_xfer_init(handle, CLOCK_ATTRIBUTES, SCMI_PROTOCOL_CLOCK,
+sizeof(clk_id), sizeof(*attr), );
+   if (ret)
+   return ret;
+
+   *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
+   attr = t->rx.buf;
+
+  

[PATCH v5 04/20] firmware: arm_scmi: add common infrastructure and support for base protocol

[Sudeep Holla]

The base protocol describes the properties of the implementation and
provide generic error management. The base protocol provides commands
to describe protocol version, discover implementation specific
attributes and vendor/sub-vendor identification, list of protocols
implemented and the various agents are in the system including OSPM
and the platform. It also supports registering for notifications of
platform errors.

This protocol is mandatory. This patch adds support for the same along
with some basic infrastructure to add support for other protocols.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/Makefile |   3 +-
 drivers/firmware/arm_scmi/base.c   | 293 +
 drivers/firmware/arm_scmi/common.h |  37 +
 drivers/firmware/arm_scmi/driver.c |  53 +++
 include/linux/scmi_protocol.h  |  37 +
 5 files changed, 422 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/base.c

diff --git a/drivers/firmware/arm_scmi/Makefile 
b/drivers/firmware/arm_scmi/Makefile
index b2a24ba2b636..5d9c7ef35f0f 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -1,2 +1,3 @@
-obj-y  = scmi-driver.o
+obj-y  = scmi-driver.o scmi-protocols.o
 scmi-driver-y = driver.o
+scmi-protocols-y = base.o
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
new file mode 100644
index ..2b5fbb724899
--- /dev/null
+++ b/drivers/firmware/arm_scmi/base.c
@@ -0,0 +1,293 @@
+/*
+ * System Control and Management Interface (SCMI) Base Protocol
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see .
+ */
+
+#include "common.h"
+
+enum scmi_base_protocol_cmd {
+   BASE_DISCOVER_VENDOR = 0x3,
+   BASE_DISCOVER_SUB_VENDOR = 0x4,
+   BASE_DISCOVER_IMPLEMENT_VERSION = 0x5,
+   BASE_DISCOVER_LIST_PROTOCOLS = 0x6,
+   BASE_DISCOVER_AGENT = 0x7,
+   BASE_NOTIFY_ERRORS = 0x8,
+};
+
+struct scmi_msg_resp_base_attributes {
+   u8 num_protocols;
+   u8 num_agents;
+   __le16 reserved;
+};
+
+/**
+ * scmi_base_attributes_get() - gets the implementation details
+ * that are associated with the base protocol.
+ *
+ * @handle - SCMI entity handle
+ *
+ * Return: 0 on success, else appropriate SCMI error.
+ */
+static int scmi_base_attributes_get(const struct scmi_handle *handle)
+{
+   int ret;
+   struct scmi_xfer *t;
+   struct scmi_msg_resp_base_attributes *attr_info;
+   struct scmi_revision_info *rev = handle->version;
+
+   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+SCMI_PROTOCOL_BASE, 0, sizeof(*attr_info), );
+   if (ret)
+   return ret;
+
+   ret = scmi_do_xfer(handle, t);
+   if (!ret) {
+   attr_info = t->rx.buf;
+   rev->num_protocols = attr_info->num_protocols;
+   rev->num_agents = attr_info->num_agents;
+   }
+
+   scmi_one_xfer_put(handle, t);
+   return ret;
+}
+
+/**
+ * scmi_base_vendor_id_get() - gets vendor/subvendor identifier ASCII string.
+ *
+ * @handle - SCMI entity handle
+ * @sub_vendor - specify true if sub-vendor ID is needed
+ *
+ * Return: 0 on success, else appropriate SCMI error.
+ */
+static int
+scmi_base_vendor_id_get(const struct scmi_handle *handle, bool sub_vendor)
+{
+   u8 cmd;
+   int ret, size;
+   char *vendor_id;
+   struct scmi_xfer *t;
+   struct scmi_revision_info *rev = handle->version;
+
+   if (sub_vendor) {
+   cmd = BASE_DISCOVER_SUB_VENDOR;
+   vendor_id = rev->sub_vendor_id;
+   size = ARRAY_SIZE(rev->sub_vendor_id);
+   } else {
+   cmd = BASE_DISCOVER_VENDOR;
+   vendor_id = rev->vendor_id;
+   size = ARRAY_SIZE(rev->vendor_id);
+   }
+
+   ret = scmi_one_xfer_init(handle, cmd, SCMI_PROTOCOL_BASE, 0, size, );
+   if (ret)
+   return ret;
+
+   ret = scmi_do_xfer(handle, t);
+   if (!ret)
+   memcpy(vendor_id, t->rx.buf, size);
+
+   scmi_one_xfer_put(handle, t);
+   return ret;
+}
+
+/**
+ * scmi_base_implementation_version_get() - gets a vendor-specific
+ * implementation 32-bit version. The format of the version number is
+ * vendor-specific
+ *
+ * @handle - SCMI entity handle

[PATCH v5 08/20] firmware: arm_scmi: add initial support for power protocol

[Sudeep Holla]

The power protocol is intended for management of power states of various
power domains. The power domain management protocol provides commands to
describe the protocol version, discover the implementation specific
attributes, set and get the power state of a domain.

This patch adds support for the above mention features of the protocol.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
--
 drivers/firmware/arm_scmi/Makefile |   2 +-
 drivers/firmware/arm_scmi/power.c  | 242 +
 include/linux/scmi_protocol.h  |  28 +
 3 files changed, 271 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/power.c
---
 drivers/firmware/arm_scmi/Makefile |   2 +-
 drivers/firmware/arm_scmi/power.c  | 255 +
 include/linux/scmi_protocol.h  |  29 +
 3 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/power.c

diff --git a/drivers/firmware/arm_scmi/Makefile 
b/drivers/firmware/arm_scmi/Makefile
index 2130ee9ac825..420c761ced94 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -1,4 +1,4 @@
 obj-y  = scmi-bus.o scmi-driver.o scmi-protocols.o
 scmi-bus-y = bus.o
 scmi-driver-y = driver.o
-scmi-protocols-y = base.o clock.o perf.o
+scmi-protocols-y = base.o clock.o perf.o power.o
diff --git a/drivers/firmware/arm_scmi/power.c 
b/drivers/firmware/arm_scmi/power.c
new file mode 100644
index ..50195bd6bbd2
--- /dev/null
+++ b/drivers/firmware/arm_scmi/power.c
@@ -0,0 +1,255 @@
+/*
+ * System Control and Management Interface (SCMI) Power Protocol
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see .
+ */
+
+#include "common.h"
+
+enum scmi_power_protocol_cmd {
+   POWER_DOMAIN_ATTRIBUTES = 0x3,
+   POWER_STATE_SET = 0x4,
+   POWER_STATE_GET = 0x5,
+   POWER_STATE_NOTIFY = 0x6,
+};
+
+struct scmi_msg_resp_power_attributes {
+   __le16 num_domains;
+   __le16 reserved;
+   __le32 stats_addr_low;
+   __le32 stats_addr_high;
+   __le32 stats_size;
+};
+
+struct scmi_msg_resp_power_domain_attributes {
+   __le32 flags;
+#define SUPPORTS_STATE_SET_NOTIFY(x)   ((x) & BIT(31))
+#define SUPPORTS_STATE_SET_ASYNC(x)((x) & BIT(30))
+#define SUPPORTS_STATE_SET_SYNC(x) ((x) & BIT(29))
+   u8 name[SCMI_MAX_STR_SIZE];
+};
+
+struct scmi_power_set_state {
+   __le32 flags;
+#define STATE_SET_ASYNCBIT(0)
+   __le32 domain;
+   __le32 state;
+};
+
+struct scmi_power_state_notify {
+   __le32 domain;
+   __le32 notify_enable;
+};
+
+struct power_dom_info {
+   bool state_set_sync;
+   bool state_set_async;
+   bool state_set_notify;
+   char name[SCMI_MAX_STR_SIZE];
+};
+
+struct scmi_power_info {
+   int num_domains;
+   u64 stats_addr;
+   u32 stats_size;
+   struct power_dom_info *dom_info;
+};
+
+static int scmi_power_attributes_get(const struct scmi_handle *handle,
+struct scmi_power_info *pi)
+{
+   int ret;
+   struct scmi_xfer *t;
+   struct scmi_msg_resp_power_attributes *attr;
+
+   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+SCMI_PROTOCOL_POWER, 0, sizeof(*attr), );
+   if (ret)
+   return ret;
+
+   attr = t->rx.buf;
+
+   ret = scmi_do_xfer(handle, t);
+   if (!ret) {
+   pi->num_domains = le16_to_cpu(attr->num_domains);
+   pi->stats_addr = le32_to_cpu(attr->stats_addr_low) |
+   (u64)le32_to_cpu(attr->stats_addr_high) << 32;
+   pi->stats_size = le32_to_cpu(attr->stats_size);
+   }
+
+   scmi_one_xfer_put(handle, t);
+   return ret;
+}
+
+static int
+scmi_power_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
+struct power_dom_info *dom_info)
+{
+   int ret;
+   struct scmi_xfer *t;
+   struct scmi_msg_resp_power_domain_attributes *attr;
+
+   ret = scmi_one_xfer_init(handle, POWER_DOMAIN_ATTRIBUTES,
+SCMI_PROTOCOL_POWER, sizeof(domain),
+sizeof(*attr), );
+   if (ret)
+   return ret;
+
+   *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+   attr = t->rx.buf;

Re: [PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators

[David Howells]

NeilBrown  wrote:

> David: do you agree that this sort of content would be appropriate in
> that file (which you apparently authored).  Would you like to update it,
> or shall I?

Please update it.

Thanks,
David

[PATCH v5 03/15] clk: ingenic: support PLLs with no bypass bit

[Paul Cercueil]

The second PLL of the JZ4770 does not have a bypass bit.
This commit makes it possible to support it with the current common CGU
code.

Signed-off-by: Paul Cercueil 
Acked-by: Stephen Boyd 
---
 drivers/clk/ingenic/cgu.c | 3 ++-
 drivers/clk/ingenic/cgu.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

 v2: No change
 v3: No change
 v4: No change
 v5: No change

diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index a2e73a6d60fd..381c4a17a1fc 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -100,7 +100,8 @@ ingenic_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
n += pll_info->n_offset;
od_enc = ctl >> pll_info->od_shift;
od_enc &= GENMASK(pll_info->od_bits - 1, 0);
-   bypass = !!(ctl & BIT(pll_info->bypass_bit));
+   bypass = !pll_info->no_bypass_bit &&
+!!(ctl & BIT(pll_info->bypass_bit));
enable = !!(ctl & BIT(pll_info->enable_bit));
 
if (bypass)
diff --git a/drivers/clk/ingenic/cgu.h b/drivers/clk/ingenic/cgu.h
index f1527cf75b3f..9da34910bd80 100644
--- a/drivers/clk/ingenic/cgu.h
+++ b/drivers/clk/ingenic/cgu.h
@@ -48,6 +48,7 @@
  * @bypass_bit: the index of the bypass bit in the PLL control register
  * @enable_bit: the index of the enable bit in the PLL control register
  * @stable_bit: the index of the stable bit in the PLL control register
+ * @no_bypass_bit: if set, the PLL has no bypass functionality
  */
 struct ingenic_cgu_pll_info {
unsigned reg;
@@ -58,6 +59,7 @@ struct ingenic_cgu_pll_info {
u8 bypass_bit;
u8 enable_bit;
u8 stable_bit;
+   bool no_bypass_bit;
 };
 
 /**
-- 
2.11.0

Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

[Fabio Estevam]

Hi Anson,

On Tue, Jan 2, 2018 at 1:05 PM, Anson Huang  wrote:

> This change is to support 696MHz operating point, both the speed grading
> check and pll rate change are necessary for 696MHz support, do you think
> they should be in different patch?

I thought  this could also change the behaviour for mx6q/dl/qp.

Are the others SoCs safe with this change?

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

[Arnd Bergmann]

> On 2017-12-31 07:10, Arnd Bergmann wrote:
> > On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang
> >  wrote:
> >> When PCH works under eSPI mode, the PMC (Power Management Controller) in
> >> PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in
> >> dead loop if no SUS_ACK assert. This is the basic requirement for the BMC
> >> works as eSPI slave.
> >>
> >> Also for the host power on / off actions, from BMC side, the following VW
> >> (Virtual Wire) messages are done in firmware:
> >> 1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS
> >> 2. SUS_ACK
> >> 3. OOB_RESET_ACK
> >> 4. HOST_RESET_ACK
> > I have not looked at the driver contents yet, but I'm adding the SPI
> > maintainer and
> > mailing list to Cc here for further discussion. Can you clarify how
> > the eSPI slave
> > mode relates to SPI slaves that we already support? I was under the 
> > impression
> > that the difference between SPI and eSPI is mainly on the master side, but 
> > that
> > any SPI slave can also act as an eSPI slave. Would this driver fit into the 
> > SPI
> > slave framework, possibly with some extensions to the generic abstraction?
> In simple word, the eSPI uses the SPI interface pin definition, but it
> will replace Low Pin Count (LPC)
> interface. From its name, sure, it will confuse you! ;-)

I know what eSPI is meant for, and understand the basic idea of the
protocol, but I'm not familiar with the Apeed slave hardware
implementation.

> > It also seems rather inflexible to have a single driver that is responsible 
> > both
> > for the transport (eSPI register level interface for ASPEED) and the 
> > high-level
> > protocol (talking to an Intel PCH), since either half of the work could be
> > done elsewhere, using either a different eSPI slave implementation, or
> > a different
> > host architecture)
> Yes, eSPI has the architecture such as transaction layer, link Layer;
> all of it is about the **silicon**
> design. That's why I put the driver under /misc directory, not /spi
> directory.

I don't see any requirement in the eSPI spec for the upper layers to
be implemented in hardware. Obviously an x86 host such as Intel's
PCH would implement the host interface using PIO,  and MMIO
accesses that are compatible with ISA and LPC, as this is the motivation
behind the specification, but an ARM server that wants to use eSPI
based peripherals could choose to implement it just as well using
a traditional SPI master hardware, some GPIOs (reset and alert)
and a (driver independent) software implementation of the transaction
and link layers.

On the slave side, it seems that aspeed have implemented the
virtual wires partially in hardware and require a driver like the one
you wrote to reply to some of the wires being accessed by the host,
but again it seems plausible that this could be implemented in another
BMC using a generic SPI slave and a transaction layer written
entirely in software.

Your driver does not handle the other channels (smbus, mmio, spinor)
at the moment at all, can you provide some information how they
are implemented in the ast2500? Are those handled completely
in hardware (I assume this is the case for spinor at least), or do they
require help from a driver, either this one or a separate one?

   Arnd

[PATCH] ACPI: Fix debugfs_create_*() usage

[Geert Uytterhoeven]

acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose
the wrong half on big-endian 64-bit systems.  Fix this by changing its
type to "u32" and removing the cast, as all other code already uses u32
or sometimes even only u8.

Fixes: 1195a098168fcacf ("ACPI: Provide /sys/kernel/debug/ec/...")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 drivers/acpi/ec.c   | 2 +-
 drivers/acpi/ec_sys.c   | 2 +-
 drivers/acpi/internal.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 0252c9b9af3d3a09..d9f38c645e4a1dc7 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1516,7 +1516,7 @@ static int acpi_ec_setup(struct acpi_ec *ec, bool 
handle_events)
}
 
acpi_handle_info(ec->handle,
-"GPE=0x%lx, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n",
+"GPE=0x%x, EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n",
 ec->gpe, ec->command_addr, ec->data_addr);
return ret;
 }
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index 6c7dd7af789e453c..dd70d6c2bca03eb2 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned 
int ec_device_count)
return -ENOMEM;
}
 
-   if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
+   if (!debugfs_create_x32("gpe", 0444, dev_dir, _ec->gpe))
goto error;
if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
 _ec->global_lock))
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 7f43423de43cebdd..1d0a501bc7f0cbbf 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -159,7 +159,7 @@ static inline void acpi_early_processor_osc(void) {}
-- 
*/
 struct acpi_ec {
acpi_handle handle;
-   unsigned long gpe;
+   u32 gpe;
unsigned long command_addr;
unsigned long data_addr;
bool global_lock;
-- 
2.7.4

Re: linux-next: build warning after merge of the netfilter-next tree

[Pablo Neira Ayuso]

Hi Stephen,

On Tue, Jan 02, 2018 at 12:14:51PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the netfilter-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> In file included from net/ipv6/af_inet6.c:45:0:
> include/linux/netfilter_ipv6.h:38:51: warning: 'struct nf_queue_entry' 
> declared inside parameter list
>   int (*reroute)(struct sk_buff *skb, const struct nf_queue_entry *entry);
>^

Arnd sent a fix for this, thanks for reporting!

https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git/commit/

Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64

[Arnd Bergmann]

On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov
 wrote:
> On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote:
>> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
>>  {
>>   struct evdev *evdev = handle->private;
>>   struct evdev_client *client;
>> - ktime_t ev_time[EV_CLK_MAX];
>> + struct timespec64 ev_time[EV_CLK_MAX];
>>
>> - ev_time[EV_CLK_MONO] = ktime_get();
>> - ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
>> - ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
>> -  TK_OFFS_BOOT);
>> + ktime_get_ts64(_time[EV_CLK_MONO]);
>> + ktime_get_real_ts64(_time[EV_CLK_REAL]);
>> + get_monotonic_boottime64(_time[EV_CLK_BOOT]);
>
> This may result in different ev_time[] members holding different times,
> whereas the original code would take one time sample and convert it to
> different clocks.

Is this important? On each client we only return one of the two
times, and I would guess that you cannot rely on a correlation
between timestamps on different devices, since the boot and real
offsets can change over time.

> Also, why can't we keep using ktime_t internally? It is y2038 safe,
> right?

Correct, but there may also be a performance difference if we get
a lot of events, not sure if that matters.

> I think you should drop this patch and adjust the 3rd one to
> massage the input event timestamp patch to do ktime->timespec64->input
> timestamp conversion.

The change in __evdev_queue_syn_dropped still seems useful to me
as ktime_get_*ts64() is a bit more efficient than ktime_get*() followed by
a slow ktime_to_timespec64() or ktime_to_timeval().

For evdev_events(), doing a single ktime_get() followed by a
ktime_to_timespec64/ktime_to_timeval can be faster than three
ktime_get_*ts64 (depending on the hardware clock source), or
it can be slower depending on the CPU and the clocksource
hardware. Again, no idea if this matters at the usual rate of
input events.

I guess dropping the evdev_events() change and replacing it with a
ktime_to_timespec64 change in evdev_pass_values()
would be fine here, it should keep the current performance
behavior and get rid of the timeval.

   Arnd

Re: [PATCH v2 2/2] PCI: dra7xx: Iterate over INTx status bits

[Lorenzo Pieralisi]

On Fri, Dec 29, 2017 at 05:11:31PM +0530, Vignesh R wrote:
> It is possible that more than one legacy IRQ may be set at the same
> time, therefore iterate and handle all the pending INTx interrupts
> before clearing the status and exiting the IRQ handler. Otherwise, some
> interrupts would be lost.
> 
> Signed-off-by: Vignesh R 
> ---
>  drivers/pci/dwc/pci-dra7xx.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index 892f93910012..48c6ae535847 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -257,7 +257,8 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
> void *arg)
>   struct dra7xx_pcie *dra7xx = arg;
>   struct dw_pcie *pci = dra7xx->pci;
>   struct pcie_port *pp = >pp;
> - u32 reg;
> + unsigned long reg;
> + u32 virq, bit;
>  
>   reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>  
> @@ -269,8 +270,11 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
> void *arg)
>   case INTB:
>   case INTC:
>   case INTD:
> - generic_handle_irq(irq_find_mapping(dra7xx->irq_domain,
> - ffs(reg) - 1));
> + for_each_set_bit(bit, , PCI_NUM_INTX) {
> + virq = irq_find_mapping(dra7xx->irq_domain, bit);
> + if (virq)
> + generic_handle_irq(virq);
> + }
>   break;
>   }

It is not strictly related to this patch but why MSI and INTX are
handled as mutually exclusive in dra7xx_pcie_msi_irq_handler() ?

Lorenzo

Re: [PATCH 2/3] mfd: axp20x: Add support for backup battery charging

[Lee Jones]

On Sat, 30 Dec 2017, Paul Kocialkowski wrote:

> This adds support for backup battery charging for axp20x PMICs, that is
> configured through a dedicated device-tree property.
> 
> It supports 4 different charging voltages and as many charging currents.
> This is especially useful to allow the on-chip RTC (on the SoC side) to
> be powered when the rest of the system is off.
> 
> Signed-off-by: Paul Kocialkowski 
> 
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 2468b431bb22..7847f5d0b979 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -34,6 +34,16 @@
>  #define AXP806_REG_ADDR_EXT_ADDR_MASTER_MODE 0
>  #define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE  BIT(4)
>  
> +#define AXP20X_CHRG_BAK_CTRL_ENABLE  BIT(7)
> +#define AXP20X_CHRG_BAK_VOLTAGE_3100_MV  (0 << 5)
> +#define AXP20X_CHRG_BAK_VOLTAGE_3000_MV  (1 << 5)
> +#define AXP20X_CHRG_BAK_VOLTAGE_3600_MV  (2 << 5)
> +#define AXP20X_CHRG_BAK_VOLTAGE_2500_MV  (3 << 5)
> +#define AXP20X_CHRG_BAK_CURRENT_50_UA(0 << 0)
> +#define AXP20X_CHRG_BAK_CURRENT_100_UA   (1 << 0)
> +#define AXP20X_CHRG_BAK_CURRENT_200_UA   (2 << 0)
> +#define AXP20X_CHRG_BAK_CURRENT_400_UA   (3 << 0)
> +
>  static const char * const axp20x_model_names[] = {
>   "AXP152",
>   "AXP202",
> @@ -894,6 +904,63 @@ static void axp20x_power_off(void)
>   msleep(500);
>  }
>  
> +static void axp20x_backup_setup(struct axp20x_dev *axp20x)
> +{
> + u32 backup[2];
> + int reg;
> + int ret;
> +
> + ret = of_property_read_u32_array(axp20x->dev->of_node, "backup", backup,
> +  2);
> + if (ret != 0)

Nit:
if (ret)

> + return;
> +
> + switch (axp20x->variant) {
> + case AXP202_ID:
> + case AXP209_ID:

Nested switch statements, hmm ...

Instead, what if you either only invoked this function for supported
devices, or at least returned early for non-supported ones?

if (axp20x->variant != AXP202_ID && axp20x->variant != AXP209_ID)
return;

> + reg = AXP20X_CHRG_BAK_CTRL_ENABLE;
> +
> + /* Charging voltage. */
> + switch (backup[0]) {
> + case 2500:
> + reg |= AXP20X_CHRG_BAK_VOLTAGE_2500_MV;
> + break;
> + case 3000:
> + reg |= AXP20X_CHRG_BAK_VOLTAGE_3000_MV;
> + break;
> + case 3100:
> + reg |= AXP20X_CHRG_BAK_VOLTAGE_3100_MV;
> + break;
> + case 3600:
> + reg |= AXP20X_CHRG_BAK_VOLTAGE_3600_MV;
> + break;
> + default:
> + return;
> + }
> +
> + /* Charging current. */
> + switch (backup[1]) {
> + case 50:
> + reg |= AXP20X_CHRG_BAK_CURRENT_50_UA;
> + break;
> + case 100:
> + reg |= AXP20X_CHRG_BAK_CURRENT_100_UA;
> + break;
> + case 200:
> + reg |= AXP20X_CHRG_BAK_CURRENT_200_UA;
> + break;
> + case 400:
> + reg |= AXP20X_CHRG_BAK_CURRENT_400_UA;
> + break;
> + default:
> + return;
> + }
> +
> + regmap_write(axp20x->regmap, AXP20X_CHRG_BAK_CTRL, reg);
> + break;
> + }
> +}
> +
>  int axp20x_match_device(struct axp20x_dev *axp20x)
>  {
>   struct device *dev = axp20x->dev;
> @@ -1023,6 +1090,9 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
>AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
>   }
>  
> + /* Backup RTC battery. */
> + axp20x_backup_setup(axp20x);
> +
>   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
> IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
>  -1, axp20x->regmap_irq_chip, >regmap_irqc);

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 16/22] mmc: tmio: fix never-detected card insertion bug

[Wolfram Sang]

Yamada-san,

> The TMIO mmc cannot detect the card insertion in native_hotplug mode
> if the driver is probed without a card inserted.

Hmm, it works for me without your patch just fine. Iam currently
researching it...

Happy new year, by the way! :)

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

[Ulf Hansson]

On 24 December 2017 at 13:00, Rafael J. Wysocki  wrote:
> On Saturday, December 23, 2017 4:09:33 PM CET Ulf Hansson wrote:
>> [...]
>>
>> >
>> > So IMO the changes you are proposing make sense regardless of the
>> > genpd issue, because they generally simplify the phy code, but the
>> > additional use_runtime_pm field in struct phy represents redundant
>> > information (manipulating reference counters shouldn't matter if
>> > runtime PM is disabled), so it doesn't appear to be necessary.
>> >
>>
>> Actually, the first version I posted treated the return codes from
>> pm_runtime_get_sync() according to your suggestion above.
>>
>> However, Kishon pointed out that it didn't work. That's because, there
>> are phy provider drivers that enables runtime PM *after* calling
>> phy_create(). And in those cases, that is because they want to treat
>> runtime PM themselves.
>>
>> I think that's probably something we should look into to change, but I
>> find it being a separate issue, that I didn't want to investigate as
>> part of this series.
>>
>> See more about the thread here:
>> https://www.spinics.net/lists/linux-renesas-soc/msg21711.html
>
> Even so, it shouldn't matter when the provider enables runtime PM.
>
> Calling pm_runtime_get_*()/pm_runtime_put_*() should always work as
> long as they are balanced properly regardless of whether or not
> runtime PM is enabled for the device or it is enabled in the meantime.
> Of course, the initial runtime PM status of the device must reflect
> the values of the usage counters, but that should not be too hard to
> ensure.

Yes, this is probably the main reason.

However, as stated, I think we should look into addressing this
problem more carefully, in a separate next step.

>
> The reason why it matters here is because the phy core tries to be smart
> about manipulating reference counters by itself and that's a mistake.
>
> So it looks to me like the whole thing needs to be reworked and yes,
> that should be done in the first place IMO, because it will make the
> issue with genpd go away automatically.

Sorry, but I am not fully understanding what you suggest here. Perhaps
you didn't check patch2?

>
> [Why is phy_pm_runtime_get() there at all, for instance?  It seems
> to have no users and I kind of don't see use cases for it.  Also
> phy_pm_runtime_get_sync() is only used by the phy core in three
> places - shouldn't be too hard to fix that.]

Removing these APIs and functions is done in patch2, so I guess I am
already doing what you suggests above? No?

[...]

Kind regards
Uffe

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

[Mel Gorman]

On Tue, Jan 02, 2018 at 12:29:55PM +0100, Jan Kara wrote:
> On Tue 02-01-18 10:21:03, Mel Gorman wrote:
> > On Sat, Dec 23, 2017 at 10:36:53AM +0900, Minchan Kim wrote:
> > > > code path.  It appears that similar situation is possible for them too.
> > > > 
> > > > The file cache pages will be delete from file cache address_space before
> > > > address_space (embedded in inode) is freed.  But they will be deleted
> > > > from LRU list only when its refcount dropped to zero, please take a look
> > > > at put_page() and release_pages().  While address_space will be freed
> > > > after putting reference to all file cache pages.  If someone holds a
> > > > reference to a file cache page for quite long time, it is possible for a
> > > > file cache page to be in LRU list after the inode/address_space is
> > > > freed.
> > > > 
> > > > And I found inode/address_space is freed witch call_rcu().  I don't know
> > > > whether this is related to page_mapping().
> > > > 
> > > > This is just my understanding.
> > > 
> > > Hmm, it smells like a bug of __isolate_lru_page.
> > > 
> > > Ccing Mel:
> > > 
> > > What locks protects address_space destroying when race happens between
> > > inode trauncation and __isolate_lru_page?
> > > 
> > 
> > I'm just back online and have a lot of catching up to do so this is a rushed
> > answer and I didn't read the background of this. However the question is
> > somewhat ambiguous and the scope is broad as I'm not sure which race you
> > refer to. For file cache pages, I wouldnt' expect the address_space to be
> > destroyed specifically as long as the inode exists which is the structure
> > containing the address_space in this case. A page on the LRU being isolated
> > in __isolate_lru_page will have an elevated reference count which will
> > pin the inode until remove_mapping is called which holds the page lock
> > while inode truncation looking at a page for truncation also only checks
> > page_mapping under the page lock. Very broadly speaking, pages avoid being
> > added back to an inode being freed by checking the I_FREEING state.
> 
> So I'm wondering what prevents the following:
> 
> CPU1  CPU2
> 
> truncate(inode)   __isolate_lru_page()
>   ...
>   truncate_inode_page(mapping, page);
> delete_from_page_cache(page)
>   spin_lock_irqsave(>tree_lock, flags);
> __delete_from_page_cache(page, NULL)
>   page_cache_tree_delete(..)
> ... mapping = 
> page_mapping(page);
> page->mapping = NULL;
> ...
>   spin_unlock_irqrestore(>tree_lock, flags);
>   page_cache_free_page(mapping, page)
> put_page(page)
>   if (put_page_testzero(page)) -> false
> - inode now has no pages and can be freed including embedded address_space
> 
> if (mapping && 
> !mapping->a_ops->migratepage)
> - we've dereferenced mapping which is potentially already free.
> 

Hmm, possible if unlikely.

Before delete_from_page_cache, we called truncate_cleanup_page so the
page is likely to be !PageDirty or PageWriteback which gets skipped by
the only caller that checks the mappping in __isolate_lru_page. The race
is tiny but it does exist. One way of closing it is to check the mapping
under the page lock which will prevent races with truncation. The
overhead is minimal as the calling context (compaction) is quite a heavy
operation anyway.

Build tested only for review


diff --git a/mm/vmscan.c b/mm/vmscan.c
index c02c850ea349..61bf0bc60d96 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1433,14 +1433,24 @@ int __isolate_lru_page(struct page *page, 
isolate_mode_t mode)
 
if (PageDirty(page)) {
struct address_space *mapping;
+   bool migrate_dirty;
 
/*
 * Only pages without mappings or that have a
 * ->migratepage callback are possible to migrate
-* without blocking
+* without blocking. However, we can be racing with
+* truncation so it's necessary to lock the page
+* to stabilise the mapping as truncation holds
+* the page lock until after the page is removed
+* from the page cache.
 */
+   if (!trylock_page(page))
+   return ret;
+
mapping = page_mapping(page);
-   if (mapping && !mapping->a_ops->migratepage)
+   migrate_dirty = mapping && mapping->a_ops->migratepage;
+   unlock_page(page);
+   if (!migrate_dirty)
return ret;
}
}

-- 
Mel Gorman
SUSE Labs

RE: [PATCH v3 1/9] ufs: sysfs: device descriptor

[Stanislav Nijnikov]

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, December 28, 2017 9:37 PM
> To: Stanislav Nijnikov 
> Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org;
> gre...@linuxfoundation.org; Alex Lemberg 
> Subject: Re: [PATCH v3 1/9] ufs: sysfs: device descriptor
> 
> On 12/28, Stanislav Nijnikov wrote:
> > This patch introduces a sysfs group entry for the UFS device
> > descriptor parameters. The group adds "device_descriptor" folder under
> > the UFS driver sysfs entry (/sys/bus/platform/drivers/ufshcd/*). The
> > parameters are shown as hexadecimal numbers. The full information
> > about the parameters could be found at UFS specifications 2.1.
> >
> > Signed-off-by: Stanislav Nijnikov 
> > ---
> >  Documentation/ABI/testing/sysfs-driver-ufs | 223
> +
> >  drivers/scsi/ufs/Makefile  |   3 +-
> >  drivers/scsi/ufs/ufs-sysfs.c   | 170 ++
> >  drivers/scsi/ufs/ufs-sysfs.h   |  25 
> >  drivers/scsi/ufs/ufs.h |   8 ++
> >  drivers/scsi/ufs/ufshcd.c  |  12 +-
> >  drivers/scsi/ufs/ufshcd.h  |   4 +
> >  7 files changed, 439 insertions(+), 6 deletions(-)  create mode
> > 100644 Documentation/ABI/testing/sysfs-driver-ufs
> >  create mode 100644 drivers/scsi/ufs/ufs-sysfs.c  create mode 100644
> > drivers/scsi/ufs/ufs-sysfs.h
> >
> > diff --git a/Documentation/ABI/testing/sysfs-driver-ufs
> > b/Documentation/ABI/testing/sysfs-driver-ufs
> > new file mode 100644
> > index 000..17cc4aa
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-ufs
> 
> [snip]
> 
> > diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
> > index 9310c6c..918f579 100644
> > --- a/drivers/scsi/ufs/Makefile
> > +++ b/drivers/scsi/ufs/Makefile
> > @@ -3,6 +3,7 @@
> >  obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-
> dwc.o
> > tc-dwc-g210.o
> >  obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
> > ufshcd-dwc.o tc-dwc-g210.o
> >  obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
> > -obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
> > +obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o ufshcd-core-objs :=
> > +ufshcd.o ufs-sysfs.o
> 
> Why not just adding ufs-sysfs.o in the existing configuration?

The kernel build robot compiles the UFS driver as a separate module. 
The existing configuration doesn't allow to add a new file to be compiled 
as a part of this module. The line like " obj-$(CONFIG_SCSI_UFSHCD) += 
ufshcd.o ufs-sysfs.o" in the makefile will actually create 2 modules.
This was the reason why I used EXPORT_SYMBOL in the first version.

> 
> >  obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
> >  obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o diff --git
> > a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c new file
> > mode 100644 index 000..1c685f3
> > --- /dev/null
> > +++ b/drivers/scsi/ufs/ufs-sysfs.c
> > @@ -0,0 +1,170 @@
> > +/*
> > +* UFS Device Management sysfs
> > +*
> > +* Copyright (C) 2017 Western Digital Corporation
> > +*
> > +* This program is free software; you can redistribute it and/or
> > +* modify it under the terms of the GNU General Public License version
> > +* 2 as published by the Free Software Foundation.
> > +*
> > +* This program is distributed in the hope that it will be useful, but
> > +* WITHOUT ANY WARRANTY; without even the implied warranty of
> > +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU
> > +* General Public License for more details.
> > +*
> > +*/
> > +
> > +#include 
> > +#include 
> > +
> > +#include "ufs.h"
> > +#include "ufs-sysfs.h"
> > +/* collision between the device descriptor parameter and the
> > +definition */ #undef DEVICE_CLASS
> 
> Does this make sense? How about attaching "_" for all the macro like
> _DEVICE_CLASS below?
> 

It's not just changing the one line that uses "DEVICE_CLASS" to use 
"_DEVICE_CLASS". It's will be necessary to add "_" to all descriptor
parameters macros in all patches.

> > +
> > +enum ufs_desc_param_size {
> > +   UFS_PARAM_BYTE_SIZE = 1,
> > +   UFS_PARAM_WORD_SIZE = 2,
> > +   UFS_PARAM_DWORD_SIZE= 4,
> > +   UFS_PARAM_QWORD_SIZE= 8,
> > +};
> > +
> > +static inline ssize_t ufs_sysfs_read_desc_param(
> > +   struct ufs_hba *hba, u8 desc_idn, u8 index, char *buf, u8 off,
> > +   enum ufs_desc_param_size param_size) {
> > +   int desc_len;
> > +   int ret;
> > +   u8 *desc_buf;
> > +
> > +   if (ufshcd_map_desc_id_to_length(hba, desc_idn, _len) ||
> > +   off >= desc_len)
> > +   return -EINVAL;
> > +   desc_buf = kzalloc(desc_len, GFP_ATOMIC);
> > +   if (!desc_buf)
> > +   return -ENOMEM;
> > +   ret = ufshcd_query_descriptor_retry(hba,
> UPIU_QUERY_OPCODE_READ_DESC,
> > +   desc_idn, index, 0, desc_buf, _len);
> > +   if (ret)
> 
> Should free desc_buf 

[PATCH 03/12] spi: sirf: account for const type of of_device_id.data

[Julia Lawall]

This driver creates various const structures that it stores in the
data field of an of_device_id array.

Adding const to the declaration of the location that receives the
const value from the data field ensures that the compiler will
continue to check that the value is not modified.  Furthermore, the
const-discarding cast on the extraction from the data field is no
longer needed.

Done using Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/spi/spi-sirf.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -u -p a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
--- a/drivers/spi/spi-sirf.c
+++ b/drivers/spi/spi-sirf.c
@@ -1072,7 +1072,7 @@ static int spi_sirfsoc_probe(struct plat
struct sirfsoc_spi *sspi;
struct spi_master *master;
struct resource *mem_res;
-   struct sirf_spi_comp_data *spi_comp_data;
+   const struct sirf_spi_comp_data *spi_comp_data;
int irq;
int ret;
const struct of_device_id *match;
@@ -1092,7 +1092,7 @@ static int spi_sirfsoc_probe(struct plat
platform_set_drvdata(pdev, master);
sspi = spi_master_get_devdata(master);
sspi->fifo_full_offset = ilog2(sspi->fifo_size);
-   spi_comp_data = (struct sirf_spi_comp_data *)match->data;
+   spi_comp_data = match->data;
sspi->regs = spi_comp_data->regs;
sspi->type = spi_comp_data->type;
sspi->fifo_level_chk_mask = (sspi->fifo_size / 4) - 1;

[PATCH 07/12] i2c: rk3x: account for const type of of_device_id.data

[Julia Lawall]

This driver creates a number of const structures that it stores in
the data field of an of_device_id array.

The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.

Furthermore, adding const to the declaration of the location that
receives a const value from such a field ensures that the compiler
will continue to check that the value is not modified.  The
const-discarding cast on the extraction from the data field is thus
no longer needed.

Done using Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/i2c/busses/i2c-rk3x.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff -u -p a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -194,7 +194,7 @@ struct rk3x_i2c_soc_data {
 struct rk3x_i2c {
struct i2c_adapter adap;
struct device *dev;
-   struct rk3x_i2c_soc_data *soc_data;
+   const struct rk3x_i2c_soc_data *soc_data;
 
/* Hardware resources */
void __iomem *regs;
@@ -1164,27 +1164,27 @@ static const struct rk3x_i2c_soc_data rk
 static const struct of_device_id rk3x_i2c_match[] = {
{
.compatible = "rockchip,rv1108-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{
.compatible = "rockchip,rk3066-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{
.compatible = "rockchip,rk3188-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{
.compatible = "rockchip,rk3228-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{
.compatible = "rockchip,rk3288-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{
.compatible = "rockchip,rk3399-i2c",
-   .data = (void *)_soc_data
+   .data = _soc_data
},
{},
 };
@@ -1207,7 +1207,7 @@ static int rk3x_i2c_probe(struct platfor
return -ENOMEM;
 
match = of_match_node(rk3x_i2c_match, np);
-   i2c->soc_data = (struct rk3x_i2c_soc_data *)match->data;
+   i2c->soc_data = match->data;
 
/* use common interface to get I2C timing properties */
i2c_parse_fw_timings(>dev, >t, true);

[PATCH 10/12] spi: spi-fsl-dspi: account for const type of of_device_id.data

[Julia Lawall]

This driver creates a number of const structures that it stores in the
data field of an of_device_id array.

The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.

Done using Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/spi/spi-fsl-dspi.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 02d3ed7..0630962 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -903,10 +903,9 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
 }
 
 static const struct of_device_id fsl_dspi_dt_ids[] = {
-   { .compatible = "fsl,vf610-dspi", .data = (void *)_data, },
-   { .compatible = "fsl,ls1021a-v1.0-dspi",
-   .data = (void *)_v1_data, },
-   { .compatible = "fsl,ls2085a-dspi", .data = (void *)_data, },
+   { .compatible = "fsl,vf610-dspi", .data = _data, },
+   { .compatible = "fsl,ls1021a-v1.0-dspi", .data = _v1_data, },
+   { .compatible = "fsl,ls2085a-dspi", .data = _data, },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);

[PATCH 06/12] power: supply: account for const type of of_device_id.data

[Julia Lawall]

This driver creates two const structures that it stores in the data
field of an of_device_id array.

The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.

Furthermore, adding const to the declaration of the location that
receives a const value from such a field ensures that the compiler
will continue to check that the value is not modified.  The
const-discarding cast on the extraction from the data field is thus
no longer needed.

Done using Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/power/supply/axp20x_ac_power.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff -u -p a/drivers/power/supply/axp20x_ac_power.c 
b/drivers/power/supply/axp20x_ac_power.c
--- a/drivers/power/supply/axp20x_ac_power.c
+++ b/drivers/power/supply/axp20x_ac_power.c
@@ -159,7 +159,7 @@ static int axp20x_ac_power_probe(struct
struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
struct power_supply_config psy_cfg = {};
struct axp20x_ac_power *power;
-   struct axp_data *axp_data;
+   const struct axp_data *axp_data;
static const char * const irq_names[] = { "ACIN_PLUGIN", "ACIN_REMOVAL",
NULL };
int i, irq, ret;
@@ -176,7 +176,7 @@ static int axp20x_ac_power_probe(struct
if (!power)
return -ENOMEM;
 
-   axp_data = (struct axp_data *)of_device_get_match_data(>dev);
+   axp_data = of_device_get_match_data(>dev);
 
if (axp_data->acin_adc) {
power->acin_v = devm_iio_channel_get(>dev, "acin_v");
@@ -230,10 +230,10 @@ static int axp20x_ac_power_probe(struct
 static const struct of_device_id axp20x_ac_power_match[] = {
{
.compatible = "x-powers,axp202-ac-power-supply",
-   .data = (void *)_data,
+   .data = _data,
}, {
.compatible = "x-powers,axp221-ac-power-supply",
-   .data = (void *)_data,
+   .data = _data,
}, { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, axp20x_ac_power_match);

[PATCH 08/12] pinctrl: axp209: account for const type of of_device_id.data

[Julia Lawall]

The return value of of_device_get_match_data has type const void *.
The desc field of the pctl structure also has a const type, so there
is no need for the const-discarding cast between them.

Done using Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/pinctrl/pinctrl-axp209.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/drivers/pinctrl/pinctrl-axp209.c b/drivers/pinctrl/pinctrl-axp209.c
--- a/drivers/pinctrl/pinctrl-axp209.c
+++ b/drivers/pinctrl/pinctrl-axp209.c
@@ -414,7 +414,7 @@ static int axp20x_pctl_probe(struct plat
pctl->chip.direction_input  = axp20x_gpio_input;
pctl->chip.direction_output = axp20x_gpio_output;
 
-   pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
+   pctl->desc = of_device_get_match_data(dev);
 
pctl->chip.ngpio= pctl->desc->npins;
 

[PATCH 00/12] account for const type of of_device_id.data

[Julia Lawall]

Maintain const annotations when putting values into the data field of
an of_device_id structure, and afterwards when extracting them from
the data field of such a structure.

This was done using the following semantic patch:
(http://coccinelle.lip6.fr/)

// 
@r@
identifier i,j;
const struct j *m;
struct i *y;
type T;
expression x,e;
position p;
@@

(
y =@p (T)(of_device_get_match_data(...));
|
x = of_match_node(...);
... when != x = e
(
m = e;
|
y =@p (T)(x->data);
)
)

@s@
identifier r.i,j;
@@

const struct i j = { ... };

@t depends on s disable optional_qualifier@
expression e;
identifier r.i,x,j,n;
struct j *m;
struct i *e1;
position any r.p;
type T;
@@

(
+const
struct i *x;
<+...
(
x =@p 
-   (T)(e)
+   e
|
x =@p e
)
...+>
|
m->@e1 n =@p 
-   (T)(e)
+   e
|
m->@e1 n =@p e
)

@disable optional_qualifier@
identifier t.j,t.n,r.i;
@@

struct j {
  ...
+ const
  struct i *n;
  ...
}

@@
identifier x,s.j;
type T;
@@

struct of_device_id x[] = { ...,
  { .data =
-   (T)
, }, ...};

// 

---

 drivers/i2c/busses/i2c-rk3x.c   |   16 
 drivers/iio/common/ssp_sensors/ssp.h|2 +-
 drivers/iio/common/ssp_sensors/ssp_dev.c|2 +-
 drivers/mtd/spi-nor/fsl-quadspi.c   |8 
 drivers/pci/dwc/pcie-qcom.c |4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c |4 ++--
 drivers/pinctrl/pinctrl-at91-pio4.c |4 ++--
 drivers/pinctrl/pinctrl-axp209.c|2 +-
 drivers/power/avs/rockchip-io-domain.c  |   24 
 drivers/power/reset/at91-sama5d2_shdwc.c|4 ++--
 drivers/power/supply/axp20x_ac_power.c  |8 
 drivers/spi/spi-fsl-dspi.c  |7 +++
 drivers/spi/spi-sirf.c  |4 ++--
 13 files changed, 44 insertions(+), 44 deletions(-)

Re: Rename the SmPL script “kzalloc-….cocci”?

[SF Markus Elfring]

Hello,

A script for the semantic patch language was extended in significant ways.

[PATCH v2] Coccinelle: kzalloc-simple: Add “all” zero allocating functions
https://lkml.org/lkml/2017/12/26/182
https://patchwork.kernel.org/patch/10133277/
https://lkml.kernel.org/r/<1514324410-14561-1-git-send-email-himanshujha199...@gmail.com>
https://systeme.lip6.fr/pipermail/cocci/2017-December/004783.html

Now I find that it became more advanced than the previous version.
How do you think about to update also the corresponding file name
(instead of keeping the word “simple” there)?

Regards,
Markus

Re: [PATCH 4/5] Expand the INIT_SIGNALS and INIT_SIGHAND macros and remove

[David Howells]

Thomas Gleixner  wrote:

> >  #define INIT_CPU_TIMERS(s) \
> ...
> That macro is only used in init_task.c Why not moving it there and get rid
> of the whole macro maze in the header file?

The reason I didn't get rid of it is that it's got more than one expansion
point.  Same for INIT_PREV_CPUTIME and INIT_PID_LINK.

How about the attached patch?  Or do you think it's going a bit too far?

Possibly I could just move some of the #defines from the .h file to the .c
file, but otherwise leave them unexpanded.

David
---
commit ce4d0010bfc3b83f88322afa3cd9013b9c341c4d
Author: David Howells 
Date:   Tue Jan 2 14:20:17 2018 +

Expand some multi-use INIT_ macros and remove

Expand INIT_CPU_TIMERS, INIT_PREV_CPUTIME and INIT_PID_LINK in place and
remove the definitions.

I'm not entirely sure we want to do this since each of these macros has
multiple points of expansion - and not necessarily in the same structure in
each case.

Suggested-by: Thomas Gleixner 
Signed-off-by: David Howells 

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index a454b8aeb938..f4d002b329cc 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -27,34 +27,6 @@ extern struct nsproxy init_nsproxy;
 extern struct group_info init_groups;
 extern struct cred init_cred;
 
-#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
-#define INIT_PREV_CPUTIME(x)   .prev_cputime = {   \
-   .lock = __RAW_SPIN_LOCK_UNLOCKED(x.prev_cputime.lock),  \
-},
-#else
-#define INIT_PREV_CPUTIME(x)
-#endif
-
-#ifdef CONFIG_POSIX_TIMERS
-#define INIT_CPU_TIMERS(s) \
-   .cpu_timers = { \
-   LIST_HEAD_INIT(s.cpu_timers[0]),\
-   LIST_HEAD_INIT(s.cpu_timers[1]),\
-   LIST_HEAD_INIT(s.cpu_timers[2]),\
-   },
-#else
-#define INIT_CPU_TIMERS(s)
-#endif
-
-#define INIT_PID_LINK(type)\
-{  \
-   .node = {   \
-   .next = NULL,   \
-   .pprev = NULL,  \
-   },  \
-   .pid = _struct_pid,\
-}
-
 #define INIT_TASK_COMM "swapper"
 
 /* Attach to the init_task data structure for proper alignment */
diff --git a/init/init_task.c b/init/init_task.c
index 3ac6e754cf64..136d9896acdb 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -30,9 +30,15 @@ static struct signal_struct init_signals = {
.running= false,
.checking_timer = false,
},
+   .cpu_timers = {
+   LIST_HEAD_INIT(init_signals.cpu_timers[0]),
+   LIST_HEAD_INIT(init_signals.cpu_timers[1]),
+   LIST_HEAD_INIT(init_signals.cpu_timers[2]),
+   },
+#endif
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+   .prev_cputime.lock = 
__RAW_SPIN_LOCK_UNLOCKED(init_signals.prev_cputime.lock),
 #endif
-   INIT_CPU_TIMERS(init_signals)
-   INIT_PREV_CPUTIME(init_signals)
 };
 
 static struct sighand_struct init_sighand = {
@@ -107,13 +113,19 @@ struct task_struct init_task
.blocked= {{0}},
.alloc_lock = __SPIN_LOCK_UNLOCKED(init_task.alloc_lock),
.journal_info   = NULL,
-   INIT_CPU_TIMERS(init_task)
+#ifdef CONFIG_POSIX_TIMERS
+   .cpu_timers = {
+   LIST_HEAD_INIT(init_task.cpu_timers[0]),
+   LIST_HEAD_INIT(init_task.cpu_timers[1]),
+   LIST_HEAD_INIT(init_task.cpu_timers[2]),
+   },
+#endif
.pi_lock= __RAW_SPIN_LOCK_UNLOCKED(init_task.pi_lock),
.timer_slack_ns = 5, /* 50 usec default slack */
.pids = {
-   [PIDTYPE_PID]  = INIT_PID_LINK(PIDTYPE_PID),
-   [PIDTYPE_PGID] = INIT_PID_LINK(PIDTYPE_PGID),
-   [PIDTYPE_SID]  = INIT_PID_LINK(PIDTYPE_SID),
+   [PIDTYPE_PID ].pid = _struct_pid,
+   [PIDTYPE_PGID].pid = _struct_pid,
+   [PIDTYPE_SID ].pid = _struct_pid,
},
.thread_group   = LIST_HEAD_INIT(init_task.thread_group),
.thread_node= LIST_HEAD_INIT(init_signals.thread_head),
@@ -143,7 +155,9 @@ struct task_struct init_task
.pi_waiters = RB_ROOT_CACHED,
.pi_top_task= NULL,
 #endif
-   INIT_PREV_CPUTIME(init_task)
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+   .prev_cputime.lock = 
__RAW_SPIN_LOCK_UNLOCKED(init_task.prev_cputime.lock),
+#endif
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
.vtime.seqcount = 

[PATCH v5 17/20] hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration

[Sudeep Holla]

It's useful to know the maximum types of sensor supported by hwmon
framework. It can be used to allocate some data structures when sorting
the monitors based on their type.

This will be used by scmi hwmon support.

Cc: linux-hw...@vger.kernel.org
Acked-by: Guenter Roeck 
Signed-off-by: Sudeep Holla 
---
 include/linux/hwmon.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index ceb751987c40..e5fd2707b6df 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -29,6 +29,7 @@ enum hwmon_sensor_types {
hwmon_humidity,
hwmon_fan,
hwmon_pwm,
+   hwmon_max,
 };
 
 enum hwmon_chip_attributes {
-- 
2.7.4

[PATCH v5 19/20] cpufreq: add support for CPU DVFS based on SCMI message protocol

[Sudeep Holla]

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control including CPU DVFS. SCMI Message Protocol is used to
communicate with the SCP.

This patch adds a cpufreq driver for such systems using SCMI interface
to drive CPU DVFS.

Cc: linux...@vger.kernel.org
Acked-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Signed-off-by: Sudeep Holla 
---
 MAINTAINERS|   2 +-
 drivers/cpufreq/Kconfig.arm|  11 ++
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/scmi-cpufreq.c | 270 +
 4 files changed, 283 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/scmi-cpufreq.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d961de6aa0fd..d885824346a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13155,7 +13155,7 @@ L:  linux-arm-ker...@lists.infradead.org
 S: Maintained
 F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
 F: drivers/clk/clk-sc[mp]i.c
-F: drivers/cpufreq/scpi-cpufreq.c
+F: drivers/cpufreq/sc[mp]i-cpufreq.c
 F: drivers/firmware/arm_scpi.c
 F: drivers/firmware/arm_scmi/
 F: include/linux/sc[mp]i_protocol.h
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index bdce4488ded1..e21f84cbd9b4 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -205,6 +205,17 @@ config ARM_SA1100_CPUFREQ
 config ARM_SA1110_CPUFREQ
bool
 
+config ARM_SCMI_CPUFREQ
+   tristate "SCMI based CPUfreq driver"
+   depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
+   select PM_OPP
+   help
+ This adds the CPUfreq driver support for ARM platforms using SCMI
+ protocol for CPU power management.
+
+ This driver uses SCMI Message Protocol driver to interact with the
+ firmware providing the CPU DVFS functionality.
+
 config ARM_SCPI_CPUFREQ
 tristate "SCPI based CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && 
COMMON_CLK_SCPI
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 812f9e0d01a3..21ed72b78c84 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o
 obj-$(CONFIG_ARM_S5PV210_CPUFREQ)  += s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SA1100_CPUFREQ)   += sa1100-cpufreq.o
 obj-$(CONFIG_ARM_SA1110_CPUFREQ)   += sa1110-cpufreq.o
+obj-$(CONFIG_ARM_SCMI_CPUFREQ) += scmi-cpufreq.o
 obj-$(CONFIG_ARM_SCPI_CPUFREQ) += scpi-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
 obj-$(CONFIG_ARM_STI_CPUFREQ)  += sti-cpufreq.o
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
new file mode 100644
index ..0ee9335d0063
--- /dev/null
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -0,0 +1,270 @@
+/*
+ * System Control and Power Interface (SCMI) based CPUFreq Interface driver
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ * Sudeep Holla 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct scmi_data {
+   int domain_id;
+   struct device *cpu_dev;
+   struct thermal_cooling_device *cdev;
+};
+
+static const struct scmi_handle *handle;
+
+static unsigned int scmi_cpufreq_get_rate(unsigned int cpu)
+{
+   struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+   struct scmi_perf_ops *perf_ops = handle->perf_ops;
+   struct scmi_data *priv = policy->driver_data;
+   unsigned long rate;
+   int ret;
+
+   ret = perf_ops->freq_get(handle, priv->domain_id, , false);
+   if (ret)
+   return 0;
+   return rate / 1000;
+}
+
+/*
+ * perf_ops->freq_set is not a synchronous, the actual OPP change will
+ * happen asynchronously and can get notified if the events are
+ * subscribed for by the SCMI firmware
+ */
+static int
+scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
+{
+   struct scmi_data *priv = policy->driver_data;
+   struct scmi_perf_ops *perf_ops = handle->perf_ops;
+   u64 freq = policy->freq_table[index].frequency * 1000;
+
+   return perf_ops->freq_set(handle, priv->domain_id, freq, false);
+}
+
+static int
+scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask 

[PATCH v5 20/20] cpufreq: scmi: add support for fast frequency switching

[Sudeep Holla]

The cpufreq core provides option for drivers to implement fast_switch
callback which is invoked for frequency switching from interrupt context.

This patch adds support for fast_switch callback in SCMI cpufreq driver
by making use of polling based SCMI transfer. It also sets the flag
fast_switch_possible.

Cc: linux...@vger.kernel.org
Acked-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Signed-off-by: Sudeep Holla 
---
 drivers/cpufreq/scmi-cpufreq.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 0ee9335d0063..d0a82d7c6fd4 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, 
unsigned int index)
return perf_ops->freq_set(handle, priv->domain_id, freq, false);
 }
 
+static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
+unsigned int target_freq)
+{
+   struct scmi_data *priv = policy->driver_data;
+   struct scmi_perf_ops *perf_ops = handle->perf_ops;
+
+   if (!perf_ops->freq_set(handle, priv->domain_id,
+   target_freq * 1000, true))
+   return target_freq;
+
+   return 0;
+}
+
 static int
 scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
 {
@@ -163,6 +176,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
 
policy->cpuinfo.transition_latency = latency;
 
+   policy->fast_switch_possible = true;
return 0;
 
 out_free_cpufreq_table:
@@ -222,6 +236,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
.verify = cpufreq_generic_frequency_table_verify,
.attr   = cpufreq_generic_attr,
.target_index   = scmi_cpufreq_set_target,
+   .fast_switch= scmi_cpufreq_fast_switch,
.get= scmi_cpufreq_get_rate,
.init   = scmi_cpufreq_init,
.exit   = scmi_cpufreq_exit,
-- 
2.7.4

Re: [lkp-robot] [tpm] b008bd39b1: kmsg.tpm_tpm#:A_TPM_error(#)occurred_attempting_get_random

[Jarkko Sakkinen]

On Wed, Dec 27, 2017 at 01:11:14PM -0700, Jason Gunthorpe wrote:
> On Wed, Dec 27, 2017 at 10:55:32AM +0800, kernel test robot wrote:
> 
> > caused below changes (please refer to attached dmesg/kmsg for entire 
> > log/backtrace):
> > 
> > [5.903660] tpm_tis 00:05: 1.2 TPM (device-id 0xFE, rev-id 70)
> > [5.934271] tpm tpm0: A TPM error (7) occurred attempting to read a pcr 
> > value
> > [5.941471] tpm tpm0: TPM is disabled/deactivated (0x7)
> > [5.953053] tpm tpm0: A TPM error (7) occurred attempting get random
> 
> Should the BIOS expose a disabled/deactivated TPM to the operating
> system?
> 
> Jason

Nope.

/Jarkko

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

[Chris Wilson]

Quoting Christian König (2018-01-02 12:13:58)
> TTM tries to allocate coherent memory in chunks of 2MB first to improve
> TLB efficiency and falls back to allocating 4K pages if that fails.
> 
> Suppress the warning when the 2MB allocations fails since there is a
> valid fall back path.
> 
> v2: suppress warnings from swiotlb_tbl_map_single as well
> 
> Signed-off-by: Christian König 
> Reported-by: Mike Galbraith 
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
> CC: sta...@vger.kernel.org
> ---
> @@ -989,7 +1002,8 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct 
> scatterlist *sgl, int nelems,
> if (swiotlb_force == SWIOTLB_FORCE ||
> !dma_capable(hwdev, dev_addr, sg->length)) {
> phys_addr_t map = map_single(hwdev, sg_phys(sg),
> -sg->length, dir, attrs);
> +sg->length, dir, attrs,
> +true);

This keeps the warning for dma_map_sg(), so seems quite ineffective.

> if (map == SWIOTLB_MAP_ERROR) {
> /* Don't panic here, we expect map_sg users
>to do proper error handling. */

And counter to the suggestion here?
-Chris

Re: [PATCH v3] backlight: tdo24m: fix the spi cs between transfers

[Lee Jones]

On Thu, 28 Dec 2017, Robert Jarzmik wrote:

> Currently the LCD display (TD035S) on the cm-x300 platform is broken and
> remains blank.
> 
> The TD0245S specification requires that the chipselect is toggled
> between commands sent to the panel. This was also the purpose of the
> former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip
> select changes between transfers").
> 
> Unfortunately, the "cs_change" field of a SPI transfer is
> misleading. Its true meaning is that for a SPI message holding multiple
> transfers, the chip select is toggled between each transfer, but for the
> last transfer it remains asserted.
> 
> In this driver, all the SPI messages contain exactly one transfer, which
> means that each transfer is the last of its message, and as a
> consequence the chip select is never toggled.
> 
> Actually, there was a second bug hidding the first one, hence the
> problem was not seen until v4.6. This problem was fixed by commit
> a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based
> boards.
> 
> This fix makes the TD035S work again on a cm-x300 board. The same
> applies to other PXA boards, ie. corgi and tosa.
> 
> Fixes: a52db659c79c ("spi: pxa2xx: Fix cs_change management")

Since this fixes an old kernel, I'm not going to apply it for -fixes.

> Reported-by: Andrea Adami 
> Signed-off-by: Robert Jarzmik 
> Acked-by: Daniel Thompson 
> ---
> Since v1: added 2 other panels
> Since v2: added Daniel's ack
> ---
>  drivers/video/backlight/corgi_lcd.c | 2 +-
>  drivers/video/backlight/tdo24m.c| 2 +-
>  drivers/video/backlight/tosa_lcd.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Applied to -next, thanks.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 1/2] dt-bindings: Document mti,mips-cpc binding

[Rob Herring]

On Wed, Dec 27, 2017 at 03:37:51PM +0100, Aleksandar Markovic wrote:
> From: Paul Burton 
> 
> Document a binding for the MIPS Cluster Power Controller (CPC) that
> allows the device tree to specify where the CPC registers are located.
> 
> Signed-off-by: Paul Burton 
> Signed-off-by: Aleksandar Markovic 
> ---
>  Documentation/devicetree/bindings/power/mti,mips-cpc.txt | 8 
>  1 file changed, 8 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.txt

Reviewed-by: Rob Herring 

[PATCH v2] MIPS: Loongson64: Drop 32-bit support for Loongson 2E/2F devices

[Jiaxun Yang]

The 32-bit support was broken at runtime, it doesn't boot anymore,
witch is hard to debug because even early printk isn't working, also
there are some build warnings. Some newer bootloader may not support
32-bit ELF. So we decide to drop 32-bit support.

Make loongson64 a pure 64-bit arch.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/loongson64/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/loongson64/Kconfig b/arch/mips/loongson64/Kconfig
index 0d249fc3cfe9..a7d9a9241ac4 100644
--- a/arch/mips/loongson64/Kconfig
+++ b/arch/mips/loongson64/Kconfig
@@ -17,7 +17,6 @@ config LEMOTE_FULOONG2E
select I8259
select ISA
select IRQ_MIPS_CPU
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HIGHMEM
@@ -49,7 +48,6 @@ config LEMOTE_MACH2F
select ISA
select SYS_HAS_CPU_LOONGSON2F
select SYS_HAS_EARLY_PRINTK
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
-- 
2.15.1

Re: [PATCH V2 3/7] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()

[Sinan Kaya]

On 12/13/2017 5:43 PM, Bjorn Helgaas wrote:
>> +
>> +/*
>> + * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
> I think this should reference the "Advanced Capabilities for
> Conventional PCI" ECN, shouldn't it?  The one I see is dated 13 April
> 2006, updated 27 July 2006, and I don't see a PCI spec that includes
> it.

I'll add reference to PCI spec as well. Any other comments on the series?

> 
>> + * 100ms, but may silently discard requests while the FLR is in
>> + * progress.  Wait 100ms before trying to access the device.
>> + */
>> +msleep(100);
>> +
>> +return pci_dev_wait(dev, "AF_FLR", PCIE_RESET_READY_POLL_MS);
> CRS is not applicable to conventional PCI.  The ECN mentions waiting
> 100ms.  I don't see anything about polling after that, but I guess it
> probably doesn't hurt anything.

ok, I'll keep it as it is.

> 
>>  }


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH 1/3] dt-bindings: mfd: axp20x: Document backup battery charging property

[Lee Jones]

On Sat, 30 Dec 2017, Paul Kocialkowski wrote:

> This adds documentation for the "backup" property of the axp20x driver,
> that controls the charging mechanism for the backup battery on axp20x.
> 
> Signed-off-by: Paul Kocialkowski 
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 9455503b0299..382776b29932 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -58,6 +58,11 @@ Optional properties:
> See Documentation/devicetree/bindings/regulator/regulator.txt
> for more information on standard regulator bindings.
>  
> +- backup: An array of two integers for backup battery charging (axp20x-only),
> +   describing the charging voltage in mV first and the charging current
> +   in uA second. Backup battery charging is only enabled when these two
> +   fields are filled.
> +
>  Optional properties for DCDC regulators:
>  - x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
> Default: Current hardware setting
> @@ -256,4 +261,6 @@ axp209: pmic@34 {
>   /* unused but preferred to be managed by OS */
>   };
>   };
> +
> + backup = <3000 200>;

It's unlikely that this will become a generic property, so you should
prefix it with your vendor ID.

>  };

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] Nokia N9: add support for up/down keys in the dts

[Pavel Machek]

This adds support for volume up/down keys in the dts.

Signed-off-by: Pavel Machek 

diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 39e35f8..57a6679 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -11,9 +11,10 @@
 /dts-v1/;
 
 #include "omap3-n950-n9.dtsi"
+#include 
 
 / {
model = "Nokia N9";
compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
 };
 
@@ -72,3 +133,9 @@
st,max-limit-y = <46>;
st,max-limit-z = <46>;
 };
+
+_keypad {
+   linux,keymap = < MATRIX_KEY(6, 8, KEY_VOLUMEUP)
+MATRIX_KEY(7, 8, KEY_VOLUMEDOWN)
+>;
+};


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 10/22] mmc: tmio: support IP-builtin card detection logic

[Wolfram Sang]

On Sat, Nov 25, 2017 at 01:24:45AM +0900, Masahiro Yamada wrote:
> A card detect GPIO is set up only for platforms with "cd-gpios"
> DT property or TMIO_MMC_USE_GPIO_CD flag.  However, the driver
> core always uses mmc_gpio_get_cd, which just fails with -ENOSYS
> if ctx->cd_gpio is unset.
> 
> The bit 5 of the status register provides the current signal level
> of the CD line.  Allow to use it if the GPIO is unused.
> 
> Signed-off-by: Masahiro Yamada 

As mentioned before (sorry, I lost this thread :( ), I like the
refactoring to select in probe() which function to call depending on
GPIO usage or not. If you like, we can do the same for read_only, too.

Thanks!



signature.asc
Description: PGP signature

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

[Matthew Wilcox]

On Sun, Dec 24, 2017 at 03:42:02PM +0800, Wei Wang wrote:
> On 12/24/2017 12:45 PM, Tetsuo Handa wrote:
> > Matthew Wilcox wrote:
> > > If you can't preload with anything better than that, I think that
> > > xb_set_bit() should attempt an allocation with GFP_NOWAIT | __GFP_NOWARN,
> > > and then you can skip the preload; it has no value for you.
> > Yes, that's why I suggest directly using kzalloc() at xb_set_bit().
> 
> It has some possibilities to remove that preload if we also do the bitmap
> allocation in the xb_set_bit():
> 
> bitmap = rcu_dereference_raw(*slot);
> if (!bitmap) {
> bitmap = this_cpu_xchg(ida_bitmap, NULL);
> if (!bitmap) {
> bitmap = kmalloc(sizeof(*bitmap), gfp);
> if (!bitmap)
> return -ENOMEM;
> }
> }
> 
> But why not just follow the radix tree implementation style that puts the
> allocation in preload, which would be invoked with a more relaxed gfp in
> other use cases?

Actually, the radix tree does attempt allocation, and falls back to the
preload.  The IDA was the odd one out that doesn't attempt allocation,
and that was where I copied the code from.  For other users, the preload
API is beneficial, so I will leave it in.

> Its usage in virtio_balloon is just a little special that we need to put the
> allocation within the balloon_lock, which doesn't give us the benefit of
> using a relaxed gfp in preload, but it doesn't prevent us from living with
> the current APIs (i.e. the preload + xb_set pattern).
> On the other side, if we do it as above, we have more things that need to
> consider. For example, what if the a use case just want the radix tree
> implementation style, which means it doesn't want allocation within
> xb_set(), then would we be troubled with how to avoid the allocation path in
> that case?
> 
> So, I think it is better to stick with the convention by putting the
> allocation in preload. Breaking the convention should show obvious
> advantages, IMHO.

The radix tree convention is objectively awful, which is why I'm working
to change it.  Specifying the GFP flags at radix tree initialisation time
rather than allocation time leads to all kinds of confusion.  The preload
API is a pretty awful workaround, and it will go away once the XArray
is working correctly.  That said, there's no alternative to it without
making XBitmap depend on XArray, and I don't want to hold you up there.
So there's an xb_preload for the moment.

[PATCH v3] drm/ttm: check the return value of kzalloc

[Xiongwei Song]

In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.

Signed-off-by: Xiongwei Song 
---
v2->v3: delete goto expression
v1->v2: delete kfree _manager
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..5d252fb27a82 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
pr_info("Initializing pool allocator\n");
 
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+   if (!_manager)
+   return -ENOMEM;
 
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
 
-- 
2.15.1

[PATCH] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II

[Paul Cercueil]

Add touchscreen platform data for the Teclast X98 Plus II tablet.

Signed-off-by: Paul Cercueil 
---
 drivers/platform/x86/silead_dmi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/platform/x86/silead_dmi.c 
b/drivers/platform/x86/silead_dmi.c
index 266535c2a72f..ebe8692a2868 100644
--- a/drivers/platform/x86/silead_dmi.c
+++ b/drivers/platform/x86/silead_dmi.c
@@ -171,6 +171,22 @@ static const struct silead_ts_dmi_data 
digma_citi_e200_data = {
.properties = digma_citi_e200_props,
 };
 
+static const struct property_entry teclast_x98plus2_props[] = {
+   PROPERTY_ENTRY_U32("touchscreen-size-x", 2048),
+   PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
+   PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
+   PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+   PROPERTY_ENTRY_STRING("firmware-name",
+ "gsl1686-teclast_x98plus2.fw"),
+   PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+   { }
+};
+
+static const struct silead_ts_dmi_data teclast_x98plus2_data = {
+   .acpi_name  = "MSSL1680:00",
+   .properties = teclast_x98plus2_props,
+};
+
 static const struct dmi_system_id silead_ts_dmi_table[] = {
{
/* CUBE iwork8 Air */
@@ -271,6 +287,14 @@ static const struct dmi_system_id silead_ts_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
},
},
+   {
+   /* Teclast X98 Plus II */
+   .driver_data = (void *)_x98plus2_data,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X98 Plus II"),
+   },
+   },
{ },
 };
 
-- 
2.11.0

Re: [PATCH 04/12] ext2: drop unneeded newline

[Jan Kara]

On Wed 27-12-17 23:30:42, Ted Tso wrote:
> On Wed, Dec 27, 2017 at 03:51:37PM +0100, Julia Lawall wrote:
> > ext2_msg prints a newline at the end of the message string, so the message
> > string does not need to include a newline explicitly.  Done using
> > Coccinelle.
> > 
> > Signed-off-by: Julia Lawall 
> 
> Reviewed-by: Theodore Ts'o 

Thanks. I've picked up the patch to my tree.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] PM / wakeup: Drop redundant check from device_init_wakeup()

[Ulf Hansson]

On 2 January 2018 at 01:42, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> Since device_wakeup_disable() checks the device's power.can_wakeup
> flag, device_init_wakeup() doesn't need to do that before calling it,
> so drop that redundant check from device_init_wakeup().
>
> No intentional changes in functionality.
>
> Signed-off-by: Rafael J. Wysocki 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/base/power/wakeup.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> Index: linux-pm/drivers/base/power/wakeup.c
> ===
> --- linux-pm.orig/drivers/base/power/wakeup.c
> +++ linux-pm/drivers/base/power/wakeup.c
> @@ -448,9 +448,7 @@ int device_init_wakeup(struct device *de
> device_set_wakeup_capable(dev, true);
> ret = device_wakeup_enable(dev);
> } else {
> -   if (dev->power.can_wakeup)
> -   device_wakeup_disable(dev);
> -
> +   device_wakeup_disable(dev);
> device_set_wakeup_capable(dev, false);
> }
>
>

Re: [PATCH] PM / wakeup: Drop redundant check from device_set_wakeup_enable()

[Ulf Hansson]

On 26 December 2017 at 01:50, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> Since both device_wakeup_enable() and device_wakeup_disable() check
> if dev is not NULL and whether or not power.can_wakeup is set for it,
> device_set_wakeup_enable() doesn't have to do that, so drop that
> check from it.
>
> No intentional changes in functionality.
>
> Signed-off-by: Rafael J. Wysocki 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/base/power/wakeup.c |3 ---
>  1 file changed, 3 deletions(-)
>
> Index: linux-pm/drivers/base/power/wakeup.c
> ===
> --- linux-pm.orig/drivers/base/power/wakeup.c
> +++ linux-pm/drivers/base/power/wakeup.c
> @@ -464,9 +464,6 @@ EXPORT_SYMBOL_GPL(device_init_wakeup);
>   */
>  int device_set_wakeup_enable(struct device *dev, bool enable)
>  {
> -   if (!dev || !dev->power.can_wakeup)
> -   return -EINVAL;
> -
> return enable ? device_wakeup_enable(dev) : 
> device_wakeup_disable(dev);
>  }
>  EXPORT_SYMBOL_GPL(device_set_wakeup_enable);
>

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

[Geert Uytterhoeven]

On Tue, Jan 2, 2018 at 1:53 PM, Ulf Hansson  wrote:
> On 2 January 2018 at 11:48, Rafael J. Wysocki  wrote:
>> On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven
>>  wrote:
>>> On Tue, Jan 2, 2018 at 11:32 AM, Rafael J. Wysocki  
>>> wrote:
 On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson  
 wrote:
> --- a/drivers/gpio/gpio-rcar.c
> +++ b/drivers/gpio/gpio-rcar.c
>>>
> @@ -415,6 +402,18 @@ static int gpio_rcar_parse_dt(struct gpio_rcar_priv 
> *p, unsigned int *npins)
> return 0;
>  }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_rcar_suspend(struct device *dev)
> +{
> +   struct gpio_rcar_priv *p = dev_get_drvdata(dev);
> +
> +   dev_pm_set_driver_flags(dev, p->wakeup_path ? 
> DPM_FLAG_WAKEUP_PATH : 0);

 Why don't you simply set dev->power.wakeup_path here?
>>>
>>> That's what my v1 did (https://patchwork.kernel.org/patch/10050995/).
>>
>> I very much prefer this one. :-)
>
> Okay!

>> What's wrong with it?
>
> It works, although I would rather change the assignment of the flag to
> respect if the current value is true, something like this:
>
> dev->power.wakeup_path = dev->power.wakeup_path || p->wakeup_path;

dev->power.wakeup_path |= p->wakeup_path?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Thursday, 28 December 2017 16:01:16 EET Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi
> b/arch/arm/boot/dts/r7s72100.dtsi index ab9645a..b09b032 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -135,9 +135,9 @@
>   #clock-cells = <1>;
>   compatible = "renesas,r7s72100-mstp-clocks", 
> "renesas,cpg-mstp-
clocks";
>   reg = <0xfcfe042c 4>;
> - clocks = <_clk>;
> - clock-indices = ;
> - clock-output-names = "rtc";
> + clocks = <_clk>, <_clk>;
> + clock-indices = ;
> + clock-output-names = "ceu", "rtc";
>   };
> 
>   mstp7_clks: mstp7_clks@fcfe0430 {
> @@ -667,4 +667,13 @@
>   power-domains = <_clocks>;
>   status = "disabled";
>   };
> +
> + ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;

With the reg issue pointed out by Geert fixed,

Reviewed-by: Laurent Pinchart 

> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> + clocks = <_clks R7S72100_CLK_CEU>;
> + power-domains = <_clocks>;
> + status = "disabled";
> + };
>  };

-- 
Regards,

Laurent Pinchart

[PATCH] USB: usbip: remove useless call in usbip_recv

[Gustavo A. R. Silva]

Calling msg_data_left() is only useful for its return value,
which in this particular case is ignored.

Fix this by removing such call.

Addresses-Coverity-ID: 1427080
Fixes: 90120d15f4c3 ("usbip: prevent leaking socket pointer address in 
messages")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/usbip/usbip_common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index 7b219d9..b5af6fc 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -325,7 +325,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
usbip_dbg_xmit("enter\n");
 
do {
-   msg_data_left();
sock->sk->sk_allocation = GFP_NOIO;
 
result = sock_recvmsg(sock, , MSG_WAITALL);
-- 
2.7.4

Re: [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Boris Ostrovsky]

On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
> The header declares this function as __init but is defined in __ref
> section.
>
> Signed-off-by: Nick Desaulniers 

AFAIK section attributes in header files are ignored by compiler anyway
so I'd remove all of them.

-boris


> ---
>  arch/x86/xen/xen-ops.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 75011b8..3b34745 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -72,7 +72,7 @@ u64 xen_clocksource_read(void);
>  void xen_setup_cpu_clockevents(void);
>  void xen_save_time_memory_area(void);
>  void xen_restore_time_memory_area(void);
> -void __init xen_init_time_ops(void);
> +void __ref xen_init_time_ops(void);
>  void __init xen_hvm_init_time_ops(void);
>  
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id);

Re: [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Juergen Gross]

On 02/01/18 15:18, Boris Ostrovsky wrote:
> On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
>> The header declares this function as __init but is defined in __ref
>> section.
>>
>> Signed-off-by: Nick Desaulniers 
> 
> AFAIK section attributes in header files are ignored by compiler anyway
> so I'd remove all of them.

Hmm, I'm not sure all future compilers will ignore the section
attributes. include/linux/init.h explictily mentions where to put
the attrubute in a prototype, so I'd rather keep it.


Juergen

Re: [PATCH v3] drm/ttm: check the return value of kzalloc

[Christian König]

Am 02.01.2018 um 14:24 schrieb Xiongwei Song:

In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.

Signed-off-by: Xiongwei Song 


Reviewed-by: Christian König 

Going to pick that up for the next release.

Thanks,
Christian.


---
v2->v3: delete goto expression
v1->v2: delete kfree _manager
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..5d252fb27a82 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
pr_info("Initializing pool allocator\n");
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);

+   if (!_manager)
+   return -ENOMEM;
  
  	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  

[PATCH][crypto-next] crypto: inside-secure - make function safexcel_try_push_requests static

[Colin King]

From: Colin Ian King 

The function safexcel_try_push_requests  is local to the source and does
not need to be in global scope, so make it static.

Cleans up sparse warning:
symbol 'safexcel_try_push_requests' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/crypto/inside-secure/safexcel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/inside-secure/safexcel.c 
b/drivers/crypto/inside-secure/safexcel.c
index 0d685be75241..e3745139644b 100644
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -432,8 +432,8 @@ static int safexcel_hw_init(struct safexcel_crypto_priv 
*priv)
 }
 
 /* Called with ring's lock taken */
-int safexcel_try_push_requests(struct safexcel_crypto_priv *priv, int ring,
-  int reqs)
+static int safexcel_try_push_requests(struct safexcel_crypto_priv *priv,
+int ring, int reqs)
 {
int coal = min_t(int, reqs, EIP197_MAX_BATCH_SZ);
 
-- 
2.14.1

[PATCH v5 16/20] clk: add support for clocks provided by SCMI

[Sudeep Holla]

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Management Interface(SCMI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.

This patch adds support for the clocks provided by SCP using SCMI
protocol.

Cc: linux-...@vger.kernel.org
Cc: Michael Turquette 
Acked-by: Stephen Boyd 
Signed-off-by: Sudeep Holla 
---
 MAINTAINERS|   2 +-
 drivers/clk/Kconfig|  10 +++
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-scmi.c | 213 +
 4 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/clk-scmi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e7526be3a05b..d961de6aa0fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13154,7 +13154,7 @@ M:  Sudeep Holla 
 L: linux-arm-ker...@lists.infradead.org
 S: Maintained
 F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
-F: drivers/clk/clk-scpi.c
+F: drivers/clk/clk-sc[mp]i.c
 F: drivers/cpufreq/scpi-cpufreq.c
 F: drivers/firmware/arm_scpi.c
 F: drivers/firmware/arm_scmi/
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 1c4e1aa6767e..57c66b22eab8 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -62,6 +62,16 @@ config COMMON_CLK_HI655X
  multi-function device has one fixed-rate oscillator, clocked
  at 32KHz.
 
+config COMMON_CLK_SCMI
+   tristate "Clock driver controlled via SCMI interface"
+   depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
+ ---help---
+ This driver provides support for clocks that are controlled
+ by firmware that implements the SCMI interface.
+
+ This driver uses SCMI Message Protocol to interact with the
+ firmware providing all the clock controls.
+
 config COMMON_CLK_SCPI
tristate "Clock driver controlled via SCPI interface"
depends on ARM_SCPI_PROTOCOL || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f7f761b02bed..da622c01526c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_CLK_QORIQ)   += clk-qoriq.o
 obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
 obj-$(CONFIG_COMMON_CLK_HI655X)+= clk-hi655x.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11)   += clk-s2mps11.o
+obj-$(CONFIG_COMMON_CLK_SCMI)   += clk-scmi.o
 obj-$(CONFIG_COMMON_CLK_SCPI)   += clk-scpi.o
 obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
 obj-$(CONFIG_COMMON_CLK_SI514) += clk-si514.o
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
new file mode 100644
index ..1e4d7a57779b
--- /dev/null
+++ b/drivers/clk/clk-scmi.c
@@ -0,0 +1,213 @@
+/*
+ * System Control and Power Interface (SCMI) Protocol based clock driver
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct scmi_clk {
+   u32 id;
+   struct clk_hw hw;
+   const struct scmi_clock_info *info;
+   const struct scmi_handle *handle;
+};
+
+#define to_scmi_clk(clk) container_of(clk, struct scmi_clk, hw)
+
+static unsigned long scmi_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   int ret;
+   u64 rate;
+   struct scmi_clk *clk = to_scmi_clk(hw);
+
+   ret = clk->handle->clk_ops->rate_get(clk->handle, clk->id, );
+   if (ret)
+   return 0;
+   return rate;
+}
+
+static long scmi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *parent_rate)
+{
+   int step;
+   u64 fmin, fmax, ftmp;
+   struct scmi_clk *clk = to_scmi_clk(hw);
+
+   /*
+* We can't figure out what rate it will be, so just return the
+* rate back to the caller. scmi_clk_recalc_rate() will be called
+* after the rate is set and we'll know what rate the clock is
+* running at then.
+*/
+   if (clk->info->rate_discrete)
+   return rate;
+
+   fmin = clk->info->range.min_rate;
+   fmax = clk->info->range.max_rate;
+   

[PATCH v5 01/20] dt-bindings: mailbox: add support for mailbox client shared memory

[Sudeep Holla]

Many users of the mailbox controllers depend on the shared memory
between the two end points to exchange the main data while using simple
doorbell mechanism to alert the end points of the presence of a message.

This patch defines device tree bindings to represent such shared memory
in a generic way.

Cc: Mark Rutland 
Acked-by: Rob Herring 
Signed-off-by: Sudeep Holla 
---
 .../devicetree/bindings/mailbox/mailbox.txt| 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/mailbox/mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/mailbox.txt
index be05b9746c69..af8ecee2ac68 100644
--- a/Documentation/devicetree/bindings/mailbox/mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/mailbox.txt
@@ -23,6 +23,11 @@ assign appropriate mailbox channel to client drivers.
 
 Optional property:
 - mbox-names: List of identifier strings for each mailbox channel.
+- shmem : List of phandle pointing to the shared memory(SHM) area between the
+ users of these mailboxes for IPC, one for each mailbox. This shared
+ memory can be part of any memory reserved for the purpose of this
+ communication between the mailbox client and the remote.
+
 
 Example:
pwr_cntrl: power {
@@ -30,3 +35,26 @@ assign appropriate mailbox channel to client drivers.
mbox-names = "pwr-ctrl", "rpc";
mboxes = < 0  1>;
};
+
+Example with shared memory(shmem):
+
+   sram: sram@5000 {
+   compatible = "mmio-sram";
+   reg = <0x5000 0x1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x5000 0x1>;
+
+   cl_shmem: shmem@0 {
+   compatible = "client-shmem";
+   reg = <0x0 0x200>;
+   };
+   };
+
+   client@2e00 {
+   ...
+   mboxes = < 0>;
+   shmem = <_shmem>;
+   ..
+   };
-- 
2.7.4

[PATCH v5 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI

[Sudeep Holla]

The SCMI is intended to allow OSPM to manage various functions that are
provided by the hardware platform it is running on, including power and
performance functions. SCMI provides two levels of abstraction, protocols
and transports. Protocols define individual groups of system control and
management messages. A protocol specification describes the messages
that it supports. Transports describe the method by which protocol
messages are communicated between agents and the platform.

This patch adds basic infrastructure to manage the message allocation,
initialisation, packing/unpacking and shared memory management.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 MAINTAINERS|   3 +-
 drivers/firmware/Kconfig   |  21 ++
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/arm_scmi/Makefile |   2 +
 drivers/firmware/arm_scmi/common.h |  77 
 drivers/firmware/arm_scmi/driver.c | 708 +
 include/linux/scmi_protocol.h  |  27 ++
 7 files changed, 838 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/Makefile
 create mode 100644 drivers/firmware/arm_scmi/common.h
 create mode 100644 drivers/firmware/arm_scmi/driver.c
 create mode 100644 include/linux/scmi_protocol.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 56885de4ba44..e7526be3a05b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13157,7 +13157,8 @@ F:  
Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
 F: drivers/clk/clk-scpi.c
 F: drivers/cpufreq/scpi-cpufreq.c
 F: drivers/firmware/arm_scpi.c
-F: include/linux/scpi_protocol.h
+F: drivers/firmware/arm_scmi/
+F: include/linux/sc[mp]i_protocol.h
 
 SYSTEM RESET/SHUTDOWN DRIVERS
 M: Sebastian Reichel 
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index fa87a055905e..10b917d32087 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -19,6 +19,27 @@ config ARM_PSCI_CHECKER
  on and off through hotplug, so for now torture tests and PSCI checker
  are mutually exclusive.
 
+config ARM_SCMI_PROTOCOL
+   bool "ARM System Control and Management Interface (SCMI) Message 
Protocol"
+   depends on ARM || ARM64 || COMPILE_TEST
+   depends on MAILBOX
+   help
+ ARM System Control and Management Interface (SCMI) protocol is a
+ set of operating system-independent software interfaces that are
+ used in system management. SCMI is extensible and currently provides
+ interfaces for: Discovery and self-description of the interfaces
+ it supports, Power domain management which is the ability to place
+ a given device or domain into the various power-saving states that
+ it supports, Performance management which is the ability to control
+ the performance of a domain that is composed of compute engines
+ such as application processors and other accelerators, Clock
+ management which is the ability to set and inquire rates on platform
+ managed clocks and Sensor management which is the ability to read
+ sensor data, and be notified of sensor value.
+
+ This protocol library provides interface for all the client drivers
+ making use of the features offered by the SCMI.
+
 config ARM_SCPI_PROTOCOL
tristate "ARM System Control and Power Interface (SCPI) Message 
Protocol"
depends on ARM || ARM64 || COMPILE_TEST
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index feaa890197f3..33dcc099e021 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
 CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension 
sec,-DREQUIRES_SEC=1) -march=armv7-a
 obj-$(CONFIG_TI_SCI_PROTOCOL)  += ti_sci.o
 
+obj-$(CONFIG_ARM_SCMI_PROTOCOL)+= arm_scmi/
 obj-y  += broadcom/
 obj-y  += meson/
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
diff --git a/drivers/firmware/arm_scmi/Makefile 
b/drivers/firmware/arm_scmi/Makefile
new file mode 100644
index ..b2a24ba2b636
--- /dev/null
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -0,0 +1,2 @@
+obj-y  = scmi-driver.o
+scmi-driver-y = driver.o
diff --git a/drivers/firmware/arm_scmi/common.h 
b/drivers/firmware/arm_scmi/common.h
new file mode 100644
index ..cdfc43427c3c
--- /dev/null
+++ b/drivers/firmware/arm_scmi/common.h
@@ -0,0 +1,77 @@
+/*
+ * System Control and Management Interface (SCMI) Message Protocol
+ * driver common header file containing some definitions, structures
+ * and function prototypes used in all the different SCMI protocols.
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 

[PATCH v5 13/20] firmware: arm_scmi: refactor in preparation to support per-protocol channels

[Sudeep Holla]

In order to support per-protocol channels if available, we need to
factor out all the mailbox channel information(Tx/Rx payload and
channel handle) out of the main SCMI instance information structure.

This patch refactors the existing channel information into a separate
chan_info structure.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/driver.c | 86 --
 1 file changed, 54 insertions(+), 32 deletions(-)

diff --git a/drivers/firmware/arm_scmi/driver.c 
b/drivers/firmware/arm_scmi/driver.c
index 0c9dda72f10c..24acb421208c 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -105,6 +105,22 @@ struct scmi_desc {
 };
 
 /**
+ * struct scmi_chan_info - Structure representing a SCMI channel informfation
+ *
+ * @cl: Mailbox Client
+ * @chan: Transmit/Receive mailbox channel
+ * @payload: Transmit/Receive mailbox channel payload area
+ * @dev: Reference to device in the SCMI hierarchy corresponding to this
+ *  channel
+ */
+struct scmi_chan_info {
+   struct mbox_client cl;
+   struct mbox_chan *chan;
+   void __iomem *payload;
+   struct device *dev;
+};
+
+/**
  * struct scmi_info - Structure representing a  SCMI instance
  *
  * @dev: Device pointer
@@ -112,10 +128,8 @@ struct scmi_desc {
  * @handle: Instance of SCMI handle to send to clients
  * @version: SCMI revision information containing protocol version,
  * implementation version and (sub-)vendor identification.
- * @cl: Mailbox Client
- * @tx_chan: Transmit mailbox channel
- * @tx_payload: Transmit mailbox channel payload area
  * @minfo: Message info
+ * @tx_cinfo: Reference to SCMI channel information
  * @protocols_imp: list of protocols implemented, currently maximum of
  * MAX_PROTOCOLS_IMP elements allocated by the base protocol
  * @node: list head
@@ -126,16 +140,14 @@ struct scmi_info {
const struct scmi_desc *desc;
struct scmi_revision_info version;
struct scmi_handle handle;
-   struct mbox_client cl;
-   struct mbox_chan *tx_chan;
-   void __iomem *tx_payload;
struct scmi_xfers_info minfo;
+   struct scmi_chan_info *tx_cinfo;
u8 *protocols_imp;
struct list_head node;
int users;
 };
 
-#define client_to_scmi_info(c) container_of(c, struct scmi_info, cl)
+#define client_to_scmi_chan_info(c) container_of(c, struct scmi_chan_info, cl)
 #define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle)
 
 /*
@@ -218,10 +230,11 @@ static void scmi_rx_callback(struct mbox_client *cl, void 
*m)
 {
u16 xfer_id;
struct scmi_xfer *xfer;
-   struct scmi_info *info = client_to_scmi_info(cl);
+   struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
+   struct device *dev = cinfo->dev;
+   struct scmi_info *info = dev_get_drvdata(dev);
struct scmi_xfers_info *minfo = >minfo;
-   struct device *dev = info->dev;
-   struct scmi_shared_mem __iomem *mem = info->tx_payload;
+   struct scmi_shared_mem __iomem *mem = cinfo->payload;
 
xfer_id = MSG_XTRACT_TOKEN(ioread32(>msg_header));
 
@@ -272,8 +285,8 @@ static inline u32 pack_scmi_header(struct scmi_msg_hdr *hdr)
 static void scmi_tx_prepare(struct mbox_client *cl, void *m)
 {
struct scmi_xfer *t = m;
-   struct scmi_info *info = client_to_scmi_info(cl);
-   struct scmi_shared_mem __iomem *mem = info->tx_payload;
+   struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
+   struct scmi_shared_mem __iomem *mem = cinfo->payload;
 
/* Mark channel busy + clear error */
iowrite32(0x0, >channel_status);
@@ -366,15 +379,15 @@ void scmi_one_xfer_put(const struct scmi_handle *handle, 
struct scmi_xfer *xfer)
 }
 
 static bool
-scmi_xfer_poll_done(const struct scmi_info *info, struct scmi_xfer *xfer)
+scmi_xfer_poll_done(const struct scmi_chan_info *cinfo, struct scmi_xfer *xfer)
 {
-   struct scmi_shared_mem *mem = info->tx_payload;
-   u16 xfer_id = MSG_XTRACT_TOKEN(le32_to_cpu(mem->msg_header));
+   struct scmi_shared_mem __iomem *mem = cinfo->payload;
+   u16 xfer_id = MSG_XTRACT_TOKEN(ioread32(>msg_header));
 
if (xfer->hdr.seq != xfer_id)
return false;
 
-   return le32_to_cpu(mem->channel_status) &
+   return ioread32(>channel_status) &
(SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR |
SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
 }
@@ -396,8 +409,9 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct 
scmi_xfer *xfer)
int timeout;
struct scmi_info *info = handle_to_scmi_info(handle);
struct device *dev = info->dev;
+   struct scmi_chan_info *cinfo = info->tx_cinfo;
 
-   ret = mbox_send_message(info->tx_chan, xfer);
+   ret = mbox_send_message(cinfo->chan, xfer);
if (ret < 0) {
dev_dbg(dev, "mbox send fail %d\n", ret);

[PATCH v5 14/20] firmware: arm_scmi: add per-protocol channels support using idr objects

[Sudeep Holla]

In order to maintain the channel information per protocol, we need
some sort of list or hashtable to hold all this information. IDR
provides sparse array mapping of small integer ID numbers onto arbitrary
pointers. In this case the arbitrary pointers can be pointers to the
channel information.

This patch adds support for per-protocol channels using those idr
objects.

Cc: Arnd Bergmann 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/driver.c | 54 +-
 1 file changed, 42 insertions(+), 12 deletions(-)

diff --git a/drivers/firmware/arm_scmi/driver.c 
b/drivers/firmware/arm_scmi/driver.c
index 24acb421208c..6734a035bcc6 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -118,6 +118,7 @@ struct scmi_chan_info {
struct mbox_chan *chan;
void __iomem *payload;
struct device *dev;
+   struct scmi_handle *handle;
 };
 
 /**
@@ -129,7 +130,7 @@ struct scmi_chan_info {
  * @version: SCMI revision information containing protocol version,
  * implementation version and (sub-)vendor identification.
  * @minfo: Message info
- * @tx_cinfo: Reference to SCMI channel information
+ * @tx_idr: IDR object to map protocol id to channel info pointer
  * @protocols_imp: list of protocols implemented, currently maximum of
  * MAX_PROTOCOLS_IMP elements allocated by the base protocol
  * @node: list head
@@ -141,7 +142,7 @@ struct scmi_info {
struct scmi_revision_info version;
struct scmi_handle handle;
struct scmi_xfers_info minfo;
-   struct scmi_chan_info *tx_cinfo;
+   struct idr tx_idr;
u8 *protocols_imp;
struct list_head node;
int users;
@@ -232,7 +233,7 @@ static void scmi_rx_callback(struct mbox_client *cl, void 
*m)
struct scmi_xfer *xfer;
struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
struct device *dev = cinfo->dev;
-   struct scmi_info *info = dev_get_drvdata(dev);
+   struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
struct scmi_xfers_info *minfo = >minfo;
struct scmi_shared_mem __iomem *mem = cinfo->payload;
 
@@ -409,7 +410,11 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct 
scmi_xfer *xfer)
int timeout;
struct scmi_info *info = handle_to_scmi_info(handle);
struct device *dev = info->dev;
-   struct scmi_chan_info *cinfo = info->tx_cinfo;
+   struct scmi_chan_info *cinfo;
+
+   cinfo = idr_find(>tx_idr, xfer->hdr.protocol_id);
+   if (unlikely(!cinfo))
+   return -EINVAL;
 
ret = mbox_send_message(cinfo->chan, xfer);
if (ret < 0) {
@@ -681,13 +686,18 @@ static int scmi_mailbox_check(struct device_node *np)
return of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0, );
 }
 
-static int scmi_mbox_free_channel(struct scmi_chan_info *cinfo)
+static int scmi_mbox_free_channel(int id, void *p, void *data)
 {
+   struct scmi_chan_info *cinfo = p;
+   struct idr *idr = data;
+
if (!IS_ERR_OR_NULL(cinfo->chan)) {
mbox_free_channel(cinfo->chan);
cinfo->chan = NULL;
}
 
+   idr_remove(idr, id);
+
return 0;
 }
 
@@ -695,6 +705,7 @@ static int scmi_remove(struct platform_device *pdev)
 {
int ret = 0;
struct scmi_info *info = platform_get_drvdata(pdev);
+   struct idr *idr = >tx_idr;
 
mutex_lock(_list_mutex);
if (info->users)
@@ -703,28 +714,34 @@ static int scmi_remove(struct platform_device *pdev)
list_del(>node);
mutex_unlock(_list_mutex);
 
-   if (!ret)
+   if (!ret) {
/* Safe to free channels since no more users */
-   return scmi_mbox_free_channel(info->tx_cinfo);
+   ret = idr_for_each(idr, scmi_mbox_free_channel, idr);
+   idr_destroy(>tx_idr);
+   }
 
return ret;
 }
 
-static inline int scmi_mbox_chan_setup(struct scmi_info *info)
+static inline int
+scmi_mbox_chan_setup(struct scmi_info *info, struct device *dev, int prot_id)
 {
int ret;
struct resource res;
resource_size_t size;
-   struct device *dev = info->dev;
struct device_node *shmem, *np = dev->of_node;
struct scmi_chan_info *cinfo;
struct mbox_client *cl;
 
+   if (scmi_mailbox_check(np)) {
+   cinfo = idr_find(>tx_idr, SCMI_PROTOCOL_BASE);
+   goto idr_alloc;
+   }
+
cinfo = devm_kzalloc(info->dev, sizeof(*cinfo), GFP_KERNEL);
if (!cinfo)
return -ENOMEM;
 
-   info->tx_cinfo = cinfo;
cinfo->dev = dev;
 
cl = >cl;
@@ -758,6 +775,14 @@ static inline int scmi_mbox_chan_setup(struct scmi_info 
*info)
return ret;
}
 
+idr_alloc:
+   ret = idr_alloc(>tx_idr, cinfo, prot_id, prot_id + 1, GFP_KERNEL);
+   if (ret != prot_id) 

[PATCH v5 18/20] hwmon: add support for sensors exported via ARM SCMI

[Sudeep Holla]

Create a driver to add support for SoC sensors exported by the System
Control Processor (SCP) via the System Control and Management Interface
(SCMI). The supported sensor types is one of voltage, temperature,
current, and power.

The sensor labels and values provided by the SCP are exported via the
hwmon sysfs interface.

Cc: linux-hw...@vger.kernel.org
Acked-by: Guenter Roeck 
Signed-off-by: Sudeep Holla 
---
 drivers/hwmon/Kconfig  |  12 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/scmi-hwmon.c | 233 +
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/hwmon/scmi-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 7ad017690e3a..518483386bd2 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -321,6 +321,18 @@ config SENSORS_APPLESMC
  Say Y here if you have an applicable laptop and want to experience
  the awesome power of applesmc.
 
+config SENSORS_ARM_SCMI
+   tristate "ARM SCMI Sensors"
+   depends on ARM_SCMI_PROTOCOL
+   depends on THERMAL || !THERMAL_OF
+   help
+ This driver provides support for temperature, voltage, current
+ and power sensors available on SCMI based platforms. The actual
+ number and type of sensors exported depend on the platform.
+
+ This driver can also be built as a module.  If so, the module
+ will be called scmi-hwmon.
+
 config SENSORS_ARM_SCPI
tristate "ARM SCPI Sensors"
depends on ARM_SCPI_PROTOCOL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 0fe489fab663..86ae4011021f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_ADT7462) += adt7462.o
 obj-$(CONFIG_SENSORS_ADT7470)  += adt7470.o
 obj-$(CONFIG_SENSORS_ADT7475)  += adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
+obj-$(CONFIG_SENSORS_ARM_SCMI) += scmi-hwmon.o
 obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)  += asc7621.o
 obj-$(CONFIG_SENSORS_ASPEED)   += aspeed-pwm-tacho.o
diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
new file mode 100644
index ..7a0ab768d4b5
--- /dev/null
+++ b/drivers/hwmon/scmi-hwmon.c
@@ -0,0 +1,233 @@
+/*
+ * System Control and Management Interface(SCMI) based hwmon sensor driver
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ * Sudeep Holla 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct scmi_sensors {
+   const struct scmi_handle *handle;
+   const struct scmi_sensor_info **info[hwmon_max];
+};
+
+static int scmi_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+  u32 attr, int channel, long *val)
+{
+   int ret;
+   u64 value;
+   const struct scmi_sensor_info *sensor;
+   struct scmi_sensors *scmi_sensors = dev_get_drvdata(dev);
+   const struct scmi_handle *h = scmi_sensors->handle;
+
+   sensor = *(scmi_sensors->info[type] + channel);
+   ret = h->sensor_ops->reading_get(h, sensor->id, false, );
+   if (!ret)
+   *val = value;
+
+   return ret;
+}
+
+static int
+scmi_hwmon_read_string(struct device *dev, enum hwmon_sensor_types type,
+  u32 attr, int channel, const char **str)
+{
+   const struct scmi_sensor_info *sensor;
+   struct scmi_sensors *scmi_sensors = dev_get_drvdata(dev);
+
+   sensor = *(scmi_sensors->info[type] + channel);
+   *str = sensor->name;
+
+   return 0;
+}
+
+static umode_t
+scmi_hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+   const struct scmi_sensor_info *sensor;
+   const struct scmi_sensors *scmi_sensors = drvdata;
+
+   sensor = *(scmi_sensors->info[type] + channel);
+   if (sensor && sensor->name)
+   return S_IRUGO;
+
+   return 0;
+}
+
+static const struct hwmon_ops scmi_hwmon_ops = {
+   .is_visible = scmi_hwmon_is_visible,
+   .read = scmi_hwmon_read,
+   .read_string = scmi_hwmon_read_string,
+};
+
+static struct hwmon_chip_info scmi_chip_info = {
+   .ops = _hwmon_ops,
+   .info = NULL,
+};
+
+static int scmi_hwmon_add_chan_info(struct hwmon_channel_info *scmi_hwmon_chan,
+   struct device *dev, int num,
+   enum hwmon_sensor_types type, u32 config)
+{
+   int i;

[PATCH v5 00/20] firmware: ARM System Control and Management Interface(SCMI) support

[Sudeep Holla]

Hi all,

ARM System Control and Management Interface(SCMI) is more flexible and
easily extensible than any of the existing interfaces. Many vendors were
involved in the making of this formal specification and is now published[1].

There is a strong trend in the industry to provide micro-controllers in
systems to abstract various power, or other system management tasks.
These controllers usually have similar interfaces, both in terms of the
functions that are provided by them, and in terms of how requests are
communicated to them.

This specification is to standardise and avoid (any further)
fragmentation in the design of such interface by various vendors.

This patch set is intended to get feedback on the design and structure
of the code. This is not complete and not fully tested due to
non-availability of firmware with full feature set at this time.

It currently doesn't support notification, asynchronous/delayed response,
perf/power statistics region and sensor register region to name a few.
I have borrowed some of the ideas of message allocation/management from
TI SCI.

Changes:

v4[6]->v5:
- Rebased to v4.15-rc6
- Updated all the gathered Ack/Reviewed-by tags(which includes
  all the drivers using SCMI protocol)

v3[5]->v4[6]:
- Added SCMI protocol bus to enumerate supported protocols as
  suggested by Arnd
- Dropped the abstraction to mailbox as it may be optional

v2[4]->v3:
- Addressed various comments recieved so far(clock, hwmon and
  cpufreq drivers along with scmi drivers)
- Hwmon driver now uses core layer to create and manage sysfs
  attributes
- Added a shim layer to abstract the mailbox interface to support
  any custom adaptation required by the controller driver
- Simple ARM MHU shim layer using newly added abstraction

v1[3]->v2[4]:
- Additional support for polling based DVFS and per protocol
  channels
- Dependent drivers(clock, hwmon, cpufreq and power domains)
- Various other review comments and issued found during testing
  addressed
- Explicit binding for method dropped as even SMC based method
  are adviertised as mailbox

RFC[2]->v1[3]:
- Add generic mailbox binding for shared memory(Rob H)
- Dropped compatibles per protocol(Suggested by Matt S)
- Dropped lot of unnecessary pointer casting(Arnd B)
- Dropped packing of structures(Arnd B)
- Few other changes/additions based initial testing with firmware
  providing SCMI interface to OSPM

--
Regards,
Sudeep

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[2] https://marc.info/?l=linux-kernel=149685193627620=2
[3] https://marc.info/?l=linux-arm-kernel=149849482623492=2
[4] https://marc.info/?l=devicetree=150185763105926=2
[5] https://marc.info/?l=devicetree=150660452015351=2
[6] https://marc.info/?l=devicetree=150972061408961=2

Sudeep Holla (20):
  dt-bindings: mailbox: add support for mailbox client shared memory
  dt-bindings: arm: add support for ARM System Control and Management
Interface(SCMI) protocol
  firmware: arm_scmi: add basic driver infrastructure for SCMI
  firmware: arm_scmi: add common infrastructure and support for base
protocol
  firmware: arm_scmi: add scmi protocol bus to enumerate protocol
devices
  firmware: arm_scmi: add initial support for performance protocol
  firmware: arm_scmi: add initial support for clock protocol
  firmware: arm_scmi: add initial support for power protocol
  firmware: arm_scmi: add initial support for sensor protocol
  firmware: arm_scmi: probe and initialise all the supported protocols
  firmware: arm_scmi: add support for polling based SCMI transfers
  firmware: arm_scmi: add option for polling based performance domain
operations
  firmware: arm_scmi: refactor in preparation to support per-protocol
channels
  firmware: arm_scmi: add per-protocol channels support using idr
objects
  firmware: arm_scmi: add device power domain support using genpd
  clk: add support for clocks provided by SCMI
  hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration
  hwmon: add support for sensors exported via ARM SCMI
  cpufreq: add support for CPU DVFS based on SCMI message protocol
  cpufreq: scmi: add support for fast frequency switching

 Documentation/devicetree/bindings/arm/arm,scmi.txt | 179 +
 .../devicetree/bindings/mailbox/mailbox.txt|  28 +
 MAINTAINERS|  11 +-
 drivers/clk/Kconfig|  10 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-scmi.c | 213 +
 drivers/cpufreq/Kconfig.arm|  11 +
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/scmi-cpufreq.c | 285 +++
 drivers/firmware/Kconfig   |  

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Boris Ostrovsky]

On 01/02/2018 09:32 AM, Andrew Cooper wrote:
> On 02/01/18 14:24, Juergen Gross wrote:
>> On 02/01/18 15:18, Boris Ostrovsky wrote:
>>> On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
 The header declares this function as __init but is defined in __ref
 section.

 Signed-off-by: Nick Desaulniers 
>>> AFAIK section attributes in header files are ignored by compiler anyway
>>> so I'd remove all of them.
>> Hmm, I'm not sure all future compilers will ignore the section
>> attributes. include/linux/init.h explictily mentions where to put
>> the attrubute in a prototype, so I'd rather keep it.
> Attributes in the declaration are for static analysis tools such as sparse.
>
> How else are you going to work out whether a section mismatch has occurred?

Isn't this done based on definitions?

Tons of __init routines don't have the attribute specified in header
files. In fact, even in this file (arch/x86/xen/xen-ops.h) there are
some that don't have it.

-boris

Re: [PATCH v8 1/2] tpm_tis: Move ilb_base_addr to tpm_tis_data

[Jason Gunthorpe]

On Tue, Jan 02, 2018 at 05:31:30AM +, Shaikh, Azhar wrote:
> >>On Mon, Jan 01, 2018 at 08:05:43PM -0800, Azhar Shaikh wrote:
> >>
> >>> - return tpm_chip_register(chip);
> >>> + rc = tpm_chip_register(chip);
> >>> + if (rc && is_bsw())
> >>> + iounmap(priv->ilb_base_addr);
> >>> +
> >>> + return rc;
> >>>  out_err:
> >>>   tpm_tis_remove(chip);
> >>> + if (is_bsw())
> >>> + iounmap(priv->ilb_base_addr);
> >>> +
> >>>   return rc;
> >>>  }
> >>
> >>I thought you were resending this to fix the above, why is is it still 
> >>wonky?
> >>
> >
> >Oh! I fixed it in the second patch ("tpm: Keep CLKRUN enabled throughout
> >the duration of transmit_cmd()"). Should have fixed in this patch instead. My
> >bad, didn't see it was introduced in this patch. I thought it was part of 
> >second
> >patch. Will fix this.
> >
> 
> On checking, the ops->clk_enable is not still introduced yet. It is 
> introduced in the second patch. The cleanup is done in the next patch.
> So do you want me to still fix this here?

Try hard to not edit your own patches in your series. No reason why
iounmap cannot be put into tpm_tis_remove in the first place

Jason

Re: [PATCH v3 1/9] ufs: sysfs: device descriptor

[Bart Van Assche]

On Tue, 2018-01-02 at 13:54 +, Stanislav Nijnikov wrote:
> The existing configuration doesn't allow to add a new file to be compiled 
> as a part of this module. The line like " obj-$(CONFIG_SCSI_UFSHCD) += 
> ufshcd.o ufs-sysfs.o" in the makefile will actually create 2 modules.
> This was the reason why I used EXPORT_SYMBOL in the first version.

There are plenty of kernel modules that consist of multiple source files, e.g.
the SCSI core. Please make yourself familiar with how to do this.

Thanks,

Bart.

[PATCH v5 11/15] MIPS: ingenic: Initial JZ4770 support

[Paul Cercueil]

Provide just enough bits (clocks, clocksource, uart) to allow a kernel
to boot on the JZ4770 SoC to a initramfs userspace.

Signed-off-by: Paul Cercueil 
---
 arch/mips/boot/dts/ingenic/jz4770.dtsi | 212 +
 arch/mips/jz4740/Kconfig   |   6 +
 arch/mips/jz4740/time.c|   2 +-
 3 files changed, 219 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/boot/dts/ingenic/jz4770.dtsi

 v2: No change
 v3: No change
 v4: No change
 v5: Use SPDX license identifier

diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi 
b/arch/mips/boot/dts/ingenic/jz4770.dtsi
new file mode 100644
index ..7c2804f3f5f1
--- /dev/null
+++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "ingenic,jz4770";
+
+   cpuintc: interrupt-controller {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "mti,cpu-interrupt-controller";
+   };
+
+   intc: interrupt-controller@10001000 {
+   compatible = "ingenic,jz4770-intc";
+   reg = <0x10001000 0x40>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   ext: ext {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   };
+
+   osc32k: osc32k {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
+
+   cgu: jz4770-cgu@1000 {
+   compatible = "ingenic,jz4770-cgu";
+   reg = <0x1000 0x100>;
+
+   clocks = <>, <>;
+   clock-names = "ext", "osc32k";
+
+   #clock-cells = <1>;
+   };
+
+   pinctrl: pin-controller@1001 {
+   compatible = "ingenic,jz4770-pinctrl";
+   reg = <0x1001 0x600>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   gpa: gpio@0 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <0>;
+
+   gpio-controller;
+   gpio-ranges = < 0 0 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <17>;
+   };
+
+   gpb: gpio@1 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <1>;
+
+   gpio-controller;
+   gpio-ranges = < 0 32 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <16>;
+   };
+
+   gpc: gpio@2 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <2>;
+
+   gpio-controller;
+   gpio-ranges = < 0 64 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <15>;
+   };
+
+   gpd: gpio@3 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <3>;
+
+   gpio-controller;
+   gpio-ranges = < 0 96 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <14>;
+   };
+
+   gpe: gpio@4 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <4>;
+
+   gpio-controller;
+   gpio-ranges = < 0 128 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <13>;
+   };
+
+   gpf: gpio@5 {
+   compatible = "ingenic,jz4770-gpio";
+   reg = <5>;
+
+   gpio-controller;
+   gpio-ranges = < 0 160 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   

[PATCH v5 15/15] MIPS: ingenic: Initial GCW Zero support

[Paul Cercueil]

The GCW Zero (http://www.gcw-zero.com) is a retro-gaming focused
handheld game console, successfully kickstarted in ~2012, running Linux.

Signed-off-by: Paul Cercueil 
---
 arch/mips/boot/dts/ingenic/Makefile |  1 +
 arch/mips/boot/dts/ingenic/gcw0.dts | 61 +
 arch/mips/configs/gcw0_defconfig| 27 
 arch/mips/jz4740/Kconfig|  4 +++
 arch/mips/jz4740/boards.c   |  1 +
 5 files changed, 94 insertions(+)
 create mode 100644 arch/mips/boot/dts/ingenic/gcw0.dts
 create mode 100644 arch/mips/configs/gcw0_defconfig

 v2: No change
 v3: No change
 v4: No change
 v5: Use SPDX license identifier
 Drop custom CROSS_COMPILE from defconfig

diff --git a/arch/mips/boot/dts/ingenic/Makefile 
b/arch/mips/boot/dts/ingenic/Makefile
index 6a31759839b4..5b1361a89e02 100644
--- a/arch/mips/boot/dts/ingenic/Makefile
+++ b/arch/mips/boot/dts/ingenic/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_JZ4740_QI_LB60)   += qi_lb60.dtb
+dtb-$(CONFIG_JZ4770_GCW0)  += gcw0.dtb
 dtb-$(CONFIG_JZ4780_CI20)  += ci20.dtb
 
 obj-y  += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/boot/dts/ingenic/gcw0.dts 
b/arch/mips/boot/dts/ingenic/gcw0.dts
new file mode 100644
index ..4dc72de387db
--- /dev/null
+++ b/arch/mips/boot/dts/ingenic/gcw0.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "jz4770.dtsi"
+
+/ {
+   compatible = "gcw,zero", "ingenic,jz4770";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:57600n8";
+   };
+
+   board {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges = <>;
+
+   otg_phy: otg-phy {
+   compatible = "usb-nop-xceiv";
+   clocks = < JZ4770_CLK_OTG_PHY>;
+   clock-names = "main_clk";
+   };
+   };
+};
+
+ {
+   clock-frequency = <1200>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   /* Put high-speed peripherals under PLL1, such that we can change the
+* PLL0 frequency on demand without having to suspend peripherals.
+* We use a rate of 432 MHz, which is the least common multiple of
+* 27 MHz (required by TV encoder) and 48 MHz (required by USB host).
+*/
+   assigned-clocks =
+   < JZ4770_CLK_PLL1>,
+   < JZ4770_CLK_UHC>;
+   assigned-clock-parents =
+   <0>,
+   < JZ4770_CLK_PLL1>;
+   assigned-clock-rates =
+   <43200>;
+};
+
+ {
+   /* The WiFi module is connected to the UHC. */
+   status = "okay";
+};
diff --git a/arch/mips/configs/gcw0_defconfig b/arch/mips/configs/gcw0_defconfig
new file mode 100644
index ..99ac1fa3b35f
--- /dev/null
+++ b/arch/mips/configs/gcw0_defconfig
@@ -0,0 +1,27 @@
+CONFIG_MACH_INGENIC=y
+CONFIG_JZ4770_GCW0=y
+CONFIG_HIGHMEM=y
+# CONFIG_BOUNCE is not set
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_SECCOMP is not set
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_EMBEDDED=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_NETDEVICES=y
+CONFIG_SERIAL_8250=y
+# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_INGENIC=y
+CONFIG_USB=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_TMPFS=y
diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
index 29a9361a2b77..4dd0c446ecec 100644
--- a/arch/mips/jz4740/Kconfig
+++ b/arch/mips/jz4740/Kconfig
@@ -8,6 +8,10 @@ config JZ4740_QI_LB60
bool "Qi Hardware Ben NanoNote"
select MACH_JZ4740
 
+config JZ4770_GCW0
+   bool "Game Consoles Worldwide GCW Zero"
+   select MACH_JZ4770
+
 config JZ4780_CI20
bool "MIPS Creator CI20"
select MACH_JZ4780
diff --git a/arch/mips/jz4740/boards.c b/arch/mips/jz4740/boards.c
index 13b0bddd8cb7..1389d6eec80f 100644
--- a/arch/mips/jz4740/boards.c
+++ b/arch/mips/jz4740/boards.c
@@ -8,5 +8,6 @@
 #include 
 
 MIPS_MACHINE(MACH_INGENIC_JZ4740, "qi,lb60", "Qi Hardware Ben Nanonote", NULL);
+MIPS_MACHINE(MACH_INGENIC_JZ4770, "gcw,zero", "GCW Zero", NULL);
 MIPS_MACHINE(MACH_INGENIC_JZ4780, "img,ci20",
"Imagination Technologies CI20", NULL);
-- 
2.11.0

[PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

[Paul Cercueil]

From: Maarten ter Huurne 

We have seen MMC DMA transfers read corrupted data from SDRAM when
a burst interval ends at physical address 0x1000. To avoid this
problem, we remove the final page of low memory from the memory map.

Signed-off-by: Maarten ter Huurne 
---
 arch/mips/jz4740/setup.c | 24 
 arch/mips/kernel/setup.c |  8 
 2 files changed, 32 insertions(+)

 v2: No change
 v3: No change
 v4: No change
 v5: No change

diff --git a/arch/mips/jz4740/setup.c b/arch/mips/jz4740/setup.c
index afd84ee966e8..6948b133a15d 100644
--- a/arch/mips/jz4740/setup.c
+++ b/arch/mips/jz4740/setup.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -102,6 +103,29 @@ void __init arch_init_irq(void)
irqchip_init();
 }
 
+/*
+ * We have seen MMC DMA transfers read corrupted data from SDRAM when a burst
+ * interval ends at physical address 0x1000. To avoid this problem, we
+ * remove the final page of low memory from the memory map.
+ */
+void __init jz4770_reserve_unsafe_for_dma(void)
+{
+   int i;
+
+   for (i = 0; i < boot_mem_map.nr_map; i++) {
+   struct boot_mem_map_entry *entry = boot_mem_map.map + i;
+
+   if (entry->type != BOOT_MEM_RAM)
+   continue;
+
+   if (entry->addr + entry->size != 0x1000)
+   continue;
+
+   entry->size -= PAGE_SIZE;
+   break;
+   }
+}
+
 static int __init jz4740_machine_setup(void)
 {
mips_machine_setup();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 85bc601e9a0d..5a2c20145aee 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -879,6 +879,14 @@ static void __init arch_mem_init(char **cmdline_p)
 
parse_early_param();
 
+#ifdef CONFIG_MACH_JZ4770
+   if (current_cpu_type() == CPU_JZRISC &&
+   mips_machtype == MACH_INGENIC_JZ4770) {
+   extern void __init jz4770_reserve_unsafe_for_dma(void);
+   jz4770_reserve_unsafe_for_dma();
+   }
+#endif
+
if (usermem) {
pr_info("User-defined physical RAM map:\n");
print_memory_map();
-- 
2.11.0

[PATCH v5 14/15] devicetree/bindings: Add GCW vendor prefix

[Paul Cercueil]

Game Consoles Worldwide, mostly known under the acronym GCW, is the
creator of the GCW Zero open-source video game system.

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

 v2: It's 'Game Consoles Worldwide', not 'Games Consoles Worldwide'
 v3: No change
 v4: No change
 v5: No change

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..f40f4da39937 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -123,6 +123,7 @@ focaltech   FocalTech Systems Co.,Ltd
 friendlyarmGuangzhou FriendlyARM Computer Tech Co., Ltd
 fslFreescale Semiconductor
 fujitsuFujitsu Ltd.
+gcw Game Consoles Worldwide
 ge General Electric Company
 geekbuying GeekBuying
 gefGE Fanuc Intelligent Platforms Embedded Systems, Inc.
-- 
2.11.0

[PATCH v5 10/15] MIPS: ingenic: Add machine info for supported boards

[Paul Cercueil]

This makes sure that 'mips_machtype' will be initialized to the SoC
version used on the board.

Signed-off-by: Paul Cercueil 
---
 arch/mips/Kconfig |  1 +
 arch/mips/jz4740/Makefile |  2 +-
 arch/mips/jz4740/boards.c | 12 
 arch/mips/jz4740/setup.c  | 34 +-
 4 files changed, 43 insertions(+), 6 deletions(-)
 create mode 100644 arch/mips/jz4740/boards.c

 v2: No change
 v3: No change
 v4: No change
 v5: Use SPDX license identifier

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 350a990fc719..83243e427e36 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -376,6 +376,7 @@ config MACH_INGENIC
select BUILTIN_DTB
select USE_OF
select LIBFDT
+   select MIPS_MACHINE
 
 config LANTIQ
bool "Lantiq based platforms"
diff --git a/arch/mips/jz4740/Makefile b/arch/mips/jz4740/Makefile
index 88d6aa7d000b..fc2d3b3c4a80 100644
--- a/arch/mips/jz4740/Makefile
+++ b/arch/mips/jz4740/Makefile
@@ -6,7 +6,7 @@
 # Object file lists.
 
 obj-y += prom.o time.o reset.o setup.o \
-   platform.o timer.o
+   platform.o timer.o boards.o
 
 CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt
 
diff --git a/arch/mips/jz4740/boards.c b/arch/mips/jz4740/boards.c
new file mode 100644
index ..13b0bddd8cb7
--- /dev/null
+++ b/arch/mips/jz4740/boards.c
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic boards support
+ * Copyright 2017, Paul Cercueil 
+ */
+
+#include 
+#include 
+
+MIPS_MACHINE(MACH_INGENIC_JZ4740, "qi,lb60", "Qi Hardware Ben Nanonote", NULL);
+MIPS_MACHINE(MACH_INGENIC_JZ4780, "img,ci20",
+   "Imagination Technologies CI20", NULL);
diff --git a/arch/mips/jz4740/setup.c b/arch/mips/jz4740/setup.c
index 6d0152321819..afd84ee966e8 100644
--- a/arch/mips/jz4740/setup.c
+++ b/arch/mips/jz4740/setup.c
@@ -22,6 +22,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -53,16 +54,34 @@ static void __init jz4740_detect_mem(void)
add_memory_region(0, size, BOOT_MEM_RAM);
 }
 
+static unsigned long __init get_board_mach_type(const void *fdt)
+{
+   const struct mips_machine *mach;
+
+   for (mach = (struct mips_machine *)&__mips_machines_start;
+   mach < (struct mips_machine *)&__mips_machines_end;
+   mach++) {
+   if (!fdt_node_check_compatible(fdt, 0, mach->mach_id))
+   return mach->mach_type;
+   }
+
+   return MACH_INGENIC_JZ4740;
+}
+
 void __init plat_mem_setup(void)
 {
int offset;
 
+   if (!early_init_dt_scan(__dtb_start))
+   return;
+
jz4740_reset_init();
-   __dt_setup_arch(__dtb_start);
 
offset = fdt_path_offset(__dtb_start, "/memory");
if (offset < 0)
jz4740_detect_mem();
+
+   mips_machtype = get_board_mach_type(__dtb_start);
 }
 
 void __init device_tree_init(void)
@@ -75,13 +94,18 @@ void __init device_tree_init(void)
 
 const char *get_system_type(void)
 {
-   if (IS_ENABLED(CONFIG_MACH_JZ4780))
-   return "JZ4780";
-
-   return "JZ4740";
+   return mips_get_machine_name();
 }
 
 void __init arch_init_irq(void)
 {
irqchip_init();
 }
+
+static int __init jz4740_machine_setup(void)
+{
+   mips_machine_setup();
+
+   return 0;
+}
+arch_initcall(jz4740_machine_setup);
-- 
2.11.0

[PATCH v5 12/15] MIPS: JZ4770: Work around config2 misreporting associativity

[Paul Cercueil]

From: Maarten ter Huurne 

According to config2, the associativity would be 5-ways, but the
documentation states 4-ways, which also matches the documented
L2 cache size of 256 kB.

Signed-off-by: Maarten ter Huurne 
---
 arch/mips/mm/sc-mips.c | 9 +
 1 file changed, 9 insertions(+)

 v2: No change
 v3: No change
 v4: Rebased on top of Linux 4.15-rc5
 v5: No change

diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index 548acb7f8557..394673991bab 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * MIPS32/MIPS64 L2 cache handling
@@ -220,6 +221,14 @@ static inline int __init mips_sc_probe(void)
else
return 0;
 
+   /*
+* According to config2 it would be 5-ways, but that is contradicted
+* by all documentation.
+*/
+   if (current_cpu_type() == CPU_JZRISC &&
+   mips_machtype == MACH_INGENIC_JZ4770)
+   c->scache.ways = 4;
+
c->scache.waysize = c->scache.sets * c->scache.linesz;
c->scache.waybit = __ffs(c->scache.waysize);
 
-- 
2.11.0

Re: [PATCH v17 0/5] ZII RAVE platform driver

[Lee Jones]

On Wed, 20 Dec 2017, Andrey Smirnov wrote:

> Everyone:
> 
> This patch series is v17 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical subsystems on RAVE
> devices whose firmware implements protocol to command/qery them.
> 
> NOTE:
> 
>  * This driver dependends on crc_ccitt_false(), added by
>2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
>was pulled in by Andrew Morton and is currently avaiting users, so
>this series might have to go in through Andrew's tree

Hmm... well that's annoying!  I just attempted to merge this set, but
early build tests fail due to a dependency already merged into -next.

../drivers/mfd/rave-sp.c:227:25: error:
implicit declaration of function ‘crc_ccitt_false’
[-Werror=implicit-function-declaration]

We need to figure out if either of the following are true:

 - Patch [0] can be dropped from Andrew's tree
   - ... and I can take it via the MFD tree instead
 - Patch [0] is on an immutable branch I can pull in to my PR

If not, it will have to wait until the next cycle.

[0]:

Author: Andrey Vostrikov 
Date:   Mon Dec 25 22:39:57 2017 +1100

lib/crc-ccitt: add CCITT-FALSE CRC16 variant

In support of a soon to be published MFD driver using serdev to talk to
a supervisory processor that uses the CCITT-FALSE CRC16 variant in it's
protocol, this patch was tested successfully on an i.MX6 ARM platform.

Link: 
http://lkml.kernel.org/r/20170413142932.27287-1-andrew.smir...@gmail.com
Signed-off-by: Andrey Vostrikov 
Signed-off-by: Andrey Smirnov 
Tested-by: Chris Healy 
Signed-off-by: Andrew Morton 
Signed-off-by: Stephen Rothwell 

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Julia Lawall]

On Tue, 2 Jan 2018, Bart Van Assche wrote:

> On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote:
> > On Tue, 2 Jan 2018, Bob Peterson wrote:
> > > - Original Message -
> > > > - Original Message -
> > > >
> > > Still, the GFS2 and DLM code has a plethora of broken-up printk messages,
> > > and I don't like the thought of re-combining them all.
> >
> > Actually, the point of the patch was to remove the unnecessary \n at the
> > end of the string, because log_print will add another one.  If you prefer
> > to keep the string broken up, I can resend the patch in that form, but
> > without the unnecessary \n.
>
> Please combine any user-visible strings into a single line for which the
> unneeded newline is dropped since these strings are modified anyway by
> your patch.

That is what the submitted patch (2/12 specifically) did.

julia

[PATCH] thermal/x86 pkg temp: Remove debugfs_create_u32() casts

[Geert Uytterhoeven]

When exposing data access through debugfs, the correct
debugfs_create_*() functions must be used, depending on data type.

Remove all casts from data pointers passed to debugfs_create_*()
functions, as such casts prevent the compiler from flagging bugs.

Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 drivers/thermal/x86_pkg_temp_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/x86_pkg_temp_thermal.c 
b/drivers/thermal/x86_pkg_temp_thermal.c
index d93eee2f101b0aee..1a6c88b10a396e37 100644
--- a/drivers/thermal/x86_pkg_temp_thermal.c
+++ b/drivers/thermal/x86_pkg_temp_thermal.c
@@ -96,12 +96,12 @@ static int pkg_temp_debugfs_init(void)
return -ENOENT;
 
d = debugfs_create_u32("pkg_thres_interrupt", S_IRUGO, debugfs,
-   (u32 *)_interrupt_cnt);
+  _interrupt_cnt);
if (!d)
goto err_out;
 
d = debugfs_create_u32("pkg_thres_work", S_IRUGO, debugfs,
-   (u32 *)_work_cnt);
+  _work_cnt);
if (!d)
goto err_out;
 
-- 
2.7.4

Re: [PATCH 05/12] pinctrl: armada-37xx: account for const type of of_device_id.data

[Gregory CLEMENT]

Hi Julia,
 
 On mar., janv. 02 2018, Julia Lawall  wrote:

> The data field of an of_device_id structure has type const void *, so
> there is no need for a const-discarding cast when putting const values
> into such a structure.
>
> Done using Coccinelle.
>
> Signed-off-by: Julia Lawall 


Acked-by: Gregory CLEMENT 

Thanks,

Gregory


PS: actually the intent was not to do a const-discarding cast it was
just a useless cast! :)


>
> ---
>  drivers/pinctrl/mvebu/pinctrl-armada-37xx.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -u -p a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
> b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
> --- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
> @@ -1006,11 +1006,11 @@ static int armada_37xx_pinctrl_register(
>  static const struct of_device_id armada_37xx_pinctrl_of_match[] = {
>   {
>   .compatible = "marvell,armada3710-sb-pinctrl",
> - .data = (void *)_37xx_pin_sb,
> + .data = _37xx_pin_sb,
>   },
>   {
>   .compatible = "marvell,armada3710-nb-pinctrl",
> - .data = (void *)_37xx_pin_nb,
> + .data = _37xx_pin_nb,
>   },
>   { },
>  };
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

[Wang, Haiyue]

On 2018-01-02 23:13, Arnd Bergmann wrote:

On 2017-12-31 07:10, Arnd Bergmann wrote:

On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang
 wrote:

When PCH works under eSPI mode, the PMC (Power Management Controller) in
PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in
dead loop if no SUS_ACK assert. This is the basic requirement for the BMC
works as eSPI slave.

Also for the host power on / off actions, from BMC side, the following VW
(Virtual Wire) messages are done in firmware:
1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS
2. SUS_ACK
3. OOB_RESET_ACK
4. HOST_RESET_ACK

I have not looked at the driver contents yet, but I'm adding the SPI
maintainer and
mailing list to Cc here for further discussion. Can you clarify how
the eSPI slave
mode relates to SPI slaves that we already support? I was under the impression
that the difference between SPI and eSPI is mainly on the master side, but that
any SPI slave can also act as an eSPI slave. Would this driver fit into the SPI
slave framework, possibly with some extensions to the generic abstraction?

In simple word, the eSPI uses the SPI interface pin definition, but it
will replace Low Pin Count (LPC)
interface. From its name, sure, it will confuse you! ;-)

I know what eSPI is meant for, and understand the basic idea of the
protocol, but I'm not familiar with the Apeed slave hardware
implementation.

I see! ;-)

It also seems rather inflexible to have a single driver that is responsible both
for the transport (eSPI register level interface for ASPEED) and the high-level
protocol (talking to an Intel PCH), since either half of the work could be
done elsewhere, using either a different eSPI slave implementation, or
a different
host architecture)

Yes, eSPI has the architecture such as transaction layer, link Layer;
all of it is about the **silicon**
design. That's why I put the driver under /misc directory, not /spi
directory.

I don't see any requirement in the eSPI spec for the upper layers to
be implemented in hardware. Obviously an x86 host such as Intel's
PCH would implement the host interface using PIO,  and MMIO
accesses that are compatible with ISA and LPC, as this is the motivation
behind the specification, but an ARM server that wants to use eSPI
based peripherals could choose to implement it just as well using
a traditional SPI master hardware, some GPIOs (reset and alert)
and a (driver independent) software implementation of the transaction
and link layers.

On the slave side, it seems that aspeed have implemented the
virtual wires partially in hardware and require a driver like the one
you wrote to reply to some of the wires being accessed by the host,
but again it seems plausible that this could be implemented in another
BMC using a generic SPI slave and a transaction layer written
entirely in software.
Yes, you are right, Aspeed have implemented the virtual wires partially. 
Tthat's why I named it

as aspeed-espi-slave driver.

Your driver does not handle the other channels (smbus, mmio, spinor)
at the moment at all, can you provide some information how they
are implemented in the ast2500? Are those handled completely
in hardware (I assume this is the case for spinor at least), or do they
require help from a driver, either this one or a separate one?
I can't send the AST2500 datasheet to you directly, but you can contact 
Aspeed firstly.

https://www.aspeedtech.com/products.php?fPath=20=440

These functions are handled in hardware, the original SDK just provides 
some ioctl API for user
application to access them. The mmio function such as KCS / Port 80, 
these controllers will get
data from eSPI IP in silicon, but their drivers do not need to be 
changed, run the same as LPC

mode.

You can image bellowing work path:

 KCS    Mailbox  Snoop (Port 80)  UART 
   ^    ^ ^  ^
   | |    |   |
   | |    |   |
    \    |    /  /
 { LPC IP }    < { eSPI IP to 
decode the mmio address }


And in our first generation eSPI x86 server, we  just use the eSPI new 
function to decode the VW to
boot the PCH (eSPI master). Other functions such as GPIO SMBus, we 
didn't use it. So for making
things clean, we just keep the basic code, which is verified and tested 
well.

Arnd

---
BR,
Haiyue

Re: [PATCH v7 2/2] mfd: syscon: Add hardware spinlock support

[Lee Jones]

Arnd,

> Some system control registers need hardware spinlock to synchronize
> between the multiple subsystems, so we should add hardware spinlock
> support for syscon.
> 
> Signed-off-by: Baolin Wang 
> Acked-by: Rob Herring 

... did you sign off on this in the end?

> ---
> Changes since v6:
>  - Treat hwlock id 0 as valid for regmap.
> 
> Changes since v5:
>  - Fix the case that hwspinlock is not enabled.
> 
> Changes since v4:
>  - Add one exapmle to show how to add hwlock.
>  - Fix the coding style issue.
> 
> Changes since v3:
>  - Add error handling for of_hwspin_lock_get_id()
> 
> Changes since v2:
>  - Add acked tag from Rob.
> 
> Changes since v1:
>  - Remove timeout configuration.
>  - Modify the binding file to add hwlocks.
> ---
>  Documentation/devicetree/bindings/mfd/syscon.txt |8 
>  drivers/mfd/syscon.c |   19 +++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> index 8b92d45..25d9e9c 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -16,9 +16,17 @@ Required properties:
>  Optional property:
>  - reg-io-width: the size (in bytes) of the IO accesses that should be
>performed on the device.
> +- hwlocks: reference to a phandle of a hardware spinlock provider node.
>  
>  Examples:
>  gpr: iomuxc-gpr@20e {
>   compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
>   reg = <0x020e 0x38>;
> + hwlocks = < 1>;
> +};
> +
> +hwlock1: hwspinlock@4050 {
> + ...
> + reg = <0x4050 0x1000>;
> + #hwlock-cells = <1>;
>  };
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index b93fe4c..7eaa40b 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -87,6 +88,24 @@ static struct syscon *of_syscon_register(struct 
> device_node *np)
>   if (ret)
>   reg_io_width = 4;
>  
> + ret = of_hwspin_lock_get_id(np, 0);
> + if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) {
> + syscon_config.use_hwlock = true;
> + syscon_config.hwlock_id = ret;
> + syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
> + } else if (ret < 0) {
> + switch (ret) {
> + case -ENOENT:
> + /* Ignore missing hwlock, it's optional. */
> + break;
> + default:
> + pr_err("Failed to retrieve valid hwlock: %d\n", ret);
> + /* fall-through */
> + case -EPROBE_DEFER:
> + goto err_regmap;
> + }
> + }
> +
>   syscon_config.reg_stride = reg_io_width;
>   syscon_config.val_bits = reg_io_width * 8;
>   syscon_config.max_register = resource_size() - reg_io_width;

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile

[Lee Jones]

On Fri, 22 Dec 2017, Hans de Goede wrote:

> The input current limit bits get updated by the charger detection logic,
> so we should not cache the contents of this register.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/mfd/axp20x.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog