Re: [PATCH v2] vfio/pci: Mask buggy SR-IOV VF INTx support

[Christoph Hellwig]

> +/*
> + * Nag about hardware bugs, hopefully to have vendors fix them, but at least
> + * to collect a list of dependencies for the VF INTx pin quirk below.
> + */
> +static const struct pci_device_id known_bogus_vf_intx_pin[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x270c) },
> + {}
> +};

What device is this? We don't have the device ID anywhere, so I guess
it is something match by the class code?

Re: [PATCH v2] vfio/pci: Mask buggy SR-IOV VF INTx support

[Christoph Hellwig]

> +/*
> + * Nag about hardware bugs, hopefully to have vendors fix them, but at least
> + * to collect a list of dependencies for the VF INTx pin quirk below.
> + */
> +static const struct pci_device_id known_bogus_vf_intx_pin[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x270c) },
> + {}
> +};

What device is this? We don't have the device ID anywhere, so I guess
it is something match by the class code?

Re: [PATCH 0/2] Add API to retrieve the Bluetooth Device Address (BD_ADDR)

[Sinan Kaya]

On 9/20/2018 7:19 PM, Matthias Kaehlcke wrote:

If the existing users populate a custom property with the BD address
in the bootloader you could roll out a bootloader change. You'd have
to make sure that bootloader and kernel match. The bootloader could
still populate the custom property to be compatible with 'old'
kernels.


If there is no standard about the name of the property, this probably
doesn't belong to property.c but should rather be hosted in bluetooth
directory for consumption among the bluetooth drivers.

Re: [PATCH 0/2] Add API to retrieve the Bluetooth Device Address (BD_ADDR)

[Sinan Kaya]

On 9/20/2018 7:19 PM, Matthias Kaehlcke wrote:

If the existing users populate a custom property with the BD address
in the bootloader you could roll out a bootloader change. You'd have
to make sure that bootloader and kernel match. The bootloader could
still populate the custom property to be compatible with 'old'
kernels.


If there is no standard about the name of the property, this probably
doesn't belong to property.c but should rather be hosted in bluetooth
directory for consumption among the bluetooth drivers.

Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port

[Arnd Bergmann]

On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt  wrote:
>
> On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote:
> > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren  wrote:
> I don't want to hijack this thread, but in RISC-V land we were hoping to have 
> a
> user ABI free of 32-bit time_t.  Our 32-bit glibc ABI hasn't been finalized
> yet, and when I talked to the glibc guys a few weeks ago they were happy to 
> let
> us wait until 32-bit time_t can be removed before we stabilize the ABI.  We've
> been maintaining out-of-tree glibc patches for a while now, so I'd really like
> to get them into the next glibc release.
>
> Mapping out the schedule more explicitly, as I'm terrible with dates:
>
> * 4.19-rc4 was 2018-09-16
> * 4.19 should be 2018-10-21
> * 4.20 should be 2019-01-13 (skipping 2 weeks for the holidays)
> * 4.21 merge window should close 2019-01-27
> * glibc 2.29 is scheduled for 2019-02-01
>
> That's very tight, but assuming we at least have a prototype of the API so we
> can get the rv32i glibc patches in much earlier it might be OK.  There was 
> some
> talk of being able to use some workarounds to do a 32-bit time_t user ABI
> without the cooresponding kernel ABI, so we could always go down that route to
> start and then decide to deprecate or not deprecate the 32-bit kernel ABI at
> the last minute -- not something I'm fond of doing, but an option.
>
> How close to done do you think the 32-bit time_t will be by the end of the 
> 4.20
> merge window?  If it's close enough to start our glibc push then that might be
> OK.

It will be a bit of a stretch, but it's possible. Most syscalls are
done in linux-next,
I have a few more pending, and only clock_adjtime is really missing now (I had
some earlier patches that I could revive).

My plan was to get that all into 4.20, and then have a conversation about the
actual syscall table changes in 4.21. If we need it for both csky and rv32,
we might just change the generic syscall table that way in 4.21 without
changing all the other ones along with them. I don't want to drag things out
over too many merge windows though, and my plan was to do all architectures
together to simplify the version checks in the libc code to only have to check
for a single version.

 Arnd

Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port

[Arnd Bergmann]

On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt  wrote:
>
> On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote:
> > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren  wrote:
> I don't want to hijack this thread, but in RISC-V land we were hoping to have 
> a
> user ABI free of 32-bit time_t.  Our 32-bit glibc ABI hasn't been finalized
> yet, and when I talked to the glibc guys a few weeks ago they were happy to 
> let
> us wait until 32-bit time_t can be removed before we stabilize the ABI.  We've
> been maintaining out-of-tree glibc patches for a while now, so I'd really like
> to get them into the next glibc release.
>
> Mapping out the schedule more explicitly, as I'm terrible with dates:
>
> * 4.19-rc4 was 2018-09-16
> * 4.19 should be 2018-10-21
> * 4.20 should be 2019-01-13 (skipping 2 weeks for the holidays)
> * 4.21 merge window should close 2019-01-27
> * glibc 2.29 is scheduled for 2019-02-01
>
> That's very tight, but assuming we at least have a prototype of the API so we
> can get the rv32i glibc patches in much earlier it might be OK.  There was 
> some
> talk of being able to use some workarounds to do a 32-bit time_t user ABI
> without the cooresponding kernel ABI, so we could always go down that route to
> start and then decide to deprecate or not deprecate the 32-bit kernel ABI at
> the last minute -- not something I'm fond of doing, but an option.
>
> How close to done do you think the 32-bit time_t will be by the end of the 
> 4.20
> merge window?  If it's close enough to start our glibc push then that might be
> OK.

It will be a bit of a stretch, but it's possible. Most syscalls are
done in linux-next,
I have a few more pending, and only clock_adjtime is really missing now (I had
some earlier patches that I could revive).

My plan was to get that all into 4.20, and then have a conversation about the
actual syscall table changes in 4.21. If we need it for both csky and rv32,
we might just change the generic syscall table that way in 4.21 without
changing all the other ones along with them. I don't want to drag things out
over too many merge windows though, and my plan was to do all architectures
together to simplify the version checks in the libc code to only have to check
for a single version.

 Arnd

Re: [PATCH] KVM: x86: fix failure of injecting exceptions inx86_emulate_instruction

[Paolo Bonzini]

On 21/09/2018 04:08, peng.h...@zte.com.cn wrote:
>>> Unqueued, sorry.  The hypercall test from kvm-unit-tests fails.  A
>>> VMCALL on the "edge" of canonical address space, i.e. at 0x7ffd,
>>> raises a general protection fault before this patch and a double fault
>>> afterwards.
>> Peng Hao submitted a very similar patch[1], the difference being that
>> it also modified x86_emulate_instruction() to ignore the result of
>> inject_emulated_exception().  I have no idea if that change is correct
>> but it may be related to the aforementioned unit test failing.
> The return value of inject_emulated_exception for #PF represents whether in 
> nested vcpu, 
> not about the success or failure. Because we are not in nested vcpu, 
> inject_emulated_exception 
> must return false. And for other exceptions,  inject_emulated_exception just 
> return false. 
> After propagating exceptions to guest, we just should return to guest mode 
> and let guest handle.

Yes, your patch should work, and the x86_emulate_instruction code that
is there now is clearly wrong (though I'm not sure how the double-fault
comes up, #GP + #UD shouldn't generate one because #UD is a benign
exception).

Peng Hao, do you have a testcase?  Eduardo's kvm-unit-tests patch from
Nov 2017 doesn't reproduce the bug anymore for me.

Thanks,

Paolo

Re: [PATCH] KVM: x86: fix failure of injecting exceptions inx86_emulate_instruction

[Paolo Bonzini]

On 21/09/2018 04:08, peng.h...@zte.com.cn wrote:
>>> Unqueued, sorry.  The hypercall test from kvm-unit-tests fails.  A
>>> VMCALL on the "edge" of canonical address space, i.e. at 0x7ffd,
>>> raises a general protection fault before this patch and a double fault
>>> afterwards.
>> Peng Hao submitted a very similar patch[1], the difference being that
>> it also modified x86_emulate_instruction() to ignore the result of
>> inject_emulated_exception().  I have no idea if that change is correct
>> but it may be related to the aforementioned unit test failing.
> The return value of inject_emulated_exception for #PF represents whether in 
> nested vcpu, 
> not about the success or failure. Because we are not in nested vcpu, 
> inject_emulated_exception 
> must return false. And for other exceptions,  inject_emulated_exception just 
> return false. 
> After propagating exceptions to guest, we just should return to guest mode 
> and let guest handle.

Yes, your patch should work, and the x86_emulate_instruction code that
is there now is clearly wrong (though I'm not sure how the double-fault
comes up, #GP + #UD shouldn't generate one because #UD is a benign
exception).

Peng Hao, do you have a testcase?  Eduardo's kvm-unit-tests patch from
Nov 2017 doesn't reproduce the bug anymore for me.

Thanks,

Paolo

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Phil Reid]

G'day Song,

One more comment below.
On 20/09/2018 9:46 PM, Peter Meerwald-Stadler wrote:

On Thu, 20 Sep 2018, Song Qiang wrote:


PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.


comments below



Following functions are available:
  - Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
  - Triggerd buffer measurement.
  - Both i2c and spi interface are supported.
  - Both interrupt and polling measurement is supported, depands on if
the 'interrupts' in DT is declared.

Signed-off-by: Song Qiang 
---
  .../bindings/iio/magnetometer/pni,rm3100.txt  |  57 +++
  .../devicetree/bindings/vendor-prefixes.txt   |   1 +
  MAINTAINERS   |  10 +
  drivers/iio/magnetometer/Kconfig  |  29 ++
  drivers/iio/magnetometer/Makefile |   4 +
  drivers/iio/magnetometer/rm3100-core.c| 399 ++
  drivers/iio/magnetometer/rm3100-i2c.c |  66 +++
  drivers/iio/magnetometer/rm3100-spi.c |  72 
  drivers/iio/magnetometer/rm3100.h |  90 
  9 files changed, 728 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
  create mode 100644 drivers/iio/magnetometer/rm3100-core.c
  create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
  create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
  create mode 100644 drivers/iio/magnetometer/rm3100.h

diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt 
b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
new file mode 100644
index ..d0d2063e943f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,57 @@
+* PNI RM3100 9-axis magnetometer sensor
+
+I2C Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-i2c"
+- reg : the I2C address of the magnetometer
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+  The interrupts can be triggered on rising edges.
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+- pinctrl-*: pinctrl setup for DRDY line.
+
+Example:
+
+rm3100: rm3100@20 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   compatible = "pni,rm3100-i2c";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
+
+SPI Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-spi"
+- reg : address of sensor, usually 0 or 1.
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+  The interrupts can be triggered on rising edges.
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+- pinctrl-*: pinctrl setup for DRDY line, depands on archtechture.


depends
architecture


+
+Example:
+
+rm3100: rm3100@0{
+   compatible = "pni,rm3100-spi";
+   reg = <0>;
+
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41f0b97eb933..5bf3395fe9ae 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -288,6 +288,7 @@ pine64  Pine64
  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
  plathome  Plat'Home Co., Ltd.
  plda  PLDA
+pni PNI
  portwell  Portwell Inc.
  poslabPoslab Technology Co., Ltd.
  powervr   PowerVR (deprecated, use img)
diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..30ee8cf98312 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,16 @@ M: "Rafael J. Wysocki" 
  S:Maintained
  F:drivers/pnp/
  
+PNI RM3100 IIO DRIVER

+M: Song Qiang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100-core.c
+F: drivers/iio/magnetometer/rm3100-i2c.c
+F: drivers/iio/magnetometer/rm3100-spi.c
+F: drivers/iio/magnetometer/rm3100.h
+F: Documentation/devicetree/bindings/iio/magnetometer/rm3100.txt
+
  POSIX CLOCKS and TIMERS
  M:Thomas Gleixner 
  L:linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..f130b866a4fc 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
  - hmc5843_core (core functions)
  - hmc5843_spi (support for HMC5983)
  
+config SENSORS_RM3100

+   tristate
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+   tristate "PNI RM3100 9-Axis Magnetometer (I2C)"
+   depends on I2C
+   select SENSORS_RM3100
+   

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Phil Reid]

G'day Song,

One more comment below.
On 20/09/2018 9:46 PM, Peter Meerwald-Stadler wrote:

On Thu, 20 Sep 2018, Song Qiang wrote:


PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.


comments below



Following functions are available:
  - Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
  - Triggerd buffer measurement.
  - Both i2c and spi interface are supported.
  - Both interrupt and polling measurement is supported, depands on if
the 'interrupts' in DT is declared.

Signed-off-by: Song Qiang 
---
  .../bindings/iio/magnetometer/pni,rm3100.txt  |  57 +++
  .../devicetree/bindings/vendor-prefixes.txt   |   1 +
  MAINTAINERS   |  10 +
  drivers/iio/magnetometer/Kconfig  |  29 ++
  drivers/iio/magnetometer/Makefile |   4 +
  drivers/iio/magnetometer/rm3100-core.c| 399 ++
  drivers/iio/magnetometer/rm3100-i2c.c |  66 +++
  drivers/iio/magnetometer/rm3100-spi.c |  72 
  drivers/iio/magnetometer/rm3100.h |  90 
  9 files changed, 728 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
  create mode 100644 drivers/iio/magnetometer/rm3100-core.c
  create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
  create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
  create mode 100644 drivers/iio/magnetometer/rm3100.h

diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt 
b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
new file mode 100644
index ..d0d2063e943f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,57 @@
+* PNI RM3100 9-axis magnetometer sensor
+
+I2C Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-i2c"
+- reg : the I2C address of the magnetometer
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+  The interrupts can be triggered on rising edges.
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+- pinctrl-*: pinctrl setup for DRDY line.
+
+Example:
+
+rm3100: rm3100@20 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   compatible = "pni,rm3100-i2c";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
+
+SPI Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-spi"
+- reg : address of sensor, usually 0 or 1.
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+  The interrupts can be triggered on rising edges.
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+- pinctrl-*: pinctrl setup for DRDY line, depands on archtechture.


depends
architecture


+
+Example:
+
+rm3100: rm3100@0{
+   compatible = "pni,rm3100-spi";
+   reg = <0>;
+
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41f0b97eb933..5bf3395fe9ae 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -288,6 +288,7 @@ pine64  Pine64
  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
  plathome  Plat'Home Co., Ltd.
  plda  PLDA
+pni PNI
  portwell  Portwell Inc.
  poslabPoslab Technology Co., Ltd.
  powervr   PowerVR (deprecated, use img)
diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..30ee8cf98312 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,16 @@ M: "Rafael J. Wysocki" 
  S:Maintained
  F:drivers/pnp/
  
+PNI RM3100 IIO DRIVER

+M: Song Qiang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100-core.c
+F: drivers/iio/magnetometer/rm3100-i2c.c
+F: drivers/iio/magnetometer/rm3100-spi.c
+F: drivers/iio/magnetometer/rm3100.h
+F: Documentation/devicetree/bindings/iio/magnetometer/rm3100.txt
+
  POSIX CLOCKS and TIMERS
  M:Thomas Gleixner 
  L:linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..f130b866a4fc 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
  - hmc5843_core (core functions)
  - hmc5843_spi (support for HMC5983)
  
+config SENSORS_RM3100

+   tristate
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+   tristate "PNI RM3100 9-Axis Magnetometer (I2C)"
+   depends on I2C
+   select SENSORS_RM3100
+   

Re: [RESEND PATCH] error-injection: remove meaningless null pointer check before debugfs_remove_recursive

[Kees Cook]

On Thu, Sep 20, 2018 at 6:46 PM, zhong jiang  wrote:
> debugfs_remove_recursive has taken the null pointer into account.
> just remove the null check before debugfs_remove_recursive.
>
> Acked-by: Masami Hiramatsu 
> Signed-off-by: zhong jiang 

Acked-by: Kees Cook 

-Kees

> ---
>  kernel/fail_function.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> index bc80a4e..17f75b5 100644
> --- a/kernel/fail_function.c
> +++ b/kernel/fail_function.c
> @@ -173,8 +173,7 @@ static void fei_debugfs_remove_attr(struct fei_attr *attr)
> struct dentry *dir;
>
> dir = debugfs_lookup(attr->kp.symbol_name, fei_debugfs_dir);
> -   if (dir)
> -   debugfs_remove_recursive(dir);
> +   debugfs_remove_recursive(dir);
>  }
>
>  static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
> --
> 1.7.12.4
>



-- 
Kees Cook
Pixel Security

Re: [RESEND PATCH] error-injection: remove meaningless null pointer check before debugfs_remove_recursive

[Kees Cook]

On Thu, Sep 20, 2018 at 6:46 PM, zhong jiang  wrote:
> debugfs_remove_recursive has taken the null pointer into account.
> just remove the null check before debugfs_remove_recursive.
>
> Acked-by: Masami Hiramatsu 
> Signed-off-by: zhong jiang 

Acked-by: Kees Cook 

-Kees

> ---
>  kernel/fail_function.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> index bc80a4e..17f75b5 100644
> --- a/kernel/fail_function.c
> +++ b/kernel/fail_function.c
> @@ -173,8 +173,7 @@ static void fei_debugfs_remove_attr(struct fei_attr *attr)
> struct dentry *dir;
>
> dir = debugfs_lookup(attr->kp.symbol_name, fei_debugfs_dir);
> -   if (dir)
> -   debugfs_remove_recursive(dir);
> +   debugfs_remove_recursive(dir);
>  }
>
>  static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
> --
> 1.7.12.4
>



-- 
Kees Cook
Pixel Security

Penting Pesan

[Administrator]

PERHATIAN;

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0078880
Surat Dukungan Teknis ©2018

terima kasih
Sistem Administrator 

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Penting Pesan

[Administrator]

PERHATIAN;

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0078880
Surat Dukungan Teknis ©2018

terima kasih
Sistem Administrator 

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[PATCH v9 6/7] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845

[Can Guo]

From: Can Guo 

Update the compatible string for UFS QMP PHY on SDM845.

Signed-off-by: Can Guo 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index cef8765..930d94c 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -11,7 +11,8 @@ Required properties:
   "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
   "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy,
   "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
-  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
+  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
+  "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
 
  - reg: offset and length of register set for PHY's common serdes block.
 
@@ -29,6 +30,7 @@ Required properties:
"aux" for phy aux clock,
"ref" for 19.2 MHz ref clk,
"com_aux" for phy common block aux clock,
+   "ref_aux" for phy reference aux clock,
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 6/7] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845

[Can Guo]

From: Can Guo 

Update the compatible string for UFS QMP PHY on SDM845.

Signed-off-by: Can Guo 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index cef8765..930d94c 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -11,7 +11,8 @@ Required properties:
   "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
   "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy,
   "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
-  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
+  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
+  "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
 
  - reg: offset and length of register set for PHY's common serdes block.
 
@@ -29,6 +30,7 @@ Required properties:
"aux" for phy aux clock,
"ref" for 19.2 MHz ref clk,
"com_aux" for phy common block aux clock,
+   "ref_aux" for phy reference aux clock,
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 7/7] dt-bindings: ufshcd-pltfrm: Add core reset string

[Can Guo]

From: Can Guo 

Add core reset support string for UFS.

Signed-off-by: Amit Nischal 
Signed-off-by: Can Guo 
---
 Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index c39dfef..6b697c4 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -11,6 +11,11 @@ Required properties:
  "qcom,ufshc"
 - interrupts: 
 - reg   : 
+- reset : reset specifier pair consists of phandle for the reset 
provider
+  and reset lines used by this controller. It is mandatory 
for
+ QCOM SDM845 platform.
+- reset-names   : reset signal name strings sorted in the same order as the
+ resets property. It is mandatory for QCOM SDM845 platform.
 
 Optional properties:
 - phys  : phandle to UFS PHY node
@@ -64,6 +69,8 @@ Example:
clocks = < 0>, < 0>, < 0>;
clock-names = "core_clk", "ref_clk", "iface_clk";
freq-table-hz = <1 2>, <0 0>, <0 0>;
+   resets = ;
+   reset-names = "core_reset";
phys = <>;
phy-names = "ufsphy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 7/7] dt-bindings: ufshcd-pltfrm: Add core reset string

[Can Guo]

From: Can Guo 

Add core reset support string for UFS.

Signed-off-by: Amit Nischal 
Signed-off-by: Can Guo 
---
 Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index c39dfef..6b697c4 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -11,6 +11,11 @@ Required properties:
  "qcom,ufshc"
 - interrupts: 
 - reg   : 
+- reset : reset specifier pair consists of phandle for the reset 
provider
+  and reset lines used by this controller. It is mandatory 
for
+ QCOM SDM845 platform.
+- reset-names   : reset signal name strings sorted in the same order as the
+ resets property. It is mandatory for QCOM SDM845 platform.
 
 Optional properties:
 - phys  : phandle to UFS PHY node
@@ -64,6 +69,8 @@ Example:
clocks = < 0>, < 0>, < 0>;
clock-names = "core_clk", "ref_clk", "iface_clk";
freq-table-hz = <1 2>, <0 0>, <0 0>;
+   resets = ;
+   reset-names = "core_reset";
phys = <>;
phy-names = "ufsphy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 3/7] phy: Add QMP phy based UFS phy support for sdm845

[Can Guo]

From: Can Guo 

Add UFS PHY support to make SDM845 UFS work with common PHY framework.

Signed-off-by: Can Guo 
Reviewed-by: Evan Green 
Reviewed-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 172 +++-
 drivers/phy/qualcomm/phy-qcom-qmp.h |  15 
 2 files changed, 186 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 9be9754..de7ff18 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -156,6 +156,11 @@ enum qphy_reg_layout {
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
 };
 
+static const unsigned int sdm845_ufsphy_regs_layout[] = {
+   [QPHY_START_CTRL]   = 0x00,
+   [QPHY_PCS_READY_STATUS] = 0x160,
+};
+
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -601,6 +606,83 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_REFGEN_REQ_CONFIG2, 0x60),
 };
 
+static const struct qmp_phy_init_tbl sdm845_ufsphy_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0xd5),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x05),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL1, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL2, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xda),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE1, 0x98),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE1, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE1, 0xc1),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE1, 0x32),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE1, 0x0f),
+
+   /* Rate B */
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x44),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_LVL, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_INTERFACE_MODE, 0x40),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_TERM_BW, 0x5b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_HALF, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_QUARTER, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x81),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x59),
+};
+
+static const struct 

[PATCH v9 3/7] phy: Add QMP phy based UFS phy support for sdm845

[Can Guo]

From: Can Guo 

Add UFS PHY support to make SDM845 UFS work with common PHY framework.

Signed-off-by: Can Guo 
Reviewed-by: Evan Green 
Reviewed-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 172 +++-
 drivers/phy/qualcomm/phy-qcom-qmp.h |  15 
 2 files changed, 186 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 9be9754..de7ff18 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -156,6 +156,11 @@ enum qphy_reg_layout {
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
 };
 
+static const unsigned int sdm845_ufsphy_regs_layout[] = {
+   [QPHY_START_CTRL]   = 0x00,
+   [QPHY_PCS_READY_STATUS] = 0x160,
+};
+
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -601,6 +606,83 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_REFGEN_REQ_CONFIG2, 0x60),
 };
 
+static const struct qmp_phy_init_tbl sdm845_ufsphy_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0xd5),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x05),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL1, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL2, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xda),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE1, 0x98),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE1, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE1, 0xc1),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE1, 0x32),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE1, 0x0f),
+
+   /* Rate B */
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x44),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_LVL, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_INTERFACE_MODE, 0x40),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_TERM_BW, 0x5b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_HALF, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_QUARTER, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x81),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x59),
+};
+
+static const struct 

[PATCH v9 1/7] phy: Update PHY power control sequence

[Can Guo]

From: Can Guo 

All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.

Signed-off-by: Can Guo 
Reviewed-by: Manu Gautam 
Reviewed-by: Vivek Gautam 
Reviewed-by: Evan Green 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..ccb8578 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -935,10 +935,12 @@ static void qcom_qmp_phy_configure(void __iomem *base,
}
 }
 
-static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
+static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 {
+   struct qcom_qmp *qmp = qphy->qmp;
const struct qmp_phy_cfg *cfg = qmp->cfg;
void __iomem *serdes = qmp->serdes;
+   void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
int ret, i;
 
@@ -979,10 +981,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
goto err_rst;
}
 
-   if (cfg->has_phy_com_ctrl)
-   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
-SW_PWRDN);
-
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
 SW_PWRDN);
@@ -1000,6 +998,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
}
 
+   if (cfg->has_phy_com_ctrl)
+   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
+SW_PWRDN);
+   else
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+
/* Serdes configuration */
qcom_qmp_phy_configure(serdes, cfg->regs, cfg->serdes_tbl,
   cfg->serdes_tbl_num);
@@ -1090,7 +1094,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
 
dev_vdbg(qmp->dev, "Initializing QMP phy\n");
 
-   ret = qcom_qmp_phy_com_init(qmp);
+   ret = qcom_qmp_phy_com_init(qphy);
if (ret)
return ret;
 
@@ -1127,7 +1131,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
 * Pull out PHY from POWER DOWN state.
 * This is active low enable signal to power-down PHY.
 */
-   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   if(cfg->type == PHY_TYPE_PCIE)
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
 
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 1/7] phy: Update PHY power control sequence

[Can Guo]

From: Can Guo 

All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.

Signed-off-by: Can Guo 
Reviewed-by: Manu Gautam 
Reviewed-by: Vivek Gautam 
Reviewed-by: Evan Green 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..ccb8578 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -935,10 +935,12 @@ static void qcom_qmp_phy_configure(void __iomem *base,
}
 }
 
-static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
+static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 {
+   struct qcom_qmp *qmp = qphy->qmp;
const struct qmp_phy_cfg *cfg = qmp->cfg;
void __iomem *serdes = qmp->serdes;
+   void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
int ret, i;
 
@@ -979,10 +981,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
goto err_rst;
}
 
-   if (cfg->has_phy_com_ctrl)
-   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
-SW_PWRDN);
-
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
 SW_PWRDN);
@@ -1000,6 +998,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
}
 
+   if (cfg->has_phy_com_ctrl)
+   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
+SW_PWRDN);
+   else
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+
/* Serdes configuration */
qcom_qmp_phy_configure(serdes, cfg->regs, cfg->serdes_tbl,
   cfg->serdes_tbl_num);
@@ -1090,7 +1094,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
 
dev_vdbg(qmp->dev, "Initializing QMP phy\n");
 
-   ret = qcom_qmp_phy_com_init(qmp);
+   ret = qcom_qmp_phy_com_init(qphy);
if (ret)
return ret;
 
@@ -1127,7 +1131,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
 * Pull out PHY from POWER DOWN state.
 * This is active low enable signal to power-down PHY.
 */
-   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   if(cfg->type == PHY_TYPE_PCIE)
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
 
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 2/7] phy: General struct and field cleanup

[Can Guo]

From: Can Guo 

Move MSM8996 specific PHY vreg list struct name to a genernal one as it is
used by all PHYs. Add a specific field to handle dual lane situation.

Signed-off-by: Can Guo 
Reviewed-by: Evan Green 
Reviewed-by: Manu Gautam 
Reviewed-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index ccb8578..9be9754 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -649,6 +649,8 @@ struct qmp_phy_cfg {
 
/* true, if PHY has a separate DP_COM control block */
bool has_phy_dp_com_ctrl;
+   /* true, if PHY has secondary tx/rx lanes to be configured */
+   bool is_dual_lane_phy;
/* Register offset of secondary tx/rx lanes for USB DP combo PHY */
unsigned int tx_b_lane_offset;
unsigned int rx_b_lane_offset;
@@ -758,7 +760,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
 };
 
 /* list of regulators */
-static const char * const msm8996_phy_vreg_l[] = {
+static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
 };
 
@@ -778,8 +780,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_pciephy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_pciephy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = pciephy_regs_layout,
 
.start_ctrl = PCS_START | PLL_READY_GATE_EN,
@@ -809,8 +811,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -870,8 +872,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -883,6 +885,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.pwrdn_delay_max= POWER_DOWN_DELAY_US_MAX,
 
.has_phy_dp_com_ctrl= true,
+   .is_dual_lane_phy   = true,
.tx_b_lane_offset   = 0x400,
.rx_b_lane_offset   = 0x400,
 };
@@ -903,8 +906,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -1116,12 +1119,12 @@ static int qcom_qmp_phy_init(struct phy *phy)
/* Tx, Rx, and PCS configurations */
qcom_qmp_phy_configure(tx, cfg->regs, cfg->tx_tbl, cfg->tx_tbl_num);
/* Configuration for other LANE for USB-DP combo PHY */
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(tx + cfg->tx_b_lane_offset, cfg->regs,
   cfg->tx_tbl, cfg->tx_tbl_num);
 
qcom_qmp_phy_configure(rx, cfg->regs, cfg->rx_tbl, cfg->rx_tbl_num);
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(rx + cfg->rx_b_lane_offset, cfg->regs,
   cfg->rx_tbl, cfg->rx_tbl_num);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a 

[PATCH v9 2/7] phy: General struct and field cleanup

[Can Guo]

From: Can Guo 

Move MSM8996 specific PHY vreg list struct name to a genernal one as it is
used by all PHYs. Add a specific field to handle dual lane situation.

Signed-off-by: Can Guo 
Reviewed-by: Evan Green 
Reviewed-by: Manu Gautam 
Reviewed-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index ccb8578..9be9754 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -649,6 +649,8 @@ struct qmp_phy_cfg {
 
/* true, if PHY has a separate DP_COM control block */
bool has_phy_dp_com_ctrl;
+   /* true, if PHY has secondary tx/rx lanes to be configured */
+   bool is_dual_lane_phy;
/* Register offset of secondary tx/rx lanes for USB DP combo PHY */
unsigned int tx_b_lane_offset;
unsigned int rx_b_lane_offset;
@@ -758,7 +760,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
 };
 
 /* list of regulators */
-static const char * const msm8996_phy_vreg_l[] = {
+static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
 };
 
@@ -778,8 +780,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_pciephy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_pciephy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = pciephy_regs_layout,
 
.start_ctrl = PCS_START | PLL_READY_GATE_EN,
@@ -809,8 +811,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -870,8 +872,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -883,6 +885,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.pwrdn_delay_max= POWER_DOWN_DELAY_US_MAX,
 
.has_phy_dp_com_ctrl= true,
+   .is_dual_lane_phy   = true,
.tx_b_lane_offset   = 0x400,
.rx_b_lane_offset   = 0x400,
 };
@@ -903,8 +906,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -1116,12 +1119,12 @@ static int qcom_qmp_phy_init(struct phy *phy)
/* Tx, Rx, and PCS configurations */
qcom_qmp_phy_configure(tx, cfg->regs, cfg->tx_tbl, cfg->tx_tbl_num);
/* Configuration for other LANE for USB-DP combo PHY */
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(tx + cfg->tx_b_lane_offset, cfg->regs,
   cfg->tx_tbl, cfg->tx_tbl_num);
 
qcom_qmp_phy_configure(rx, cfg->regs, cfg->rx_tbl, cfg->rx_tbl_num);
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(rx + cfg->rx_b_lane_offset, cfg->regs,
   cfg->rx_tbl, cfg->rx_tbl_num);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a 

Re: [PATCH 1/2] device property: Add device_get_bd_address() and fwnode_get_bd_address()

[Greg Kroah-Hartman]

On Thu, Sep 20, 2018 at 03:34:35PM -0700, Matthias Kaehlcke wrote:
> +EXPORT_SYMBOL(fwnode_get_bd_address);

EXPORT_SYMBOL_GPL()?  That matches the majority in this file.

thanks,

greg k-h

Re: [PATCH 1/2] device property: Add device_get_bd_address() and fwnode_get_bd_address()

[Greg Kroah-Hartman]

On Thu, Sep 20, 2018 at 03:34:35PM -0700, Matthias Kaehlcke wrote:
> +EXPORT_SYMBOL(fwnode_get_bd_address);

EXPORT_SYMBOL_GPL()?  That matches the majority in this file.

thanks,

greg k-h

Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765

[Sean Wang]

On Tue, 2018-09-18 at 21:37 -0700, Manivannan Sadhasivam wrote:
> On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote:
> > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote:
> > > On Sat, Sep 8, 2018 at 4:07 AM  wrote:
> > > 
> > > > v2 and changes since v1:
> > > 
> > > I had trouble applying the last patches in the series so I applied
> > > all on an immutable branch (ib-mtk) then merged that into devel
> > > and added a patch on top to fix up some GPIO includes (just sent).
> > > 
> > > Please check the result!
> > > 
> > 
> > Sure, I'll take a look and and test on the devel branch.
> > 
> > On the top, I'll add a fix for the issue recently reported by kbuild
> > test robot about implicit declaration and a new MT6765 driver based
> > on the series.
> >
> 
> Hi Sean,
> 
> Do you have any plans to add support for MT6797?
> 

I personally have no the plan to add support to MT6797 because I have no
the device, but as I knew some of people in mediatek have interest to
add them by volunteers and thus there is no clear schedule. Eventually,
if they're really done, they would be still based on vendor binding not
by generic binding.

> Thanks,
> Mani
> 
> > > Yours,
> > > Linus Walleij
> > 
> > 

Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765

[Sean Wang]

On Tue, 2018-09-18 at 21:37 -0700, Manivannan Sadhasivam wrote:
> On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote:
> > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote:
> > > On Sat, Sep 8, 2018 at 4:07 AM  wrote:
> > > 
> > > > v2 and changes since v1:
> > > 
> > > I had trouble applying the last patches in the series so I applied
> > > all on an immutable branch (ib-mtk) then merged that into devel
> > > and added a patch on top to fix up some GPIO includes (just sent).
> > > 
> > > Please check the result!
> > > 
> > 
> > Sure, I'll take a look and and test on the devel branch.
> > 
> > On the top, I'll add a fix for the issue recently reported by kbuild
> > test robot about implicit declaration and a new MT6765 driver based
> > on the series.
> >
> 
> Hi Sean,
> 
> Do you have any plans to add support for MT6797?
> 

I personally have no the plan to add support to MT6797 because I have no
the device, but as I knew some of people in mediatek have interest to
add them by volunteers and thus there is no clear schedule. Eventually,
if they're really done, they would be still based on vendor binding not
by generic binding.

> Thanks,
> Mani
> 
> > > Yours,
> > > Linus Walleij
> > 
> > 

Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace

[Andy Lutomirski]

> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski  wrote:
> 
> 
> 
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior 
>>  wrote:
>> 
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
 --- a/arch/x86/kernel/fpu/core.c
 +++ b/arch/x86/kernel/fpu/core.c
 @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
 
  kernel_fpu_disable();
 
 -if (fpu->initialized) {
 +__cpu_invalidate_fpregs_state();
 +
 +if (!test_and_set_thread_flag(TIF_LOAD_FPU)) {
>>> 
>>> Since the already-TIF_LOAD_FPU path is supposed to be fast here, use 
>>> test_thread_flag() instead. test_and_set operations do unconditional RMW 
>>> operations and are always full barriers, so they’re slow.
>> okay.
>> 
>>> Also, on top of this patch, there should be lots of cleanups available. In 
>>> particular, all the fpu state accessors could probably be reworked to take 
>>> TIF_LOAD_FPU into account, which would simplify the callers and maybe even 
>>> the mess of variables tracking whether the state is in regs.
>> 
>> Do you refer to the fpu.initilized check or something else?
>> 
> 
> I mean the fpu.initialized variable entirely. AFAIK, its only use is for 
> kernel threads — setting it to false lets us switch to a kernel thread and 
> back without saving and restoring. But TIF_LOAD_FPU should be able to replace 
> it: when we have FPU regs loaded and we switch to *any* thread, kernel or 
> otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.  So we 
> don’t need the special case for kernel threads.
> 
> Which reminds me: if you haven’t already done so, can you add a helper to 
> sanity check the current context?  It should check that the combination of 
> owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or 
> last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is 
> clear, it should warn.  I think that at least switch_fpu_finish should call 
> it.  Arguably switch_fpu_prepare should too, at the beginning.

Looking some more, the “preload” variable needs to go away or be renamed. It 
hasn’t had anything to do with preloading for some time.

Also, the interaction between TIF_LOAD_FPU and FPU emulation needs to be 
documented somewhere.  Probably FPU-less systems should never have TIF_LOAD_FPU 
set.

Or we could decide that no one uses FPU emulation any more.

Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace

[Andy Lutomirski]

> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski  wrote:
> 
> 
> 
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior 
>>  wrote:
>> 
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
 --- a/arch/x86/kernel/fpu/core.c
 +++ b/arch/x86/kernel/fpu/core.c
 @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
 
  kernel_fpu_disable();
 
 -if (fpu->initialized) {
 +__cpu_invalidate_fpregs_state();
 +
 +if (!test_and_set_thread_flag(TIF_LOAD_FPU)) {
>>> 
>>> Since the already-TIF_LOAD_FPU path is supposed to be fast here, use 
>>> test_thread_flag() instead. test_and_set operations do unconditional RMW 
>>> operations and are always full barriers, so they’re slow.
>> okay.
>> 
>>> Also, on top of this patch, there should be lots of cleanups available. In 
>>> particular, all the fpu state accessors could probably be reworked to take 
>>> TIF_LOAD_FPU into account, which would simplify the callers and maybe even 
>>> the mess of variables tracking whether the state is in regs.
>> 
>> Do you refer to the fpu.initilized check or something else?
>> 
> 
> I mean the fpu.initialized variable entirely. AFAIK, its only use is for 
> kernel threads — setting it to false lets us switch to a kernel thread and 
> back without saving and restoring. But TIF_LOAD_FPU should be able to replace 
> it: when we have FPU regs loaded and we switch to *any* thread, kernel or 
> otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.  So we 
> don’t need the special case for kernel threads.
> 
> Which reminds me: if you haven’t already done so, can you add a helper to 
> sanity check the current context?  It should check that the combination of 
> owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or 
> last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is 
> clear, it should warn.  I think that at least switch_fpu_finish should call 
> it.  Arguably switch_fpu_prepare should too, at the beginning.

Looking some more, the “preload” variable needs to go away or be renamed. It 
hasn’t had anything to do with preloading for some time.

Also, the interaction between TIF_LOAD_FPU and FPU emulation needs to be 
documented somewhere.  Probably FPU-less systems should never have TIF_LOAD_FPU 
set.

Or we could decide that no one uses FPU emulation any more.

[PATCH 2/4] pinctrl: mediatek: add no eint function for pin define

[sean.wang]

From: Mars Cheng 

Add NO_EINT_SUPPORT back to pinctrl-mtk-common-v2.h as the alias of
EINT_NA to indicate that some pin not capable of being controlled as eint
and that is required by pinctrl-paris based driver as old
pinctrl-mtk-common.h already had.

Signed-off-by: Mars Cheng 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index b618042..991c1c5 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -19,6 +19,7 @@
 #define MTK_PULLUP 1
 
 #define EINT_NAU16_MAX
+#define NO_EINT_SUPPORTEINT_NA
 
 #define PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs,  \
   _s_bit, _x_bits, _sz_reg, _fixed) {  \
-- 
2.7.4

[PATCH 2/4] pinctrl: mediatek: add no eint function for pin define

[sean.wang]

From: Mars Cheng 

Add NO_EINT_SUPPORT back to pinctrl-mtk-common-v2.h as the alias of
EINT_NA to indicate that some pin not capable of being controlled as eint
and that is required by pinctrl-paris based driver as old
pinctrl-mtk-common.h already had.

Signed-off-by: Mars Cheng 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index b618042..991c1c5 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -19,6 +19,7 @@
 #define MTK_PULLUP 1
 
 #define EINT_NAU16_MAX
+#define NO_EINT_SUPPORTEINT_NA
 
 #define PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs,  \
   _s_bit, _x_bits, _sz_reg, _fixed) {  \
-- 
2.7.4

[PATCH 1/4] pinctrl: mediatek: fix static checker warning caused by EINT_NA

[sean.wang]

From: Sean Wang 

EINT_NA is an u16 number, so it should be U16_MAX instead of -1
to fix up drivers/pinctrl/mediatek/pinctrl-paris.c:732 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

Also happens in
drivers/pinctrl/mediatek/pinctrl-paris.c:749 mtk_gpio_set_config()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

drivers/pinctrl/mediatek/pinctrl-moore.c:479 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

drivers/pinctrl/mediatek/pinctrl-moore.c:496 mtk_gpio_set_config()
warn: impossible condition '(desc->eint.eint_n == -1) => (0-u16max == (-1))

Fixes: 6561859b067f ("pinctrl: mediatek: add eint support to MT8183 pinctrl 
driver")
Reported-by: Dan Carpenter 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 10d33ec..b618042 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -18,7 +18,7 @@
 #define MTK_PULLDOWN   0
 #define MTK_PULLUP 1
 
-#define EINT_NA-1
+#define EINT_NAU16_MAX
 
 #define PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs,  \
   _s_bit, _x_bits, _sz_reg, _fixed) {  \
-- 
2.7.4

[PATCH 3/4] pinctrl: mediatek: add MT6765 pinctrl driver

[sean.wang]

From: ZH Chen 

Add MT6765 pinctrl driver based on MediaTek pinctrl-paris core.

Signed-off-by: Mars Cheng 
Signed-off-by: ZH Chen 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt6765.c | 1100 
 drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h | 1754 +
 4 files changed, 2862 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt6765.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 1cd5502..05be5dd 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -69,6 +69,13 @@ config PINCTRL_MT2712
default ARM64 && ARCH_MEDIATEK
select PINCTRL_MTK
 
+config PINCTRL_MT6765
+   bool "Mediatek MT6765 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   default ARM64 && ARCH_MEDIATEK
+   select PINCTRL_MTK_PARIS
+
 config PINCTRL_MT7622
bool "MediaTek MT7622 pin control"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index 871e0e2..70d8000 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PINCTRL_MT2701)  += pinctrl-mt2701.o
 obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
+obj-$(CONFIG_PINCTRL_MT6765)   += pinctrl-mt6765.o
 obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
 obj-$(CONFIG_PINCTRL_MT7623)   += pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c 
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
new file mode 100644
index 000..1cae634
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -0,0 +1,1100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: ZH Chen 
+ *
+ */
+
+#include "pinctrl-mtk-mt6765.h"
+#include "pinctrl-paris.h"
+
+/* MT6765 have multiple bases to program pin configuration listed as the below:
+ * iocfg[0]:0x10005000, iocfg[1]:0x10002C00, iocfg[2]:0x10002800,
+ * iocfg[3]:0x10002A00, iocfg[4]:0x10002000, iocfg[5]:0x10002200,
+ * iocfg[6]:0x10002500, iocfg[7]:0x10002600.
+ * _i_base could be used to indicate what base the pin should be mapped into.
+ */
+
+#define PIN_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit, 
_x_bits)\
+   PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,  
\
+  _x_bits, 32, 0)
+
+#define PINS_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit, 
_x_bits)   \
+   PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,  
\
+ _x_bits, 32, 1)
+
+static const struct mtk_pin_field_calc mt6765_pin_mode_range[] = {
+   PIN_FIELD(0, 202, 0x300, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_dir_range[] = {
+   PIN_FIELD(0, 202, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_di_range[] = {
+   PIN_FIELD(0, 202, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_do_range[] = {
+   PIN_FIELD(0, 202, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_smt_range[] = {
+   PINS_FIELD_BASE(0, 3, 2, 0x00b0, 0x10, 4, 1),
+   PINS_FIELD_BASE(4, 7, 2, 0x00b0, 0x10, 5, 1),
+   PIN_FIELD_BASE(8, 8, 3, 0x0080, 0x10, 3, 1),
+   PINS_FIELD_BASE(9, 11, 2, 0x00b0, 0x10, 6, 1),
+   PIN_FIELD_BASE(12, 12, 5, 0x0060, 0x10, 9, 1),
+   PINS_FIELD_BASE(13, 16, 6, 0x00b0, 0x10, 10, 1),
+   PINS_FIELD_BASE(17, 20, 6, 0x00b0, 0x10, 8, 1),
+   PINS_FIELD_BASE(21, 24, 6, 0x00b0, 0x10, 9, 1),
+   PINS_FIELD_BASE(25, 28, 6, 0x00b0, 0x10, 7, 1),
+   PIN_FIELD_BASE(29, 29, 6, 0x00b0, 0x10, 0, 1),
+   PIN_FIELD_BASE(30, 30, 6, 0x00b0, 0x10, 1, 1),
+   PINS_FIELD_BASE(31, 34, 6, 0x00b0, 0x10, 2, 1),
+   PINS_FIELD_BASE(35, 36, 6, 0x00b0, 0x10, 5, 1),
+   PIN_FIELD_BASE(37, 37, 6, 0x00b0, 0x10, 6, 1),
+   PIN_FIELD_BASE(38, 38, 6, 0x00b0, 0x10, 4, 1),
+   PINS_FIELD_BASE(39, 40, 6, 0x00b0, 0x10, 3, 1),
+   PINS_FIELD_BASE(41, 42, 7, 0x00c0, 0x10, 6, 1),
+   PIN_FIELD_BASE(43, 43, 7, 0x00c0, 0x10, 3, 1),
+   PIN_FIELD_BASE(44, 44, 7, 0x00c0, 0x10, 4, 1),
+   PIN_FIELD_BASE(45, 45, 7, 0x00c0, 0x10, 8, 1),
+   PINS_FIELD_BASE(46, 47, 7, 0x00c0, 0x10, 7, 1),
+   PIN_FIELD_BASE(48, 48, 7, 0x00c0, 0x10, 15, 1),
+   PIN_FIELD_BASE(49, 49, 7, 0x00c0, 0x10, 17, 1),
+   PIN_FIELD_BASE(50, 50, 7, 0x00c0, 0x10, 14, 1),
+   PIN_FIELD_BASE(51, 51, 7, 0x00c0, 0x10, 16, 1),
+   PINS_FIELD_BASE(52, 57, 7, 0x00c0, 0x10, 0, 1),
+   

[PATCH 1/4] pinctrl: mediatek: fix static checker warning caused by EINT_NA

[sean.wang]

From: Sean Wang 

EINT_NA is an u16 number, so it should be U16_MAX instead of -1
to fix up drivers/pinctrl/mediatek/pinctrl-paris.c:732 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

Also happens in
drivers/pinctrl/mediatek/pinctrl-paris.c:749 mtk_gpio_set_config()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

drivers/pinctrl/mediatek/pinctrl-moore.c:479 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))

drivers/pinctrl/mediatek/pinctrl-moore.c:496 mtk_gpio_set_config()
warn: impossible condition '(desc->eint.eint_n == -1) => (0-u16max == (-1))

Fixes: 6561859b067f ("pinctrl: mediatek: add eint support to MT8183 pinctrl 
driver")
Reported-by: Dan Carpenter 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 10d33ec..b618042 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -18,7 +18,7 @@
 #define MTK_PULLDOWN   0
 #define MTK_PULLUP 1
 
-#define EINT_NA-1
+#define EINT_NAU16_MAX
 
 #define PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs,  \
   _s_bit, _x_bits, _sz_reg, _fixed) {  \
-- 
2.7.4

[PATCH 3/4] pinctrl: mediatek: add MT6765 pinctrl driver

[sean.wang]

From: ZH Chen 

Add MT6765 pinctrl driver based on MediaTek pinctrl-paris core.

Signed-off-by: Mars Cheng 
Signed-off-by: ZH Chen 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt6765.c | 1100 
 drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h | 1754 +
 4 files changed, 2862 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt6765.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 1cd5502..05be5dd 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -69,6 +69,13 @@ config PINCTRL_MT2712
default ARM64 && ARCH_MEDIATEK
select PINCTRL_MTK
 
+config PINCTRL_MT6765
+   bool "Mediatek MT6765 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   default ARM64 && ARCH_MEDIATEK
+   select PINCTRL_MTK_PARIS
+
 config PINCTRL_MT7622
bool "MediaTek MT7622 pin control"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index 871e0e2..70d8000 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PINCTRL_MT2701)  += pinctrl-mt2701.o
 obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
+obj-$(CONFIG_PINCTRL_MT6765)   += pinctrl-mt6765.o
 obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
 obj-$(CONFIG_PINCTRL_MT7623)   += pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c 
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
new file mode 100644
index 000..1cae634
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -0,0 +1,1100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: ZH Chen 
+ *
+ */
+
+#include "pinctrl-mtk-mt6765.h"
+#include "pinctrl-paris.h"
+
+/* MT6765 have multiple bases to program pin configuration listed as the below:
+ * iocfg[0]:0x10005000, iocfg[1]:0x10002C00, iocfg[2]:0x10002800,
+ * iocfg[3]:0x10002A00, iocfg[4]:0x10002000, iocfg[5]:0x10002200,
+ * iocfg[6]:0x10002500, iocfg[7]:0x10002600.
+ * _i_base could be used to indicate what base the pin should be mapped into.
+ */
+
+#define PIN_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit, 
_x_bits)\
+   PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,  
\
+  _x_bits, 32, 0)
+
+#define PINS_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit, 
_x_bits)   \
+   PIN_FIELD_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,  
\
+ _x_bits, 32, 1)
+
+static const struct mtk_pin_field_calc mt6765_pin_mode_range[] = {
+   PIN_FIELD(0, 202, 0x300, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_dir_range[] = {
+   PIN_FIELD(0, 202, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_di_range[] = {
+   PIN_FIELD(0, 202, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_do_range[] = {
+   PIN_FIELD(0, 202, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt6765_pin_smt_range[] = {
+   PINS_FIELD_BASE(0, 3, 2, 0x00b0, 0x10, 4, 1),
+   PINS_FIELD_BASE(4, 7, 2, 0x00b0, 0x10, 5, 1),
+   PIN_FIELD_BASE(8, 8, 3, 0x0080, 0x10, 3, 1),
+   PINS_FIELD_BASE(9, 11, 2, 0x00b0, 0x10, 6, 1),
+   PIN_FIELD_BASE(12, 12, 5, 0x0060, 0x10, 9, 1),
+   PINS_FIELD_BASE(13, 16, 6, 0x00b0, 0x10, 10, 1),
+   PINS_FIELD_BASE(17, 20, 6, 0x00b0, 0x10, 8, 1),
+   PINS_FIELD_BASE(21, 24, 6, 0x00b0, 0x10, 9, 1),
+   PINS_FIELD_BASE(25, 28, 6, 0x00b0, 0x10, 7, 1),
+   PIN_FIELD_BASE(29, 29, 6, 0x00b0, 0x10, 0, 1),
+   PIN_FIELD_BASE(30, 30, 6, 0x00b0, 0x10, 1, 1),
+   PINS_FIELD_BASE(31, 34, 6, 0x00b0, 0x10, 2, 1),
+   PINS_FIELD_BASE(35, 36, 6, 0x00b0, 0x10, 5, 1),
+   PIN_FIELD_BASE(37, 37, 6, 0x00b0, 0x10, 6, 1),
+   PIN_FIELD_BASE(38, 38, 6, 0x00b0, 0x10, 4, 1),
+   PINS_FIELD_BASE(39, 40, 6, 0x00b0, 0x10, 3, 1),
+   PINS_FIELD_BASE(41, 42, 7, 0x00c0, 0x10, 6, 1),
+   PIN_FIELD_BASE(43, 43, 7, 0x00c0, 0x10, 3, 1),
+   PIN_FIELD_BASE(44, 44, 7, 0x00c0, 0x10, 4, 1),
+   PIN_FIELD_BASE(45, 45, 7, 0x00c0, 0x10, 8, 1),
+   PINS_FIELD_BASE(46, 47, 7, 0x00c0, 0x10, 7, 1),
+   PIN_FIELD_BASE(48, 48, 7, 0x00c0, 0x10, 15, 1),
+   PIN_FIELD_BASE(49, 49, 7, 0x00c0, 0x10, 17, 1),
+   PIN_FIELD_BASE(50, 50, 7, 0x00c0, 0x10, 14, 1),
+   PIN_FIELD_BASE(51, 51, 7, 0x00c0, 0x10, 16, 1),
+   PINS_FIELD_BASE(52, 57, 7, 0x00c0, 0x10, 0, 1),
+   

[PATCH 4/4] pinctrl: mediatek: add eint support to MT6765 pinctrl driver

[sean.wang]

From: Mars Cheng 

Just add eint support to MT6765 pinctrl driver as usual as
happens on the other SoCs.

Signed-off-by: Mars Cheng 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mt6765.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c 
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index 1cae634..32451e8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1056,11 +1056,19 @@ static const char * const 
mt6765_pinctrl_register_base_names[] = {
"iocfg6", "iocfg7",
 };
 
+static const struct mtk_eint_hw mt6765_eint_hw = {
+   .port_mask = 7,
+   .ports = 6,
+   .ap_num= 160,
+   .db_cnt= 13,
+};
+
 static const struct mtk_pin_soc mt6765_data = {
.reg_cal = mt6765_reg_cals,
.pins = mtk_pins_mt6765,
.npins = ARRAY_SIZE(mtk_pins_mt6765),
.ngrps = ARRAY_SIZE(mtk_pins_mt6765),
+   .eint_hw = _eint_hw,
.gpio_m = 0,
.ies_present = true,
.base_names = mt6765_pinctrl_register_base_names,
-- 
2.7.4

[PATCH 4/4] pinctrl: mediatek: add eint support to MT6765 pinctrl driver

[sean.wang]

From: Mars Cheng 

Just add eint support to MT6765 pinctrl driver as usual as
happens on the other SoCs.

Signed-off-by: Mars Cheng 
Signed-off-by: Sean Wang 
---
 drivers/pinctrl/mediatek/pinctrl-mt6765.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c 
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index 1cae634..32451e8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1056,11 +1056,19 @@ static const char * const 
mt6765_pinctrl_register_base_names[] = {
"iocfg6", "iocfg7",
 };
 
+static const struct mtk_eint_hw mt6765_eint_hw = {
+   .port_mask = 7,
+   .ports = 6,
+   .ap_num= 160,
+   .db_cnt= 13,
+};
+
 static const struct mtk_pin_soc mt6765_data = {
.reg_cal = mt6765_reg_cals,
.pins = mtk_pins_mt6765,
.npins = ARRAY_SIZE(mtk_pins_mt6765),
.ngrps = ARRAY_SIZE(mtk_pins_mt6765),
+   .eint_hw = _eint_hw,
.gpio_m = 0,
.ies_present = true,
.base_names = mt6765_pinctrl_register_base_names,
-- 
2.7.4

Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace

[Andy Lutomirski]

> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior 
>  wrote:
> 
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>> 
>>>   kernel_fpu_disable();
>>> 
>>> -if (fpu->initialized) {
>>> +__cpu_invalidate_fpregs_state();
>>> +
>>> +if (!test_and_set_thread_flag(TIF_LOAD_FPU)) {
>> 
>> Since the already-TIF_LOAD_FPU path is supposed to be fast here, use 
>> test_thread_flag() instead. test_and_set operations do unconditional RMW 
>> operations and are always full barriers, so they’re slow.
> okay.
> 
>> Also, on top of this patch, there should be lots of cleanups available. In 
>> particular, all the fpu state accessors could probably be reworked to take 
>> TIF_LOAD_FPU into account, which would simplify the callers and maybe even 
>> the mess of variables tracking whether the state is in regs.
> 
> Do you refer to the fpu.initilized check or something else?
> 

I mean the fpu.initialized variable entirely. AFAIK, its only use is for kernel 
threads — setting it to false lets us switch to a kernel thread and back 
without saving and restoring. But TIF_LOAD_FPU should be able to replace it: 
when we have FPU regs loaded and we switch to *any* thread, kernel or 
otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.  So we don’t 
need the special case for kernel threads.

Which reminds me: if you haven’t already done so, can you add a helper to 
sanity check the current context?  It should check that the combination of 
owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or 
last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is 
clear, it should warn.  I think that at least switch_fpu_finish should call it. 
 Arguably switch_fpu_prepare should too, at the beginning.

Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace

[Andy Lutomirski]

> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior 
>  wrote:
> 
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>> 
>>>   kernel_fpu_disable();
>>> 
>>> -if (fpu->initialized) {
>>> +__cpu_invalidate_fpregs_state();
>>> +
>>> +if (!test_and_set_thread_flag(TIF_LOAD_FPU)) {
>> 
>> Since the already-TIF_LOAD_FPU path is supposed to be fast here, use 
>> test_thread_flag() instead. test_and_set operations do unconditional RMW 
>> operations and are always full barriers, so they’re slow.
> okay.
> 
>> Also, on top of this patch, there should be lots of cleanups available. In 
>> particular, all the fpu state accessors could probably be reworked to take 
>> TIF_LOAD_FPU into account, which would simplify the callers and maybe even 
>> the mess of variables tracking whether the state is in regs.
> 
> Do you refer to the fpu.initilized check or something else?
> 

I mean the fpu.initialized variable entirely. AFAIK, its only use is for kernel 
threads — setting it to false lets us switch to a kernel thread and back 
without saving and restoring. But TIF_LOAD_FPU should be able to replace it: 
when we have FPU regs loaded and we switch to *any* thread, kernel or 
otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.  So we don’t 
need the special case for kernel threads.

Which reminds me: if you haven’t already done so, can you add a helper to 
sanity check the current context?  It should check that the combination of 
owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or 
last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is 
clear, it should warn.  I think that at least switch_fpu_finish should call it. 
 Arguably switch_fpu_prepare should too, at the beginning.

Re: [PATCH] Driver core: add bus_find_device_by_of_node

[Silesh C V]

Hello Rafael,

On Thu, Sep 20, 2018 at 1:06 PM Rafael J. Wysocki  wrote:
>
> On Thu, Sep 20, 2018 at 7:43 AM Silesh C V  wrote:
> >
> > Similar to bus_find_device_by_name, but finds the device having a
> > specific of_node.
>
> First, what do you need it for?  Please describe your use case in the 
> changelog.

This will be useful for drivers that do not register a platform_driver
(but retrieve the "simple-bus" device_node using
of_find_compatible_node etc.) but are still interested in the struct
device.

>
> Second, what about a more generic bus_find_device_by_fwnode() ?

If you think that the above requirement warrants the inclusion of
bus_find_device_by_of_node, I can try implementing this in v2.

Thanks.

Regards,
Silesh

Re: [PATCH] Driver core: add bus_find_device_by_of_node

[Silesh C V]

Hello Rafael,

On Thu, Sep 20, 2018 at 1:06 PM Rafael J. Wysocki  wrote:
>
> On Thu, Sep 20, 2018 at 7:43 AM Silesh C V  wrote:
> >
> > Similar to bus_find_device_by_name, but finds the device having a
> > specific of_node.
>
> First, what do you need it for?  Please describe your use case in the 
> changelog.

This will be useful for drivers that do not register a platform_driver
(but retrieve the "simple-bus" device_node using
of_find_compatible_node etc.) but are still interested in the struct
device.

>
> Second, what about a more generic bus_find_device_by_fwnode() ?

If you think that the above requirement warrants the inclusion of
bus_find_device_by_of_node, I can try implementing this in v2.

Thanks.

Regards,
Silesh

Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler

[Joel Stanley]

On Fri, 21 Sep 2018 at 06:39, Tao Ren  wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij"  wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij 
>
> Thank you Linus for the quick review!
>
> > Sorry for any cargo-cult programming on my part :/
> > Would be nice to get a nod from the AST2400 users that this works
> > for them too, so included them in the To: field.
>
> Make sense. I actually booted up kernel on qemu-palmetto (ast2400) but I'm 
> doubting if test is valid because it depends on how qemu emulates the 
> hardware. It would be great if someone can help to verify the patch on 
> physical ast2400.

I gave this a spin on the ast2400. It looked okay, but I was wondering
if you could share you test case so I can run the same test?

Cheers,

Joel

Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler

[Joel Stanley]

On Fri, 21 Sep 2018 at 06:39, Tao Ren  wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij"  wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij 
>
> Thank you Linus for the quick review!
>
> > Sorry for any cargo-cult programming on my part :/
> > Would be nice to get a nod from the AST2400 users that this works
> > for them too, so included them in the To: field.
>
> Make sense. I actually booted up kernel on qemu-palmetto (ast2400) but I'm 
> doubting if test is valid because it depends on how qemu emulates the 
> hardware. It would be great if someone can help to verify the patch on 
> physical ast2400.

I gave this a spin on the ast2400. It looked okay, but I was wondering
if you could share you test case so I can run the same test?

Cheers,

Joel

Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek and Pavel,

On 11 September 2018 at 10:47, Baolin Wang  wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can write 'pattern' file to enable the software pattern
> which alters the brightness for the specified duration with one
> software timer.
>
> Moreover consumers can write 'hw_pattern' file to enable the hardware
> pattern for some LED controllers which can autonomously control
> brightness over time, according to some preprogrammed hardware
> patterns.
>
> Signed-off-by: Raphael Teysseyre 
> Signed-off-by: Baolin Wang 
> ---
> Changes from v11:
>  - Change -1 means repeat indefinitely.
>
> Changes from v10:
>  - Change 'int' to 'u32' for delta_t field.
>
> Changes from v9:
>  - None.
>
> Changes from v8:
>  - None.
>
> Changes from v7:
>  - Move the SC27XX hardware patterns description into its own ABI file.
>
> Changes from v6:
>  - Improve commit message.
>  - Optimize the description of the hw_pattern file.
>  - Simplify some logics.
>
> Changes from v5:
>  - Add one 'hw_pattern' file for hardware patterns.
>
> Changes from v4:
>  - Change the repeat file to return the originally written number.
>  - Improve comments.
>  - Fix some build warnings.
>
> Changes from v3:
>  - Reset pattern number to 0 if user provides incorrect pattern string.
>  - Support one pattern.
>
> Changes from v2:
>  - Remove hardware_pattern boolen.
>  - Chnage the pattern string format.
>
> Changes from v1:
>  - Use ATTRIBUTE_GROUPS() to define attributes.
>  - Introduce hardware_pattern flag to determine if software pattern
>  or hardware pattern.
>  - Re-implement pattern_trig_store_pattern() function.
>  - Remove pattern_get() interface.
>  - Improve comments.
>  - Other small optimization.
> ---

Do you have any comments for the v12 patch set? Thanks.

-- 
Baolin Wang
Best Regards

Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek and Pavel,

On 11 September 2018 at 10:47, Baolin Wang  wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can write 'pattern' file to enable the software pattern
> which alters the brightness for the specified duration with one
> software timer.
>
> Moreover consumers can write 'hw_pattern' file to enable the hardware
> pattern for some LED controllers which can autonomously control
> brightness over time, according to some preprogrammed hardware
> patterns.
>
> Signed-off-by: Raphael Teysseyre 
> Signed-off-by: Baolin Wang 
> ---
> Changes from v11:
>  - Change -1 means repeat indefinitely.
>
> Changes from v10:
>  - Change 'int' to 'u32' for delta_t field.
>
> Changes from v9:
>  - None.
>
> Changes from v8:
>  - None.
>
> Changes from v7:
>  - Move the SC27XX hardware patterns description into its own ABI file.
>
> Changes from v6:
>  - Improve commit message.
>  - Optimize the description of the hw_pattern file.
>  - Simplify some logics.
>
> Changes from v5:
>  - Add one 'hw_pattern' file for hardware patterns.
>
> Changes from v4:
>  - Change the repeat file to return the originally written number.
>  - Improve comments.
>  - Fix some build warnings.
>
> Changes from v3:
>  - Reset pattern number to 0 if user provides incorrect pattern string.
>  - Support one pattern.
>
> Changes from v2:
>  - Remove hardware_pattern boolen.
>  - Chnage the pattern string format.
>
> Changes from v1:
>  - Use ATTRIBUTE_GROUPS() to define attributes.
>  - Introduce hardware_pattern flag to determine if software pattern
>  or hardware pattern.
>  - Re-implement pattern_trig_store_pattern() function.
>  - Remove pattern_get() interface.
>  - Improve comments.
>  - Other small optimization.
> ---

Do you have any comments for the v12 patch set? Thanks.

-- 
Baolin Wang
Best Regards

Re: [PATCH 6/7] mm/gup: Combine parameters into struct

[kbuild test robot]

Hi Keith,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc4 next-20180919]
[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/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: arm-oxnas_v6_defconfig (attached as .config)
compiler: arm-linux-gnueabi-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
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
   mm/gup.c: In function 'follow_pmd_mask':
>> mm/gup.c:233:34: error: macro "follow_huge_pd" passed 5 arguments, but takes 
>> just 3
  ctx->flags, PGDIR_SHIFT);
 ^
>> mm/gup.c:231:10: error: 'follow_huge_pd' undeclared (first use in this 
>> function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   mm/gup.c:231:10: note: each undeclared identifier is reported only once for 
each function it appears in
>> mm/gup.c:257:28: error: passing argument 1 of 'follow_devmap_pmd' from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  page = follow_devmap_pmd(ctx, pmd);
   ^~~
   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:344:28: note: expected 'struct gup_context *' but 
argument is of type 'struct follow_page_context *'
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
   ^
   mm/gup.c: In function 'follow_pud_mask':
   mm/gup.c:333:32: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, PUD_SHIFT);
   ^
   mm/gup.c:331:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
>> mm/gup.c:340:28: error: passing argument 1 of 'follow_devmap_pud' from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  page = follow_devmap_pud(ctx, pud);
   ^~~
   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:349:28: note: expected 'struct gup_context *' but 
argument is of type 'struct follow_page_context *'
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
   ^
   mm/gup.c: In function 'follow_p4d_mask':
   mm/gup.c:366:32: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, P4D_SHIFT);
   ^
   mm/gup.c:364:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   mm/gup.c: In function 'follow_page_mask':
   mm/gup.c:414:34: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, PGDIR_SHIFT);
 ^
   mm/gup.c:412:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   cc1: some warnings being treated as errors

vim +/follow_huge_pd +233 mm/gup.c

   208  
   209  static struct page *follow_pmd_mask(struct follow_page_context *ctx, 
pud_t *pudp)
   210  {
   211  pmd_t *pmd, pmdval;
   212  spinlock_t *ptl;
   213  struct page *page;
   214  struct mm_struct *mm = ctx->vma->vm_mm;
   215  
   216  pmd =

Re: [PATCH 6/7] mm/gup: Combine parameters into struct

[kbuild test robot]

Hi Keith,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc4 next-20180919]
[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/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: arm-oxnas_v6_defconfig (attached as .config)
compiler: arm-linux-gnueabi-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
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
   mm/gup.c: In function 'follow_pmd_mask':
>> mm/gup.c:233:34: error: macro "follow_huge_pd" passed 5 arguments, but takes 
>> just 3
  ctx->flags, PGDIR_SHIFT);
 ^
>> mm/gup.c:231:10: error: 'follow_huge_pd' undeclared (first use in this 
>> function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   mm/gup.c:231:10: note: each undeclared identifier is reported only once for 
each function it appears in
>> mm/gup.c:257:28: error: passing argument 1 of 'follow_devmap_pmd' from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  page = follow_devmap_pmd(ctx, pmd);
   ^~~
   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:344:28: note: expected 'struct gup_context *' but 
argument is of type 'struct follow_page_context *'
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
   ^
   mm/gup.c: In function 'follow_pud_mask':
   mm/gup.c:333:32: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, PUD_SHIFT);
   ^
   mm/gup.c:331:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
>> mm/gup.c:340:28: error: passing argument 1 of 'follow_devmap_pud' from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  page = follow_devmap_pud(ctx, pud);
   ^~~
   In file included from include/linux/mm.h:506:0,
from mm/gup.c:6:
   include/linux/huge_mm.h:349:28: note: expected 'struct gup_context *' but 
argument is of type 'struct follow_page_context *'
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
   ^
   mm/gup.c: In function 'follow_p4d_mask':
   mm/gup.c:366:32: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, P4D_SHIFT);
   ^
   mm/gup.c:364:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   mm/gup.c: In function 'follow_page_mask':
   mm/gup.c:414:34: error: macro "follow_huge_pd" passed 5 arguments, but takes 
just 3
  ctx->flags, PGDIR_SHIFT);
 ^
   mm/gup.c:412:10: error: 'follow_huge_pd' undeclared (first use in this 
function); did you mean 'follow_page_pte'?
  page = follow_huge_pd(ctx->vma, ctx->address,
 ^~
 follow_page_pte
   cc1: some warnings being treated as errors

vim +/follow_huge_pd +233 mm/gup.c

   208  
   209  static struct page *follow_pmd_mask(struct follow_page_context *ctx, 
pud_t *pudp)
   210  {
   211  pmd_t *pmd, pmdval;
   212  spinlock_t *ptl;
   213  struct page *page;
   214  struct mm_struct *mm = ctx->vma->vm_mm;
   215  
   216  pmd =

Re: [PATCH 6/7] mm/gup: Combine parameters into struct

[kbuild test robot]

Hi Keith,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc4 next-20180920]
[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/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: sh-rsk7201_defconfig (attached as .config)
compiler: sh4-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
GCC_VERSION=7.2.0 make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   In file included from include/linux/mm.h:506:0,
from arch/sh/kernel/asm-offsets.c:14:
>> include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
--
   In file included from include/linux/mm.h:506:0,
from arch/sh/kernel/asm-offsets.c:14:
>> include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
   :1317:2: warning: #warning syscall pkey_mprotect not implemented 
[-Wcpp]
   :1320:2: warning: #warning syscall pkey_alloc not implemented [-Wcpp]
   :1323:2: warning: #warning syscall pkey_free not implemented [-Wcpp]
   :1326:2: warning: #warning syscall statx not implemented [-Wcpp]
   :1332:2: warning: #warning syscall io_pgetevents not implemented 
[-Wcpp]
   :1335:2: warning: #warning syscall rseq not implemented [-Wcpp]

vim +344 include/linux/huge_mm.h

   343  
 > 344  static inline struct page *follow_devmap_pmd(struct gup_context *ctx, 
 > pmd_t *pmd)
   345  {
   346  return NULL;
   347  }
   348  

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


.config.gz
Description: application/gzip

Re: [PATCH 6/7] mm/gup: Combine parameters into struct

[kbuild test robot]

Hi Keith,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc4 next-20180920]
[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/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: sh-rsk7201_defconfig (attached as .config)
compiler: sh4-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
GCC_VERSION=7.2.0 make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   In file included from include/linux/mm.h:506:0,
from arch/sh/kernel/asm-offsets.c:14:
>> include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
--
   In file included from include/linux/mm.h:506:0,
from arch/sh/kernel/asm-offsets.c:14:
>> include/linux/huge_mm.h:344:53: warning: 'struct gup_context' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
static inline struct page *follow_devmap_pmd(struct gup_context *ctx, pmd_t 
*pmd)
^~~
   include/linux/huge_mm.h:349:53: warning: 'struct gup_context' declared 
inside parameter list will not be visible outside of this definition or 
declaration
static inline struct page *follow_devmap_pud(struct gup_context *ctx, pud_t 
*pud)
^~~
   :1317:2: warning: #warning syscall pkey_mprotect not implemented 
[-Wcpp]
   :1320:2: warning: #warning syscall pkey_alloc not implemented [-Wcpp]
   :1323:2: warning: #warning syscall pkey_free not implemented [-Wcpp]
   :1326:2: warning: #warning syscall statx not implemented [-Wcpp]
   :1332:2: warning: #warning syscall io_pgetevents not implemented 
[-Wcpp]
   :1335:2: warning: #warning syscall rseq not implemented [-Wcpp]

vim +344 include/linux/huge_mm.h

   343  
 > 344  static inline struct page *follow_devmap_pmd(struct gup_context *ctx, 
 > pmd_t *pmd)
   345  {
   346  return NULL;
   347  }
   348  

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


.config.gz
Description: application/gzip

Re: Code of Conduct: Let's revamp it.

[unixing]

On Friday, September 21, 2018 1:48 AM, Rik van Riel  wrote:

> On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
>
> > I think there are important differences between code to be run by
> > CPUs
> > and a Code to be run by humans. And when the author goes on a
> > victory
> > lap on Twitter and declares the Code to be "a political document",
> > is
> > it any surprise I'm worried?
>
> Speaking for myself, I expect there will be occasional
> impedance mismatches in communication between people
> from different cultures, and people with different
> neurotypes.
>
> That is not only expected, it is also perfectly fine.
>
> If people end up feeling like they are in conflict
> with each other, and they would like help resolving
> it, the first task of the TAB will be to mediate,
> and help people figure out how communication could
> be improved.
>
> The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the
> Linux community.
>
> Mediation is not about telling people what to do,
> but about asking the people involved what they would
> like to see, and helping to breach the gap between
> their styles of communication.
>
> As an aside, the TAB has no power to remove anyone
> from the community. Patches are applied by maintainers,
> mailing lists are run by their administrators.
>
> The only things the TAB can do is mediate and advise.

That couldn't be more wrong. The existence of a TAB itself
is the problem. The community will be pushed to behave
according to what TAB expects to, otherwise the person will
be shamed and could even have their job jeopardized.
The world currently is walking towards a culture where everyone claimed to be 
oppressed becomes a mini dictator that can force,
shame, offend. I borrow the words of a wise man who's no longer
alive: “All of it began the first time some of you who know
bettet... let young people think that they had the right to
choose the laws they would obey as long as they were doing it in
the name of social protest.”
I'm using a phony e-mail because I don't feel "job-wise" safe to
criticize this culture, as the punishment is to lose job, end
career, end social life, etc.

I ask our fellows linuxers to not allow this culture to take over
our community. If the current code of conflict isn't working, let's
create a new one, politically NEUTRAL, and without any set of people
with power to dictate the behavior of thousands of engineers. Linux
is NOT a hostile place to work. According to this culture, I am a
minority, coming from third world country who found on Linux
community (since kernel 2.4) a very good source of knowledge and
freedom.

Kind regards,

Unixing

Re: Code of Conduct: Let's revamp it.

[unixing]

On Friday, September 21, 2018 1:48 AM, Rik van Riel  wrote:

> On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
>
> > I think there are important differences between code to be run by
> > CPUs
> > and a Code to be run by humans. And when the author goes on a
> > victory
> > lap on Twitter and declares the Code to be "a political document",
> > is
> > it any surprise I'm worried?
>
> Speaking for myself, I expect there will be occasional
> impedance mismatches in communication between people
> from different cultures, and people with different
> neurotypes.
>
> That is not only expected, it is also perfectly fine.
>
> If people end up feeling like they are in conflict
> with each other, and they would like help resolving
> it, the first task of the TAB will be to mediate,
> and help people figure out how communication could
> be improved.
>
> The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the
> Linux community.
>
> Mediation is not about telling people what to do,
> but about asking the people involved what they would
> like to see, and helping to breach the gap between
> their styles of communication.
>
> As an aside, the TAB has no power to remove anyone
> from the community. Patches are applied by maintainers,
> mailing lists are run by their administrators.
>
> The only things the TAB can do is mediate and advise.

That couldn't be more wrong. The existence of a TAB itself
is the problem. The community will be pushed to behave
according to what TAB expects to, otherwise the person will
be shamed and could even have their job jeopardized.
The world currently is walking towards a culture where everyone claimed to be 
oppressed becomes a mini dictator that can force,
shame, offend. I borrow the words of a wise man who's no longer
alive: “All of it began the first time some of you who know
bettet... let young people think that they had the right to
choose the laws they would obey as long as they were doing it in
the name of social protest.”
I'm using a phony e-mail because I don't feel "job-wise" safe to
criticize this culture, as the punishment is to lose job, end
career, end social life, etc.

I ask our fellows linuxers to not allow this culture to take over
our community. If the current code of conflict isn't working, let's
create a new one, politically NEUTRAL, and without any set of people
with power to dictate the behavior of thousands of engineers. Linux
is NOT a hostile place to work. According to this culture, I am a
minority, coming from third world country who found on Linux
community (since kernel 2.4) a very good source of knowledge and
freedom.

Kind regards,

Unixing

Re: [PATCH v6 4/5] seccomp: add support for passing fds via USER_NOTIF

[Andy Lutomirski]

On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen  wrote:
>
> On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > On Wed, Sep 19, 2018 at 7:38 AM, Tycho Andersen  wrote:
> > > On Wed, Sep 19, 2018 at 07:19:56AM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > On Sep 19, 2018, at 2:55 AM, Tycho Andersen  wrote:
> > >> >
> > >> >> On Wed, Sep 12, 2018 at 04:52:38PM -0700, Andy Lutomirski wrote:
> > >> >>> On Thu, Sep 6, 2018 at 8:28 AM, Tycho Andersen  
> > >> >>> wrote:
> > >> >>> The idea here is that the userspace handler should be able to pass 
> > >> >>> an fd
> > >> >>> back to the trapped task, for example so it can be returned from 
> > >> >>> socket().
> > >> >>>
> > >> >>> I've proposed one API here, but I'm open to other options. In 
> > >> >>> particular,
> > >> >>> this only lets you return an fd from a syscall, which may not be 
> > >> >>> enough in
> > >> >>> all cases. For example, if an fd is written to an output parameter 
> > >> >>> instead
> > >> >>> of returned, the current API can't handle this. Another case is that
> > >> >>> netlink takes as input fds sometimes (IFLA_NET_NS_FD, e.g.). If 
> > >> >>> netlink
> > >> >>> ever decides to install an fd and output it, we wouldn't be able to 
> > >> >>> handle
> > >> >>> this either.
> > >> >>
> > >> >> An alternative could be to have an API (an ioctl on the listener,
> > >> >> perhaps) that just copies an fd into the tracee.  There would be the
> > >> >> obvious set of options: do we replace an existing fd or allocate a new
> > >> >> one, and is it CLOEXEC.  Then the tracer could add an fd and then
> > >> >> return it just like it's a regular number.
> > >> >>
> > >> >> I feel like this would be more flexible and conceptually simpler, but
> > >> >> maybe a little slower for the common cases.  What do you think?
> > >> >
> > >> > I'm just implementing this now, and there's one question: when do we
> > >> > actually do the fd install? Should we do it when the user calls
> > >> > SECCOMP_NOTIF_PUT_FD, or when the actual response is sent? It feels
> > >> > like we should do it when the response is sent, instead of doing it
> > >> > right when SECCOMP_NOTIF_PUT_FD is called, since if there's a
> > >> > subsequent signal and the tracer decides to discard the response,
> > >> > we'll have to implement some delete mechanism to delete the fd, but it
> > >> > would have already been visible to the process, etc. So I'll go
> > >> > forward with this unless there are strong objections, but I thought
> > >> > I'd point it out just to avoid another round trip.
> > >> >
> > >> >
> > >>
> > >> Can you do that non-racily?  That is, you need to commit to an fd 
> > >> *number* right away, but what if another thread uses the number before 
> > >> you actually install the fd?
> > >
> > > I was thinking we could just do an __alloc_fd() and then do the
> > > fd_install() when the response is sent or clean up the case that the
> > > listener or task dies. I haven't actually tried to run the code yet,
> > > so it's possible the locking won't work :)
> >
> > I would be very surprised if the locking works.  How can you run a
> > thread in a process when another thread has allocated but not
> > installed an fd and is blocked for an arbitrarily long time?
>
> I think the trick is that there's no actual locking required (except
> for a brief locking of task->files). I've run the patch below and it
> seems to work. But perhaps that's abusing __alloc_fd a little too
> hard, I don't really know.
>

Hmm.  This makes me highly nervous.  If nothing else, what releases
the busy-but-not-open fd if the whole process aborts?

> > >
> > >> Do we really allow non-“kill” signals to interrupt the whole process?  
> > >> It might be the case that we don’t really need to clean up from signals 
> > >> if there’s a guarantee that the thread dies.
> > >
> > > Yes, we do, because of this: https://lkml.org/lkml/2018/3/15/1122
> > >
> >
> > I'm still not sure I see the problem.  Suppose I'm implementing a user
> > notifier for a nasty syscall like recvmsg().  If I'm the tracer, by
> > the time I decide to install an fd, I've committed to returning
> > something other than -EINTR, even if a non-fatal signal is sent before
> > I finish.  No rollback should be necessary.
>
> I don't understand why this is true. Surely you could stop a handler
> on receipt of a new signal, and have it do something else entirely?

I think you *could*, but I'm not sure why you would.  In general,
syscalls never execute signal handlers mid-syscall.  There is a very
small number of syscalls that use sys_restart_syscall(), but I don't
think any of them allocate fds, and I'm not sure we need or want to
support them with user notifiers.  The rest of the syscalls will, if
they're behaving correct, either do *something* (like reading some or
all of a buffer) and return success or they'll do nothing and return
-EINTR.  Or they return an -ERESTARTSYS variant.  And then, only
*after* the syscall 

Re: [PATCH v6 4/5] seccomp: add support for passing fds via USER_NOTIF

[Andy Lutomirski]

On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen  wrote:
>
> On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > On Wed, Sep 19, 2018 at 7:38 AM, Tycho Andersen  wrote:
> > > On Wed, Sep 19, 2018 at 07:19:56AM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > On Sep 19, 2018, at 2:55 AM, Tycho Andersen  wrote:
> > >> >
> > >> >> On Wed, Sep 12, 2018 at 04:52:38PM -0700, Andy Lutomirski wrote:
> > >> >>> On Thu, Sep 6, 2018 at 8:28 AM, Tycho Andersen  
> > >> >>> wrote:
> > >> >>> The idea here is that the userspace handler should be able to pass 
> > >> >>> an fd
> > >> >>> back to the trapped task, for example so it can be returned from 
> > >> >>> socket().
> > >> >>>
> > >> >>> I've proposed one API here, but I'm open to other options. In 
> > >> >>> particular,
> > >> >>> this only lets you return an fd from a syscall, which may not be 
> > >> >>> enough in
> > >> >>> all cases. For example, if an fd is written to an output parameter 
> > >> >>> instead
> > >> >>> of returned, the current API can't handle this. Another case is that
> > >> >>> netlink takes as input fds sometimes (IFLA_NET_NS_FD, e.g.). If 
> > >> >>> netlink
> > >> >>> ever decides to install an fd and output it, we wouldn't be able to 
> > >> >>> handle
> > >> >>> this either.
> > >> >>
> > >> >> An alternative could be to have an API (an ioctl on the listener,
> > >> >> perhaps) that just copies an fd into the tracee.  There would be the
> > >> >> obvious set of options: do we replace an existing fd or allocate a new
> > >> >> one, and is it CLOEXEC.  Then the tracer could add an fd and then
> > >> >> return it just like it's a regular number.
> > >> >>
> > >> >> I feel like this would be more flexible and conceptually simpler, but
> > >> >> maybe a little slower for the common cases.  What do you think?
> > >> >
> > >> > I'm just implementing this now, and there's one question: when do we
> > >> > actually do the fd install? Should we do it when the user calls
> > >> > SECCOMP_NOTIF_PUT_FD, or when the actual response is sent? It feels
> > >> > like we should do it when the response is sent, instead of doing it
> > >> > right when SECCOMP_NOTIF_PUT_FD is called, since if there's a
> > >> > subsequent signal and the tracer decides to discard the response,
> > >> > we'll have to implement some delete mechanism to delete the fd, but it
> > >> > would have already been visible to the process, etc. So I'll go
> > >> > forward with this unless there are strong objections, but I thought
> > >> > I'd point it out just to avoid another round trip.
> > >> >
> > >> >
> > >>
> > >> Can you do that non-racily?  That is, you need to commit to an fd 
> > >> *number* right away, but what if another thread uses the number before 
> > >> you actually install the fd?
> > >
> > > I was thinking we could just do an __alloc_fd() and then do the
> > > fd_install() when the response is sent or clean up the case that the
> > > listener or task dies. I haven't actually tried to run the code yet,
> > > so it's possible the locking won't work :)
> >
> > I would be very surprised if the locking works.  How can you run a
> > thread in a process when another thread has allocated but not
> > installed an fd and is blocked for an arbitrarily long time?
>
> I think the trick is that there's no actual locking required (except
> for a brief locking of task->files). I've run the patch below and it
> seems to work. But perhaps that's abusing __alloc_fd a little too
> hard, I don't really know.
>

Hmm.  This makes me highly nervous.  If nothing else, what releases
the busy-but-not-open fd if the whole process aborts?

> > >
> > >> Do we really allow non-“kill” signals to interrupt the whole process?  
> > >> It might be the case that we don’t really need to clean up from signals 
> > >> if there’s a guarantee that the thread dies.
> > >
> > > Yes, we do, because of this: https://lkml.org/lkml/2018/3/15/1122
> > >
> >
> > I'm still not sure I see the problem.  Suppose I'm implementing a user
> > notifier for a nasty syscall like recvmsg().  If I'm the tracer, by
> > the time I decide to install an fd, I've committed to returning
> > something other than -EINTR, even if a non-fatal signal is sent before
> > I finish.  No rollback should be necessary.
>
> I don't understand why this is true. Surely you could stop a handler
> on receipt of a new signal, and have it do something else entirely?

I think you *could*, but I'm not sure why you would.  In general,
syscalls never execute signal handlers mid-syscall.  There is a very
small number of syscalls that use sys_restart_syscall(), but I don't
think any of them allocate fds, and I'm not sure we need or want to
support them with user notifiers.  The rest of the syscalls will, if
they're behaving correct, either do *something* (like reading some or
all of a buffer) and return success or they'll do nothing and return
-EINTR.  Or they return an -ERESTARTSYS variant.  And then, only
*after* the syscall 

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Phil Reid]

On 20/09/2018 9:13 PM, Song Qiang wrote:

PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.



In the subject: Isn't the RM3100 a 3axis mag.
The 9axis bit comes when you combine it with an accel / gryo I think.

... snip


+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,57 @@
+* PNI RM3100 9-axis magnetometer sensor
+
+I2C Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-i2c"
+- reg : the I2C address of the magnetometer
+


... snip


+SPI Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-spi"
+- reg : address of sensor, usually 0 or 1.
+


Looking at other drivers supporting i2c / spi.
They use the same compatible for both.

eg: see iio/accel/adxl345_*.c

and it's binding doc:

Required properties:
 - compatible : should be "adi,adxl345"
 - reg : the I2C address or SPI chip select number of the sensor

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Phil Reid]

On 20/09/2018 9:13 PM, Song Qiang wrote:

PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.



In the subject: Isn't the RM3100 a 3axis mag.
The 9axis bit comes when you combine it with an accel / gryo I think.

... snip


+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,57 @@
+* PNI RM3100 9-axis magnetometer sensor
+
+I2C Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-i2c"
+- reg : the I2C address of the magnetometer
+


... snip


+SPI Bus:
+
+Required properties:
+
+- compatible : should be "pni,rm3100-spi"
+- reg : address of sensor, usually 0 or 1.
+


Looking at other drivers supporting i2c / spi.
They use the same compatible for both.

eg: see iio/accel/adxl345_*.c

and it's binding doc:

Required properties:
 - compatible : should be "adi,adxl345"
 - reg : the I2C address or SPI chip select number of the sensor

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

[Baoquan He]

On 09/12/18 at 08:31am, Ingo Molnar wrote:
> Would you like to work on this? These would be really nice additions, once 
> the code is cleaned 
> up to be maintainable and the pending bug fixes you have are merged.
> 
> In terms of patch logistics I'd suggest this ordering:
> 
>  - documentation fixes
>  - simple cleanups
>  - fixes
>  - enhancements

Sorry, there were some RHEL kernel issues last week, so started this
since yesterday. I have sent out documentation fixes as you suggested in
the first patch series. Next is simple cleanup.

> 
> With no more than ~5 patches sent in a series. Feel free to integrate all 
> pending 
> boot-memory-map fixes and features as well, we'll figure out the right way to 
> do them as they 
> happen - but let's start with the simple stuff first, ok?
> 

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

[Baoquan He]

On 09/12/18 at 08:31am, Ingo Molnar wrote:
> Would you like to work on this? These would be really nice additions, once 
> the code is cleaned 
> up to be maintainable and the pending bug fixes you have are merged.
> 
> In terms of patch logistics I'd suggest this ordering:
> 
>  - documentation fixes
>  - simple cleanups
>  - fixes
>  - enhancements

Sorry, there were some RHEL kernel issues last week, so started this
since yesterday. I have sent out documentation fixes as you suggested in
the first patch series. Next is simple cleanup.

> 
> With no more than ~5 patches sent in a series. Feel free to integrate all 
> pending 
> boot-memory-map fixes and features as well, we'll figure out the right way to 
> do them as they 
> happen - but let's start with the simple stuff first, ok?
> 

YOUR REPLY IS NEEDED

[Hama Diallo]

--
Greetings,

I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.

Mr. Hama Diallo
--

YOUR REPLY IS NEEDED

[Hama Diallo]

--
Greetings,

I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.

Mr. Hama Diallo
--

Re: [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization

[Kees Cook]

On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
 wrote:
> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler  
>>> wrote:
 On 9/20/2018 9:23 AM, Kees Cook wrote:
>  config LSM_ORDER
>   string "Default initialization order of builtin LSMs"
> - default "yama,loadpin,integrity"
> + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor"
 If I want to compile all the major modules into my kernel and use
 AppArmor by default would I use

 default "yama,loadpin,integrity,apparmor,selinux,smack,tomoyo"

 or

 default "yama,loadpin,integrity,apparmor"
>>> I was expecting the former, but the latter will have the same result.
>
> t find having the two be equivalent violates expectations. At least
> when considering the end goal of full/extreme stacking, its trivially
> the same with current major lsms being exclusive

This mixes "enablement" with "ordering", though, and I think the past
threads have shown this to be largely problematic.

However, with CONFIG_LSM_ENABLED, we get the effect you're looking for, IIUC.

 When we have "blob-sharing" how could I compile in tomoyo,
 but exclude it without a boot line option?
>>> Ooh, yes, this series has no way to do that. Perhaps
>>> CONFIG_LSM_DISABLE in the same form as CONFIG_LSM_ORDER? I would
>>> totally remove LoadPin's CONFIG for this in favor it.
>>
>> I would generally prefer an optional CONFIG_LSM_ENABLE to
>> CONFIG_LSM_DISABLE, but I understand the logic behind your
>> approach. I would be looking for something like
>>
> +1 on the CONFIG_LSM_ENABLE ove DISABLE
>
>> CONFIG LSM_ENABLE
>>   string "Default set of enabled LSMs"
>>   default ""
>>
>> as opposed to
>>
>> CONFIG LSM_DISABLE
>>   string "Default set of disabled LSMs"
>>   default ""
>>
>> where an empty string is interpreted as "use 'em all"
>> in either case.

Yes, I like CONFIG_LSM_ENABLE if "empty" means "enable all". Should
CONFIG_LSM_ENABLE replace all the other CONFIG-based LSM
enabling/disabling?

 When we have full stacking, how could I compile in selinux
 but exclude it?
>>> Yup, same problem. Same suggested solution?
>>>
>>> Should lsm.enable/disable= also become a comma-separated list, or
>>> should I leave it as a multi-instance thing like I have it?
>>
>> I prefer the multi-instance
>>   lsm.disable=selinux lsm.disable=yama
>> to the list
>>   lsm.disable=selinux,yama
>>
>> but at this point I don't really care all that much.
>
> the comma separated list however is consistent with what is being
> done for default order

Yeah, and it would match the new CONFIG_LSM_ENABLE.

FWIW, it was tedious to type "lsm.enable" and "lsm.disable" over and
over when doing testing, so I almost prefer the comma separated list
at the end of the day. I'll ponder this a bit.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization

[Kees Cook]

On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
 wrote:
> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler  
>>> wrote:
 On 9/20/2018 9:23 AM, Kees Cook wrote:
>  config LSM_ORDER
>   string "Default initialization order of builtin LSMs"
> - default "yama,loadpin,integrity"
> + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor"
 If I want to compile all the major modules into my kernel and use
 AppArmor by default would I use

 default "yama,loadpin,integrity,apparmor,selinux,smack,tomoyo"

 or

 default "yama,loadpin,integrity,apparmor"
>>> I was expecting the former, but the latter will have the same result.
>
> t find having the two be equivalent violates expectations. At least
> when considering the end goal of full/extreme stacking, its trivially
> the same with current major lsms being exclusive

This mixes "enablement" with "ordering", though, and I think the past
threads have shown this to be largely problematic.

However, with CONFIG_LSM_ENABLED, we get the effect you're looking for, IIUC.

 When we have "blob-sharing" how could I compile in tomoyo,
 but exclude it without a boot line option?
>>> Ooh, yes, this series has no way to do that. Perhaps
>>> CONFIG_LSM_DISABLE in the same form as CONFIG_LSM_ORDER? I would
>>> totally remove LoadPin's CONFIG for this in favor it.
>>
>> I would generally prefer an optional CONFIG_LSM_ENABLE to
>> CONFIG_LSM_DISABLE, but I understand the logic behind your
>> approach. I would be looking for something like
>>
> +1 on the CONFIG_LSM_ENABLE ove DISABLE
>
>> CONFIG LSM_ENABLE
>>   string "Default set of enabled LSMs"
>>   default ""
>>
>> as opposed to
>>
>> CONFIG LSM_DISABLE
>>   string "Default set of disabled LSMs"
>>   default ""
>>
>> where an empty string is interpreted as "use 'em all"
>> in either case.

Yes, I like CONFIG_LSM_ENABLE if "empty" means "enable all". Should
CONFIG_LSM_ENABLE replace all the other CONFIG-based LSM
enabling/disabling?

 When we have full stacking, how could I compile in selinux
 but exclude it?
>>> Yup, same problem. Same suggested solution?
>>>
>>> Should lsm.enable/disable= also become a comma-separated list, or
>>> should I leave it as a multi-instance thing like I have it?
>>
>> I prefer the multi-instance
>>   lsm.disable=selinux lsm.disable=yama
>> to the list
>>   lsm.disable=selinux,yama
>>
>> but at this point I don't really care all that much.
>
> the comma separated list however is consistent with what is being
> done for default order

Yeah, and it would match the new CONFIG_LSM_ENABLE.

FWIW, it was tedious to type "lsm.enable" and "lsm.disable" over and
over when doing testing, so I almost prefer the comma separated list
at the end of the day. I'll ponder this a bit.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] gpiolib: Show correct direction from the beginning

[Timur Tabi]

On 9/20/18 5:36 PM, Linus Walleij wrote:

What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.

Whether it makes sense semantically is a different debate, but it
seems possible to reintroduce calling .get_direction() without
hurting anyone.


That means that all the logic for checking valid_mask needs to be added 
to the chip driver's .get_direction() function.  We can add that logic 
to msm_gpio_get_direction (at one point, I had a patch that did that, 
but it was rejected).


My concern is: what if a driver depends on a .request call being made 
(in order to configure muxes, for example) before touching the hardware?


I wonder if this is something that really should be handled in the 
driver's .probe function.  The driver should collect that information 
and pass it to add_data.

Re: [PATCH] gpiolib: Show correct direction from the beginning

[Timur Tabi]

On 9/20/18 5:36 PM, Linus Walleij wrote:

What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.

Whether it makes sense semantically is a different debate, but it
seems possible to reintroduce calling .get_direction() without
hurting anyone.


That means that all the logic for checking valid_mask needs to be added 
to the chip driver's .get_direction() function.  We can add that logic 
to msm_gpio_get_direction (at one point, I had a patch that did that, 
but it was rejected).


My concern is: what if a driver depends on a .request call being made 
(in order to configure muxes, for example) before touching the hardware?


I wonder if this is something that really should be handled in the 
driver's .probe function.  The driver should collect that information 
and pass it to add_data.

[PATCH -next] pinctrl: sunxi: fix 'pctrl->functions' allocation in sunxi_pinctrl_build_state

[YueHaibing]

fixes following Smatch static check warning:

 ./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state()
 warn: passing devm_ allocated variable to kfree. 'pctrl->functions'

As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there, devm_kzalloc() shouldn't be used with
the allocation in the first place.  Fix the warning by calling kcalloc()
and managing the free procedure in error path on our own.

Fixes: 0e37f88d9ad8 ("ARM: sunxi: Add pinctrl driver for Allwinner SoCs")
Signed-off-by: YueHaibing 
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 3ccbe22..213a5d5 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -1079,10 +1079,9 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 * We suppose that we won't have any more functions than pins,
 * we'll reallocate that later anyway
 */
-   pctl->functions = devm_kcalloc(>dev,
-  pctl->ngroups,
-  sizeof(*pctl->functions),
-  GFP_KERNEL);
+   pctl->functions = kcalloc(pctl->ngroups,
+ sizeof(*pctl->functions),
+ GFP_KERNEL);
if (!pctl->functions)
return -ENOMEM;
 
@@ -1133,8 +1132,10 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 
func_item = sunxi_pinctrl_find_function_by_name(pctl,

func->name);
-   if (!func_item)
+   if (!func_item) {
+   kfree(pctl->functions);
return -EINVAL;
+   }
 
if (!func_item->groups) {
func_item->groups =
@@ -1142,8 +1143,10 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 func_item->ngroups,
 sizeof(*func_item->groups),
 GFP_KERNEL);
-   if (!func_item->groups)
+   if (!func_item->groups) {
+   kfree(pctl->functions);
return -ENOMEM;
+   }
}
 
func_grp = func_item->groups;
-- 
2.7.0

[PATCH -next] pinctrl: sunxi: fix 'pctrl->functions' allocation in sunxi_pinctrl_build_state

[YueHaibing]

fixes following Smatch static check warning:

 ./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state()
 warn: passing devm_ allocated variable to kfree. 'pctrl->functions'

As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there, devm_kzalloc() shouldn't be used with
the allocation in the first place.  Fix the warning by calling kcalloc()
and managing the free procedure in error path on our own.

Fixes: 0e37f88d9ad8 ("ARM: sunxi: Add pinctrl driver for Allwinner SoCs")
Signed-off-by: YueHaibing 
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 3ccbe22..213a5d5 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -1079,10 +1079,9 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 * We suppose that we won't have any more functions than pins,
 * we'll reallocate that later anyway
 */
-   pctl->functions = devm_kcalloc(>dev,
-  pctl->ngroups,
-  sizeof(*pctl->functions),
-  GFP_KERNEL);
+   pctl->functions = kcalloc(pctl->ngroups,
+ sizeof(*pctl->functions),
+ GFP_KERNEL);
if (!pctl->functions)
return -ENOMEM;
 
@@ -1133,8 +1132,10 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 
func_item = sunxi_pinctrl_find_function_by_name(pctl,

func->name);
-   if (!func_item)
+   if (!func_item) {
+   kfree(pctl->functions);
return -EINVAL;
+   }
 
if (!func_item->groups) {
func_item->groups =
@@ -1142,8 +1143,10 @@ static int sunxi_pinctrl_build_state(struct 
platform_device *pdev)
 func_item->ngroups,
 sizeof(*func_item->groups),
 GFP_KERNEL);
-   if (!func_item->groups)
+   if (!func_item->groups) {
+   kfree(pctl->functions);
return -ENOMEM;
+   }
}
 
func_grp = func_item->groups;
-- 
2.7.0

Applied "regulator: da905{2,5}: Remove unnecessary array check" to the regulator tree

[Mark Brown]

The patch

   regulator: da905{2,5}: Remove unnecessary array check

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5a7d7d0f9f791b1e13f26dbbb07c86482912ad62 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor 
Date: Thu, 20 Sep 2018 17:04:20 -0700
Subject: [PATCH] regulator: da905{2,5}: Remove unnecessary array check

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/regulator/da9052-regulator.c:423:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (pdata && pdata->regulators) {
  ~~ ~~~^~
drivers/regulator/da9055-regulator.c:615:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (pdata && pdata->regulators) {
  ~~ ~~~^~

Link: https://github.com/ClangBuiltLinux/linux/issues/142
Signed-off-by: Nathan Chancellor 
Signed-off-by: Mark Brown 
---
 drivers/regulator/da9052-regulator.c | 2 +-
 drivers/regulator/da9055-regulator.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/da9052-regulator.c 
b/drivers/regulator/da9052-regulator.c
index 9ececfef42d6..37e4025203e3 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -420,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device 
*pdev)
config.dev = >dev;
config.driver_data = regulator;
config.regmap = da9052->regmap;
-   if (pdata && pdata->regulators) {
+   if (pdata) {
config.init_data = pdata->regulators[cell->id];
} else {
 #ifdef CONFIG_OF
diff --git a/drivers/regulator/da9055-regulator.c 
b/drivers/regulator/da9055-regulator.c
index f40c3b8644ae..588c3d2445cf 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -612,7 +612,7 @@ static int da9055_regulator_probe(struct platform_device 
*pdev)
config.driver_data = regulator;
config.regmap = da9055->regmap;
 
-   if (pdata && pdata->regulators) {
+   if (pdata) {
config.init_data = pdata->regulators[pdev->id];
} else {
ret = da9055_regulator_dt_init(pdev, regulator, ,
-- 
2.19.0

Applied "spi: pic32: Use proper enum in dmaengine_prep_slave_rg" to the spi tree

[Mark Brown]

The patch

   spi: pic32: Use proper enum in dmaengine_prep_slave_rg

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 8cfde7847d5ed0bb77bace41519572963e43cd17 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor 
Date: Thu, 20 Sep 2018 16:13:37 -0700
Subject: [PATCH] spi: pic32: Use proper enum in dmaengine_prep_slave_rg

Clang warns when one enumerated type is converted implicitly to another:

drivers/spi/spi-pic32.c:323:8: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
  DMA_FROM_DEVICE,
  ^~~
drivers/spi/spi-pic32.c:333:8: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
  DMA_TO_DEVICE,
  ^
2 warnings generated.

Use the proper enums from dma_transfer_direction (DMA_FROM_DEVICE =
DMA_DEV_TO_MEM = 2, DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1) to satify Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/159
Signed-off-by: Nathan Chancellor 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-pic32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pic32.c b/drivers/spi/spi-pic32.c
index 46ff76193ee1..131849adc570 100644
--- a/drivers/spi/spi-pic32.c
+++ b/drivers/spi/spi-pic32.c
@@ -320,7 +320,7 @@ static int pic32_spi_dma_transfer(struct pic32_spi *pic32s,
desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
  xfer->rx_sg.sgl,
  xfer->rx_sg.nents,
- DMA_FROM_DEVICE,
+ DMA_DEV_TO_MEM,
  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc_rx) {
ret = -EINVAL;
@@ -330,7 +330,7 @@ static int pic32_spi_dma_transfer(struct pic32_spi *pic32s,
desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
  xfer->tx_sg.sgl,
  xfer->tx_sg.nents,
- DMA_TO_DEVICE,
+ DMA_MEM_TO_DEV,
  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc_tx) {
ret = -EINVAL;
-- 
2.19.0

Applied "regulator: da905{2,5}: Remove unnecessary array check" to the regulator tree

[Mark Brown]

The patch

   regulator: da905{2,5}: Remove unnecessary array check

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5a7d7d0f9f791b1e13f26dbbb07c86482912ad62 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor 
Date: Thu, 20 Sep 2018 17:04:20 -0700
Subject: [PATCH] regulator: da905{2,5}: Remove unnecessary array check

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/regulator/da9052-regulator.c:423:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (pdata && pdata->regulators) {
  ~~ ~~~^~
drivers/regulator/da9055-regulator.c:615:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (pdata && pdata->regulators) {
  ~~ ~~~^~

Link: https://github.com/ClangBuiltLinux/linux/issues/142
Signed-off-by: Nathan Chancellor 
Signed-off-by: Mark Brown 
---
 drivers/regulator/da9052-regulator.c | 2 +-
 drivers/regulator/da9055-regulator.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/da9052-regulator.c 
b/drivers/regulator/da9052-regulator.c
index 9ececfef42d6..37e4025203e3 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -420,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device 
*pdev)
config.dev = >dev;
config.driver_data = regulator;
config.regmap = da9052->regmap;
-   if (pdata && pdata->regulators) {
+   if (pdata) {
config.init_data = pdata->regulators[cell->id];
} else {
 #ifdef CONFIG_OF
diff --git a/drivers/regulator/da9055-regulator.c 
b/drivers/regulator/da9055-regulator.c
index f40c3b8644ae..588c3d2445cf 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -612,7 +612,7 @@ static int da9055_regulator_probe(struct platform_device 
*pdev)
config.driver_data = regulator;
config.regmap = da9055->regmap;
 
-   if (pdata && pdata->regulators) {
+   if (pdata) {
config.init_data = pdata->regulators[pdev->id];
} else {
ret = da9055_regulator_dt_init(pdev, regulator, ,
-- 
2.19.0

Applied "spi: pic32: Use proper enum in dmaengine_prep_slave_rg" to the spi tree

[Mark Brown]

The patch

   spi: pic32: Use proper enum in dmaengine_prep_slave_rg

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 8cfde7847d5ed0bb77bace41519572963e43cd17 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor 
Date: Thu, 20 Sep 2018 16:13:37 -0700
Subject: [PATCH] spi: pic32: Use proper enum in dmaengine_prep_slave_rg

Clang warns when one enumerated type is converted implicitly to another:

drivers/spi/spi-pic32.c:323:8: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
  DMA_FROM_DEVICE,
  ^~~
drivers/spi/spi-pic32.c:333:8: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
  DMA_TO_DEVICE,
  ^
2 warnings generated.

Use the proper enums from dma_transfer_direction (DMA_FROM_DEVICE =
DMA_DEV_TO_MEM = 2, DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1) to satify Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/159
Signed-off-by: Nathan Chancellor 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-pic32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pic32.c b/drivers/spi/spi-pic32.c
index 46ff76193ee1..131849adc570 100644
--- a/drivers/spi/spi-pic32.c
+++ b/drivers/spi/spi-pic32.c
@@ -320,7 +320,7 @@ static int pic32_spi_dma_transfer(struct pic32_spi *pic32s,
desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
  xfer->rx_sg.sgl,
  xfer->rx_sg.nents,
- DMA_FROM_DEVICE,
+ DMA_DEV_TO_MEM,
  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc_rx) {
ret = -EINVAL;
@@ -330,7 +330,7 @@ static int pic32_spi_dma_transfer(struct pic32_spi *pic32s,
desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
  xfer->tx_sg.sgl,
  xfer->tx_sg.nents,
- DMA_TO_DEVICE,
+ DMA_MEM_TO_DEV,
  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc_tx) {
ret = -EINVAL;
-- 
2.19.0

[RESEND PATCH] error-injection: remove meaningless null pointer check before debugfs_remove_recursive

[zhong jiang]

debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.

Acked-by: Masami Hiramatsu 
Signed-off-by: zhong jiang 
---
 kernel/fail_function.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/fail_function.c b/kernel/fail_function.c
index bc80a4e..17f75b5 100644
--- a/kernel/fail_function.c
+++ b/kernel/fail_function.c
@@ -173,8 +173,7 @@ static void fei_debugfs_remove_attr(struct fei_attr *attr)
struct dentry *dir;
 
dir = debugfs_lookup(attr->kp.symbol_name, fei_debugfs_dir);
-   if (dir)
-   debugfs_remove_recursive(dir);
+   debugfs_remove_recursive(dir);
 }
 
 static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
-- 
1.7.12.4

[RESEND PATCH] error-injection: remove meaningless null pointer check before debugfs_remove_recursive

[zhong jiang]

debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.

Acked-by: Masami Hiramatsu 
Signed-off-by: zhong jiang 
---
 kernel/fail_function.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/fail_function.c b/kernel/fail_function.c
index bc80a4e..17f75b5 100644
--- a/kernel/fail_function.c
+++ b/kernel/fail_function.c
@@ -173,8 +173,7 @@ static void fei_debugfs_remove_attr(struct fei_attr *attr)
struct dentry *dir;
 
dir = debugfs_lookup(attr->kp.symbol_name, fei_debugfs_dir);
-   if (dir)
-   debugfs_remove_recursive(dir);
+   debugfs_remove_recursive(dir);
 }
 
 static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
-- 
1.7.12.4

Re: [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN

[Andy Lutomirski]

This patch seems reasonable, but you emailed the wrong people :)

On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld  wrote:
>
> It turns out that KASAN in general will bloat stack frames in unexpected
> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> default to be associated with KASAN instead of KASAN_EXTRA.
>
> Signed-off-by: Jason A. Donenfeld 
> ---
>  lib/Kconfig.debug | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4966c4fbe7f7..39078a080e29 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -222,7 +222,7 @@ config ENABLE_MUST_CHECK
>  config FRAME_WARN
> int "Warn for stack frames larger than (needs gcc 4.4)"
> range 0 8192
> -   default 3072 if KASAN_EXTRA
> +   default 3072 if KASAN
> default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> default 1280 if (!64BIT && PARISC)
> default 1024 if (!64BIT && !PARISC)
> --
> 2.19.0
>

Re: [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN

[Andy Lutomirski]

This patch seems reasonable, but you emailed the wrong people :)

On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld  wrote:
>
> It turns out that KASAN in general will bloat stack frames in unexpected
> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> default to be associated with KASAN instead of KASAN_EXTRA.
>
> Signed-off-by: Jason A. Donenfeld 
> ---
>  lib/Kconfig.debug | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4966c4fbe7f7..39078a080e29 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -222,7 +222,7 @@ config ENABLE_MUST_CHECK
>  config FRAME_WARN
> int "Warn for stack frames larger than (needs gcc 4.4)"
> range 0 8192
> -   default 3072 if KASAN_EXTRA
> +   default 3072 if KASAN
> default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> default 1280 if (!64BIT && PARISC)
> default 1024 if (!64BIT && !PARISC)
> --
> 2.19.0
>

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

[Minchan Kim]

Hi Guys,

Could you have a chance to review this patchset?

Thanks!

On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote:
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder bits to make bit 5 free.
> 
> We will use the bit for L_PTE_SPECIAL in next patch.
> 
> A note from Catalin
> "
> > Anyway, on ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to
> > shared device in hardware. Looking through the arm32 code, it seems that
> > MT_DEVICE_NONSHARED is used by arch/arm/mach-shmobile/setup-r8a7779.c
> > and IIUC that's a v7 platform (R-Car H1, Cortex-A9). I think the above
> > should be defined to L_PTE_MT_DEV_SHARED, unless I miss any place where
> > DEV_NONSHARED is relevant on ARMv6 (adding Simon to confirm on shmbile).
> "
> 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Steve Capper 
> Cc: Simon Horman 
> Signed-off-by: Minchan Kim 
> ---
>  arch/arm/include/asm/pgtable-2level.h | 19 +++
>  arch/arm/mm/proc-macros.S |  4 ++--
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/pgtable-2level.h 
> b/arch/arm/include/asm/pgtable-2level.h
> index 92fd2c8a9af0..514b13c27b43 100644
> --- a/arch/arm/include/asm/pgtable-2level.h
> +++ b/arch/arm/include/asm/pgtable-2level.h
> @@ -164,14 +164,25 @@
>  #define L_PTE_MT_BUFFERABLE  (_AT(pteval_t, 0x01) << 2)  /* 0001 */
>  #define L_PTE_MT_WRITETHROUGH(_AT(pteval_t, 0x02) << 2)  /* 0010 
> */
>  #define L_PTE_MT_WRITEBACK   (_AT(pteval_t, 0x03) << 2)  /* 0011 */
> +#define L_PTE_MT_DEV_SHARED  (_AT(pteval_t, 0x04) << 2)  /* 0100 */
> +#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x05) << 2)  /* 0101 */
>  #define L_PTE_MT_MINICACHE   (_AT(pteval_t, 0x06) << 2)  /* 0110 
> (sa1100, xscale) */
>  #define L_PTE_MT_WRITEALLOC  (_AT(pteval_t, 0x07) << 2)  /* 0111 */
> -#define L_PTE_MT_DEV_SHARED  (_AT(pteval_t, 0x04) << 2)  /* 0100 */
> -#define L_PTE_MT_DEV_NONSHARED   (_AT(pteval_t, 0x0c) << 2)  /* 1100 
> */
> +#if defined(CONFIG_CPU_V7) || defined (CONFIG_CPU_V6) || 
> defined(CONFIG_CPU_V6K)
> +/*
> + * On ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to
> + * shared device in hardware.
> + */
> +#define L_PTE_MT_DEV_NONSHARED   L_PTE_MT_DEV_SHARED
> +#define L_PTE_MT_DEV_WC  L_PTE_MT_BUFFERABLE
> +#define L_PTE_MT_DEV_CACHED  L_PTE_MT_WRITEBACK
> +#define L_PTE_MT_MASK(_AT(pteval_t, 0x07) << 2)
> +#else
>  #define L_PTE_MT_DEV_WC  (_AT(pteval_t, 0x09) << 2)  /* 1001 
> */
>  #define L_PTE_MT_DEV_CACHED  (_AT(pteval_t, 0x0b) << 2)  /* 1011 */
> -#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x0f) << 2)  /*  */
> -#define L_PTE_MT_MASK(_AT(pteval_t, 0x0f) << 2)
> +#define L_PTE_MT_DEV_NONSHARED   (_AT(pteval_t, 0x0c) << 2)  /* 1100 
> */
> +#define L_PTE_MT_MASK   (_AT(pteval_t, 0x0f) << 2)
> +#endif
>  
>  #ifndef __ASSEMBLY__
>  
> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> index 81d0efb055c6..367a89d5aeca 100644
> --- a/arch/arm/mm/proc-macros.S
> +++ b/arch/arm/mm/proc-macros.S
> @@ -138,7 +138,7 @@
>   .long   PTE_CACHEABLE   @ 
> L_PTE_MT_WRITETHROUGH
>   .long   PTE_CACHEABLE | PTE_BUFFERABLE  @ 
> L_PTE_MT_WRITEBACK
>   .long   PTE_BUFFERABLE  @ 
> L_PTE_MT_DEV_SHARED
> - .long   0x00@ unused
> + .long   PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@ 
> L_PTE_MT_VECTORS
>   .long   0x00@ 
> L_PTE_MT_MINICACHE (not present)
>   .long   PTE_EXT_TEX(1) | PTE_CACHEABLE | PTE_BUFFERABLE @ 
> L_PTE_MT_WRITEALLOC
>   .long   0x00@ unused
> @@ -148,7 +148,7 @@
>   .long   PTE_EXT_TEX(2)  @ 
> L_PTE_MT_DEV_NONSHARED
>   .long   0x00@ unused
>   .long   0x00@ unused
> - .long   PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@ 
> L_PTE_MT_VECTORS
> + .long   0x00@ unused
>   .endm
>  
>   .macro  armv6_set_pte_ext pfx
> -- 
> 2.19.0.397.gdd90340f6a-goog
> 

[PATCH 2/6] platform/x86: acerhdf: Enable ability to list supported systems

[Paul Gortmaker]

This driver has two module parameters that allow an override of the
checks for matching model and BIOS version.  However, both parameters
expect you to choose an entry from the existing list of supported
systems, encoded within the driver itself.

Without the source, such as in a binary distribution, the end user
does not have access to this information, thus rendering the two
module parameters essentially useless.

Add a module parameter that allows the end user to dump the list
of make/model/versions so that they can then pick one that most
closely matches their own system.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 3d5c4e183111..2735815c73c5 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -86,6 +86,7 @@ static unsigned int interval = 10;
 static unsigned int fanon = 6;
 static unsigned int fanoff = 53000;
 static unsigned int verbose;
+static unsigned int list_supported;
 static unsigned int fanstate = ACERHDF_FAN_AUTO;
 static char force_bios[16];
 static char force_product[16];
@@ -104,6 +105,8 @@ module_param(fanoff, uint, 0600);
 MODULE_PARM_DESC(fanoff, "Turn the fan off below this temperature");
 module_param(verbose, uint, 0600);
 MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
+module_param(list_supported, uint, 0600);
+MODULE_PARM_DESC(list_supported, "List supported models and BIOS versions");
 module_param_string(force_bios, force_bios, 16, 0);
 MODULE_PARM_DESC(force_bios, "Pretend system has this known supported BIOS 
version");
 module_param_string(force_product, force_product, 16, 0);
@@ -632,6 +635,17 @@ static int acerhdf_check_hardware(void)
 
pr_info("Acer Aspire One Fan driver, v.%s\n", DRV_VER);
 
+   if (list_supported) {
+   pr_info("List of supported Manufacturer/Model/BIOS:\n");
+   
pr_info("---\n");
+   for (bt = bios_tbl; bt->vendor[0]; bt++) {
+   pr_info("%-13s | %-17s | %-10s\n", bt->vendor,
+   bt->product, bt->version);
+   }
+   
pr_info("---\n");
+   return -ECANCELED;
+   }
+
if (force_bios[0]) {
version = force_bios;
pr_info("forcing BIOS version: %s\n", version);
-- 
2.15.0

[PATCH 0/6] platform/x86: acerhdf: new BIOS string, better modparam handling

[Paul Gortmaker]

I came across this older netbook over the xmas holidays, and noticed the
acerhdf driver wouldn't load.  Turns out the BIOS string was too new,
and not listed in the driver.  There were module params for overrides,
but I found their use isn't quite clear without reading the source.

Here I clarify some of the module parameter usage, and then add the new
BIOS string, so they won't be needed for this particular platform.  Some
probe code is also shifted out to be __init to reduce the driver size a
bit.  Further details can be found in the respective commit logs.

Since it was months ago when I created these patches, I retested on top
of tree to ensure things still work, as can be seen below.

root@gw:~# cat /proc/version 
Linux version 4.19.0-rc4+ (paul@host) (gcc version 5.4.0 20160609 (Ubuntu 
5.4.0-6ubuntu1~16.04.10)) #1 SMP Thu Sep 20 18:47:15 EDT 2018
root@gw:~# modprobe acerhdf
root@gw:~# dmesg|tail -n3
acerhdf: Acer Aspire One Fan driver, v.0.7.0
acerhdf: Fan control off, to enable do:
acerhdf: echo -n "enabled" > /sys/class/thermal/thermal_zoneN/mode # N=0,1,2...
root@gw:~# lsmod
Module  Size  Used by
acerhdf16384  0 
root@gw:~# 

Paul.
---

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 

Paul Gortmaker (6):
  platform/x86: acerhdf: clarify modinfo messages for BIOS override
  platform/x86: acerhdf: Enable ability to list supported systems
  platform/x86: acerhdf: Remove cut-and-paste trap from instructions
  platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307
  platform/x86: acerhdf: mark appropriate content with __init prefix
  platform/x86: acerhdf: restructure to allow large BIOS table be __initconst

 drivers/platform/x86/Kconfig   |  5 +++-
 drivers/platform/x86/acerhdf.c | 68 ++
 2 files changed, 53 insertions(+), 20 deletions(-)

-- 
2.15.0

Re: Code of Conduct: Let's revamp it.

[Rik van Riel]

On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:

> I think there are important differences between code to be run by
> CPUs
>  and a Code to be run by humans.  And when the author goes on a
> victory
>  lap on Twitter and declares the Code to be "a political document",
> is
>  it any surprise I'm worried?

Speaking for myself, I expect there will be occasional
impedance mismatches in communication between people
from different cultures, and people with different
neurotypes.

That is not only expected, it is also perfectly fine.

If people end up feeling like they are in conflict
with each other, and they would like help resolving
it, the first task of the TAB will be to mediate,
and help people figure out how communication could
be improved.

The goal of the code of conduct is to make the community
welcoming, and to help people with being a part of the
Linux community.

Mediation is not about telling people what to do,
but about asking the people involved what they would
like to see, and helping to breach the gap between
their styles of communication.

As an aside, the TAB has no power to remove anyone
from the community. Patches are applied by maintainers,
mailing lists are run by their administrators.

The only things the TAB can do is mediate and advise.

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part

[PATCH 3/6] platform/x86: acerhdf: Remove cut-and-paste trap from instructions

[Paul Gortmaker]

Just like we avoid specifying actual block devices like sda for fdisk
and dd examples, we should not specify specific thermal zones here.

On the platform I was testing on, zone0 was acpitz, and zone1 was for
this acerhdf driver.  Make the printk such that it won't work with a
blind cut-and-paste, and force the user to determine which zone is
correct for this driver.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/Kconfig   | 5 -
 drivers/platform/x86/acerhdf.c | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0c1aa6c314f5..1fca33c97e8a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -60,7 +60,10 @@ config ACERHDF
 
  After loading this driver the BIOS is still in control of the fan.
  To let the kernel handle the fan, do:
- echo -n enabled > /sys/class/thermal/thermal_zone0/mode
+ echo -n enabled > /sys/class/thermal/thermal_zoneN/mode
+ where N=0,1,2... depending on the number of thermal nodes and the
+ detection order of your particular system.  The "type" parameter
+ in the same node directory will tell you if it is "acerhdf".
 
  For more information about this driver see
  
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 2735815c73c5..fef3b727bc24 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -688,7 +688,7 @@ static int acerhdf_check_hardware(void)
 */
if (!kernelmode) {
pr_notice("Fan control off, to enable do:\n");
-   pr_notice("echo -n \"enabled\" > 
/sys/class/thermal/thermal_zone0/mode\n");
+   pr_notice("echo -n \"enabled\" > 
/sys/class/thermal/thermal_zoneN/mode # N=0,1,2...\n");
}
 
return 0;
-- 
2.15.0

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

[Minchan Kim]

Hi Guys,

Could you have a chance to review this patchset?

Thanks!

On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote:
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder bits to make bit 5 free.
> 
> We will use the bit for L_PTE_SPECIAL in next patch.
> 
> A note from Catalin
> "
> > Anyway, on ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to
> > shared device in hardware. Looking through the arm32 code, it seems that
> > MT_DEVICE_NONSHARED is used by arch/arm/mach-shmobile/setup-r8a7779.c
> > and IIUC that's a v7 platform (R-Car H1, Cortex-A9). I think the above
> > should be defined to L_PTE_MT_DEV_SHARED, unless I miss any place where
> > DEV_NONSHARED is relevant on ARMv6 (adding Simon to confirm on shmbile).
> "
> 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Steve Capper 
> Cc: Simon Horman 
> Signed-off-by: Minchan Kim 
> ---
>  arch/arm/include/asm/pgtable-2level.h | 19 +++
>  arch/arm/mm/proc-macros.S |  4 ++--
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/pgtable-2level.h 
> b/arch/arm/include/asm/pgtable-2level.h
> index 92fd2c8a9af0..514b13c27b43 100644
> --- a/arch/arm/include/asm/pgtable-2level.h
> +++ b/arch/arm/include/asm/pgtable-2level.h
> @@ -164,14 +164,25 @@
>  #define L_PTE_MT_BUFFERABLE  (_AT(pteval_t, 0x01) << 2)  /* 0001 */
>  #define L_PTE_MT_WRITETHROUGH(_AT(pteval_t, 0x02) << 2)  /* 0010 
> */
>  #define L_PTE_MT_WRITEBACK   (_AT(pteval_t, 0x03) << 2)  /* 0011 */
> +#define L_PTE_MT_DEV_SHARED  (_AT(pteval_t, 0x04) << 2)  /* 0100 */
> +#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x05) << 2)  /* 0101 */
>  #define L_PTE_MT_MINICACHE   (_AT(pteval_t, 0x06) << 2)  /* 0110 
> (sa1100, xscale) */
>  #define L_PTE_MT_WRITEALLOC  (_AT(pteval_t, 0x07) << 2)  /* 0111 */
> -#define L_PTE_MT_DEV_SHARED  (_AT(pteval_t, 0x04) << 2)  /* 0100 */
> -#define L_PTE_MT_DEV_NONSHARED   (_AT(pteval_t, 0x0c) << 2)  /* 1100 
> */
> +#if defined(CONFIG_CPU_V7) || defined (CONFIG_CPU_V6) || 
> defined(CONFIG_CPU_V6K)
> +/*
> + * On ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to
> + * shared device in hardware.
> + */
> +#define L_PTE_MT_DEV_NONSHARED   L_PTE_MT_DEV_SHARED
> +#define L_PTE_MT_DEV_WC  L_PTE_MT_BUFFERABLE
> +#define L_PTE_MT_DEV_CACHED  L_PTE_MT_WRITEBACK
> +#define L_PTE_MT_MASK(_AT(pteval_t, 0x07) << 2)
> +#else
>  #define L_PTE_MT_DEV_WC  (_AT(pteval_t, 0x09) << 2)  /* 1001 
> */
>  #define L_PTE_MT_DEV_CACHED  (_AT(pteval_t, 0x0b) << 2)  /* 1011 */
> -#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x0f) << 2)  /*  */
> -#define L_PTE_MT_MASK(_AT(pteval_t, 0x0f) << 2)
> +#define L_PTE_MT_DEV_NONSHARED   (_AT(pteval_t, 0x0c) << 2)  /* 1100 
> */
> +#define L_PTE_MT_MASK   (_AT(pteval_t, 0x0f) << 2)
> +#endif
>  
>  #ifndef __ASSEMBLY__
>  
> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> index 81d0efb055c6..367a89d5aeca 100644
> --- a/arch/arm/mm/proc-macros.S
> +++ b/arch/arm/mm/proc-macros.S
> @@ -138,7 +138,7 @@
>   .long   PTE_CACHEABLE   @ 
> L_PTE_MT_WRITETHROUGH
>   .long   PTE_CACHEABLE | PTE_BUFFERABLE  @ 
> L_PTE_MT_WRITEBACK
>   .long   PTE_BUFFERABLE  @ 
> L_PTE_MT_DEV_SHARED
> - .long   0x00@ unused
> + .long   PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@ 
> L_PTE_MT_VECTORS
>   .long   0x00@ 
> L_PTE_MT_MINICACHE (not present)
>   .long   PTE_EXT_TEX(1) | PTE_CACHEABLE | PTE_BUFFERABLE @ 
> L_PTE_MT_WRITEALLOC
>   .long   0x00@ unused
> @@ -148,7 +148,7 @@
>   .long   PTE_EXT_TEX(2)  @ 
> L_PTE_MT_DEV_NONSHARED
>   .long   0x00@ unused
>   .long   0x00@ unused
> - .long   PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@ 
> L_PTE_MT_VECTORS
> + .long   0x00@ unused
>   .endm
>  
>   .macro  armv6_set_pte_ext pfx
> -- 
> 2.19.0.397.gdd90340f6a-goog
> 

[PATCH 2/6] platform/x86: acerhdf: Enable ability to list supported systems

[Paul Gortmaker]

This driver has two module parameters that allow an override of the
checks for matching model and BIOS version.  However, both parameters
expect you to choose an entry from the existing list of supported
systems, encoded within the driver itself.

Without the source, such as in a binary distribution, the end user
does not have access to this information, thus rendering the two
module parameters essentially useless.

Add a module parameter that allows the end user to dump the list
of make/model/versions so that they can then pick one that most
closely matches their own system.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 3d5c4e183111..2735815c73c5 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -86,6 +86,7 @@ static unsigned int interval = 10;
 static unsigned int fanon = 6;
 static unsigned int fanoff = 53000;
 static unsigned int verbose;
+static unsigned int list_supported;
 static unsigned int fanstate = ACERHDF_FAN_AUTO;
 static char force_bios[16];
 static char force_product[16];
@@ -104,6 +105,8 @@ module_param(fanoff, uint, 0600);
 MODULE_PARM_DESC(fanoff, "Turn the fan off below this temperature");
 module_param(verbose, uint, 0600);
 MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
+module_param(list_supported, uint, 0600);
+MODULE_PARM_DESC(list_supported, "List supported models and BIOS versions");
 module_param_string(force_bios, force_bios, 16, 0);
 MODULE_PARM_DESC(force_bios, "Pretend system has this known supported BIOS 
version");
 module_param_string(force_product, force_product, 16, 0);
@@ -632,6 +635,17 @@ static int acerhdf_check_hardware(void)
 
pr_info("Acer Aspire One Fan driver, v.%s\n", DRV_VER);
 
+   if (list_supported) {
+   pr_info("List of supported Manufacturer/Model/BIOS:\n");
+   
pr_info("---\n");
+   for (bt = bios_tbl; bt->vendor[0]; bt++) {
+   pr_info("%-13s | %-17s | %-10s\n", bt->vendor,
+   bt->product, bt->version);
+   }
+   
pr_info("---\n");
+   return -ECANCELED;
+   }
+
if (force_bios[0]) {
version = force_bios;
pr_info("forcing BIOS version: %s\n", version);
-- 
2.15.0

[PATCH 0/6] platform/x86: acerhdf: new BIOS string, better modparam handling

[Paul Gortmaker]

I came across this older netbook over the xmas holidays, and noticed the
acerhdf driver wouldn't load.  Turns out the BIOS string was too new,
and not listed in the driver.  There were module params for overrides,
but I found their use isn't quite clear without reading the source.

Here I clarify some of the module parameter usage, and then add the new
BIOS string, so they won't be needed for this particular platform.  Some
probe code is also shifted out to be __init to reduce the driver size a
bit.  Further details can be found in the respective commit logs.

Since it was months ago when I created these patches, I retested on top
of tree to ensure things still work, as can be seen below.

root@gw:~# cat /proc/version 
Linux version 4.19.0-rc4+ (paul@host) (gcc version 5.4.0 20160609 (Ubuntu 
5.4.0-6ubuntu1~16.04.10)) #1 SMP Thu Sep 20 18:47:15 EDT 2018
root@gw:~# modprobe acerhdf
root@gw:~# dmesg|tail -n3
acerhdf: Acer Aspire One Fan driver, v.0.7.0
acerhdf: Fan control off, to enable do:
acerhdf: echo -n "enabled" > /sys/class/thermal/thermal_zoneN/mode # N=0,1,2...
root@gw:~# lsmod
Module  Size  Used by
acerhdf16384  0 
root@gw:~# 

Paul.
---

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 

Paul Gortmaker (6):
  platform/x86: acerhdf: clarify modinfo messages for BIOS override
  platform/x86: acerhdf: Enable ability to list supported systems
  platform/x86: acerhdf: Remove cut-and-paste trap from instructions
  platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307
  platform/x86: acerhdf: mark appropriate content with __init prefix
  platform/x86: acerhdf: restructure to allow large BIOS table be __initconst

 drivers/platform/x86/Kconfig   |  5 +++-
 drivers/platform/x86/acerhdf.c | 68 ++
 2 files changed, 53 insertions(+), 20 deletions(-)

-- 
2.15.0

Re: Code of Conduct: Let's revamp it.

[Rik van Riel]

On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:

> I think there are important differences between code to be run by
> CPUs
>  and a Code to be run by humans.  And when the author goes on a
> victory
>  lap on Twitter and declares the Code to be "a political document",
> is
>  it any surprise I'm worried?

Speaking for myself, I expect there will be occasional
impedance mismatches in communication between people
from different cultures, and people with different
neurotypes.

That is not only expected, it is also perfectly fine.

If people end up feeling like they are in conflict
with each other, and they would like help resolving
it, the first task of the TAB will be to mediate,
and help people figure out how communication could
be improved.

The goal of the code of conduct is to make the community
welcoming, and to help people with being a part of the
Linux community.

Mediation is not about telling people what to do,
but about asking the people involved what they would
like to see, and helping to breach the gap between
their styles of communication.

As an aside, the TAB has no power to remove anyone
from the community. Patches are applied by maintainers,
mailing lists are run by their administrators.

The only things the TAB can do is mediate and advise.

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part

[PATCH 3/6] platform/x86: acerhdf: Remove cut-and-paste trap from instructions

[Paul Gortmaker]

Just like we avoid specifying actual block devices like sda for fdisk
and dd examples, we should not specify specific thermal zones here.

On the platform I was testing on, zone0 was acpitz, and zone1 was for
this acerhdf driver.  Make the printk such that it won't work with a
blind cut-and-paste, and force the user to determine which zone is
correct for this driver.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/Kconfig   | 5 -
 drivers/platform/x86/acerhdf.c | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0c1aa6c314f5..1fca33c97e8a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -60,7 +60,10 @@ config ACERHDF
 
  After loading this driver the BIOS is still in control of the fan.
  To let the kernel handle the fan, do:
- echo -n enabled > /sys/class/thermal/thermal_zone0/mode
+ echo -n enabled > /sys/class/thermal/thermal_zoneN/mode
+ where N=0,1,2... depending on the number of thermal nodes and the
+ detection order of your particular system.  The "type" parameter
+ in the same node directory will tell you if it is "acerhdf".
 
  For more information about this driver see
  
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 2735815c73c5..fef3b727bc24 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -688,7 +688,7 @@ static int acerhdf_check_hardware(void)
 */
if (!kernelmode) {
pr_notice("Fan control off, to enable do:\n");
-   pr_notice("echo -n \"enabled\" > 
/sys/class/thermal/thermal_zone0/mode\n");
+   pr_notice("echo -n \"enabled\" > 
/sys/class/thermal/thermal_zoneN/mode # N=0,1,2...\n");
}
 
return 0;
-- 
2.15.0

[no subject]

[Kassey]

unsubscribe linux-kernel


-- 
Best regards
Kassey

[PATCH 4/6] platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307

[Paul Gortmaker]

To fix:

  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!

As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older platform either.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index fef3b727bc24..eddcd8e94a88 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -236,6 +236,7 @@ static const struct bios_settings bios_tbl[] = {
{"Gateway", "LT31",   "v1.3201",  0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31",   "v1.3302",  0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31",   "v1.3303t", 0x55, 0x58, {0x9e, 0x00}, 0},
+   {"Gateway", "LT31",   "v1.3307",  0x55, 0x58, {0x9e, 0x00}, 0},
/* Packard Bell */
{"Packard Bell", "DOA150",  "v0.3104",  0x55, 0x58, {0x21, 0x00}, 0},
{"Packard Bell", "DOA150",  "v0.3105",  0x55, 0x58, {0x20, 0x00}, 0},
-- 
2.15.0

Re: [PATCH v2] HID: logitech: fix a used uninitialized GCC warning

[zhong jiang]

Hi Jiri

Can you pick up the patch?

Thanks
zhong jiang

On 2018/9/13 15:41, zhong jiang wrote:
> Fix the following compile warning:
>
> drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable':
> drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>   hidpp->vertical_wheel_counter.resolution_multiplier = multiplier;
>
> Signed-off-by: zhong jiang 
> ---
> v1->v2:
>  According to Benjamin's suggestion, To initialize the value
> and remove the duplicated assignement. 
>
>  drivers/hid/hid-logitech-hidpp.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 5f0c080..f012808 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -1231,7 +1231,6 @@ static int hidpp_hrw_get_wheel_capability(struct 
> hidpp_device *hidpp,
>   *multiplier = response.fap.params[0];
>   return 0;
>  return_default:
> - *multiplier = 8;
>   hid_warn(hidpp->hid_dev,
>"Couldn't get wheel multiplier (error %d), assuming %d.\n",
>ret, *multiplier);
> @@ -2696,7 +2695,7 @@ static int hi_res_scroll_look_up_microns(__u32 
> product_id)
>  static int hi_res_scroll_enable(struct hidpp_device *hidpp)
>  {
>   int ret;
> - u8 multiplier;
> + u8 multiplier = 8;
>  
>   if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_X2121) {
>   ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
> @@ -2704,10 +2703,9 @@ static int hi_res_scroll_enable(struct hidpp_device 
> *hidpp)
>   } else if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_X2120) {
>   ret = hidpp_hrs_set_highres_scrolling_mode(hidpp, true,
>  );
> - } else /* if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_1P0) */ {
> + } else /* if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_1P0) */
>   ret = hidpp10_enable_scrolling_acceleration(hidpp);
> - multiplier = 8;
> - }
> +
>   if (ret)
>   return ret;
>  

[PATCH 1/6] platform/x86: acerhdf: clarify modinfo messages for BIOS override

[Paul Gortmaker]

Normally, a module parameter for a BIOS check override implies "pretend
you support this version" (and the user will enter their local version).

However, this driver uses the model/BIOS module parameters in a way that
is "pretend my system is the supported model XYZ with BIOS version ABC."
which is less common.

Since the help strings don't make such a distinction, one gets this
somewhat frustrating scenario, where the user sees the error, enters
*their* BIOS version and then gets the same error:

  root@gw:~# modprobe acerhdf
  acerhdf: Acer Aspire One Fan driver, v.0.7.0
  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!
  modprobe: ERROR: could not insert 'acerhdf': Invalid argument

  root@gw:~# modprobe acerhdf force_bios=v1.3307
  acerhdf: Acer Aspire One Fan driver, v.0.7.0
  acerhdf: forcing BIOS version: v1.3307
  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!
  modprobe: ERROR: could not insert 'acerhdf': Invalid argument

Clarify the module param help text to make it clear that the driver
expects a choice from existing supported models/versions.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index ea22591ee66f..3d5c4e183111 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -105,9 +105,9 @@ MODULE_PARM_DESC(fanoff, "Turn the fan off below this 
temperature");
 module_param(verbose, uint, 0600);
 MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
 module_param_string(force_bios, force_bios, 16, 0);
-MODULE_PARM_DESC(force_bios, "Force BIOS version and omit BIOS check");
+MODULE_PARM_DESC(force_bios, "Pretend system has this known supported BIOS 
version");
 module_param_string(force_product, force_product, 16, 0);
-MODULE_PARM_DESC(force_product, "Force BIOS product and omit BIOS check");
+MODULE_PARM_DESC(force_product, "Pretend system is this known supported 
model");
 
 /*
  * cmd_off: to switch the fan completely off and check if the fan is off
-- 
2.15.0

Re: [PATCH 1/3] percpu_ref: add a new helper interface __percpu_ref_get_many

[jianchao.wang]

Hi Tejun

Thanks for your kindly response.

On 09/21/2018 04:53 AM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
>> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>> +static inline void __percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>>  {
>>  unsigned long __percpu *percpu_count;
>>  
>> -rcu_read_lock_sched();
> 
> So, if we're gonna do this (please read below tho), please add the
> matching assertion

Yes, I will.

> 
>>  if (__ref_is_percpu(ref, _count))
>>  this_cpu_add(*percpu_count, nr);
>>  else
>>  atomic_long_add(nr, >count);
>> +}
>>  
>> +/**
>> + * percpu_ref_get_many - increment a percpu refcount
>> + * @ref: percpu_ref to get
>> + * @nr: number of references to get
>> + *
>> + * Analogous to atomic_long_add().
>> + *
>> + * This function is safe to call as long as @ref is between init and exit.
>> + */
>> +static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>> +{
>> +rcu_read_lock_sched();
>> +__percpu_ref_get_many(ref, nr);
>>  rcu_read_unlock_sched();
>>  }
> 
> And add the matching variant for get/put with and without _many.

Yes.

> 
> Ming, so, if we make locking explicit like above, I think it should be
> fine to share the locking.  However, please note that percpu_ref and
> blk_mq are using different types of RCU, at least for now, and I'm not
> really sure that unifying that and taking out one rcu read lock/unlock
> is a meaningful optimization.
> 

Essentially, I want to rework the current queue freeze which depends on
percpu_ref_kil/reinit. We implement our own condition checking instead of
using the __PERCPU_REF_DEAD checking in percpu_ref_tryget_live. And use
percpu with percpu_ref_switch_to_atomic/percpu to switch the percpu ref
mode between percpu and atimic directly. Then it will be more convenient
to implement:
 - unfreeze the queue without draining requests.
 - check whether q->q_usage_counter is zero
 - add other gate conditions into blk_queue_enter, such as preempt-only

So I want to put the condition checking and percpu_ref_get_many into a
same sched rcu critical section.
 rcu_read_lock_sched()
   if condition check true
 percpu_ref_get_many(>q_usage_counter, 1)
   else
 goto wait
   rcu_read_unlock_sched()

Then we could freeze the queue like:
  set FROZEN flag on q
  percpu_ref_put(1)
  percpu_ref_switch_to_atomic
Otherwise, we may need a synchronize_rcu.
It is not for performance.

Is there any reason that why blk_queue_enter only could use rcu lock instead of
the sched rcu lock ?


> Let's please first do something straight-forward.  If somebody can
> show that this actually impacts performance, we can optimize it but
> right now all these seem premature to me.

Adding this interface is just for saving an extra rcu_read_lock/unlock_sched 
pair.
If it doesn't make any sense, It is OK for me to discard it. :)

Thanks
Jianchao

[PATCH 6/6] platform/x86: acerhdf: restructure to allow large BIOS table be __initconst

[Paul Gortmaker]

There is a table of Vendor/Model/Version {control data} in this driver,
but outside of the initial probe, the V/M/V is never used again, and
neither are any of the entries for platforms other than the one which
matches the running target.

By simply storing the {control data} for the matched platform, we can
mark the large table __initconst, which reduces the loaded driver size
by 20 percent.

Before:
root@gw:~/git/linux-head# lsmod
Module  Size  Used by
acerhdf20480  0
root@gw:~/git/linux-head#

After:
root@gw:~/git/linux-head# lsmod
Module  Size  Used by
acerhdf16384  0
root@gw:~/git/linux-head#

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5f579fcde315..505224225378 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -133,7 +133,7 @@ static const struct manualcmd mcmd = {
.moff = 0xff,
 };
 
-/* BIOS settings */
+/* BIOS settings - only used during probe */
 struct bios_settings {
const char *vendor;
const char *product;
@@ -144,8 +144,18 @@ struct bios_settings {
int mcmd_enable;
 };
 
+/* This could be a daughter struct in the above, but not worth the redirect */
+struct ctrl_settings {
+   u8 fanreg;
+   u8 tempreg;
+   struct fancmd cmd;
+   int mcmd_enable;
+};
+
+static struct ctrl_settings ctrl_cfg __read_mostly;
+
 /* Register addresses and values for different BIOS versions */
-static const struct bios_settings bios_tbl[] = {
+static const struct bios_settings bios_tbl[] __initconst = {
/* AOA110 */
{"Acer", "AOA110", "v0.3109", 0x55, 0x58, {0x1f, 0x00}, 0},
{"Acer", "AOA110", "v0.3114", 0x55, 0x58, {0x1f, 0x00}, 0},
@@ -260,8 +270,6 @@ static const struct bios_settings bios_tbl[] = {
{"", "", "", 0, 0, {0, 0}, 0}
 };
 
-static const struct bios_settings *bios_cfg __read_mostly;
-
 /*
  * this struct is used to instruct thermal layer to use bang_bang instead of
  * default governor for acerhdf
@@ -274,7 +282,7 @@ static int acerhdf_get_temp(int *temp)
 {
u8 read_temp;
 
-   if (ec_read(bios_cfg->tempreg, _temp))
+   if (ec_read(ctrl_cfg.tempreg, _temp))
return -EINVAL;
 
*temp = read_temp * 1000;
@@ -286,10 +294,10 @@ static int acerhdf_get_fanstate(int *state)
 {
u8 fan;
 
-   if (ec_read(bios_cfg->fanreg, ))
+   if (ec_read(ctrl_cfg.fanreg, ))
return -EINVAL;
 
-   if (fan != bios_cfg->cmd.cmd_off)
+   if (fan != ctrl_cfg.cmd.cmd_off)
*state = ACERHDF_FAN_AUTO;
else
*state = ACERHDF_FAN_OFF;
@@ -310,13 +318,13 @@ static void acerhdf_change_fanstate(int state)
state = ACERHDF_FAN_AUTO;
}
 
-   cmd = (state == ACERHDF_FAN_OFF) ? bios_cfg->cmd.cmd_off
-: bios_cfg->cmd.cmd_auto;
+   cmd = (state == ACERHDF_FAN_OFF) ? ctrl_cfg.cmd.cmd_off
+: ctrl_cfg.cmd.cmd_auto;
fanstate = state;
 
-   ec_write(bios_cfg->fanreg, cmd);
+   ec_write(ctrl_cfg.fanreg, cmd);
 
-   if (bios_cfg->mcmd_enable && state == ACERHDF_FAN_OFF) {
+   if (ctrl_cfg.mcmd_enable && state == ACERHDF_FAN_OFF) {
if (verbose)
pr_notice("turning off fan manually\n");
ec_write(mcmd.mreg, mcmd.moff);
@@ -623,6 +631,7 @@ static int __init acerhdf_check_hardware(void)
 {
char const *vendor, *version, *product;
const struct bios_settings *bt = NULL;
+   int found = 0;
 
/* get BIOS data */
vendor  = dmi_get_system_info(DMI_SYS_VENDOR);
@@ -672,17 +681,23 @@ static int __init acerhdf_check_hardware(void)
if (str_starts_with(vendor, bt->vendor) &&
str_starts_with(product, bt->product) &&
str_starts_with(version, bt->version)) {
-   bios_cfg = bt;
+   found = 1;
break;
}
}
 
-   if (!bios_cfg) {
+   if (!found) {
pr_err("unknown (unsupported) BIOS version %s/%s/%s, please 
report, aborting!\n",
   vendor, product, version);
return -EINVAL;
}
 
+   /* Copy control settings from BIOS table before we free it. */
+   ctrl_cfg.fanreg = bt->fanreg;
+   ctrl_cfg.tempreg = bt->tempreg;
+   memcpy(_cfg.cmd, >cmd, sizeof(struct fancmd));
+   ctrl_cfg.mcmd_enable = bt->mcmd_enable;
+
/*
 * if started with kernel mode off, prevent the kernel from 

[PATCH 5/6] platform/x86: acerhdf: mark appropriate content with __init prefix

[Paul Gortmaker]

These three functions are only called from the probe code which is
already marked __init and hence these can be __init as well.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index eddcd8e94a88..5f579fcde315 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -619,7 +619,7 @@ static int str_starts_with(const char *str, const char 
*start)
 }
 
 /* check hardware */
-static int acerhdf_check_hardware(void)
+static int __init acerhdf_check_hardware(void)
 {
char const *vendor, *version, *product;
const struct bios_settings *bt = NULL;
@@ -695,7 +695,7 @@ static int acerhdf_check_hardware(void)
return 0;
 }
 
-static int acerhdf_register_platform(void)
+static int __init acerhdf_register_platform(void)
 {
int err = 0;
 
@@ -727,7 +727,7 @@ static void acerhdf_unregister_platform(void)
platform_driver_unregister(_driver);
 }
 
-static int acerhdf_register_thermal(void)
+static int __init acerhdf_register_thermal(void)
 {
cl_dev = thermal_cooling_device_register("acerhdf-fan", NULL,
 _cooling_ops);
-- 
2.15.0

[no subject]

[Kassey]

unsubscribe linux-kernel


-- 
Best regards
Kassey

[PATCH 4/6] platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307

[Paul Gortmaker]

To fix:

  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!

As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older platform either.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index fef3b727bc24..eddcd8e94a88 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -236,6 +236,7 @@ static const struct bios_settings bios_tbl[] = {
{"Gateway", "LT31",   "v1.3201",  0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31",   "v1.3302",  0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31",   "v1.3303t", 0x55, 0x58, {0x9e, 0x00}, 0},
+   {"Gateway", "LT31",   "v1.3307",  0x55, 0x58, {0x9e, 0x00}, 0},
/* Packard Bell */
{"Packard Bell", "DOA150",  "v0.3104",  0x55, 0x58, {0x21, 0x00}, 0},
{"Packard Bell", "DOA150",  "v0.3105",  0x55, 0x58, {0x20, 0x00}, 0},
-- 
2.15.0

Re: [PATCH v2] HID: logitech: fix a used uninitialized GCC warning

[zhong jiang]

Hi Jiri

Can you pick up the patch?

Thanks
zhong jiang

On 2018/9/13 15:41, zhong jiang wrote:
> Fix the following compile warning:
>
> drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable':
> drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>   hidpp->vertical_wheel_counter.resolution_multiplier = multiplier;
>
> Signed-off-by: zhong jiang 
> ---
> v1->v2:
>  According to Benjamin's suggestion, To initialize the value
> and remove the duplicated assignement. 
>
>  drivers/hid/hid-logitech-hidpp.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 5f0c080..f012808 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -1231,7 +1231,6 @@ static int hidpp_hrw_get_wheel_capability(struct 
> hidpp_device *hidpp,
>   *multiplier = response.fap.params[0];
>   return 0;
>  return_default:
> - *multiplier = 8;
>   hid_warn(hidpp->hid_dev,
>"Couldn't get wheel multiplier (error %d), assuming %d.\n",
>ret, *multiplier);
> @@ -2696,7 +2695,7 @@ static int hi_res_scroll_look_up_microns(__u32 
> product_id)
>  static int hi_res_scroll_enable(struct hidpp_device *hidpp)
>  {
>   int ret;
> - u8 multiplier;
> + u8 multiplier = 8;
>  
>   if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_X2121) {
>   ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
> @@ -2704,10 +2703,9 @@ static int hi_res_scroll_enable(struct hidpp_device 
> *hidpp)
>   } else if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_X2120) {
>   ret = hidpp_hrs_set_highres_scrolling_mode(hidpp, true,
>  );
> - } else /* if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_1P0) */ {
> + } else /* if (hidpp->quirks & HIDPP_QUIRK_HI_RES_SCROLL_1P0) */
>   ret = hidpp10_enable_scrolling_acceleration(hidpp);
> - multiplier = 8;
> - }
> +
>   if (ret)
>   return ret;
>  

[PATCH 1/6] platform/x86: acerhdf: clarify modinfo messages for BIOS override

[Paul Gortmaker]

Normally, a module parameter for a BIOS check override implies "pretend
you support this version" (and the user will enter their local version).

However, this driver uses the model/BIOS module parameters in a way that
is "pretend my system is the supported model XYZ with BIOS version ABC."
which is less common.

Since the help strings don't make such a distinction, one gets this
somewhat frustrating scenario, where the user sees the error, enters
*their* BIOS version and then gets the same error:

  root@gw:~# modprobe acerhdf
  acerhdf: Acer Aspire One Fan driver, v.0.7.0
  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!
  modprobe: ERROR: could not insert 'acerhdf': Invalid argument

  root@gw:~# modprobe acerhdf force_bios=v1.3307
  acerhdf: Acer Aspire One Fan driver, v.0.7.0
  acerhdf: forcing BIOS version: v1.3307
  acerhdf: unknown (unsupported) BIOS version Gateway  /LT31   /v1.3307 , 
please report, aborting!
  modprobe: ERROR: could not insert 'acerhdf': Invalid argument

Clarify the module param help text to make it clear that the driver
expects a choice from existing supported models/versions.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index ea22591ee66f..3d5c4e183111 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -105,9 +105,9 @@ MODULE_PARM_DESC(fanoff, "Turn the fan off below this 
temperature");
 module_param(verbose, uint, 0600);
 MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
 module_param_string(force_bios, force_bios, 16, 0);
-MODULE_PARM_DESC(force_bios, "Force BIOS version and omit BIOS check");
+MODULE_PARM_DESC(force_bios, "Pretend system has this known supported BIOS 
version");
 module_param_string(force_product, force_product, 16, 0);
-MODULE_PARM_DESC(force_product, "Force BIOS product and omit BIOS check");
+MODULE_PARM_DESC(force_product, "Pretend system is this known supported 
model");
 
 /*
  * cmd_off: to switch the fan completely off and check if the fan is off
-- 
2.15.0

Re: [PATCH 1/3] percpu_ref: add a new helper interface __percpu_ref_get_many

[jianchao.wang]

Hi Tejun

Thanks for your kindly response.

On 09/21/2018 04:53 AM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
>> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>> +static inline void __percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>>  {
>>  unsigned long __percpu *percpu_count;
>>  
>> -rcu_read_lock_sched();
> 
> So, if we're gonna do this (please read below tho), please add the
> matching assertion

Yes, I will.

> 
>>  if (__ref_is_percpu(ref, _count))
>>  this_cpu_add(*percpu_count, nr);
>>  else
>>  atomic_long_add(nr, >count);
>> +}
>>  
>> +/**
>> + * percpu_ref_get_many - increment a percpu refcount
>> + * @ref: percpu_ref to get
>> + * @nr: number of references to get
>> + *
>> + * Analogous to atomic_long_add().
>> + *
>> + * This function is safe to call as long as @ref is between init and exit.
>> + */
>> +static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned 
>> long nr)
>> +{
>> +rcu_read_lock_sched();
>> +__percpu_ref_get_many(ref, nr);
>>  rcu_read_unlock_sched();
>>  }
> 
> And add the matching variant for get/put with and without _many.

Yes.

> 
> Ming, so, if we make locking explicit like above, I think it should be
> fine to share the locking.  However, please note that percpu_ref and
> blk_mq are using different types of RCU, at least for now, and I'm not
> really sure that unifying that and taking out one rcu read lock/unlock
> is a meaningful optimization.
> 

Essentially, I want to rework the current queue freeze which depends on
percpu_ref_kil/reinit. We implement our own condition checking instead of
using the __PERCPU_REF_DEAD checking in percpu_ref_tryget_live. And use
percpu with percpu_ref_switch_to_atomic/percpu to switch the percpu ref
mode between percpu and atimic directly. Then it will be more convenient
to implement:
 - unfreeze the queue without draining requests.
 - check whether q->q_usage_counter is zero
 - add other gate conditions into blk_queue_enter, such as preempt-only

So I want to put the condition checking and percpu_ref_get_many into a
same sched rcu critical section.
 rcu_read_lock_sched()
   if condition check true
 percpu_ref_get_many(>q_usage_counter, 1)
   else
 goto wait
   rcu_read_unlock_sched()

Then we could freeze the queue like:
  set FROZEN flag on q
  percpu_ref_put(1)
  percpu_ref_switch_to_atomic
Otherwise, we may need a synchronize_rcu.
It is not for performance.

Is there any reason that why blk_queue_enter only could use rcu lock instead of
the sched rcu lock ?


> Let's please first do something straight-forward.  If somebody can
> show that this actually impacts performance, we can optimize it but
> right now all these seem premature to me.

Adding this interface is just for saving an extra rcu_read_lock/unlock_sched 
pair.
If it doesn't make any sense, It is OK for me to discard it. :)

Thanks
Jianchao

[PATCH 6/6] platform/x86: acerhdf: restructure to allow large BIOS table be __initconst

[Paul Gortmaker]

There is a table of Vendor/Model/Version {control data} in this driver,
but outside of the initial probe, the V/M/V is never used again, and
neither are any of the entries for platforms other than the one which
matches the running target.

By simply storing the {control data} for the matched platform, we can
mark the large table __initconst, which reduces the loaded driver size
by 20 percent.

Before:
root@gw:~/git/linux-head# lsmod
Module  Size  Used by
acerhdf20480  0
root@gw:~/git/linux-head#

After:
root@gw:~/git/linux-head# lsmod
Module  Size  Used by
acerhdf16384  0
root@gw:~/git/linux-head#

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5f579fcde315..505224225378 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -133,7 +133,7 @@ static const struct manualcmd mcmd = {
.moff = 0xff,
 };
 
-/* BIOS settings */
+/* BIOS settings - only used during probe */
 struct bios_settings {
const char *vendor;
const char *product;
@@ -144,8 +144,18 @@ struct bios_settings {
int mcmd_enable;
 };
 
+/* This could be a daughter struct in the above, but not worth the redirect */
+struct ctrl_settings {
+   u8 fanreg;
+   u8 tempreg;
+   struct fancmd cmd;
+   int mcmd_enable;
+};
+
+static struct ctrl_settings ctrl_cfg __read_mostly;
+
 /* Register addresses and values for different BIOS versions */
-static const struct bios_settings bios_tbl[] = {
+static const struct bios_settings bios_tbl[] __initconst = {
/* AOA110 */
{"Acer", "AOA110", "v0.3109", 0x55, 0x58, {0x1f, 0x00}, 0},
{"Acer", "AOA110", "v0.3114", 0x55, 0x58, {0x1f, 0x00}, 0},
@@ -260,8 +270,6 @@ static const struct bios_settings bios_tbl[] = {
{"", "", "", 0, 0, {0, 0}, 0}
 };
 
-static const struct bios_settings *bios_cfg __read_mostly;
-
 /*
  * this struct is used to instruct thermal layer to use bang_bang instead of
  * default governor for acerhdf
@@ -274,7 +282,7 @@ static int acerhdf_get_temp(int *temp)
 {
u8 read_temp;
 
-   if (ec_read(bios_cfg->tempreg, _temp))
+   if (ec_read(ctrl_cfg.tempreg, _temp))
return -EINVAL;
 
*temp = read_temp * 1000;
@@ -286,10 +294,10 @@ static int acerhdf_get_fanstate(int *state)
 {
u8 fan;
 
-   if (ec_read(bios_cfg->fanreg, ))
+   if (ec_read(ctrl_cfg.fanreg, ))
return -EINVAL;
 
-   if (fan != bios_cfg->cmd.cmd_off)
+   if (fan != ctrl_cfg.cmd.cmd_off)
*state = ACERHDF_FAN_AUTO;
else
*state = ACERHDF_FAN_OFF;
@@ -310,13 +318,13 @@ static void acerhdf_change_fanstate(int state)
state = ACERHDF_FAN_AUTO;
}
 
-   cmd = (state == ACERHDF_FAN_OFF) ? bios_cfg->cmd.cmd_off
-: bios_cfg->cmd.cmd_auto;
+   cmd = (state == ACERHDF_FAN_OFF) ? ctrl_cfg.cmd.cmd_off
+: ctrl_cfg.cmd.cmd_auto;
fanstate = state;
 
-   ec_write(bios_cfg->fanreg, cmd);
+   ec_write(ctrl_cfg.fanreg, cmd);
 
-   if (bios_cfg->mcmd_enable && state == ACERHDF_FAN_OFF) {
+   if (ctrl_cfg.mcmd_enable && state == ACERHDF_FAN_OFF) {
if (verbose)
pr_notice("turning off fan manually\n");
ec_write(mcmd.mreg, mcmd.moff);
@@ -623,6 +631,7 @@ static int __init acerhdf_check_hardware(void)
 {
char const *vendor, *version, *product;
const struct bios_settings *bt = NULL;
+   int found = 0;
 
/* get BIOS data */
vendor  = dmi_get_system_info(DMI_SYS_VENDOR);
@@ -672,17 +681,23 @@ static int __init acerhdf_check_hardware(void)
if (str_starts_with(vendor, bt->vendor) &&
str_starts_with(product, bt->product) &&
str_starts_with(version, bt->version)) {
-   bios_cfg = bt;
+   found = 1;
break;
}
}
 
-   if (!bios_cfg) {
+   if (!found) {
pr_err("unknown (unsupported) BIOS version %s/%s/%s, please 
report, aborting!\n",
   vendor, product, version);
return -EINVAL;
}
 
+   /* Copy control settings from BIOS table before we free it. */
+   ctrl_cfg.fanreg = bt->fanreg;
+   ctrl_cfg.tempreg = bt->tempreg;
+   memcpy(_cfg.cmd, >cmd, sizeof(struct fancmd));
+   ctrl_cfg.mcmd_enable = bt->mcmd_enable;
+
/*
 * if started with kernel mode off, prevent the kernel from 

[PATCH 5/6] platform/x86: acerhdf: mark appropriate content with __init prefix

[Paul Gortmaker]

These three functions are only called from the probe code which is
already marked __init and hence these can be __init as well.

Cc: Peter Feuerer 
Cc: Darren Hart 
Cc: Andy Shevchenko 
Signed-off-by: Paul Gortmaker 
---
 drivers/platform/x86/acerhdf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index eddcd8e94a88..5f579fcde315 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -619,7 +619,7 @@ static int str_starts_with(const char *str, const char 
*start)
 }
 
 /* check hardware */
-static int acerhdf_check_hardware(void)
+static int __init acerhdf_check_hardware(void)
 {
char const *vendor, *version, *product;
const struct bios_settings *bt = NULL;
@@ -695,7 +695,7 @@ static int acerhdf_check_hardware(void)
return 0;
 }
 
-static int acerhdf_register_platform(void)
+static int __init acerhdf_register_platform(void)
 {
int err = 0;
 
@@ -727,7 +727,7 @@ static void acerhdf_unregister_platform(void)
platform_driver_unregister(_driver);
 }
 
-static int acerhdf_register_thermal(void)
+static int __init acerhdf_register_thermal(void)
 {
cl_dev = thermal_cooling_device_register("acerhdf-fan", NULL,
 _cooling_ops);
-- 
2.15.0

Re: [PATCH v7 3/4] dt-bindings: power: supply: qcom_bms: Add bindings

[Sebastian Reichel]

Hi,

On Fri, Sep 21, 2018 at 04:08:28AM +0800, Baolin Wang wrote:
> Hi Sebastian,
> 
> On 21 September 2018 at 00:58, Sebastian Reichel
>  wrote:
> > [Dropped a couple of people from CC, added Baolin]
> >
> > Hi Craig, Baolin and Rob,
> >
> > On Thu, Sep 20, 2018 at 03:32:29PM +0100, Craig wrote:
> >> On 16 September 2018 13:10:45 BST, Sebastian Reichel 
> >>  wrote:
> >> >Sorry for my long delay in reviewing this. I like the binding,
> >> >but the "qcom," specific properties should become common properties
> >> >in
> >> >
> >> >Documentation/devicetree/bindings/power/supply/battery.txt
> >> >and referenced via monitored-battery.
> >
> >> Thanks for the review, what bindings for ocv would you prefer? The
> >> spreadtrum ones or mine?
> >
> > Most importantly I want to see only one generic binding supporting
> > both use cases. As far as I can see there are two major differences:
> >
> > 1. Qcom uses legend properties and SC27XX embedds this into data
> > 2. Qcom supports temperature based mapping
> >
> > The second point is easy: Not having temperature information can
> > be a subset of the data with temperature info. The main thing to
> > discuss are the legend properties. I suppose we have these
> > proposals:
> >
> > Proposal A (from Qcom BMS binding):
> >
> > ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 70 65 60 55 50 45 ...>;
> > ocv-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>;
> > ocv-lut-microvolt = <4305 4305 4303 4299
> >
> > Proposal B (from SC27XX binding):
> >
> > ocv-cap-table = <4185 100>, <4113 95>, <4066 90>, <4022 85> ...;
> >
> > I prefer the second binding (with mV -> uV), but I think it becomes
> > messy when temperature is added. What do you think about the
> > following proposal (derived from pinctrl style):
> >
> > Proposal C:
> >
> > ocv-capacity-table-temperatures = <(-10) 0 10>;
> > ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
> > ocv-capacity-table-1 = <420 100>, <4185000 95>, <4113000 90>, ...;
> > ocv-capacity-table-2 = <425 100>, <420 95>, <4185000 90>, ...;
> 
> For SC27XX, we have no temperatures consideration, but I think
> Proposal C can be compatible with our case.

Yes. I think for SC27XX proposal C could be used like this:

ocv-capacity-table-temperatures = <20>; /* room temperature */
ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;

With only one curve defined it would be used for all temperatures.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v7 3/4] dt-bindings: power: supply: qcom_bms: Add bindings

[Sebastian Reichel]

On Thu, Sep 20, 2018 at 08:13:52PM +0100, Craig wrote:
> On 20 September 2018 17:58:47 BST, Sebastian Reichel 
>  wrote:
> >[Dropped a couple of people from CC, added Baolin]
> >
> >Hi Craig, Baolin and Rob,
> >
> >On Thu, Sep 20, 2018 at 03:32:29PM +0100, Craig wrote:
> >> On 16 September 2018 13:10:45 BST, Sebastian Reichel
> > wrote:
> >> >Sorry for my long delay in reviewing this. I like the binding,
> >> >but the "qcom," specific properties should become common properties
> >> >in
> >> >
> >> >Documentation/devicetree/bindings/power/supply/battery.txt
> >> >and referenced via monitored-battery.
> >
> >> Thanks for the review, what bindings for ocv would you prefer? The
> >> spreadtrum ones or mine?
> >
> >Most importantly I want to see only one generic binding supporting
> >both use cases. As far as I can see there are two major differences:
> >
> >1. Qcom uses legend properties and SC27XX embedds this into data
> >2. Qcom supports temperature based mapping
> >
> >The second point is easy: Not having temperature information can
> >be a subset of the data with temperature info. The main thing to
> >discuss are the legend properties. I suppose we have these
> >proposals:
> >
> >Proposal A (from Qcom BMS binding):
> >
> >ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 70 65 60 55 50 45
> >...>;
> >ocv-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>;
> >ocv-lut-microvolt = <4305 4305 4303 4299
> >
> >Proposal B (from SC27XX binding):
> >
> >ocv-cap-table = <4185 100>, <4113 95>, <4066 90>, <4022 85> ...;
> >
> >I prefer the second binding (with mV -> uV), but I think it becomes
> >messy when temperature is added. What do you think about the
> >following proposal (derived from pinctrl style):
> >
> >Proposal C:
> >
> >ocv-capacity-table-temperatures = <(-10) 0 10>;
> >ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
> >ocv-capacity-table-1 = <420 100>, <4185000 95>, <4113000 90>, ...;
> >ocv-capacity-table-2 = <425 100>, <420 95>, <4185000 90>, ...;
> >
> >-- Sebastian
> 
> C looks good to me however I do kinda think it should be
> millivolts as I don't think any hardware reads in microvolts and
> the zeroes make it look quite ugly

I agree, that it looks a bit ugly in the table. Nevertheless I think we
should use microvolts, since that is being used by all other properties.

-- Sebastian


signature.asc
Description: PGP signature