[PATCH v1] iio: adc: modify NPCM ADC read reference voltage

[Tomer Maimon]

Checking if regulator is valid before reading
NPCM ADC regulator voltage to avoid system crash
in a case the regulator is not valid.

Signed-off-by: Tomer Maimon 
---
 drivers/iio/adc/npcm_adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
index 9e25bbec9c70..193b3b81de4d 100644
--- a/drivers/iio/adc/npcm_adc.c
+++ b/drivers/iio/adc/npcm_adc.c
@@ -149,7 +149,7 @@ static int npcm_adc_read_raw(struct iio_dev *indio_dev,
}
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
-   if (info->vref) {
+   if (!IS_ERR(info->vref)) {
vref_uv = regulator_get_voltage(info->vref);
*val = vref_uv / 1000;
} else {
-- 
2.14.1

[PATCH] regulator: bd718x7: Use rdev_get_id() to get regulator id

[Axel Lin]

Use rdev_get_id() instead of directly access rdev->desc->id.
While at it also remove unneeded init for ramp_value variable.

Signed-off-by: Axel Lin 
---
 drivers/regulator/bd718x7-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/bd718x7-regulator.c 
b/drivers/regulator/bd718x7-regulator.c
index b2191be49670..fde4264da6ff 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -27,8 +27,8 @@
 static int bd718xx_buck1234_set_ramp_delay(struct regulator_dev *rdev,
   int ramp_delay)
 {
-   int id = rdev->desc->id;
-   unsigned int ramp_value = BUCK_RAMPRATE_10P00MV;
+   int id = rdev_get_id(rdev);
+   unsigned int ramp_value;
 
dev_dbg(&rdev->dev, "Buck[%d] Set Ramp = %d\n", id + 1,
ramp_delay);
-- 
2.17.1

Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules

[Masahiro Yamada]

(+CC Jonas Gorski)


On Tue, Mar 26, 2019 at 6:58 PM Wiebe, Wladislav (Nokia - DE/Ulm)
 wrote:
>
> Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
> was intended to give KBUILD_MODPOST_WARN flexibility to be configurable.
> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
> set which happens per default when building modules out of the tree.
>
> This change gives the opportunity to define module build behaving also
> in case of out of tree builds and default will become exit on error.
> Errors which can be detected by the build should be trapped out of the box
> there, unless somebody wants to notice broken stuff later at runtime.

If an external module refers to a symbol
provided by another external module,
this patch will turn the warning into the error by default,
which is probably a bad idea.


I suggested a desired change in the following.
https://patchwork.kernel.org/patch/9980691/

I am poking Jonas Gorski
if he plans to send v2.


> Signed-off-by: Wladislav Wiebe 
> ---
>  scripts/Makefile.modpost | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> index 6b7f354f189a..fec6ec2ffa47 100644
> --- a/scripts/Makefile.modpost
> +++ b/scripts/Makefile.modpost
> @@ -78,7 +78,7 @@ modpost = scripts/mod/modpost\
>   $(if $(KBUILD_EXTRA_SYMBOLS), $(patsubst %, -e %,$(KBUILD_EXTRA_SYMBOLS))) \
>   $(if $(KBUILD_EXTMOD),-o $(modulesymfile))  \
>   $(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E)  \
> - $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
> + $(if $(KBUILD_MODPOST_WARN),-w)
>
>  MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
>
> --
> 2.19.2



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/6] kbuild: pass $(MAKECMDGOALS) to sub-make as is

[Masahiro Yamada]

On Sat, Mar 30, 2019 at 9:04 PM Masahiro Yamada
 wrote:
>
> Manipulating $(MAKECMDGOALS) for sub-make seems odd to me.
>
> [1] 'make O=foo sub-make' is turned into 'make O=foo', which builds
> the default targets. It would make sense to terminate the build with:
>
>   *** No rule to make target 'sub-make'.  Stop.
>
> [2] 'make O=foo defconfig _all' is turned into 'make O=foo defconfig',
> which changes the behavior.
>
> Let's pass $(MAKECMDGOALS) as is.
>
> Signed-off-by: Masahiro Yamada 
> ---

Series, applied to linux-kbuild.


>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 92ad066..9cbd367 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -168,7 +168,7 @@ $(filter-out _all sub-make $(lastword $(MAKEFILE_LIST)), 
> $(MAKECMDGOALS)) _all:
>  sub-make:
> $(Q)$(MAKE) \
> $(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
> -   -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
> +   -f $(CURDIR)/Makefile $(MAKECMDGOALS)
>
>  endif # need-sub-make
>  endif # sub_make_done
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada

Re: 8b275b3754 ("x86/irq/64: Remap the IRQ stack with guard pages"): BUG: unable to handle kernel paging request at ffffb659000a1000

[Thomas Gleixner]

On Sat, 6 Apr 2019, Andy Lutomirski wrote:
> I haven't spotted the actual bug yet, but the faulting instruction is:
> 
>   2a:65 8b 35 09 ca 75 63 mov%gs:*0x6375ca09(%rip),%esi
> # 0x6375ca3a<-- trapping instruction
> 
> This seems to be faulting just above the top of the stack (the thing
> in RSP), so I suspect that there is some path that is shoving the
> remapped value into GSBASE, which is wrong.
> 
> Also, FWIW, there was some reason that I initialized all the virtual
> mappings for all possible CPUs early.  I don't remember what it was,
> and it may not have been a good reason, but I put at least some
> nonzero amount of thought into it :)

There is absolutely no reason to have irq stacks before init_IRQ(). 32bit
uses at runtime allocated irq stacks for years.

If the CPU takes a device interrupt before that, then there are way more
things which explode than just the irqstack pointer being NULL.

Thanks,

tglx

Re: [patch V2 28/29] x86/irq/64: Remap the IRQ stack with guard pages

[Andy Lutomirski]

> On Apr 6, 2019, at 11:08 PM, Thomas Gleixner  wrote:
> 
>> On Sat, 6 Apr 2019, Andy Lutomirski wrote:
>>> On Fri, Apr 5, 2019 at 8:11 AM Thomas Gleixner  wrote:
>>> 
>>> From: Andy Lutomirski 
>>> 
>>> The IRQ stack lives in percpu space, so an IRQ handler that overflows it
>>> will overwrite other data structures.
>>> 
>>> Use vmap() to remap the IRQ stack so that it will have the usual guard
>>> pages that vmap/vmalloc allocations have. With this the kernel will panic
>>> immediately on an IRQ stack overflow.
>> 
>> The 0day bot noticed that this dies with DEBUG_PAGEALLOC on.  This is
>> because the store_stackinfo() function is utter garbage and this patch
>> correctly detects just how broken it is.  The attached patch "fixes"
>> it.  (It also contains a reliability improvement that should probably
>> get folded in, but is otherwise unrelated.)
>> 
>> A real fix would remove the generic kstack_end() function entirely
>> along with __HAVE_ARCH_KSTACK_END and would optionally replace
>> store_stackinfo() with something useful.  Josh, do we have a generic
>> API to do a little stack walk like this?  Otherwise, I don't think it
>> would be the end of the world to just remove the offending code.
> 
> Yes, I found the same yesterday before heading out. It's already broken
> with the percpu stack because there is no guarantee that the per cpu stack
> is thread size aligned. It's guaranteed to be page aligned not more.
> 
> I'm all for removing that nonsense, but the real question is whether there
> is more code which assumes THREAD_SIZE aligned stacks aside of the thread
> stack itself.
> 
> 

Well, any code like this is already busted, since the stacks alignment doesn’t 
really change with these patches applied.

Re: 8b275b3754 ("x86/irq/64: Remap the IRQ stack with guard pages"): BUG: unable to handle kernel paging request at ffffb659000a1000

[Andy Lutomirski]

> On Apr 7, 2019, at 2:23 AM, Thomas Gleixner  wrote:
> 
>> On Sat, 6 Apr 2019, Andy Lutomirski wrote:
>> I haven't spotted the actual bug yet, but the faulting instruction is:
>> 
>>  2a:65 8b 35 09 ca 75 63 mov%gs:*0x6375ca09(%rip),%esi
>># 0x6375ca3a<-- trapping instruction
>> 
>> This seems to be faulting just above the top of the stack (the thing
>> in RSP), so I suspect that there is some path that is shoving the
>> remapped value into GSBASE, which is wrong.
>> 
>> Also, FWIW, there was some reason that I initialized all the virtual
>> mappings for all possible CPUs early.  I don't remember what it was,
>> and it may not have been a good reason, but I put at least some
>> nonzero amount of thought into it :)
> 
> There is absolutely no reason to have irq stacks before init_IRQ(). 32bit
> uses at runtime allocated irq stacks for years.
> 
> If the CPU takes a device interrupt before that, then there are way more
> things which explode than just the irqstack pointer being NULL.
> 

Fair enough.  Although the patch I emailed in the other thread allows at least 
the entry code to survive on 64-bit at the cost of just a couple lines of code.

But the kernel does indeed seem to work fine without the change. Feel free to 
disregard that part :)

Re: [patch V2 28/29] x86/irq/64: Remap the IRQ stack with guard pages

[Thomas Gleixner]

On Sun, 7 Apr 2019, Andy Lutomirski wrote:
> > On Apr 6, 2019, at 11:08 PM, Thomas Gleixner  wrote:
> > 
> >> On Sat, 6 Apr 2019, Andy Lutomirski wrote:
> >>> On Fri, Apr 5, 2019 at 8:11 AM Thomas Gleixner  wrote:
> >>> 
> >>> From: Andy Lutomirski 
> >>> 
> >>> The IRQ stack lives in percpu space, so an IRQ handler that overflows it
> >>> will overwrite other data structures.
> >>> 
> >>> Use vmap() to remap the IRQ stack so that it will have the usual guard
> >>> pages that vmap/vmalloc allocations have. With this the kernel will panic
> >>> immediately on an IRQ stack overflow.
> >> 
> >> The 0day bot noticed that this dies with DEBUG_PAGEALLOC on.  This is
> >> because the store_stackinfo() function is utter garbage and this patch
> >> correctly detects just how broken it is.  The attached patch "fixes"
> >> it.  (It also contains a reliability improvement that should probably
> >> get folded in, but is otherwise unrelated.)
> >> 
> >> A real fix would remove the generic kstack_end() function entirely
> >> along with __HAVE_ARCH_KSTACK_END and would optionally replace
> >> store_stackinfo() with something useful.  Josh, do we have a generic
> >> API to do a little stack walk like this?  Otherwise, I don't think it
> >> would be the end of the world to just remove the offending code.
> > 
> > Yes, I found the same yesterday before heading out. It's already broken
> > with the percpu stack because there is no guarantee that the per cpu stack
> > is thread size aligned. It's guaranteed to be page aligned not more.
> > 
> > I'm all for removing that nonsense, but the real question is whether there
> > is more code which assumes THREAD_SIZE aligned stacks aside of the thread
> > stack itself.
> > 
> > 
> Well, any code like this is already busted, since the stacks alignment
> doesn’t really change with these patches applied.

It does. The existing code has it aligned by chance because the irq stack
is the first entry in the per cpu area. But yes, there is no reason to require
that alignment for irqstacks.

Thanks,

tglx

[PATCH] kbuild: remove unneeded dependency for include/config/kernel.release

[Masahiro Yamada]

This is unneeded since commit 43fee2b23895 ("kbuild: do not redirect
the first prerequisite for filechk").

Signed-off-by: Masahiro Yamada 
---

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 895022b..10643c3 100644
--- a/Makefile
+++ b/Makefile
@@ -1067,7 +1067,7 @@ filechk_kernel.release = \
echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
 
 # Store (new) KERNELRELEASE string in include/config/kernel.release
-include/config/kernel.release: $(srctree)/Makefile FORCE
+include/config/kernel.release: FORCE
$(call filechk,kernel.release)
 
 # Additional helpers built in scripts/
-- 
2.7.4

Re: [PATCH 3/3] iio: Add PAT9125 optical tracker sensor

[Jonathan Cameron]

On Fri,  5 Apr 2019 09:34:30 +
Alexandre Mergnat  wrote:

> This adds support for PixArt Imaging’s miniature low power
> optical navigation chip using LASER light source
> enabling digital surface tracking.

Hi Alexandre,

So I have no problem with this as an IIO driver, but for devices that
are somewhat 'on the edge' I always like to get a clear answer to the
question: Why not input?

I would also argue that, to actually be 'useful' we would typically need
some representation of the 'mechanicals' that are providing the motion
being measured.  Looking at the datasheet this includes, rotating shafts
(side or end on), disk edges and flat surface tracking (mouse like).

That's easy enough to do with the iio in kernel consumer interface. These
are similar to when we handle analog electronic front ends.

I you can, please describe what it is being used for in your application
as that may give us somewhere to start!

+ CC Dmitry and linux-input.

> 
> This IIO driver allow to read delta position on 2 axis (X and Y).
> The values can be taken through ponctual "read_raw" which will issue
> a read in the device registers to return the deltas or subscribe
> to the data buffer feed automaticaly by a new value using a
> trigger gpio. The buffer payload is: |16 bits delta X|16 bits delta 
> Y|timestamp|.
> The possible I2C adresses are 0x73, 0x75 and 0x79.
> 
> Unfortunately, the device configuration must be hardcoded in the 
> initialization
> function and can't be changed "on-the-fly" in user space due to the lack of
> configuration interface.
> 
> The "ot" directory is added to coutain Optical Tracker drivers.
From a shared interface point of view we don't really care 'how', but rather 
'what'.
So arguably this is actually measuring differential position, or sort of
'velocity'.  I think it should probably be mapped to simple position though.  
See
below.

> 
> Signed-off-by: Alexandre Mergnat 

Comments inline.

> ---
>  drivers/iio/Kconfig  |   1 +
>  drivers/iio/Makefile |   1 +
>  drivers/iio/ot/Kconfig   |  16 ++
>  drivers/iio/ot/Makefile  |   6 +
>  drivers/iio/ot/pat9125.c | 407 
> +++
>  5 files changed, 431 insertions(+)
>  create mode 100644 drivers/iio/ot/Kconfig
>  create mode 100644 drivers/iio/ot/Makefile
>  create mode 100644 drivers/iio/ot/pat9125.c
> 
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index d08aeb4..bdf1bd0 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -86,6 +86,7 @@ source "drivers/iio/light/Kconfig"
>  source "drivers/iio/magnetometer/Kconfig"
>  source "drivers/iio/multiplexer/Kconfig"
>  source "drivers/iio/orientation/Kconfig"
> +source "drivers/iio/ot/Kconfig"
>  if IIO_TRIGGER
> source "drivers/iio/trigger/Kconfig"
>  endif #IIO_TRIGGER
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index cb59932..fdda2e1 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -32,6 +32,7 @@ obj-y += light/
>  obj-y += magnetometer/
>  obj-y += multiplexer/
>  obj-y += orientation/
> +obj-y += ot/
>  obj-y += potentiometer/
>  obj-y += potentiostat/
>  obj-y += pressure/
> diff --git a/drivers/iio/ot/Kconfig b/drivers/iio/ot/Kconfig
> new file mode 100644
> index 000..3d17fda
> --- /dev/null
> +++ b/drivers/iio/ot/Kconfig
> @@ -0,0 +1,16 @@
> +#
> +# Optical tracker sensors
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Optical tracker sensors"
> +
> +config PAT9125
> + tristate "Optical tracker PAT9125 I2C driver"
> + depends on I2C
> + select IIO_BUFFER
> + help
> +   Say yes here to build support for PAT9125 optical tracker
> +   sensors.
> +
> +endmenu
> diff --git a/drivers/iio/ot/Makefile b/drivers/iio/ot/Makefile
> new file mode 100644
> index 000..cf29491
> --- /dev/null
> +++ b/drivers/iio/ot/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for industrial I/O Optical tracker sensor drivers
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_PAT9125) += pat9125.o
> diff --git a/drivers/iio/ot/pat9125.c b/drivers/iio/ot/pat9125.c
> new file mode 100644
> index 000..f416bfa
> --- /dev/null
> +++ b/drivers/iio/ot/pat9125.c
> @@ -0,0 +1,407 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Copyright (C) 2018 BayLibre, SAS

Probably going to need to add 2019!

> + * Author: Alexandre Mergnat 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* I2C Address function to ID pin*/
> +#define PAT9125_I2C_ADDR_HI  0x73
> +#define PAT9125_I2C_ADDR_LO  0x75
> +#define PAT9125_I2C_ADDR_NC  0x79
> +
> +/* Registers */
> +#define PAT9125_PRD_ID1_REG  0x00
> +#define PAT9125_PRD_ID2_REG  0x01
> +#define PAT9125_MOTION_STATUS_REG0x02
> +#define PAT9125_DELTA_X_LO_REG   0x03
> +#define PAT9125_DE

Re: [PATCH v1] iio: adc: modify NPCM ADC read reference voltage

[Jonathan Cameron]

On Sun,  7 Apr 2019 11:19:28 +0300
Tomer Maimon  wrote:

> Checking if regulator is valid before reading
> NPCM ADC regulator voltage to avoid system crash
> in a case the regulator is not valid.
> 
> Signed-off-by: Tomer Maimon 
Good catch.

Applied to the fixes-togreg branch of iio.git and marked for
stable.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/npcm_adc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
> index 9e25bbec9c70..193b3b81de4d 100644
> --- a/drivers/iio/adc/npcm_adc.c
> +++ b/drivers/iio/adc/npcm_adc.c
> @@ -149,7 +149,7 @@ static int npcm_adc_read_raw(struct iio_dev *indio_dev,
>   }
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_SCALE:
> - if (info->vref) {
> + if (!IS_ERR(info->vref)) {
>   vref_uv = regulator_get_voltage(info->vref);
>   *val = vref_uv / 1000;
>   } else {

Help!!

[Ms. Heba Oudeh]

Dear sir/Madam,

Greetings! I would like to apologize for barging into your privacy without your 
concent. My name is Heba Oudeh from Damascus Syria and i am 29 years old orphan.

I have decided to make this contact after many thoughts and hard decision. On 
27 may 2017 i lost my parents to the Syrian war in one day and since then i 
have been in the refugee camp where am been raped every other day with no one 
to come to my aid. It is rather risky for me to send this mail and would be 
punished if caught but i have no choice than to take the risk and either die or 
be completely freed.

I have contacted you for help. I have come to realize that all my late father's 
investments were made here and have been destroyed as well except a little 
money he has in his foreign account in the U.S.A. Before i was taken to the 
camp i discovered he has deposited the sum of $1,875,000USD in an American bank 
with me as next-of-kin. I have contacted the bank to explain things to them and 
they have agreed to accept anybody i would present as the new next-of-kin so 
they will transfer they money to the person since i can not transfer the money 
to Syria.

The decision to make you the next-of-kin was not made because i need this money 
but because i want to leave this country to a better and safer place. All i 
need from you is to receive this money and make arrangement for me to join you 
in your country so i can complete my education and the remaining money can be 
invested in a business which both of us will be co-owners/partners and share 
profit equally. This might sound stupid but only option for me.

If you feel you will be able to help me on this, please let me know as soon as 
you can so i can contact the bank to know the steps to be taken and what is 
reqired from our side. I will give you a copy of my ID in my next mail.

Thanks,
Heba.

Re: [PATCH] iio: accell: mma8452: free iio trigger pointer when cleanup

[Jonathan Cameron]

On Thu, 4 Apr 2019 08:02:05 +
Anson Huang  wrote:

> When mma8452 is built as module, once it is insmod and rmmod, below
> kernel dump will show out, the root cause is module being put twice
> if iio trigger pointer is NOT NULL, this patch frees iio trigger
> pointer after iio trigger is unregistered to avoid below kernel
> dump:
> 
> [ cut here ]
> WARNING: CPU: 3 PID: 270 at kernel/module.c:1145 module_put+0xd0/0x188
> Modules linked in: mma8452(-)
> CPU: 3 PID: 270 Comm: rmmod Not tainted 
> 5.1.0-rc3-next-20190403-00022-g5ede0c9-dirty #1596
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xd8/0x10c)
> [] (dump_stack) from [] (__warn+0xf8/0x124)
> [] (__warn) from [] (warn_slowpath_null+0x3c/0x48)
> [] (warn_slowpath_null) from [] (module_put+0xd0/0x188)
> [] (module_put) from [] 
> (iio_device_unregister_trigger_consumer+0x18/0x24)
> [] (iio_device_unregister_trigger_consumer) from [] 
> (iio_dev_release+0x20/0)
> [] (iio_dev_release) from [] (device_release+0x24/0x8c)
> [] (device_release) from [] (kobject_put+0x74/0xd4)
> [] (kobject_put) from [] (release_nodes+0x16c/0x1f0)
> [] (release_nodes) from [] 
> (device_release_driver_internal+0xec/0x1a0)
> [] (device_release_driver_internal) from [] 
> (driver_detach+0x44/0x80)
> [] (driver_detach) from [] (bus_remove_driver+0x4c/0xa0)
> [] (bus_remove_driver) from [] 
> (sys_delete_module+0x130/0x1dc)
> [] (sys_delete_module) from [] (ret_fast_syscall+0x0/0x28)
> Exception stack(0xe8d87fa8 to 0xe8d87ff0)
> 7fa0:   0001ffc0 38616d6d be87bbf0 0880  be87be98
> 7fc0: 0001ffc0 38616d6d 00323534 0081 000a9744 be87bf81 000a9790 
> 7fe0: be87bbe8 be87bbd8 0001fe18 b6e381a0
> irq event stamp: 4017
> hardirqs last  enabled at (4035): [] console_unlock+0x400/0x630
> hardirqs last disabled at (4052): [] console_unlock+0x80/0x630
> softirqs last  enabled at (4050): [] __do_softirq+0x458/0x554
> softirqs last disabled at (4069): [] irq_exit+0x130/0x180
> ---[ end trace a7ba8f1823b1e073 ]---
> 
> Signed-off-by: Anson Huang 
Good fine, but the fix is not in the best place.  The key thing is that
any assignment inside a driver to iio_dev->trig should be done
with iio_trigger_get.

indio_dev->trig = iio_trigger_get(trig).  The intent is to avoid this
exact double free, but also handle it correctly if we are using
devm_ for all the handling.

I just did a grep and there are quite a few drivers not doing this though
so it's one we should be more careful about.

Hmm. Anyone fancy doing an audit of existing drivers and checking which
ones have this problem?  Some seem to do exactly what you have
here, but that isn't a the best pattern to encourage.

For this one would you mind trying with the iio_trigger_get
approach and if I'm not missing something, send a v2 fixing it
that way?

Thanks

Jonathan


> ---
>  drivers/iio/accel/mma8452.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 3027811..6b18177 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1475,8 +1475,10 @@ static int mma8452_trigger_setup(struct iio_dev 
> *indio_dev)
>  
>  static void mma8452_trigger_cleanup(struct iio_dev *indio_dev)
>  {
> - if (indio_dev->trig)
> + if (indio_dev->trig) {
>   iio_trigger_unregister(indio_dev->trig);
> + indio_dev->trig = NULL;
> + }
>  }
>  
>  static int mma8452_reset(struct i2c_client *client)

Re: [PATCH] staging: iio: frequency: ad9834: Remove unnecessary parentheses

[Jonathan Cameron]

On Tue, 2 Apr 2019 17:18:54 -0300
Melissa Wen  wrote:

> Remove unneeded parentheses around the arguments of ||. This reduces
> clutter and code behave in the same way. Change suggested by
> checkpatch.pl.
> 
> CHECK: Unnecessary parentheses around 'st->devid == ID_AD9833'
> CHECK: Unnecessary parentheses around 'st->devid == ID_AD9837'
> 
> Signed-off-by: Melissa Wen 
This isn't one I feel strongly about, but it'll get rid of the warning
so is useful in the sense of cleaning up what we have to look at there!

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/frequency/ad9834.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9834.c 
> b/drivers/staging/iio/frequency/ad9834.c
> index 0b0287503fb4..9cc6e751b479 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -286,7 +286,7 @@ ssize_t ad9834_show_out0_wavetype_available(struct device 
> *dev,
>   struct ad9834_state *st = iio_priv(indio_dev);
>   char *str;
>  
> - if ((st->devid == ID_AD9833) || (st->devid == ID_AD9837))
> + if (st->devid == ID_AD9833 || st->devid == ID_AD9837)
>   str = "sine triangle square";
>   else if (st->control & AD9834_OPBITEN)
>   str = "sine";

[PATCH] kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build

[Masahiro Yamada]

After cross-compiling the kernel, "make mrproper" should be executed
with the proper ARCH= option. Otherwise, stale objects will remain
under arch/$(SRCARCH)/.

One bad scenario is like this:

  $ make ARCH=arm defconfig all   # cross-compile the kernel for arm
  $ make mrproper # mrproper for host-arch (i.e. x86)
  $ make ARCH=arm O=build_dir defconfig all

If you miss ARCH= for mrproper and cross-compile the kernel with O=
and ARCH= options, Kbuild will happily start to build, but may fail
due to stale objects in the srctree.

If $(srctree)/arch/$(SRCARCH)/include/generated/ exists, let's stop
the out-of-tree build. To detect this, mrproper should clean only
arch/$(SRCARCH)/include/generated/.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 10643c3..17945ce 100644
--- a/Makefile
+++ b/Makefile
@@ -1091,7 +1091,9 @@ PHONY += prepare archprepare prepare1 prepare3
 prepare3: include/config/kernel.release
 ifneq ($(srctree),.)
@$(kecho) '  Using $(srctree) as source for kernel'
-   $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
+   $(Q)if [ -f $(srctree)/.config -o \
+-d $(srctree)/include/config -o \
+-d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
echo >&2 "  $(srctree) is not clean, please run 'make 
mrproper'"; \
echo >&2 "  in the '$(srctree)' directory.";\
/bin/false; \
@@ -1350,7 +1352,7 @@ CLEAN_DIRS  += $(MODVERDIR) include/ksym
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config usr/include include/generated  \
- arch/*/include/generated .tmp_objdiff
+ arch/$(SRCARCH)/include/generated .tmp_objdiff
 MRPROPER_FILES += .config .config.old .version \
  Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
  signing_key.pem signing_key.priv signing_key.x509 \
-- 
2.7.4

Re: [PATCH 1/3] iio: adc: ad7606: Move oversampling options in chip info and rework *_avail attributes

[Jonathan Cameron]

On Tue, 2 Apr 2019 16:18:39 +0300
Beniamin Bia  wrote:

> From: Stefan Popa 
> 
> Available oversampling ratios and scales can be shown by calling a
> common ad7606_show_avail function which takes as parameters the array
> which stores the values, together with the size of the array.
> 
> Oversampling options are now defined in chip info
> structure and they are loaded at probe.
> 
> Has_Oversampling attribute was removed because oversampling_num was added
> and it is not needed anymore.
> 
> The purpose of this patch is to deal with the scale_avail and
> oversampling_avail arrays in a generic way. This makes it easier to add
> support for new devices which will work with different scales and
> oversampling ratios. It is also an intermediate step for adding support
> for ad7616 which has different oversampling sampling ratios available.
> 
> Signed-off-by: Stefan Popa 
> Signed-off-by: Beniamin Bia 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/ad7606.c | 74 
>  drivers/iio/adc/ad7606.h | 16 +++--
>  2 files changed, 67 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index ebb8de03bbce..6b87ed410c93 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -31,7 +31,7 @@
>   * Scales are computed as 5000/32768 and 1/32768 respectively,
>   * so that when applied to the raw values they provide mV values
>   */
> -static const unsigned int scale_avail[2] = {
> +static const unsigned int ad7606_scale_avail[2] = {
>   152588, 305176
>  };
>  
> @@ -154,7 +154,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_SCALE:
>   *val = 0;
> - *val2 = scale_avail[st->range];
> + *val2 = st->scale_avail[st->range];
>   return IIO_VAL_INT_PLUS_MICRO;
>   case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
>   *val = st->oversampling;
> @@ -163,21 +163,31 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>   return -EINVAL;
>  }
>  
> -static ssize_t in_voltage_scale_available_show(struct device *dev,
> -struct device_attribute *attr,
> -char *buf)
> +static ssize_t ad7606_show_avail(char *buf, const unsigned int *vals,
> +  unsigned int n, bool micros)
>  {
> - int i, len = 0;
> -
> - for (i = 0; i < ARRAY_SIZE(scale_avail); i++)
> - len += scnprintf(buf + len, PAGE_SIZE - len, "0.%06u ",
> -  scale_avail[i]);
> + size_t len = 0;
> + int i;
>  
> + for (i = 0; i < n; i++) {
> + len += scnprintf(buf + len, PAGE_SIZE - len,
> + micros ? "0.%06u " : "%u ", vals[i]);
> + }
>   buf[len - 1] = '\n';
>  
>   return len;
>  }
>  
> +static ssize_t in_voltage_scale_available_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ad7606_state *st = iio_priv(indio_dev);
> +
> + return ad7606_show_avail(buf, st->scale_avail, st->num_scales, true);
> +}
> +
>  static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
>  
>  static int ad7606_write_raw(struct iio_dev *indio_dev,
> @@ -193,7 +203,7 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
>   switch (mask) {
>   case IIO_CHAN_INFO_SCALE:
>   mutex_lock(&st->lock);
> - i = find_closest(val2, scale_avail, ARRAY_SIZE(scale_avail));
> + i = find_closest(val2, st->scale_avail, st->num_scales);
>   gpiod_set_value(st->gpio_range, i);
>   st->range = i;
>   mutex_unlock(&st->lock);
> @@ -202,15 +212,15 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
>   if (val2)
>   return -EINVAL;
> - i = find_closest(val, ad7606_oversampling_avail,
> -  ARRAY_SIZE(ad7606_oversampling_avail));
> + i = find_closest(val, st->oversampling_avail,
> +  st->num_os_ratios);
>  
>   values[0] = i;
>  
>   mutex_lock(&st->lock);
>   gpiod_set_array_value(ARRAY_SIZE(values), st->gpio_os->desc,
> st->gpio_os->info, values);
> - st->oversampling = ad7606_oversampling_avail[i];
> + st->oversampling = st->oversampling_avail[i];
>   mutex_unlock(&st->lock);
>  
>   return 0;
> @@ -219,11 +229,23 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
>   }
>  }
>  
> -static IIO_CONS

Re: [PATCH 2/3] iio: adc: ad7616: Add support for AD7616 ADC

[Jonathan Cameron]

On Tue, 2 Apr 2019 16:18:40 +0300
Beniamin Bia  wrote:

> The AD7616 is a 12-bit ADC with 16 channels.
> 
> The AD7616 can be configured to work in hardware mode by controlling it via
> gpio pins and read data via spi. No support for software mode yet, but it
> is a work in progress.
> 
> This device requires a reset in order to update oversampling, so chip info
> has got a new attribute to mark this.
> 
> The current assumption that this driver makes for AD7616, is that it's
> working in Hardware Mode with Serial, Burst and Sequencer modes activated.
> To activate them, following pins must be pulled high:
>   -SER/PAR
>   -SEQEN
> And following must be pulled low:
>   -WR/BURST
>   -DB4/SEQEN
> 
> Datasheets:
> Link: 
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7616.pdf
> 
> Signed-off-by: Beniamin Bia 
> Signed-off-by: Alexandru Ardelean 

Looks good to me. One thing to look at in future is making it completely
clear what the various people in the signed-off-by list did.  It may
be that you would ideally have a co-authored-by tag in here?  The
usecases for that have only be clarified very recently so I won't
worry too much this time.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/ad7606.c | 46 
>  drivers/iio/adc/ad7606.h |  9 ---
>  drivers/iio/adc/ad7606_spi.c |  2 ++
>  3 files changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index 6b87ed410c93..24c70c3cefb4 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -39,6 +39,10 @@ static const unsigned int ad7606_oversampling_avail[7] = {
>   1, 2, 4, 8, 16, 32, 64,
>  };
>  
> +static const unsigned int ad7616_oversampling_avail[8] = {
> + 1, 2, 4, 8, 16, 32, 64, 128,
> +};
> +
>  static int ad7606_reset(struct ad7606_state *st)
>  {
>   if (st->gpio_reset) {
> @@ -220,6 +224,11 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
>   mutex_lock(&st->lock);
>   gpiod_set_array_value(ARRAY_SIZE(values), st->gpio_os->desc,
> st->gpio_os->info, values);
> +
> + /* AD7616 requires a reset to update value */
> + if (st->chip_info->os_req_reset)
> + ad7606_reset(st);
> +
>   st->oversampling = st->oversampling_avail[i];
>   mutex_unlock(&st->lock);
>  
> @@ -314,6 +323,36 @@ static const struct iio_chan_spec ad7606_channels[] = {
>   AD7606_CHANNEL(7),
>  };
>  
> +/*
> + * The current assumption that this driver makes for AD7616, is that it's
> + * working in Hardware Mode with Serial, Burst and Sequencer modes activated.
> + * To activate them, following pins must be pulled high:
> + *   -SER/PAR
> + *   -SEQEN
> + * And following pins must be pulled low:
> + *   -WR/BURST
> + *   -DB4/SER1W
> + */
> +static const struct iio_chan_spec ad7616_channels[] = {
> + IIO_CHAN_SOFT_TIMESTAMP(16),
> + AD7606_CHANNEL(0),
> + AD7606_CHANNEL(1),
> + AD7606_CHANNEL(2),
> + AD7606_CHANNEL(3),
> + AD7606_CHANNEL(4),
> + AD7606_CHANNEL(5),
> + AD7606_CHANNEL(6),
> + AD7606_CHANNEL(7),
> + AD7606_CHANNEL(8),
> + AD7606_CHANNEL(9),
> + AD7606_CHANNEL(10),
> + AD7606_CHANNEL(11),
> + AD7606_CHANNEL(12),
> + AD7606_CHANNEL(13),
> + AD7606_CHANNEL(14),
> + AD7606_CHANNEL(15),
> +};
> +
>  static const struct ad7606_chip_info ad7606_chip_info_tbl[] = {
>   /* More devices added in future */
>   [ID_AD7605_4] = {
> @@ -338,6 +377,13 @@ static const struct ad7606_chip_info 
> ad7606_chip_info_tbl[] = {
>   .oversampling_avail = ad7606_oversampling_avail,
>   .oversampling_num = ARRAY_SIZE(ad7606_oversampling_avail),
>   },
> + [ID_AD7616] = {
> + .channels = ad7616_channels,
> + .num_channels = 17,
> + .oversampling_avail = ad7616_oversampling_avail,
> + .oversampling_num = ARRAY_SIZE(ad7616_oversampling_avail),
> + .os_req_reset = true,
> + },
>  };
>  
>  static int ad7606_request_gpios(struct ad7606_state *st)
> diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> index 8c91bd427c4e..f9ef52131e74 100644
> --- a/drivers/iio/adc/ad7606.h
> +++ b/drivers/iio/adc/ad7606.h
> @@ -15,12 +15,14 @@
>   * @oversampling_avail   pointer to the array which stores the available
>   *   oversampling ratios.
>   * @oversampling_num number of elements stored in oversampling_avail array
> + * @os_req_reset some devices require a reset to update oversampling
>   */
>  struct ad7606_chip_info {
>   const struct iio_chan_spec  *channels;
>   unsigned intnum_channels;
>   const unsigned int  *oversampling_avail;
>   un

Re: [PATCH 3/3] dt-bindings: iio: adc: Add AD7616 ADC documentation

[Jonathan Cameron]

On Sat, 06 Apr 2019 01:06:39 -0500
Rob Herring  wrote:

> On Tue, 2 Apr 2019 16:18:41 +0300, Beniamin Bia wrote:
> > Document support for AD7616 Analog to Digital Converter.
> > 
> > Signed-off-by: Beniamin Bia 
> > ---
> >  Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >   
> 
> Reviewed-by: Rob Herring 
> 

Applied to the togreg branch of iio.git and pushed out as testing.

Thanks,

Jonathan

Re: [PATCH 1/6] iio: imx7d_adc: Add local struct device pointer in imx7d_adc_probe()

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:20 -0700
Andrey Smirnov  wrote:

> Use a local "struct device *dev" in imx7d_adc_probe() for brevity. No
> functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
+CC Haibo. Not heard from Haibo recently though so may well have moved on...
As such I'm not going to wait for Haibo, but am not planning to do a pull
request this week, so plenty of time for feedback!

This one is in the (hopefully) obviously correct category.
Somewhat minor benefit, but meh, if you are going to work on the driver
then you get to do things like this if you want to ;)

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan


> ---
>  drivers/iio/adc/imx7d_adc.c | 37 ++---
>  1 file changed, 18 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index ad6764fb2a23..3bbd657409d5 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -438,51 +438,51 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   struct imx7d_adc *info;
>   struct iio_dev *indio_dev;
>   struct resource *mem;
> + struct device *dev = &pdev->dev;
>   int irq;
>   int ret;
>  
> - indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
>   if (!indio_dev) {
>   dev_err(&pdev->dev, "Failed allocating iio device\n");
>   return -ENOMEM;
>   }
>  
>   info = iio_priv(indio_dev);
> - info->dev = &pdev->dev;
> + info->dev = dev;
>  
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - info->regs = devm_ioremap_resource(&pdev->dev, mem);
> + info->regs = devm_ioremap_resource(dev, mem);
>   if (IS_ERR(info->regs)) {
>   ret = PTR_ERR(info->regs);
> - dev_err(&pdev->dev,
> - "Failed to remap adc memory, err = %d\n", ret);
> + dev_err(dev, "Failed to remap adc memory, err = %d\n", ret);
>   return ret;
>   }
>  
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
> - dev_err(&pdev->dev, "No irq resource?\n");
> + dev_err(dev, "No irq resource?\n");
>   return irq;
>   }
>  
> - info->clk = devm_clk_get(&pdev->dev, "adc");
> + info->clk = devm_clk_get(dev, "adc");
>   if (IS_ERR(info->clk)) {
>   ret = PTR_ERR(info->clk);
> - dev_err(&pdev->dev, "Failed getting clock, err = %d\n", ret);
> + dev_err(dev, "Failed getting clock, err = %d\n", ret);
>   return ret;
>   }
>  
> - info->vref = devm_regulator_get(&pdev->dev, "vref");
> + info->vref = devm_regulator_get(dev, "vref");
>   if (IS_ERR(info->vref)) {
>   ret = PTR_ERR(info->vref);
> - dev_err(&pdev->dev,
> + dev_err(dev,
>   "Failed getting reference voltage, err = %d\n", ret);
>   return ret;
>   }
>  
>   ret = regulator_enable(info->vref);
>   if (ret) {
> - dev_err(&pdev->dev,
> + dev_err(dev,
>   "Can't enable adc reference top voltage, err = %d\n",
>   ret);
>   return ret;
> @@ -492,8 +492,8 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>  
>   init_completion(&info->completion);
>  
> - indio_dev->name = dev_name(&pdev->dev);
> - indio_dev->dev.parent = &pdev->dev;
> + indio_dev->name = dev_name(dev);
> + indio_dev->dev.parent = dev;
>   indio_dev->info = &imx7d_adc_iio_info;
>   indio_dev->modes = INDIO_DIRECT_MODE;
>   indio_dev->channels = imx7d_adc_iio_channels;
> @@ -501,16 +501,15 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>  
>   ret = clk_prepare_enable(info->clk);
>   if (ret) {
> - dev_err(&pdev->dev,
> - "Could not prepare or enable the clock.\n");
> + dev_err(dev, "Could not prepare or enable the clock.\n");
>   goto error_adc_clk_enable;
>   }
>  
> - ret = devm_request_irq(info->dev, irq,
> - imx7d_adc_isr, 0,
> - dev_name(&pdev->dev), info);
> + ret = devm_request_irq(dev, irq,
> +imx7d_adc_isr, 0,
> +dev_name(dev), info);
>   if (ret < 0) {
> - dev_err(&pdev->dev, "Failed requesting irq, irq = %d\n", irq);
> + dev_err(dev, "Failed requesting irq, irq = %d\n", irq);
>   goto error_iio_device_register;
>   }
>  

Re: [PATCH 2/6] iio: imx7d_adc: Replace pr_err with dev_err

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:21 -0700
Andrey Smirnov  wrote:

> Replace combination of pr_err()/dev_name() with an equivalent call for
> dev_err().
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Applied, thanks,

Jonathan

> ---
>  drivers/iio/adc/imx7d_adc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index 3bbd657409d5..72cfe9834bcb 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -388,8 +388,9 @@ static irqreturn_t imx7d_adc_isr(int irq, void *dev_id)
>* timeout flags.
>*/
>   if (status & IMX7D_REG_ADC_INT_STATUS_CHANNEL_CONV_TIME_OUT) {
> - pr_err("%s: ADC got conversion time out interrupt: 0x%08x\n",
> - dev_name(info->dev), status);
> + dev_err(info->dev,
> + "ADC got conversion time out interrupt: 0x%08x\n",
> + status);
>   status &= ~IMX7D_REG_ADC_INT_STATUS_CHANNEL_CONV_TIME_OUT;
>   writel(status, info->regs + IMX7D_REG_ADC_INT_STATUS);
>   }

Re: [PATCH 3/6] iio: imx7d_adc: Use devm_iio_device_register()

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:22 -0700
Andrey Smirnov  wrote:

> Use devm_iio_device_register() and drop explicit call to
> iio_device_unregister().
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
No to this one.  The thing to think about is the resulting order
of the unwinding that happens in remove.

Do take a look at the code flow, but in short what happens is:

1. driver.remove()
2. Devm release functions run in the opposite order to they were
   called during setup.

The upshot of the change you just made here is that we turn the power
off to the device before we remove the userspace interfaces, giving
potentially interesting failures..

There are two options to avoid this:

1. Make everything use devm_ calls (often using devm_add_action_or_reset
for the ones that don't have their own versions).

2. Stop using devm managed functions at the first non devm_ call that needs
unwinding.  From that point onwards in probe / remove you have to do everything
manually.

Jonathan

> ---
>  drivers/iio/adc/imx7d_adc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index 72cfe9834bcb..9a46838ec7cf 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -517,7 +517,7 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   imx7d_adc_feature_config(info);
>   imx7d_adc_hw_init(info);
>  
> - ret = iio_device_register(indio_dev);
> + ret = devm_iio_device_register(dev, indio_dev);
>   if (ret) {
>   imx7d_adc_power_down(info);
>   dev_err(&pdev->dev, "Couldn't register the device.\n");
> @@ -539,8 +539,6 @@ static int imx7d_adc_remove(struct platform_device *pdev)
>   struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>   struct imx7d_adc *info = iio_priv(indio_dev);
>  
> - iio_device_unregister(indio_dev);
> -
>   imx7d_adc_power_down(info);
>  
>   clk_disable_unprepare(info->clk);

Re: [PATCH 4/6] iio: imx7d_adc: Use devm_platform_ioremap_resource()

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:23 -0700
Andrey Smirnov  wrote:

> Use devm_platform_ioremap_resource() to be able to drop a bit of
> explicit boilerplate code.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Great. That one is new to me. Looks like it only got added this cycle.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/imx7d_adc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index 9a46838ec7cf..8bba92611d54 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -438,7 +438,6 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>  {
>   struct imx7d_adc *info;
>   struct iio_dev *indio_dev;
> - struct resource *mem;
>   struct device *dev = &pdev->dev;
>   int irq;
>   int ret;
> @@ -452,8 +451,7 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   info = iio_priv(indio_dev);
>   info->dev = dev;
>  
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - info->regs = devm_ioremap_resource(dev, mem);
> + info->regs = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(info->regs)) {
>   ret = PTR_ERR(info->regs);
>   dev_err(dev, "Failed to remap adc memory, err = %d\n", ret);

Re: [PATCH 5/6] iio: imx7d_adc: Use imx7d_adc_resume() in imx7d_adc_probe()

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:24 -0700
Andrey Smirnov  wrote:

> Initialization sequence performed in imx7d_adc_resume() is exactley
> the same as what's being done in imx7d_adc_probe(). Make use of the
> former in the latter to avoid code duplication.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
I'm not to going to apply this now, due to the ordering issue with the earlier
and later patches.  However, it is fine in of itself.

I do wonder if we want to rename resume to something else to reflect
it's new usage?  imx7d_adc_enable perhaps?
Similar question for suspend in the next patch.

Thanks,

Jonathan



> ---
>  drivers/iio/adc/imx7d_adc.c | 86 +++--
>  1 file changed, 35 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index 8bba92611d54..c2fa0ab923ee 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -434,6 +434,33 @@ static void imx7d_adc_power_down(struct imx7d_adc *info)
>   writel(adc_cfg, info->regs + IMX7D_REG_ADC_ADC_CFG);
>  }
>  
> +static int imx7d_adc_resume(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct imx7d_adc *info = iio_priv(indio_dev);
> + int ret;
> +
> + ret = regulator_enable(info->vref);
> + if (ret) {
> + dev_err(info->dev,
> + "Can't enable adc reference top voltage, err = %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(info->clk);
> + if (ret) {
> + dev_err(info->dev,
> + "Could not prepare or enable clock.\n");
> + regulator_disable(info->vref);
> + return ret;
> + }
> +
> + imx7d_adc_hw_init(info);
> +
> + return 0;
> +}
> +
>  static int imx7d_adc_probe(struct platform_device *pdev)
>  {
>   struct imx7d_adc *info;
> @@ -479,14 +506,6 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - ret = regulator_enable(info->vref);
> - if (ret) {
> - dev_err(dev,
> - "Can't enable adc reference top voltage, err = %d\n",
> - ret);
> - return ret;
> - }
> -
>   platform_set_drvdata(pdev, indio_dev);
>  
>   init_completion(&info->completion);
> @@ -498,38 +517,30 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   indio_dev->channels = imx7d_adc_iio_channels;
>   indio_dev->num_channels = ARRAY_SIZE(imx7d_adc_iio_channels);
>  
> - ret = clk_prepare_enable(info->clk);
> - if (ret) {
> - dev_err(dev, "Could not prepare or enable the clock.\n");
> - goto error_adc_clk_enable;
> - }
> -
>   ret = devm_request_irq(dev, irq,
>  imx7d_adc_isr, 0,
>  dev_name(dev), info);
>   if (ret < 0) {
>   dev_err(dev, "Failed requesting irq, irq = %d\n", irq);
> - goto error_iio_device_register;
> + return ret;
>   }
>  
>   imx7d_adc_feature_config(info);
> - imx7d_adc_hw_init(info);
> +
> + ret = imx7d_adc_resume(&indio_dev->dev);
> + if (ret)
> + return ret;
>  
>   ret = devm_iio_device_register(dev, indio_dev);
>   if (ret) {
>   imx7d_adc_power_down(info);
> + clk_disable_unprepare(info->clk);
> + regulator_disable(info->vref);
>   dev_err(&pdev->dev, "Couldn't register the device.\n");
> - goto error_iio_device_register;
> + return ret;
>   }
>  
>   return 0;
> -
> -error_iio_device_register:
> - clk_disable_unprepare(info->clk);
> -error_adc_clk_enable:
> - regulator_disable(info->vref);
> -
> - return ret;
>  }
>  
>  static int imx7d_adc_remove(struct platform_device *pdev)
> @@ -558,33 +569,6 @@ static int __maybe_unused imx7d_adc_suspend(struct 
> device *dev)
>   return 0;
>  }
>  
> -static int __maybe_unused imx7d_adc_resume(struct device *dev)
> -{
> - struct iio_dev *indio_dev = dev_get_drvdata(dev);
> - struct imx7d_adc *info = iio_priv(indio_dev);
> - int ret;
> -
> - ret = regulator_enable(info->vref);
> - if (ret) {
> - dev_err(info->dev,
> - "Can't enable adc reference top voltage, err = %d\n",
> - ret);
> - return ret;
> - }
> -
> - ret = clk_prepare_enable(info->clk);
> - if (ret) {
> - dev_err(info->dev,
> - "Could not prepare or enable clock.\n");
> - regulator_disable(info->vref);
> - return ret;
> - }
> -
> - imx7d_adc_hw_init(info);
> -
> - return 0;
> -}
> -
>  s

Re: [PATCH 6/6] iio: imx7d_adc: Drop imx7d_adc_remove()

[Jonathan Cameron]

On Wed,  3 Apr 2019 00:03:25 -0700
Andrey Smirnov  wrote:

> Since imx7d_adc_remove() does exactly the same thing as
> imx7d_adc_suspend() we can use the latter together with
> devm_add_action_or_reset() to get rid of the former.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Chris Healy 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Ah. OK, so you end up with one of the options I listed when rejecting
the earlier change for iio_device_register.

Please merge this patch with that one so we have a single change and don't
end up with a race condition prone state in between. Separate patches
are fine as well, but work your way down through probe rather than jumping
around like now.  Hence we'll have something valid at all stages.

Thanks,

Jonathan


> ---
>  drivers/iio/adc/imx7d_adc.c | 55 -
>  1 file changed, 23 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> index c2fa0ab923ee..ed95909eada2 100644
> --- a/drivers/iio/adc/imx7d_adc.c
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -461,6 +461,24 @@ static int imx7d_adc_resume(struct device *dev)
>   return 0;
>  }
>  
> +static int imx7d_adc_suspend(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct imx7d_adc *info = iio_priv(indio_dev);
> +
> + imx7d_adc_power_down(info);
> +
> + clk_disable_unprepare(info->clk);
> + regulator_disable(info->vref);
> +
> + return 0;
> +}
> +
> +static void __imx7d_adc_suspend(void *data)
> +{
> + imx7d_adc_suspend(data);
> +}
> +
>  static int imx7d_adc_probe(struct platform_device *pdev)
>  {
>   struct imx7d_adc *info;
> @@ -506,8 +524,6 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - platform_set_drvdata(pdev, indio_dev);
> -
>   init_completion(&info->completion);
>  
>   indio_dev->name = dev_name(dev);
> @@ -531,11 +547,13 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> + ret = devm_add_action_or_reset(dev, __imx7d_adc_suspend,
> +&indio_dev->dev);
> + if (ret)
> + return ret;
> +
>   ret = devm_iio_device_register(dev, indio_dev);
>   if (ret) {
> - imx7d_adc_power_down(info);
> - clk_disable_unprepare(info->clk);
> - regulator_disable(info->vref);
>   dev_err(&pdev->dev, "Couldn't register the device.\n");
>   return ret;
>   }
> @@ -543,37 +561,10 @@ static int imx7d_adc_probe(struct platform_device *pdev)
>   return 0;
>  }
>  
> -static int imx7d_adc_remove(struct platform_device *pdev)
> -{
> - struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> - struct imx7d_adc *info = iio_priv(indio_dev);
> -
> - imx7d_adc_power_down(info);
> -
> - clk_disable_unprepare(info->clk);
> - regulator_disable(info->vref);
> -
> - return 0;
> -}
> -
> -static int __maybe_unused imx7d_adc_suspend(struct device *dev)
> -{
> - struct iio_dev *indio_dev = dev_get_drvdata(dev);
> - struct imx7d_adc *info = iio_priv(indio_dev);
> -
> - imx7d_adc_power_down(info);
> -
> - clk_disable_unprepare(info->clk);
> - regulator_disable(info->vref);
> -
> - return 0;
> -}
> -
>  static SIMPLE_DEV_PM_OPS(imx7d_adc_pm_ops, imx7d_adc_suspend, 
> imx7d_adc_resume);
>  
>  static struct platform_driver imx7d_adc_driver = {
>   .probe  = imx7d_adc_probe,
> - .remove = imx7d_adc_remove,
>   .driver = {
>   .name   = "imx7d_adc",
>   .of_match_table = imx7d_adc_match,

Re: [PATCH v2] avia-hx711.yaml: transform DT binding to YAML

[Jonathan Cameron]

On Mon, 1 Apr 2019 20:47:19 -0500
Rob Herring  wrote:

> On Mon, Apr 1, 2019 at 12:34 PM Andreas Klinger  wrote:
> >
> > replace avia-hx711.txt by avia-hx711.yaml as yaml devicetree
> > documentation for avia hx711 iio adc sensor
> >
> > Signed-off-by: Andreas Klinger 
Applied to the togreg branch of iio.git and pushed out as testing.

Thanks,

Jonathan

> > ---
> >  .../devicetree/bindings/iio/adc/avia-hx711.txt | 24 
> >  .../devicetree/bindings/iio/adc/avia-hx711.yaml| 66 
> > ++
> >  2 files changed, 66 insertions(+), 24 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml  
> 
> Reviewed-by: Rob Herring 

Re: [PATCH -next] acpi/hmat: fix an uninitialized memory_target

[Nathan Chancellor]

On Sat, Apr 06, 2019 at 09:12:22PM -0400, Qian Cai wrote:
> The commit 665ac7e92757 ("acpi/hmat: Register processor domain to its
> memory") introduced an uninitialized "struct memory_target" that could
> cause an incorrect branching.
> 
> drivers/acpi/hmat/hmat.c:385:6: warning: variable 'target' is used
> uninitialized whenever 'if' condition is false
> [-Wsometimes-uninitialized]
> if (p->flags & ACPI_HMAT_MEMORY_PD_VALID) {
> ^~~~
> drivers/acpi/hmat/hmat.c:392:6: note: uninitialized use occurs here
> if (target && p->flags & ACPI_HMAT_PROCESSOR_PD_VALID) {
> ^~
> drivers/acpi/hmat/hmat.c:385:2: note: remove the 'if' if its condition
> is always true
> if (p->flags & ACPI_HMAT_MEMORY_PD_VALID) {
> ^~
> drivers/acpi/hmat/hmat.c:369:30: note: initialize the variable 'target'
> to silence this warning
> struct memory_target *target;
> ^
>  = NULL
> 
> Signed-off-by: Qian Cai 

Reviewed-by: Nathan Chancellor 

> ---
>  drivers/acpi/hmat/hmat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c
> index c9b8abcf012c..6653dba3b377 100644
> --- a/drivers/acpi/hmat/hmat.c
> +++ b/drivers/acpi/hmat/hmat.c
> @@ -366,7 +366,7 @@ static int __init hmat_parse_proximity_domain(union 
> acpi_subtable_headers *heade
> const unsigned long end)
>  {
>   struct acpi_hmat_proximity_domain *p = (void *)header;
> - struct memory_target *target;
> + struct memory_target *target = NULL;
>  
>   if (p->header.length != sizeof(*p)) {
>   pr_notice("HMAT: Unexpected address range header length: %d\n",
> -- 
> 2.17.2 (Apple Git-113)
> 

Re: [PATCH v2] bmp085.yaml: transform DT documentation of iio sensor into YAML

[Jonathan Cameron]

On Mon, 1 Apr 2019 20:46:54 -0500
Rob Herring  wrote:

> On Mon, Apr 1, 2019 at 12:32 PM Andreas Klinger  wrote:
> >
> > use bmp085.txt and change it into yaml format
> >
> > fix links to datasheets in replaced documentation
> >
> > Signed-off-by: Andreas Klinger 
> > ---
> >  .../devicetree/bindings/iio/pressure/bmp085.txt| 27 -
> >  .../devicetree/bindings/iio/pressure/bmp085.yaml   | 70 
> > ++
> >  2 files changed, 70 insertions(+), 27 deletions(-)
> >  delete mode 100644 
> > Documentation/devicetree/bindings/iio/pressure/bmp085.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/pressure/bmp085.yaml  
> 
> Reviewed-by: Rob Herring 
Applied,

Thanks,

Jonathan

Re: [PATCH 2/4] staging: iio: ad9832: add SPDX identifier

[Jonathan Cameron]

On Tue, 2 Apr 2019 11:40:00 -0300
Marcelo Schmitt  wrote:

> On 04/01, Greg KH wrote:
> > On Mon, Apr 01, 2019 at 08:36:50PM +0530, Mukesh Ojha wrote:  
> > > 
> > > On 4/1/2019 8:07 PM, Marcelo Schmitt wrote:  
> > > > Add SPDX identifier of GPL-2.0 for the ad9832 driver.
> > > > 
> > > > Signed-off-by: Marcelo Schmitt 
> > > > ---
> > > >   drivers/staging/iio/frequency/ad9832.c | 3 +--
> > > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/iio/frequency/ad9832.c 
> > > > b/drivers/staging/iio/frequency/ad9832.c
> > > > index 50a583020072..d8d4a7936275 100644
> > > > --- a/drivers/staging/iio/frequency/ad9832.c
> > > > +++ b/drivers/staging/iio/frequency/ad9832.c
> > > > @@ -1,9 +1,8 @@
> > > > +// SPDX-License-Identifier: GPL-2.0  
> > > 
> > > FYI
> > > 
> > > Use C notations here as per https://lkml.org/lkml/2019/2/13/570.
> > > 
> > >   
> 
> OK, I'll check it out.
> 
> > > 
> > > Once you fix it then you can take mine
> > > Reviewed-by: Mukesh Ojha   
> > 
> > Did you read the documentation about how to put a proper SPDX line in
> > the kernel documentation?  For .c files, you have to use "//", not "/* */"
> > 
> > Please read:
> > Documentation/process/license-rules.rst
> > and see the section "Style" for all of the details.  
> 
> Thanks, I'll read it to understand the details.
> 
> > 
> > thanks,
> > 
> > greg k-h  
> 
> Thanks for the advises,
> 
> Marcelo
Greg cleaned up all the remaining IIO staging drivers SPDX entries
later in the week, so this one is no longer needed.

Thanks,

Jonathan

Re: [PATCH 1/4] staging: iio: ad9832: organize includes

[Jonathan Cameron]

On Mon, 1 Apr 2019 11:37:10 -0300
Marcelo Schmitt  wrote:

> Organize includes to list them in lexicographic order.
> 
> Signed-off-by: Marcelo Schmitt 
There are a few headers in there that I'd expect to be unnecessary once
cleanup on the driver is finished, but good to get them in a nice
order to start with.

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/frequency/ad9832.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9832.c 
> b/drivers/staging/iio/frequency/ad9832.c
> index a3ce50427724..50a583020072 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -6,22 +6,24 @@
>   * Licensed under the GPL-2.
>   */
>  
> +#include 
> +
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
>  
>  #include 
>  #include 
> -#include "dds.h"
>  
>  #include "ad9832.h"
>  
> +#include "dds.h"
> +
>  /* Registers */
>  
>  #define AD9832_FREQ0LL   0x0

Re: [PATCH 3/4] staging: iio: ad9832: use clock framework for clock reference

[Jonathan Cameron]

On Mon, 1 Apr 2019 11:37:45 -0300
Marcelo Schmitt  wrote:

> Previously external clock were set through platform_data struct.
> Now device uses clk struct defined in include/linux/clk.h to handle
> external clock source.
> It also removes mclk from platform_data struct.
> 
> Signed-off-by: Marcelo Schmitt 
Looks good to me.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/frequency/ad9832.c | 37 +-
>  drivers/staging/iio/frequency/ad9832.h |  1 -
>  2 files changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9832.c 
> b/drivers/staging/iio/frequency/ad9832.c
> index d8d4a7936275..74308a2e72db 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -7,6 +7,7 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -95,7 +96,7 @@ struct ad9832_state {
>   struct spi_device   *spi;
>   struct regulator*avdd;
>   struct regulator*dvdd;
> - unsigned long   mclk;
> + struct clk  *mclk;
>   unsigned short  ctrl_fp;
>   unsigned short  ctrl_ss;
>   unsigned short  ctrl_src;
> @@ -130,10 +131,10 @@ static int ad9832_write_frequency(struct ad9832_state 
> *st,
>  {
>   unsigned long regval;
>  
> - if (fout > (st->mclk / 2))
> + if (fout > (clk_get_rate(st->mclk) / 2))
>   return -EINVAL;
>  
> - regval = ad9832_calc_freqreg(st->mclk, fout);
> + regval = ad9832_calc_freqreg(clk_get_rate(st->mclk), fout);
>  
>   st->freq_data[0] = cpu_to_be16((AD9832_CMD_FRE8BITSW << CMD_SHIFT) |
>   (addr << ADD_SHIFT) |
> @@ -334,7 +335,16 @@ static int ad9832_probe(struct spi_device *spi)
>   goto error_disable_avdd;
>   }
>  
> - st->mclk = pdata->mclk;
> + st->mclk = devm_clk_get(&spi->dev, "mclk");
> + if (IS_ERR(st->mclk)) {
> + ret = PTR_ERR(st->mclk);
> + goto error_disable_dvdd;
> + }
> +
> + ret = clk_prepare_enable(st->mclk);
> + if (ret < 0)
> + goto error_disable_dvdd;
> +
>   st->spi = spi;
>   mutex_init(&st->lock);
>  
> @@ -385,39 +395,41 @@ static int ad9832_probe(struct spi_device *spi)
>   ret = spi_sync(st->spi, &st->msg);
>   if (ret) {
>   dev_err(&spi->dev, "device init failed\n");
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>   }
>  
>   ret = ad9832_write_frequency(st, AD9832_FREQ0HM, pdata->freq0);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = ad9832_write_frequency(st, AD9832_FREQ1HM, pdata->freq1);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = ad9832_write_phase(st, AD9832_PHASE0H, pdata->phase0);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = ad9832_write_phase(st, AD9832_PHASE1H, pdata->phase1);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = ad9832_write_phase(st, AD9832_PHASE2H, pdata->phase2);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = ad9832_write_phase(st, AD9832_PHASE3H, pdata->phase3);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   ret = iio_device_register(indio_dev);
>   if (ret)
> - goto error_disable_dvdd;
> + goto error_unprepare_mclk;
>  
>   return 0;
>  
> +error_unprepare_mclk:
> + clk_disable_unprepare(st->mclk);
>  error_disable_dvdd:
>   regulator_disable(st->dvdd);
>  error_disable_avdd:
> @@ -432,6 +444,7 @@ static int ad9832_remove(struct spi_device *spi)
>   struct ad9832_state *st = iio_priv(indio_dev);
>  
>   iio_device_unregister(indio_dev);
> + clk_disable_unprepare(st->mclk);
>   regulator_disable(st->dvdd);
>   regulator_disable(st->avdd);
>  
> diff --git a/drivers/staging/iio/frequency/ad9832.h 
> b/drivers/staging/iio/frequency/ad9832.h
> index 39d326cc1af9..032579a2d539 100644
> --- a/drivers/staging/iio/frequency/ad9832.h
> +++ b/drivers/staging/iio/frequency/ad9832.h
> @@ -24,7 +24,6 @@
>   */
>  
>  struct ad9832_platform_data {
> - unsigned long   mclk;
>   unsigned long   freq0;
>   unsigned long   freq1;
>   unsigned short  phase0;

Re: [PATCH v2 00/10] iio mount matrix - revitalize missing bindings documentation and provide code for bmc150, bmg160, bma180, itg3200, hmc584x

[Jonathan Cameron]

On Thu, 4 Apr 2019 08:29:12 +0200
"H. Nikolaus Schaller"  wrote:

> Hi Jonathan,
> 
> > Am 03.03.2019 um 16:32 schrieb Jonathan Cameron :
> > 
> > Thanks to Linus and Andy for reviews.
> > I've picked up all but they documentation patch.  I think
> > it is 'very nearly there', but would like a few really minor
> > tweaks.  Seemed silly to stall the other patches on that though!  
> 
> Seems they have stalled elsewhere since they did not yet arrive in linux-next.
The iio tree is not directly pulled into linux-next.  Hence IIO patches
only turn up there once I've sent a pull request to Greg and they have
entered the staging-next tree.

They still haven't quite made it into linux-next, but I'd imagine they
will tomorrow.

Jonathan

> 
> The documentation patch is still on my todo list and will need a little more 
> time
> but that should not block the others.
Absolutely, this was just tree handling delays and me messing up a pull
request to slow things down even more.

Jonathan

> 
> BR and thanks,
> Nikolaus
> 

Re: [PATCH v2] iio: imu: mpu6050: Fix FIFO layout for ICM20602

[Jonathan Cameron]

On Tue,  2 Apr 2019 23:28:56 -0700
stev...@skydio.com wrote:

> From: Steve Moskovchenko 
> 
> The MPU6050 driver has recently gained support for the
> ICM20602 IMU, which is very similar to MPU6xxx. However,
> the ICM20602's FIFO data specifically includes temperature
> readings, which were not present on MPU6xxx parts. As a
> result, the driver will under-read the ICM20602's FIFO
> register, causing the same (partial) sample to be returned
> for all reads, until the FIFO overflows.
> 
> Fix this by adding a table of scan elements specifically
> for the ICM20602, which takes the extra temperature data
> into consideration.
> 
> While we're at it, fix the temperature offset and scaling
> on ICM20602, since it uses different scale/offset constants
> than the rest of the MPU6xxx devices.
> 
> Signed-off-by: Steve Moskovchenko 
I'd like a reviewed-by or acked-by from Jean-Baptiste on this before
I take it.

thanks,

Jonathan

> ---
> v2: Read temperature when running in accel-only mode, too.
> 
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 46 --
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  | 20 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c |  3 ++
>  3 files changed, 64 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c 
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 650de0fefb7b..fedd3f2b0135 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -471,7 +471,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
>   return IIO_VAL_INT_PLUS_MICRO;
>   case IIO_TEMP:
>   *val = 0;
> - *val2 = INV_MPU6050_TEMP_SCALE;
> + if (st->chip_type == INV_ICM20602)
> + *val2 = INV_ICM20602_TEMP_SCALE;
> + else
> + *val2 = INV_MPU6050_TEMP_SCALE;
>  
>   return IIO_VAL_INT_PLUS_MICRO;
>   default:
> @@ -480,7 +483,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_OFFSET:
>   switch (chan->type) {
>   case IIO_TEMP:
> - *val = INV_MPU6050_TEMP_OFFSET;
> + if (st->chip_type == INV_ICM20602)
> + *val = INV_ICM20602_TEMP_OFFSET;
> + else
> + *val = INV_MPU6050_TEMP_OFFSET;
>  
>   return IIO_VAL_INT;
>   default:
> @@ -845,6 +851,32 @@ static const struct iio_chan_spec inv_mpu_channels[] = {
>   INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_MPU6050_SCAN_ACCL_Z),
>  };
>  
> +static const struct iio_chan_spec inv_icm20602_channels[] = {
> + IIO_CHAN_SOFT_TIMESTAMP(INV_ICM20602_SCAN_TIMESTAMP),
> + {
> + .type = IIO_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
> + | BIT(IIO_CHAN_INFO_OFFSET)
> + | BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = INV_ICM20602_SCAN_GYRO_TEMP,
> + .scan_type = {
> + .sign = 's',
> + .realbits = 16,
> + .storagebits = 16,
> + .shift = 0,
> + .endianness = IIO_BE,
> +  },
> + },
> +
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_X, INV_ICM20602_SCAN_GYRO_X),
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_Y, INV_ICM20602_SCAN_GYRO_Y),
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_Z, INV_ICM20602_SCAN_GYRO_Z),
> +
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Y, INV_ICM20602_SCAN_ACCL_Y),
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_X, INV_ICM20602_SCAN_ACCL_X),
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_ICM20602_SCAN_ACCL_Z),
> +};
> +
>  /*
>   * The user can choose any frequency between INV_MPU6050_MIN_FIFO_RATE and
>   * INV_MPU6050_MAX_FIFO_RATE, but only these frequencies are matched by the
> @@ -1100,8 +1132,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, 
> const char *name,
>   indio_dev->name = name;
>   else
>   indio_dev->name = dev_name(dev);
> - indio_dev->channels = inv_mpu_channels;
> - indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
> +
> + if (chip_type == INV_ICM20602) {
> + indio_dev->channels = inv_icm20602_channels;
> + indio_dev->num_channels = ARRAY_SIZE(inv_icm20602_channels);
> + } else {
> + indio_dev->channels = inv_mpu_channels;
> + indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
> + }
>  
>   indio_dev->info = &mpu_info;
>   indio_dev->modes = INDIO_BUFFER_TRIGGERED;
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h 
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> index 325afd9f5f61..2ed4b98e0cd7 100644
> --- a/driv

[PATCH] rtc: wm831x: use .set_time

[Alexandre Belloni]

Use .set_time instead of the deprecated .set_mmss.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-wm831x.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 6a0defd16088..ed29f4df2a3c 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -165,15 +165,17 @@ static int wm831x_rtc_readtime(struct device *dev, struct 
rtc_time *tm)
 /*
  * Set current time and date in RTC
  */
-static int wm831x_rtc_set_mmss(struct device *dev, unsigned long time)
+static int wm831x_rtc_settime(struct device *dev, struct rtc_time *tm)
 {
struct wm831x_rtc *wm831x_rtc = dev_get_drvdata(dev);
struct wm831x *wm831x = wm831x_rtc->wm831x;
struct rtc_time new_tm;
-   unsigned long new_time;
+   unsigned long time, new_time;
int ret;
int count = 0;
 
+   time = rtc_tm_to_time64(tm);
+
ret = wm831x_reg_write(wm831x, WM831X_RTC_TIME_1,
   (time >> 16) & 0x);
if (ret < 0) {
@@ -334,7 +336,7 @@ static irqreturn_t wm831x_alm_irq(int irq, void *data)
 
 static const struct rtc_class_ops wm831x_rtc_ops = {
.read_time = wm831x_rtc_readtime,
-   .set_mmss = wm831x_rtc_set_mmss,
+   .set_time = wm831x_rtc_settime,
.read_alarm = wm831x_rtc_readalarm,
.set_alarm = wm831x_rtc_setalarm,
.alarm_irq_enable = wm831x_rtc_alarm_irq_enable,
-- 
2.20.1

Re: [PATCH] iio: adc: ads124: avoid buffer overflow

[Jonathan Cameron]

On Mon, 1 Apr 2019 07:41:37 -0500
Dan Murphy  wrote:

> On 3/31/19 1:54 PM, Vincent Stehlé wrote:
> > When initializing the priv->data array starting from index 1, there is one
> > less element to consider than when initializing the full array.
> > 
> > Fixes: e717f8c6dfec8f76 ("iio: adc: Add the TI ads124s08 ADC code")
> > Signed-off-by: Vincent Stehlé 
> > Cc: Dan Murphy 
> > Cc: Jonathan Cameron 
> > ---
> >  drivers/iio/adc/ti-ads124s08.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
> > index 53f17e4f2f230..552c2be8d87ad 100644
> > --- a/drivers/iio/adc/ti-ads124s08.c
> > +++ b/drivers/iio/adc/ti-ads124s08.c
> > @@ -202,7 +202,7 @@ static int ads124s_read(struct iio_dev *indio_dev, 
> > unsigned int chan)
> > };
> >  
> > priv->data[0] = ADS124S08_CMD_RDATA;
> > -   memset(&priv->data[1], ADS124S08_CMD_NOP, sizeof(priv->data));
> > +   memset(&priv->data[1], ADS124S08_CMD_NOP, sizeof(priv->data) - 1);
> >  
> > ret = spi_sync_transfer(priv->spi, t, ARRAY_SIZE(t));
> > if (ret < 0)
> >   
> 
> Reviewed-by: Dan Murphy 

Applied to the fixes-togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

Re: [PATCH] iio: adc: ads124: avoid buffer overflow

[Jonathan Cameron]

On Sun, 7 Apr 2019 13:02:42 +0100
Jonathan Cameron  wrote:

> On Mon, 1 Apr 2019 07:41:37 -0500
> Dan Murphy  wrote:
> 
> > On 3/31/19 1:54 PM, Vincent Stehlé wrote:  
> > > When initializing the priv->data array starting from index 1, there is one
> > > less element to consider than when initializing the full array.
> > > 
> > > Fixes: e717f8c6dfec8f76 ("iio: adc: Add the TI ads124s08 ADC code")
> > > Signed-off-by: Vincent Stehlé 
> > > Cc: Dan Murphy 
> > > Cc: Jonathan Cameron 
> > > ---
> > >  drivers/iio/adc/ti-ads124s08.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/iio/adc/ti-ads124s08.c 
> > > b/drivers/iio/adc/ti-ads124s08.c
> > > index 53f17e4f2f230..552c2be8d87ad 100644
> > > --- a/drivers/iio/adc/ti-ads124s08.c
> > > +++ b/drivers/iio/adc/ti-ads124s08.c
> > > @@ -202,7 +202,7 @@ static int ads124s_read(struct iio_dev *indio_dev, 
> > > unsigned int chan)
> > >   };
> > >  
> > >   priv->data[0] = ADS124S08_CMD_RDATA;
> > > - memset(&priv->data[1], ADS124S08_CMD_NOP, sizeof(priv->data));
> > > + memset(&priv->data[1], ADS124S08_CMD_NOP, sizeof(priv->data) - 1);
> > >  
> > >   ret = spi_sync_transfer(priv->spi, t, ARRAY_SIZE(t));
> > >   if (ret < 0)
> > > 
> > 
> > Reviewed-by: Dan Murphy   
> 
> Applied to the fixes-togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
Wrong finger memory. Not pushed out as testing. Pushed out as fixes-togreg!

Jonathan
> 
> Thanks,
> 
> Jonathan

Re: [PATCH v2] platform: chrome: Add ChromeOS EC ISHTP driver

[Rushikesh S Kadam]

Hi Enric
Thanks for your review comments. I'm taking majority of inputs,
and will send a v3 shortly

Please see comments below.

On Wed, Apr 03, 2019 at 06:36:52PM +0200, Enric Balletbo i Serra wrote:
> Hi Rushikesh,
> 
> Thanks for sending this upstream, some comments below.
> 
> On 3/4/19 10:52, Rushikesh S Kadam wrote:
> > Add ChromeOS EC ISHTP driver.
> > 
> 
> Could you explain a bit more about what ISHTP is? I suppose is a protocol to
> communicate with the Integrated Sensor Driver, but would be good have a better
> explanation here.

ISH Transport Protocol defines a transport layer protocol
for start, stop, connect, disconnect and flow control.
Generic explaination in Documentation/hid/intel-ish-hid.txt

Spec here "Chapter 7: Bus Message Layer"
http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/dcmi-hi-1-0-spec.pdf

I'll update the commit message on v3. Please let me know if
it looks good to you.

> 
> > Sends ChromeOS EC host commands over ISHTP to ISH firmware.
> > 
> > Signed-off-by: Rushikesh S Kadam 
> > ---
> > 
> > v2
> >  - Dropped unused "reset" parameter in function cros_ec_init()
> >  - Change driver name to cros_ec_ishtp to be consistent with other
> >references in the code.
> >  - Fixed a few typos. 
> > 
> > v1
> >  - Initial version
> > 
> >  drivers/platform/chrome/Kconfig |  13 +
> >  drivers/platform/chrome/Makefile|   1 +
> >  drivers/platform/chrome/cros_ec_ishtp.c | 792 
> > 
> >  3 files changed, 806 insertions(+)
> >  create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c
> > 
> > diff --git a/drivers/platform/chrome/Kconfig 
> > b/drivers/platform/chrome/Kconfig
> > index 16b1615..92a339a 100644
> > --- a/drivers/platform/chrome/Kconfig
> > +++ b/drivers/platform/chrome/Kconfig
> > @@ -84,6 +84,19 @@ config CROS_EC_LPC
> >To compile this driver as a module, choose M here: the
> >module will be called cros_ec_lpc.
> >  
> > +config CROS_EC_ISHTP
> 
> Alphabetically ordered if possible. Put all this block after 'config 
> CROS_EC_I2C'

Will do.

> 
> > +   tristate "ChromeOS Embedded Controller (ISHTP)"
> > +   depends on MFD_CROS_EC
> > +   depends on INTEL_ISH_HID
> > +   help
> > + If you say Y here, you get support for talking to the ChromeOS EC
> > + firmware running on Intel Integrated Sensor Hub (ISH), using the
> > + ISH Transport protocol (ISH-TP). This uses a simple byte-level
> > + protocol with a checksum.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called cros_ec_ishtp.
> > +
> >  config CROS_EC_LPC_MEC
> > bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant"
> > depends on CROS_EC_LPC
> > diff --git a/drivers/platform/chrome/Makefile 
> > b/drivers/platform/chrome/Makefile
> > index cd591bf..fb2639e 100644
> > --- a/drivers/platform/chrome/Makefile
> > +++ b/drivers/platform/chrome/Makefile
> > @@ -12,4 +12,5 @@ cros_ec_lpcs-objs := cros_ec_lpc.o 
> > cros_ec_lpc_reg.o
> >  cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
> >  obj-$(CONFIG_CROS_EC_LPC)  += cros_ec_lpcs.o
> >  obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
> > +obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o
> 
> Same here, put this after obj-$(CONFIG_CROS_I2C)

Will do.

> 
> >  obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT)   += cros_kbd_led_backlight.o
> > diff --git a/drivers/platform/chrome/cros_ec_ishtp.c 
> > b/drivers/platform/chrome/cros_ec_ishtp.c
> > new file mode 100644
> > index 000..10e8237
> > --- /dev/null
> > +++ b/drivers/platform/chrome/cros_ec_ishtp.c
> > @@ -0,0 +1,792 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * ISHTP client driver for talking to the Chrome OS EC firmware running
> > + * on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol
> 
> Is this protocol only for the Intel Integrated Sensor Hub or works for any 
> CrOS
> Integrated Sensor Hub?

Only Intel devices use the ISH TP protocol to my knowledge.

So this driver is applicable only when working with Intel
Integrated Sensor Hub.

> 
> > + * (ISH-TP).
> > + *
> > + * Copyright (c) 2019, Intel Corporation.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * ISH TX/RX ring buffer pool size
> > + *
> > + * The AP->ISH messages and corresponding ISH->AP responses are
> > + * serialized. We need 1 TX and 1 RX buffer for these.
> > + *
> > + * The MKBP ISH->AP events are serialized. We need one additional RX
> > + * buffer for them.
> > + */
> > +#define CROS_ISH_CL_TX_RING_SIZE   1
> > +#define CROS_ISH_CL_RX_RING_SIZE   2
> > +
> > +/* ISH CrOS EC Host Commands */
> > +enum cros_ec_ish_channel {
> > +   CROS_EC_COMMAND = 1,/* AP->ISH message */
> > +   CROS_MKBP_EVENT = 2,/* ISH->AP events */
> 

[PATCH v3] platform: chrome: Add ChromeOS EC ISHTP driver

[Rushikesh S Kadam]

This driver implements a slim layer to enable the ChromeOS
EC kernel stack (cros_ec) to communicate with ChromeOS EC
firmware running on the Intel Integrated Sensor Hub (ISH).

The driver registers a ChromeOS EC MFD device to connect
with cros_ec kernel stack (upper layer), and it registers a
client with the ISH Transport Protocol bus (lower layer) to
talk with the ISH firwmare. See description of the ISHTP
protocol at Documentation/hid/intel-ish-hid.txt

Signed-off-by: Rushikesh S Kadam 
---

v3
 - Made several changes to improve code readability. Replaced
   multiple cl_data_to_dev(client_data) with dev variable. Use
   reverse Xmas tree for variable defintion where it made sense.
   Dropped few debug prints. Add docstring for function
   prepare_cros_ec_rx().
 - Fix code in function prepare_cros_ec_rx() under label
   end_cros_ec_dev_init_error.
 - Recycle buffer in process_recv() on failing to obtain the
   semaphore.
 - Increase ISHTP TX/RX ring buffer size to 8.
 - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and
   Kconfig.
 - Updated commit message.

v2
 - Dropped unused "reset" parameter in function cros_ec_init()
 - Change driver name to cros_ec_ishtp to be consistent with other
   references in the code.
 - Fixed a few typos. 

v1
 - Initial version

 drivers/platform/chrome/Kconfig |  13 +
 drivers/platform/chrome/Makefile|   1 +
 drivers/platform/chrome/cros_ec_ishtp.c | 765 
 3 files changed, 779 insertions(+)
 create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c

diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 16b1615..5848179 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -62,6 +62,19 @@ config CROS_EC_I2C
  a checksum. Failing accesses will be retried three times to
  improve reliability.
 
+config CROS_EC_ISHTP
+   tristate "ChromeOS Embedded Controller (ISHTP)"
+   depends on MFD_CROS_EC
+   depends on INTEL_ISH_HID
+   help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ firmware running on Intel Integrated Sensor Hub (ISH), using the
+ ISH Transport protocol (ISH-TP). This uses a simple byte-level
+ protocol with a checksum.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_ishtp.
+
 config CROS_EC_SPI
tristate "ChromeOS Embedded Controller (SPI)"
depends on MFD_CROS_EC && SPI
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index cd591bf..4efe102 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -7,6 +7,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o 
cros_ec_lightbar.o \
   cros_ec_vbc.o cros_ec_debugfs.o
 obj-$(CONFIG_CROS_EC_CTL)  += cros_ec_ctl.o
 obj-$(CONFIG_CROS_EC_I2C)  += cros_ec_i2c.o
+obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o
 obj-$(CONFIG_CROS_EC_SPI)  += cros_ec_spi.o
 cros_ec_lpcs-objs  := cros_ec_lpc.o cros_ec_lpc_reg.o
 cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
diff --git a/drivers/platform/chrome/cros_ec_ishtp.c 
b/drivers/platform/chrome/cros_ec_ishtp.c
new file mode 100644
index 000..b1d19c4
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_ishtp.c
@@ -0,0 +1,765 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ISHTP client driver for talking to the Chrome OS EC firmware running
+ * on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol
+ * (ISH-TP).
+ *
+ * Copyright (c) 2019, Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * ISH TX/RX ring buffer pool size
+ *
+ * The AP->ISH messages and corresponding ISH->AP responses are
+ * serialized. We need 1 TX and 1 RX buffer for these.
+ *
+ * The MKBP ISH->AP events are serialized. We need one additional RX
+ * buffer for them.
+ */
+#define CROS_ISH_CL_TX_RING_SIZE   8
+#define CROS_ISH_CL_RX_RING_SIZE   8
+
+/* ISH CrOS EC Host Commands */
+enum cros_ec_ish_channel {
+   CROS_EC_COMMAND = 1,/* AP->ISH message */
+   CROS_MKBP_EVENT = 2,/* ISH->AP events */
+};
+
+/*
+ * ISH firmware timeout for 1 message send failure is 1Hz, and the
+ * firmware will retry 2 times, so 3Hz is used for timeout.
+ */
+#define ISHTP_SEND_TIMEOUT (3 * HZ)
+
+/* ISH Transport CrOS EC ISH client unique GUID */
+static const guid_t cros_ish_guid =
+   GUID_INIT(0x7b7154d0, 0x56f4, 0x4bdc,
+ 0xb0, 0xd8, 0x9e, 0x7c, 0xda, 0xe0, 0xd6, 0xa0);
+
+struct header {
+   u8 channel;
+   u8 status;
+   u8 reserved[2];
+} __packed;
+
+struct cros_ish_out_msg {
+   struct header hdr;
+   struct ec_host_request ec_request;
+} __packed;
+

Re: [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface

[Jonathan Cameron]

On Sun, 31 Mar 2019 12:09:46 +0200
"H. Nikolaus Schaller"  wrote:

Hi Nikolaus,

I'm probably going to repeat a few things I sent for v1 as the audience has
expanded somewhat!

Good to see this moving forwards though as there has been at least some demand
for it going way back to the early days of IIO.

> Some user spaces (e.g. some Android devices) use /dev/input/event* for 
> handling
> the 3D position of the device with respect to the center of gravity (earth).
> This can be used for gaming input, auto-rotation of screens etc.
> 
> This interface should be the standard for such use cases because it is an 
> abstraction
> of how orientation data is acquired from sensor chips. Sensor chips may be 
> connected
> through different interfaces and in different positions. They may also have 
> different
> parameters. And, if a chip is replaced by a different one, the values 
> reported by
> the device position interface should remain the same, provided the device 
> tree reflects
> the changed chip.
> 
> This did initially lead to input accelerometer drivers like 
> drivers/input/misc/bma150.c
> or drivers/misc/lis3lv02d/
> 
> But nowadays, new accelerometer chips mostly get iio drivers and rarely input 
> drivers.
> 
> Therefore we need something like a protocol stack which bridges raw data and 
> input devices.
> It can be seen as a similar layering like TCP/IP vs. bare Ethernet. Or 
> keyboard
> input events vs. raw gpio or raw USB access.
> 
> This patch bridges the gap between raw iio data and the input device 
> abstraction
> so that accelerometer measurements can additionally be presented as X/Y/Z 
> accelerometer
> channels (INPUT_PROP_ACCELEROMETER) through /dev/input/event*.
> 
> There are no special requirements or changes needed for an iio driver.
> 
> There is no need to define a mapping (e.g. in device tree).
This worries me, as it inherently means we end up with this interface being
registered in cases where it makes no sense.  A lot of generic distros get
used across widely differing use cases.

I think we need some deliberate userspace interaction to instantiate
one of these rather than 'always doing it'.

As I mentioned in V1, look at the possibility of a configfs based method
to build the map.  It's easy for userspace to work out what makes sense to
map in principle.  There may be some missing info that we also need to
look to expose.

In general, userspace created channel maps would be very useful for
other things such as maker type boards where they can plug all sorts
of odd things into ADC channels for example.

> 
> This driver simply collects the first 3 accelerometer channels as X, Y and Z.
> If only 1 or 2 channels are available, they are used for X and Y only. 
> Additional
> channels are ignored.
> 
> Scaling is done automatically so that 1g is represented by value 256 and
> range is assumed to be -511 .. +511 which gives a reasonable precision as an
> input device.

Why do we do this, rather than letting input deal with it?  Input is used
to widely differing scales IIRC

> 
> If a mount-matrix is provided by the iio driver, it is also taken into account
> so that the input event automatically gets the correct orientation with 
> respect
> to the device.
> 
> If this extension is not configured into the kernel it takes no resources 
> (except
> source code).
> 
> If it is configured, but there is no accelerometer, there is only a tiny 
> penalty
> for scanning for accelerometer channels once during probe of each iio device.
> 
> If it runs, the driver polls the device(s) once every 100 ms. A mode where the
> iio device defines the update rate is not implemented and for further study.
> 
> If there is no user-space client, polling is not running.
> 
> The driver is capable to handle multiple iio accelerometers and they are
> presented by unique /dev/input/event* files. The iio chip name is used to 
> define
> the input device name so that it can be identified (e.g. by udev rules or 
> evtest).
> 
> Here is some example what you can expect from the driver (device:
> arch/arm/boot/dts/omap3-gta04a5.dts):
> 
> root@letux:~# dmesg|fgrep iio
> [    6.324584] input: iio-bridge: bmc150_accel as 
> /devices/platform/6800.ocp/48072000.i2c/i2c-1/1-0010/iio:device1/input/input5
> [    6.516632] input: iio-bridge: bno055 as 
> /devices/platform/6800.ocp/48072000.i2c/i2c-1/1-0029/iio:device3/input/input7
> root@letux:~# evtest /dev/input/event5 | head -19
> Input driver version is 1.0.1
> Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
> Input device name: "iio-bridge: bmc150_accel"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 3 (EV_ABS)
>     Event code 0 (ABS_X)
>       Value      8
>       Min     -511
>       Max      511
>     Event code 1 (ABS_Y)
>       Value    -44
>       Min     -511
>       Max      511
>     Event code 2 (ABS_Z)
>       Value   -265
>       Min     -511
>       Max      511
> Properties:
> root@letux:~# evtest /dev/input/event7 | he

[PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning for rotation right

[Vadim Pasternak]

The warning is caused by call to rorXX(), if the second parameters of
this function "shift" is zero. In such case UBSAN reports the warning
for the next expression: (word << (XX - shift), where XX is
64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
Fix adds validation of this parameter - in case it's equal zero, no
need to rotate, just original "word" is to be returned to caller.

The UBSAN undefined behavior warning has been reported for call to
ror32():
[   11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
[   11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
[   11.441647] Hardware name: Mellanox Technologies Ltd. MSN3800/VMOD0007, BIOS 
5.11 01/06/2019
[   11.441650] Call Trace:
[   11.441661]  dump_stack+0x71/0xab
[   11.441668]  ubsan_epilogue+0x9/0x49
[   11.441676]  __ubsan_handle_shift_out_of_bounds+0x1ea/0x241
[   11.441683]  ? __ubsan_handle_load_invalid_value+0x137/0x137
[   11.441691]  ? __module_text_address+0x11/0x90
[   11.441697]  ? widen_string+0x27/0x140
[   11.441704]  ? regmap_readable+0x76/0xc0
[   11.441709]  ? regmap_readable+0x76/0xc0
[   11.441718]  ? mlxplat_mlxcpld_readable_reg+0x1f/0x30 [mlx_platform]
[   11.441723]  ? regmap_volatile+0x40/0xb0
[   11.441729]  ? mlxplat_mlxcpld_volatile_reg+0x1f/0x30 [mlx_platform]
[   11.441735]  ? _regmap_read+0x11c/0x210
[   11.441741]  ? __mutex_lock_slowpath+0x10/0x10
[   11.441750]  ? mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[   11.441756]  mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[   11.441764]  ? mlxreg_led_brightness_get+0x270/0x270 [leds_mlxreg]
[   11.441769]  ? del_timer+0xe0/0xe0
[   11.441776]  ? bust_spinlocks+0x90/0x90
[   11.441784]  led_blink_setup+0x47/0x1d0
[   11.441792]  timer_trig_activate+0x8f/0x175 [ledtrig_timer]
[   11.441799]  ? kvasprintf_const+0xb0/0xb0
[   11.441805]  ? led_delay_on_show+0x50/0x50 [ledtrig_timer]
[   11.441810]  ? _raw_write_lock_bh+0xe0/0xe0
[   11.441815]  ? _raw_read_lock_irqsave+0x80/0x80
[   11.441822]  led_trigger_set+0x2cf/0x4d0
[   11.441829]  ? led_trigger_show+0x1f0/0x1f0
[   11.441834]  ? __mutex_lock_slowpath+0x10/0x10
[   11.441840]  ? kernfs_get_active+0xb2/0x120
[   11.441845]  ? kernfs_get_parent+0x50/0x50
[   11.441851]  led_trigger_store+0xe7/0x130
[   11.441858]  kernfs_fop_write+0x19a/0x250
[   11.441863]  ? sysfs_kf_bin_read+0x120/0x120
[   11.441869]  vfs_write+0xf5/0x230
[   11.441875]  ksys_write+0xa1/0x120
[   11.441881]  ? __ia32_sys_read+0x50/0x50
[   11.441888]  ? __do_page_fault+0x3e4/0x640
[   11.441895]  do_syscall_64+0x73/0x160
[   11.441900]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.441905] RIP: 0033:0x7f955749f730
[   11.441911] Code: 73 01 c3 48 8b 0d 68 d7 2b 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 0f 1f 44 00 00 83 3d d9 2f 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 9b 01 00 48 89 04 24
[   11.441914] RSP: 002b:7ffd4da04488 EFLAGS: 0246 ORIG_RAX: 
0001
[   11.441920] RAX: ffda RBX: 0006 RCX: 7f955749f730
[   11.441923] RDX: 0006 RSI: 01a14408 RDI: 0001
[   11.441926] RBP: 01a14408 R08: 7f955775f760 R09: 7f9557da9b40
[   11.441929] R10: 0097 R11: 0246 R12: 0006
[   11.441932] R13: 0001 R14: 7f955775e600 R15: 0006

Reported-by: Ido Schimmel 
Signed-off-by: Vadim Pasternak 
---
 include/linux/bitops.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 602af23b98c7..02c00f3c8205 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
  */
 static inline __u64 ror64(__u64 word, unsigned int shift)
 {
+   if (!shift)
+   return word;
+
return (word >> shift) | (word << (64 - shift));
 }
 
@@ -90,6 +93,9 @@ static inline __u32 rol32(__u32 word, unsigned int shift)
  */
 static inline __u32 ror32(__u32 word, unsigned int shift)
 {
+   if (!shift)
+   return word;
+
return (word >> shift) | (word << (32 - shift));
 }
 
@@ -110,6 +116,9 @@ static inline __u16 rol16(__u16 word, unsigned int shift)
  */
 static inline __u16 ror16(__u16 word, unsigned int shift)
 {
+   if (!shift)
+   return word;
+
return (word >> shift) | (word << (16 - shift));
 }
 
@@ -130,6 +139,9 @@ static inline __u8 rol8(__u8 word, unsigned int shift)
  */
 static inline __u8 ror8(__u8 word, unsigned int shift)
 {
+   if (!shift)
+   return word;
+
return (word >> shift) | (word << (8 - shift));
 }
 
-- 
2.11.0

[PATCH v4 3/6] iommu: add iommu_default_dma_mode_get() helper

[Zhen Lei]

Add IOMMU_DMA_MODE_IS_LAZY() and IOMMU_DMA_MODE_IS_PASSTHROUGH() to make
the code looks cleaner.

There is no functional change, just prepare for the following patches.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/iommu.c | 12 
 include/linux/iommu.h | 11 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b75e23a2ea08da8..876c0966db2481a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -168,6 +168,11 @@ static int __init iommu_dma_mode_setup(char *str)
 }
 early_param("iommu.dma_mode", iommu_dma_mode_setup);
 
+int iommu_default_dma_mode_get(void)
+{
+   return iommu_default_dma_mode;
+}
+
 static ssize_t iommu_group_attr_show(struct kobject *kobj,
 struct attribute *__attr, char *buf)
 {
@@ -1109,9 +1114,8 @@ struct iommu_group *iommu_group_get_for_dev(struct device 
*dev)
 */
if (!group->default_domain) {
struct iommu_domain *dom;
-   int def_domain_type =
-   (iommu_default_dma_mode == IOMMU_DMA_MODE_PASSTHROUGH)
-   ? IOMMU_DOMAIN_IDENTITY : IOMMU_DOMAIN_DMA;
+   int def_domain_type = IOMMU_DMA_MODE_IS_PASSTHROUGH() \
+   ? IOMMU_DOMAIN_IDENTITY : IOMMU_DOMAIN_DMA;
 
dom = __iommu_domain_alloc(dev->bus, def_domain_type);
if (!dom && def_domain_type != IOMMU_DOMAIN_DMA) {
@@ -1127,7 +1131,7 @@ struct iommu_group *iommu_group_get_for_dev(struct device 
*dev)
if (!group->domain)
group->domain = dom;
 
-   if (dom && (iommu_default_dma_mode == IOMMU_DMA_MODE_LAZY)) {
+   if (dom && IOMMU_DMA_MODE_IS_LAZY()) {
int attr = 1;
iommu_domain_set_attr(dom,
  DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c3f4e3416176496..1b35ae3f6382e4a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -46,6 +46,10 @@
 #define IOMMU_DMA_MODE_STRICT  0x0
 #define IOMMU_DMA_MODE_LAZY0x1
 #define IOMMU_DMA_MODE_PASSTHROUGH 0x2
+#define IOMMU_DMA_MODE_IS_LAZY() \
+   (iommu_default_dma_mode_get() == IOMMU_DMA_MODE_LAZY)
+#define IOMMU_DMA_MODE_IS_PASSTHROUGH() \
+   (iommu_default_dma_mode_get() == IOMMU_DMA_MODE_PASSTHROUGH)
 
 struct iommu_ops;
 struct iommu_group;
@@ -421,6 +425,8 @@ static inline void dev_iommu_fwspec_set(struct device *dev,
 int iommu_probe_device(struct device *dev);
 void iommu_release_device(struct device *dev);
 
+extern int iommu_default_dma_mode_get(void);
+
 #else /* CONFIG_IOMMU_API */
 
 struct iommu_ops {};
@@ -705,6 +711,11 @@ const struct iommu_ops *iommu_ops_from_fwnode(struct 
fwnode_handle *fwnode)
return NULL;
 }
 
+static inline int iommu_default_dma_mode_get(void)
+{
+   return IOMMU_DMA_MODE_PASSTHROUGH;
+}
+
 #endif /* CONFIG_IOMMU_API */
 
 #ifdef CONFIG_IOMMU_DEBUGFS
-- 
1.8.3

[PATCH] s390/mm: Silence compiler warning when compiling without CONFIG_PGSTE

[Thomas Huth]

If CONFIG_PGSTE is not set (e.g. when compiling without KVM), GCC complains:

  CC  arch/s390/mm/pgtable.o
arch/s390/mm/pgtable.c:413:15: warning: ‘pmd_alloc_map’ defined but not
 used [-Wunused-function]
 static pmd_t *pmd_alloc_map(struct mm_struct *mm, unsigned long addr)
   ^

Wrap the function with "#ifdef CONFIG_PGSTE" to silence the warning.

Signed-off-by: Thomas Huth 
---
 arch/s390/mm/pgtable.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 8485d6dc2754..9ebd01219812 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -410,6 +410,7 @@ static inline pmd_t pmdp_flush_lazy(struct mm_struct *mm,
return old;
 }
 
+#ifdef CONFIG_PGSTE
 static pmd_t *pmd_alloc_map(struct mm_struct *mm, unsigned long addr)
 {
pgd_t *pgd;
@@ -427,6 +428,7 @@ static pmd_t *pmd_alloc_map(struct mm_struct *mm, unsigned 
long addr)
pmd = pmd_alloc(mm, pud, addr);
return pmd;
 }
+#endif
 
 pmd_t pmdp_xchg_direct(struct mm_struct *mm, unsigned long addr,
   pmd_t *pmdp, pmd_t new)
-- 
2.21.0

[PATCH v4 5/6] powernv/iommu: use common boot option iommu.dma_mode

[Zhen Lei]

iommu=nobypass can be replaced with iommu.dma_mode=strict.

Signed-off-by: Zhen Lei 
---
 Documentation/admin-guide/kernel-parameters.txt |  2 --
 arch/powerpc/platforms/powernv/pci-ioda.c   | 23 +--
 drivers/iommu/Kconfig   |  1 +
 3 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index a2df11945b33fc9..f88a8bff3c0caa0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1789,8 +1789,6 @@
soft
pt  [x86]
nopt[x86]
-   nobypass[PPC/POWERNV]
-   Disable IOMMU bypass, using IOMMU for PCI devices.
 
 
iommu.dma_mode= [ARM64] Configure default dma mode. if unset, use the
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3ead4c237ed0ec9..be0234c170316bc 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -85,29 +85,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const 
char *level,
va_end(args);
 }
 
-static bool pnv_iommu_bypass_disabled __read_mostly;
 static bool pci_reset_phbs __read_mostly;
 
-static int __init iommu_setup(char *str)
-{
-   if (!str)
-   return -EINVAL;
-
-   while (*str) {
-   if (!strncmp(str, "nobypass", 8)) {
-   pnv_iommu_bypass_disabled = true;
-   pr_info("PowerNV: IOMMU bypass window disabled.\n");
-   break;
-   }
-   str += strcspn(str, ",");
-   if (*str == ',')
-   str++;
-   }
-
-   return 0;
-}
-early_param("iommu", iommu_setup);
-
 static int __init pci_reset_phbs_setup(char *str)
 {
pci_reset_phbs = true;
@@ -2456,7 +2435,7 @@ static long pnv_pci_ioda2_setup_default_config(struct 
pnv_ioda_pe *pe)
return rc;
}
 
-   if (!pnv_iommu_bypass_disabled)
+   if (IOMMU_DMA_MODE_IS_PASSTHROUGH())
pnv_pci_ioda2_set_bypass(pe, true);
 
return 0;
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d88dc44d60d88ea..b053eeaa82ebca8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -77,6 +77,7 @@ config IOMMU_DEBUGFS
 choice
prompt "IOMMU dma mode"
depends on IOMMU_API
+   default IOMMU_DMA_MODE_PASSTHROUGH if (PPC_POWERNV && PCI)
default IOMMU_DMA_MODE_LAZY if S390_IOMMU
default IOMMU_DMA_MODE_STRICT
help
-- 
1.8.3

[PATCH v4 4/6] s390/pci: use common boot option iommu.dma_mode

[Zhen Lei]

s390_iommu=strict can be replaced with iommu.dma_mode=strict.

Signed-off-by: Zhen Lei 
---
 Documentation/admin-guide/kernel-parameters.txt |  7 ---
 arch/s390/pci/pci_dma.c | 20 +---
 drivers/iommu/Kconfig   |  1 +
 3 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 60409ad23b2ac8b..a2df11945b33fc9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4095,13 +4095,6 @@
 
S   [KNL] Run init in single mode
 
-   s390_iommu= [HW,S390]
-   Set s390 IOTLB flushing mode
-   strict
-   With strict flushing every unmap operation will result 
in
-   an IOTLB flush. Default is lazy flushing before reuse,
-   which is faster.
-
sa1100ir[NET]
See drivers/net/irda/sa1100_ir.c.
 
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 9e52d1527f71495..6f1615c16f33995 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -17,7 +17,6 @@
 
 static struct kmem_cache *dma_region_table_cache;
 static struct kmem_cache *dma_page_table_cache;
-static int s390_iommu_strict;
 
 static int zpci_refresh_global(struct zpci_dev *zdev)
 {
@@ -193,13 +192,13 @@ static int __dma_purge_tlb(struct zpci_dev *zdev, 
dma_addr_t dma_addr,
if (!zdev->tlb_refresh)
return 0;
} else {
-   if (!s390_iommu_strict)
+   if (IOMMU_DMA_MODE_IS_LAZY())
return 0;
}
 
ret = zpci_refresh_trans((u64) zdev->fh << 32, dma_addr,
 PAGE_ALIGN(size));
-   if (ret == -ENOMEM && !s390_iommu_strict) {
+   if (ret == -ENOMEM && IOMMU_DMA_MODE_IS_LAZY()) {
/* enable the hypervisor to free some resources */
if (zpci_refresh_global(zdev))
goto out;
@@ -278,7 +277,7 @@ static dma_addr_t dma_alloc_address(struct device *dev, int 
size)
spin_lock_irqsave(&zdev->iommu_bitmap_lock, flags);
offset = __dma_alloc_iommu(dev, zdev->next_bit, size);
if (offset == -1) {
-   if (!s390_iommu_strict) {
+   if (IOMMU_DMA_MODE_IS_LAZY()) {
/* global flush before DMA addresses are reused */
if (zpci_refresh_global(zdev))
goto out_error;
@@ -313,7 +312,7 @@ static void dma_free_address(struct device *dev, dma_addr_t 
dma_addr, int size)
if (!zdev->iommu_bitmap)
goto out;
 
-   if (s390_iommu_strict)
+   if (!IOMMU_DMA_MODE_IS_LAZY())
bitmap_clear(zdev->iommu_bitmap, offset, size);
else
bitmap_set(zdev->lazy_bitmap, offset, size);
@@ -584,7 +583,7 @@ int zpci_dma_init_device(struct zpci_dev *zdev)
rc = -ENOMEM;
goto free_dma_table;
}
-   if (!s390_iommu_strict) {
+   if (IOMMU_DMA_MODE_IS_LAZY()) {
zdev->lazy_bitmap = vzalloc(zdev->iommu_pages / 8);
if (!zdev->lazy_bitmap) {
rc = -ENOMEM;
@@ -671,12 +670,3 @@ void zpci_dma_exit(void)
/* dma_supported is unconditionally true without a callback */
 };
 EXPORT_SYMBOL_GPL(s390_pci_dma_ops);
-
-static int __init s390_iommu_setup(char *str)
-{
-   if (!strncmp(str, "strict", 6))
-   s390_iommu_strict = 1;
-   return 0;
-}
-
-__setup("s390_iommu=", s390_iommu_setup);
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 19118cfdea1c335..d88dc44d60d88ea 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -77,6 +77,7 @@ config IOMMU_DEBUGFS
 choice
prompt "IOMMU dma mode"
depends on IOMMU_API
+   default IOMMU_DMA_MODE_LAZY if S390_IOMMU
default IOMMU_DMA_MODE_STRICT
help
  IOMMU dma mode, such as: passthrough, lazy, strict.
-- 
1.8.3

Re: [PATCH v3] RISC-V: Fix Maximum Physical Memory 2GiB option for 64bit systems

[Anup Patel]

On Sat, Apr 6, 2019 at 2:47 AM Palmer Dabbelt  wrote:
>
> On Thu, 04 Apr 2019 23:01:11 PDT (-0700), a...@brainfault.org wrote:
> > On Fri, Apr 5, 2019 at 11:24 AM Christoph Hellwig  
> > wrote:
> >>
> >> On Fri, Apr 05, 2019 at 05:49:34AM +, Anup Patel wrote:
> >> > The Maximum Physical Memory 2GiB option for 64bit systems is currently
> >> > broken because kernel hangs at boot-time when this option is enabled
> >> > and the underlying system has more than 2GiB memory.
> >> >
> >> > This issue can be easily reproduced on SiFive Unleashed board where
> >> > we have 8GiB of memory.
> >> >
> >> > This patch fixes above issue by removing unusable memory region in
> >> > setup_bootmem().
> >> >
> >> > Signed-off-by: Anup Patel 
> >> > Reviewed-by: Christoph Hellwig 
> >>
> >> Btw, what is the rationale behind even offering the 2GiB option and
> >> the medlow model on 64-bit?  Do we reall have use cases where the
> >> slightly more effient generated code matters so much to keep up
> >> the support burden of this mostly unused and unusual configuration?
>
> I'd be OK dropping medlow on rv64.  The performance impact of medany is 
> pretty minor
> these days, and even back when we added the option it was mostly paranoia 
> about
> the linker being correct.  medany has been solid on rv64 for a while, but we
> did recently find a pretty major toolchain bug in medany/rv32 so if we were to
> drop that we'd need to enforce a pretty recent binutils version (the latest
> release is OK, I'd have to check on the previous one).  I'd prefer to avoid
> that, and since medany doesn't really buy us anything on rv32 it seems fine to
> leave it that way.
>
> Given how many issues we've found here recently I doubt anyone is flipping 
> this
> option away from the default for their base ISA.

Actually, this issue was reported by someone trying out Maximum Physical
Memory 2GiB option.

I agree that "Maximum Physical Memory 2GiB option" is not that useful and
does not provide much gain over cmodel medany but I would suggest that we
take this patch as a RC fix and remove "Maximum Physical Memory 2GiB
option" as separate patch because:

1. This option has been part of few kernel releases. Even if don't
recommend someone might flip it and report an issue.

2. This fix also takes care of the situation where we are using "Maximum
Physical Memory 128GiB" option (default) and underlying host has more
than 128 GiB memory (assuming a server-class RISC-V system).

>
> > Yes, if we want to use medlow with 64bit then max physical memory
> > can be 2GiB. Otherwise, I don't any practical use of restricting max
> > physical memory to 2GiB on 64bit systems.
> >
> > BTW, as-per latest revision of RISC-V priviledge spece the MMU SV32
> > mode will be able to access 34bit physical memory (i.e. 16GiB) so
> > max physical memory 2GiB will also be required for 32bit system for
> > medlow.
>
> It's a bit more complicated that than.  The 34-bit physical addresses have 
> been
> in the spec for a long time, but we've never bothered supporting them in 
> Linux.
> Right now we assume we can map all physical memory into a contiguous region,
> which is why we tie PAGE_OFFSET to the maximum physical memory.  It's
> impossible to map all physical memory with 34-bit physical addresses on a
> 32-bit system, so we'll need to break that assumption to move forward with
> 34-bit physical addresses anyway.
>
> Additionally: medlow can map everything on 32-bit systems anyway, so moving to
> medany doesn't buy you anything.

Currently, QEMU emulates the legacy SV32 with 32-bit physical address so
first QEMU has to be updated.

Further, I think we will need a kconfig option for new SV32 with 34bit physical
address to support existing RV32 hardware which implements SV32 with
32bit physical address.

Regards,
Anup

Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output

[Li, Aubrey]

On 2019/4/7 5:41, Alexey Dobriyan wrote:
> On Fri, Apr 05, 2019 at 09:32:35PM +0200, Thomas Gleixner wrote:
>>> +/* Add support for architecture specific output in /proc/pid/status */
>>> +extern void arch_proc_pid_status(struct seq_file *m, struct task_struct 
>>> *task);
>  ^^
> 
> Unnecessary extern.
> 
The linkage is default extern, but with this functions and variables
can be treated the same way.

Is it mandatory not to use it explicitly? ./script/checkpatch.pl did
not report this.

Thanks,
-Aubrey

Multi-threaded packet parsing ?

[Justin Iurman]

Hi all,

Currently working inside IPv6 on EH and more specifically on hop-by-hop's. I 
was wondering if packet processing/parsing is multi-threaded or not ? Actually, 
I want to store per-packet EH information on net_device struct, which would be 
only valid for current packet processed/parsed by the dev. The goal is to take 
advantage of the existing parsing to store important info, which would avoid 
useless duplicate jobs right after the processing of EH. It should be fine if 
it's not multi-threaded, which is not ASAIK but just wanted to make sure. Can 
you confirm/infirm ?

Thanks,
Justin

Re: [patch V2 28/29] x86/irq/64: Remap the IRQ stack with guard pages

[Andy Lutomirski]

> On Apr 7, 2019, at 2:34 AM, Thomas Gleixner  wrote:
> 
> On Sun, 7 Apr 2019, Andy Lutomirski wrote:
>>> On Apr 6, 2019, at 11:08 PM, Thomas Gleixner  wrote:
>>> 
> On Sat, 6 Apr 2019, Andy Lutomirski wrote:
> On Fri, Apr 5, 2019 at 8:11 AM Thomas Gleixner  wrote:
> 
> From: Andy Lutomirski 
> 
> The IRQ stack lives in percpu space, so an IRQ handler that overflows it
> will overwrite other data structures.
> 
> Use vmap() to remap the IRQ stack so that it will have the usual guard
> pages that vmap/vmalloc allocations have. With this the kernel will panic
> immediately on an IRQ stack overflow.
 
 The 0day bot noticed that this dies with DEBUG_PAGEALLOC on.  This is
 because the store_stackinfo() function is utter garbage and this patch
 correctly detects just how broken it is.  The attached patch "fixes"
 it.  (It also contains a reliability improvement that should probably
 get folded in, but is otherwise unrelated.)
 
 A real fix would remove the generic kstack_end() function entirely
 along with __HAVE_ARCH_KSTACK_END and would optionally replace
 store_stackinfo() with something useful.  Josh, do we have a generic
 API to do a little stack walk like this?  Otherwise, I don't think it
 would be the end of the world to just remove the offending code.
>>> 
>>> Yes, I found the same yesterday before heading out. It's already broken
>>> with the percpu stack because there is no guarantee that the per cpu stack
>>> is thread size aligned. It's guaranteed to be page aligned not more.
>>> 
>>> I'm all for removing that nonsense, but the real question is whether there
>>> is more code which assumes THREAD_SIZE aligned stacks aside of the thread
>>> stack itself.
>>> 
>>> 
>> Well, any code like this is already busted, since the stacks alignment
>> doesn’t really change with these patches applied.
> 
> It does. The existing code has it aligned by chance because the irq stack
> is the first entry in the per cpu area. But yes, there is no reason to require
> that alignment for irqstacks.
> 

Isn’t it the first entry in the percpu area (the normal one, not cea)?  Is that 
aligned beyond PAGE_SIZE?

Removing pcap?

[Alexandre Belloni]

Hello Antonio, Harald,

I've had a look at the PCAP RTC driver because I'm removing a few
deprecated APIs. While doing so, I've discovered that the driver has
never worked properly because PCAP_RTC_TOD_MASK and PCAP_RTC_DAY_MASK
are both missing a bit so every day would roll over at 18:12:15 and the
whole the date would roll over in 2014.

I discussed with Arnd about 59ee93a528b9 ("ARM: pxa: remove irq_to_gpio
from ezx-pcap driver") and it seems the whole EZX support has been
broken for a while.

Is it worth fixing the RTC driver or could I remove it?

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 2/2] arm64: dts: h6: Add watchdog node

[Clément Péron]

Hi,

On Fri, 5 Apr 2019 at 18:24, Clément Péron  wrote:
>
> Hi,
>
> On Fri, 5 Apr 2019 at 17:08, Maxime Ripard  wrote:
> >
> > On Fri, Apr 05, 2019 at 10:59:35PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Apr 5, 2019 at 10:50 PM Maxime Ripard  
> > > wrote:
> > > >
> > > > On Fri, Apr 05, 2019 at 10:35:08PM +0800, Chen-Yu Tsai wrote:
> > > > > On Fri, Apr 5, 2019 at 5:02 PM Maxime Ripard 
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Apr 04, 2019 at 03:57:36PM +0200, Clément Péron wrote:
> > > > > > > Allwinner H6 has a watchog compatible with A31.
> > > > > > >
> > > > > > > Declare it in the device tree.
> > > > > > >
> > > > > > > Signed-off-by: Clément Péron 
> > > > > >
> > > > > > Applied both, thanks!
> > > > > > Maxime
> > > > >
> > > > > IIRC there are 3 watchdogs on the H6. One is the trusted watchdog,
> > > > > which should be reserved for underlying firmware.
> > > > >
> > > > > The other two are the normal and R-block watchdog. Although they
> > > > > look the same, the "normal" one can't reset the system. :(
> > > > > That one is actually the one ATF currently uses. So reboot doesn't
> > > > > work on the H6.
>
> Some users report that the reboot on the PineH64 actually works.
>
> Clement
>
> > > >
> > > > So that patch will not do anything then?

Did some test and only interrupts are working right now. If the WDOG
is configured to make the board reboot the system will be stuck :S
Maybe better to disabled it for now and leave a comment.
I will try to ask some Pine H64 users to do the same tests.

Test done on my Beelink GS1 :
/* This should reset the system after 0.5s */
# devmem $((0x030090a0 + 0x0014))
0x0001
# devmem $((0x030090a0 + 0x0018))
0x
# devmem $((0x030090a0 + 0x0018)) 32 0x1
#
/* System is Stuck*/

/* This should reset the system after 1s */
# devmem $((0x030090a0 + 0x0014))
0x0001
# devmem $((0x030090a0 + 0x0018))
0x
# devmem $((0x030090a0 + 0x0018)) 32 $((0x1 << 4 | 0x1))
#
/* System is Stuck*/

/* This should reset the system after 1s (as recommended in the User Manual) */
# devmem $((0x030090a0 + 0x0014))
0x0001
# devmem $((0x030090a0 + 0x0018))
0x
# devmem $((0x030090a0 + 0x0018)) 32 $((0x1 << 4))
# devmem $((0x030090a0 + 0x0018))
0x0010
# devmem $((0x030090a0 + 0x0018)) 32 $((0x1 << 4 | 0x1))
#
/* System is Stuck*/

/* This should trig an interrupt after 0.5s */
# devmem $((0x030090a0 + 0x0014)) 32 0x32
# devmem $((0x030090a0 + 0x0014))
0x0002
# devmem $((0x030090a0 + 0x0018))
0x
# devmem $((0x030090a0 + 0x0018)) 32 $((0x1 << 4 | 0x1))
# devmem $((0x030090a0 + 0x0004))
0x0001
/* INT is triggered */

Regards,
Clement

> > >
> > > I'm still on vacation, so I haven't checked the address of the new device.
> > > If it's the normal one, then yeah, it won't do anything. I've tried that.
> > > IIRC Samuel (or someone else) on IRC also mentioned this.
> >
> > It's the one in the timer that we've used since pretty much day 1 on
> > older SoCs, so I guess it qualifies as the normal one :)
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com

[GIT PULL] MTD fixes for 5.1-rc4

[Richard Weinberger]

Linus,

The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:

  Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git 
tags/mtd/fixes-for-5.1-rc4

for you to fetch changes up to d9b8a67b3b95a5c5aae6422b8113adc1c2485f2b:

  mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer (2019-04-05 
00:39:19 +0200)


This pull request contains a single fix for MTD:

- Fix for a possible infinite loop in the cfi_cmdset_0002 driver


Liu Jian (1):
  mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer

 drivers/mtd/chips/cfi_cmdset_0002.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

[PATCH] watchdog: rtd119x_wdt: Fix remove function

[Guenter Roeck]

The driver registers the watchdog with devm_watchdog_register_device() but
still calls watchdog_unregister_device() on remove. Since clocks have to
be stopped when removing the driver, after the watchdog device has been
unregistered, we can not drop the call to watchdog_unregister_device().
Use watchdog_register_device() to register the watchdog.

Fixes: 2bdf6acbfead7 ("watchdog: Add Realtek RTD1295")
Cc: Andreas Färber 
Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/rtd119x_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/rtd119x_wdt.c b/drivers/watchdog/rtd119x_wdt.c
index d823c9def36f..cb17c49f3534 100644
--- a/drivers/watchdog/rtd119x_wdt.c
+++ b/drivers/watchdog/rtd119x_wdt.c
@@ -133,7 +133,7 @@ static int rtd119x_wdt_probe(struct platform_device *pdev)
rtd119x_wdt_set_timeout(&data->wdt_dev, data->wdt_dev.timeout);
rtd119x_wdt_stop(&data->wdt_dev);
 
-   ret = devm_watchdog_register_device(&pdev->dev, &data->wdt_dev);
+   ret = watchdog_register_device(&data->wdt_dev);
if (ret) {
clk_disable_unprepare(data->clk);
clk_put(data->clk);
-- 
2.7.4

Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output

[Alexey Dobriyan]

On Sun, Apr 07, 2019 at 09:02:38PM +0800, Li, Aubrey wrote:
> On 2019/4/7 5:41, Alexey Dobriyan wrote:
> > On Fri, Apr 05, 2019 at 09:32:35PM +0200, Thomas Gleixner wrote:
> >>> +/* Add support for architecture specific output in /proc/pid/status */
> >>> +extern void arch_proc_pid_status(struct seq_file *m, struct task_struct 
> >>> *task);
> >  ^^
> > 
> > Unnecessary extern.
> > 
> The linkage is default extern, but with this functions and variables
> can be treated the same way.
> 
> Is it mandatory not to use it explicitly? ./script/checkpatch.pl did
> not report this.

"extern" is only necessary for variables. For prototypes, it is more typing
and more characters on the screen.

checkpatch.pl doesn't report it because opening floodgates is not the plan.

Yours,
Extern Police.

[PATCH v2 3/3] ARM: dts: msm8974-FP2: Add vibration motor

[Luca Weiss]

Signed-off-by: Luca Weiss 
---
 arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts 
b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
index 643c57f84818..bf402ae39226 100644
--- a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
@@ -50,6 +50,12 @@
};
};
 
+   vibrator {
+   compatible = "gpio-vibrator";
+   enable-gpios = <&msmgpio 86 GPIO_ACTIVE_HIGH>;
+   vcc-supply = <&pm8941_l18>;
+   };
+
smd {
rpm {
rpm_requests {
-- 
2.21.0

[PATCH v2 1/3] dt-bindings: input: add GPIO controllable vibrator

[Luca Weiss]

Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.

Signed-off-by: Luca Weiss 
---
Changes from v1:
- Mark vcc-supply as optional

 .../bindings/input/gpio-vibrator.txt  | 20 +++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-vibrator.txt

diff --git a/Documentation/devicetree/bindings/input/gpio-vibrator.txt 
b/Documentation/devicetree/bindings/input/gpio-vibrator.txt
new file mode 100644
index ..93e5a8e7622d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-vibrator.txt
@@ -0,0 +1,20 @@
+* GPIO vibrator device tree bindings
+
+Registers a GPIO device as vibrator, where the vibration motor just has the
+capability to turn on or off. If the device is connected to a pwm, you should
+use the pwm-vibrator driver instead.
+
+Required properties:
+- compatible: should contain "gpio-vibrator"
+- enable-gpios: Should contain a GPIO handle
+
+Optional properties:
+- vcc-supply: Phandle for the regulator supplying power
+
+Example from Fairphone 2:
+
+vibrator {
+   compatible = "gpio-vibrator";
+   enable-gpios = <&msmgpio 86 GPIO_ACTIVE_HIGH>;
+   vcc-supply = <&pm8941_l18>;
+};
-- 
2.21.0

[PATCH v2 2/3] Input: add a driver for GPIO controllable vibrators

[Luca Weiss]

Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.

Signed-off-by: Luca Weiss 
---
 drivers/input/misc/Kconfig  |  12 ++
 drivers/input/misc/Makefile |   1 +
 drivers/input/misc/gpio-vibra.c | 214 
 3 files changed, 227 insertions(+)
 create mode 100644 drivers/input/misc/gpio-vibra.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index e15ed1bb8558..6dfe9e2fe5b1 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
 To compile this driver as a module, choose M here: the module
 will be called gpio_decoder.
 
+config INPUT_GPIO_VIBRA
+   tristate "GPIO vibrator support"
+   depends on GPIOLIB || COMPILE_TEST
+   select INPUT_FF_MEMLESS
+   help
+ Say Y here to get support for GPIO based vibrator devices.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called gpio-vibra.
+
 config INPUT_IXP4XX_BEEPER
tristate "IXP4XX Beeper support"
depends on ARCH_IXP4XX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b936c5b1d4ac..f38ebbdb05e2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS)   += drv2667.o
 obj-$(CONFIG_INPUT_GP2A)   += gp2ap002a00f.o
 obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o
 obj-$(CONFIG_INPUT_GPIO_DECODER)   += gpio_decoder.o
+obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.o
 obj-$(CONFIG_INPUT_HISI_POWERKEY)  += hisi_powerkey.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
diff --git a/drivers/input/misc/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
new file mode 100644
index ..14f9534668c8
--- /dev/null
+++ b/drivers/input/misc/gpio-vibra.c
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  GPIO vibrator driver
+ *
+ *  Copyright (C) 2019 Luca Weiss 
+ *
+ *  Based on PWM vibrator driver:
+ *  Copyright (C) 2017 Collabora Ltd.
+ *
+ *  Based on previous work from:
+ *  Copyright (C) 2012 Dmitry Torokhov 
+ *
+ *  Based on PWM beeper driver:
+ *  Copyright (C) 2010, Lars-Peter Clausen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum vibrator_state {
+   VIBRATOR_OFF,
+   VIBRATOR_ON
+};
+
+struct gpio_vibrator {
+   struct input_dev *input;
+   struct gpio_desc *gpio;
+   struct regulator *vcc;
+
+   struct work_struct play_work;
+   enum vibrator_state state;
+   bool vcc_on;
+};
+
+static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
+{
+   struct device *pdev = vibrator->input->dev.parent;
+   int err;
+
+   if (!vibrator->vcc_on) {
+   err = regulator_enable(vibrator->vcc);
+   if (err) {
+   dev_err(pdev, "failed to enable regulator: %d", err);
+   return err;
+   }
+   vibrator->vcc_on = true;
+   }
+
+   gpiod_set_value(vibrator->gpio, 1);
+
+   return 0;
+}
+
+static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
+{
+   gpiod_set_value(vibrator->gpio, 0);
+
+   if (vibrator->vcc_on) {
+   regulator_disable(vibrator->vcc);
+   vibrator->vcc_on = false;
+   }
+}
+
+static void gpio_vibrator_play_work(struct work_struct *work)
+{
+   struct gpio_vibrator *vibrator = container_of(work,
+   struct gpio_vibrator, play_work);
+
+   if (vibrator->state == VIBRATOR_ON)
+   gpio_vibrator_start(vibrator);
+   else
+   gpio_vibrator_stop(vibrator);
+}
+
+static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
+   struct ff_effect *effect)
+{
+   struct gpio_vibrator *vibrator = input_get_drvdata(dev);
+
+   int level = effect->u.rumble.strong_magnitude;
+
+   if (!level)
+   level = effect->u.rumble.weak_magnitude;
+
+   if (level)
+   vibrator->state = VIBRATOR_ON;
+   else
+   vibrator->state = VIBRATOR_OFF;
+
+   schedule_work(&vibrator->play_work);
+
+   return 0;
+}
+
+static void gpio_vibrator_close(struct input_dev *input)
+{
+   struct gpio_vibrator *vibrator = input_get_drvdata(input);
+
+   cancel_work_sync(&vibrator->play_work);
+   gpio_vibrator_stop(vibrator);
+}
+
+static int gpio_vibrator_probe(struct platform_device *pdev)
+{
+   struct gpio_vibrator *vibrator;
+   int err;
+
+   vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
+   if (!vibrator)
+   return -ENOMEM;
+
+   vibrator->input = devm_input_allocate_device(&pdev->dev);
+   if (!vibrato

Re: [PATCH v2] ext4: fix prefetchw of NULL page

[Theodore Ts'o]

On Sun, Mar 31, 2019 at 04:11:34PM +0800, Liu Xiang wrote:
> In ext4_mpage_readpages(), if the parameter pages is not NULL, another
> parameter page is NULL. At the first time prefetchw(&page->flags)
> works on NULL. From second time, prefetchw(&page->flags) always works on
> the last consumed page. This might do little improvment for handling
> current page. So prefetchw() should be called while the page pointer
> has just been updated.

Thanks, applied.

- Ted

Re: [GIT PULL] MTD fixes for 5.1-rc4

[pr-tracker-bot]

The pull request you sent on Sun, 07 Apr 2019 16:38:29 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git 
> tags/mtd/fixes-for-5.1-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/82331a70cc3c2901c4ae36ff88d5a28f6d14df32

Thank you!

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

Re: [PATCH] ext4: use BUG() instead of BUG_ON(1)

[Theodore Ts'o]

On Mon, Mar 25, 2019 at 02:00:25PM +0100, Arnd Bergmann wrote:
> BUG_ON(1) leads to bogus warnings from clang when
> CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
> 
>   
> 
> Change it to BUG() so clang can see that this code path can never
> continue.

Thanks, applied.

- Ted

Re: [PATCH v2 4/4] power: supply: add Ingenic JZ47xx battery driver.

[Sebastian Reichel]

Hi,

On Sun, Mar 24, 2019 at 03:31:37PM +, Jonathan Cameron wrote:
> On Sat, 23 Mar 2019 18:28:09 +0100
> Artur Rojek  wrote:
> 
> > Add a driver for battery present on Ingenic JZ47xx SoCs.
> > 
> > Signed-off-by: Artur Rojek 
> The IIO parts look fine to me.
> Reviewed-by: Jonathan Cameron 
> 
> Sebastian, assuming you are happy with this version,

The driver itself looks ok. I'm a bit unhappy, that we already have
jz4740-battery. This driver is much cleaner, but does not yet seem
to be ready to replace it. Artur Rojek what are your plans regarding
to the existing driver? Is there currently work going on migrating
JZ47xx to DT?

> do you have any preference for how we handle this series?
> 
> Probably needs one of us to do an immutable branch with just this
> in it.  I'm happy to do so once all the relevant Acks etc are in
> place, but don't mind if you want to!

I suppose you could provide an immutable branch with just the first
two patches in it. Then I can pull it and apply the power-supply
patches on top.

-- Sebastian

> Thanks,
> 
> Jonathan
> 
> > ---
> > 
> > Changes:
> > 
> > v2: - rework the return logic in ingenic_battery_get_property,
> > - make index offsets point forward in ingenic_battery_set_scale,
> > - fix spacing around scale_raw[best_idx + 1]
> > 
> >  drivers/power/supply/Kconfig   |  11 ++
> >  drivers/power/supply/Makefile  |   1 +
> >  drivers/power/supply/ingenic-battery.c | 180 +
> >  3 files changed, 192 insertions(+)
> >  create mode 100644 drivers/power/supply/ingenic-battery.c
> > 
> > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> > index e901b9879e7e..9bfb1637ec28 100644
> > --- a/drivers/power/supply/Kconfig
> > +++ b/drivers/power/supply/Kconfig
> > @@ -169,6 +169,17 @@ config BATTERY_COLLIE
> >   Say Y to enable support for the battery on the Sharp Zaurus
> >   SL-5500 (collie) models.
> >  
> > +config BATTERY_INGENIC
> > +   tristate "Ingenic JZ47xx SoCs battery driver"
> > +   depends on MIPS || COMPILE_TEST
> > +   depends on INGENIC_ADC
> > +   help
> > + Choose this option if you want to monitor battery status on
> > + Ingenic JZ47xx SoC based devices.
> > +
> > + This driver can also be built as a module. If so, the module will be
> > + called ingenic-battery.
> > +
> >  config BATTERY_IPAQ_MICRO
> > tristate "iPAQ Atmel Micro ASIC battery driver"
> > depends on MFD_IPAQ_MICRO
> > diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> > index b731c2a9b695..9e2c481d0187 100644
> > --- a/drivers/power/supply/Makefile
> > +++ b/drivers/power/supply/Makefile
> > @@ -34,6 +34,7 @@ obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
> >  obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
> >  obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
> >  obj-$(CONFIG_BATTERY_COLLIE)   += collie_battery.o
> > +obj-$(CONFIG_BATTERY_INGENIC)  += ingenic-battery.o
> >  obj-$(CONFIG_BATTERY_IPAQ_MICRO) += ipaq_micro_battery.o
> >  obj-$(CONFIG_BATTERY_WM97XX)   += wm97xx_battery.o
> >  obj-$(CONFIG_BATTERY_SBS)  += sbs-battery.o
> > diff --git a/drivers/power/supply/ingenic-battery.c 
> > b/drivers/power/supply/ingenic-battery.c
> > new file mode 100644
> > index ..822aee1c7b64
> > --- /dev/null
> > +++ b/drivers/power/supply/ingenic-battery.c
> > @@ -0,0 +1,180 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Battery driver for the Ingenic JZ47xx SoCs
> > + * Copyright (c) 2019 Artur Rojek 
> > + *
> > + * based on drivers/power/supply/jz4740-battery.c
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct ingenic_battery {
> > +   struct device *dev;
> > +   struct iio_channel *channel;
> > +   struct power_supply_desc desc;
> > +   struct power_supply *battery;
> > +   struct power_supply_battery_info info;
> > +};
> > +
> > +static int ingenic_battery_get_property(struct power_supply *psy,
> > +   enum power_supply_property psp,
> > +   union power_supply_propval *val)
> > +{
> > +   struct ingenic_battery *bat = power_supply_get_drvdata(psy);
> > +   struct power_supply_battery_info *info = &bat->info;
> > +   int ret;
> > +
> > +   switch (psp) {
> > +   case POWER_SUPPLY_PROP_HEALTH:
> > +   ret = iio_read_channel_processed(bat->channel, &val->intval);
> > +   val->intval *= 1000;
> > +   if (val->intval < info->voltage_min_design_uv)
> > +   val->intval = POWER_SUPPLY_HEALTH_DEAD;
> > +   else if (val->intval > info->voltage_max_design_uv)
> > +   val->intval = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
> > +   else
> > +   val->intval = POWER_SUPPLY_HEALTH_GOOD;
> > +   return ret;
> > +   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> > +   ret = iio_read_channel_processed(bat->channel, &val->intval);
> > +   

Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches

[Lukas Wunner]

On Thu, Mar 28, 2019 at 03:36:16PM +0300, Mika Westerberg wrote:
> +struct tb_path *tb_path_alloc(struct tb *tb, struct tb_port *src, int 
> src_hopid,
> +   struct tb_port *dst, int dst_hopid, int link_nr,
> +   const char *name)
>  {
[...]
> + in_hopid = src_hopid;
> + out_port = NULL;
> +
> + for (i = 0; i < num_hops; i++) {
> + in_port = tb_next_port_on_path(src, dst, out_port);
> + if (!in_port)
> + goto err;
> +
> + if (in_port->dual_link_port && in_port->link_nr != link_nr)
> + in_port = in_port->dual_link_port;
> +
> + ret = tb_port_alloc_in_hopid(in_port, in_hopid, -1);
> + if (ret < 0)
> + goto err;
> + in_hopid = ret;
> +
> + out_port = tb_next_port_on_path(src, dst, in_port);
> + if (!out_port)
> + goto err;
> +
> + if (out_port->dual_link_port && out_port->link_nr != link_nr)
> + out_port = out_port->dual_link_port;
> +
> + if (i == num_hops - 1)
> + ret = tb_port_alloc_out_hopid(out_port, dst_hopid,
> +   dst_hopid);
> + else
> + ret = tb_port_alloc_out_hopid(out_port, -1, -1);
> +
> + if (ret < 0)
> + goto err;
> + out_hopid = ret;
> +
> + path->hops[i].in_hop_index = in_hopid;
> + path->hops[i].in_port = in_port;
> + path->hops[i].in_counter_index = -1;
> + path->hops[i].out_port = out_port;
> + path->hops[i].next_hop_index = out_hopid;
> +
> + in_hopid = out_hopid;
> + }

According to the code comment in struct tb_regs_hop (in tb_regs.h),
the out_hopid ("next_hop" in struct tb_regs_hop) denotes the
"hop to take after sending the packet through out_port (on the
incoming port of the next switch)".

So intuitively, the hop config space is like a routing table and
the entry in in_port's hop config space specifies through which
out_port the packets shall be routed, and which entry to look up
on the remote port reachable through out_port.

This means that the out_hopid must always be identical to the in_hopid
of out_port->remote.  Otherwise the routing wouldn't work.

And yet, you've introduced *two* struct ida for each port in
patch 16.  This doesn't seem to make sense:  The out_hopids ida
of a port always has to be identical to the in_hopids ida of that
port's remote.  But if it's identical, why does it have to exist
twice?

Also, the above algorithm fails to ensure that the two struct ida
are always identical:  It uses the out_hopid on the previous switch
as *minimum* for the in_hopid on the current switch.  If that hopid
is already taken by an existing tunnel, tb_port_alloc_in_hopid()
will allocate a *different* hopid and thereby break the routing.

So either the code comment in struct tb_regs_hop is wrong, or this
algorithm and the duplicate struct ida in patch 16 are wrong, or I'm
missing something.

Thanks,

Lukas

Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output

[Andy Lutomirski]

On Fri, Apr 5, 2019 at 12:32 PM Thomas Gleixner  wrote:
>
> On Sun, 24 Feb 2019, Aubrey Li wrote:
>
> > The architecture specific information of the running processes could
> > be useful to the userland. Add support to examine process architecture
> > specific information externally.
> >
> > Signed-off-by: Aubrey Li 
> > Cc: Peter Zijlstra 
> > Cc: Andi Kleen 
> > Cc: Tim Chen 
> > Cc: Dave Hansen 
> > Cc: Arjan van de Ven 
>
> This really lacks
>
> Cc: Linux API 
> Cc: Alexey Dobriyan 
> Cc: Andrew Morton 
>
> Cc'ed now.
>

I certainly understand why you want to expose this info, but would it
make more sense to instead add an arch_status file in /proc with
architecture-specific info?  Or maybe an x86_status field for x86
status, etc.

[GIT PULL] LM3532 backlight support improvements and relocation

[Jacek Anaszewski]

The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:

  Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
tags/lm3532-driver-improvements

for you to fetch changes up to b3e9d18dc4a5e4d329dea32b59bdde5e012ae64a:

  leds: lm3532: Introduce the lm3532 LED driver (2019-04-06 21:06:07 +0200)

Thanks,
Jacek Anaszewski


LM3532 backlight driver improvements and relocation.

Dan Murphy (4):
  dt: lm3532: Add lm3532 dt doc and update ti_lmu doc
  ARM: dts: omap4-droid4: Update backlight dt properties
  mfd: ti-lmu: Remove LM3532 backlight driver references
  leds: lm3532: Introduce the lm3532 LED driver

 .../devicetree/bindings/leds/leds-lm3532.txt   | 101 +++
 Documentation/devicetree/bindings/mfd/ti-lmu.txt   |  20 -
 arch/arm/boot/dts/omap4-droid4-xt894.dts   |  27 +-
 drivers/leds/Kconfig   |  10 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-lm3532.c | 683 +
 drivers/mfd/ti-lmu.c   |  11 -
 include/linux/mfd/ti-lmu-register.h|  44 --
 include/linux/mfd/ti-lmu.h |   1 -
 9 files changed, 813 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3532.txt
 create mode 100644 drivers/leds/leds-lm3532.c

[GIT PULL] LM3532 backlight support improvements and relocation

[Jacek Anaszewski]

The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:

  Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
tags/lm3532-driver-improvements

for you to fetch changes up to b3e9d18dc4a5e4d329dea32b59bdde5e012ae64a:

  leds: lm3532: Introduce the lm3532 LED driver (2019-04-06 21:06:07 +0200)

Thanks,
Jacek Anaszewski


LM3532 backlight driver improvements and relocation.

Dan Murphy (4):
  dt: lm3532: Add lm3532 dt doc and update ti_lmu doc
  ARM: dts: omap4-droid4: Update backlight dt properties
  mfd: ti-lmu: Remove LM3532 backlight driver references
  leds: lm3532: Introduce the lm3532 LED driver

 .../devicetree/bindings/leds/leds-lm3532.txt   | 101 +++
 Documentation/devicetree/bindings/mfd/ti-lmu.txt   |  20 -
 arch/arm/boot/dts/omap4-droid4-xt894.dts   |  27 +-
 drivers/leds/Kconfig   |  10 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-lm3532.c | 683 +
 drivers/mfd/ti-lmu.c   |  11 -
 include/linux/mfd/ti-lmu-register.h|  44 --
 include/linux/mfd/ti-lmu.h |   1 -
 9 files changed, 813 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3532.txt
 create mode 100644 drivers/leds/leds-lm3532.c

Re: [v2] Updated locking documentation for transaction_t

[Theodore Ts'o]

On Mon, Mar 18, 2019 at 07:42:37PM +0100, Alexander Lochmann wrote:
>   /*t
> -  * Where in the log does this transaction's commit start? [no locking]
> +  * Where in the log does this transaction's commit start?
> +  * [journal_t.j_state_lock]
>*/
>   unsigned long   t_log_start;

Well, technically, that's not quite right.  It's only assigned in one
location, and we hold j_state_lock, yes.  But that's because we need
to access journal->j_head.  At the point where we set t_log_start, the
transaction has already been locked down (transaction->t_state >
T_LOCKED).

Similarly, we happen to be holding j_state where it is currently being
accessed, but it's not because we needed the lock in order to access
t_log_start safely.

>   /*
> -  * When transaction started
> +  * When transaction started [journal_t.j_state_lock]
>*/
>   unsigned long   t_start;

And again, not really.  The primary place where t_start is set is when
the transaction is firstt created, before it's visible anywhere else.
after that, it is used exclusively by the commit thread, and so no
locking is necessary.  It's true that in the places where it is used,
j_state_lock happens to be taken, but it's strictly not necessary.

>  
>   /*
> -  * When commit was requested
> +  * When commit was requested [journal_t.j_state_lock]
>*/
>   unsigned long   t_requested;

Yes, that appears to be correct.

>  
>   /*
> -  * Checkpointing stats [j_checkpoint_sem]
> +  * Checkpointing stats [journal_t.j_list_lock]
>*/
>   struct transaction_chp_stats_s t_chp_stats;
>

This appears to be correct.

- Ted

Re: [PATCH 2/4] ARM: dts: omap4-droid4: Update backlight dt properties

[Jacek Anaszewski]

On 4/5/19 12:00 AM, Tony Lindgren wrote:

* Jacek Anaszewski  [190404 20:12]:

Tony,

On 3/21/19 3:28 PM, Dan Murphy wrote:

Update the properties for the lm3532 device node for droid4.
With this change the backlight LED string and the keypad
LED strings will be controlled separately.

Signed-off-by: Dan Murphy 
---

v5 - No change - https://lore.kernel.org/patchwork/patch/1050409/

v4 - No change - https://lore.kernel.org/patchwork/patch/1050125/
v3 - updated keypad label on v1 comment - 
https://lore.kernel.org/patchwork/patch/1049023/
v2 - Fixed ramp-up and ramp-down properties, removed hard coded property values,
I did not change the label as it is undecided what it could be - 
https://lore.kernel.org/patchwork/patch/1048806/

   arch/arm/boot/dts/omap4-droid4-xt894.dts | 26 
   1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index e21ec929f096..aea206f04f76 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -383,20 +383,30 @@
   };
   &i2c1 {
-   lm3532@38 {
+   led-controller@38 {
compatible = "ti,lm3532";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x38>;
enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
-   lcd_backlight: backlight {
-   compatible = "ti,lm3532-backlight";
+   ramp-up-us = <1024>;
+   ramp-down-us = <8193>;
-   lcd {
-   led-sources = <0 1 2>;
-   ramp-up-msec = <1>;
-   ramp-down-msec = <0>;
-   };


Since I'll be creating integration branch for this series,
and it would be good to have this patch in it too, then
I can do the amendments by myself:


+   lcd_backlight: led@0 {
+   reg = <0>;
+   led-sources = <2>;
+   ti,led-mode = <0>;
+   label = "backlight";


s/backlight/:backlight/


+   linux,default-trigger = "backlight";
+   };
+
+   led@1 {
+   reg = <1>;
+   led-sources = <1>;
+   ti,led-mode = <0>;
+   label = "platform::kbd_backlight";


s/platform::kbd_backlight/:kbd_backlight/


Yes makes sense to me.


and then send you a pull request.

Would you be OK with that?


Sure go for it. Here's my ack for the changes:

Acked-by: Tony Lindgren 

And then for the one liner to fold in below:

Signed-off-by: Tony Lindgren 

8< -
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -214,7 +214,6 @@
  
  		width-mm = <50>;

height-mm = <89>;
-   backlight = <&lcd_backlight>;
  
  		panel-timing {

clock-frequency = <0>;/* Calculated by dsi 
*/



Folded in, thanks. Beside that, I also removed lcd_backlight DT
labels from both DT bindings and dts, since it is now unused
and misleading.

--
Best regards,
Jacek Anaszewski

Re: Removing pcap?

[Harald Welte]

Hi Alexandre,

On Sun, Apr 07, 2019 at 04:07:41PM +0200, Alexandre Belloni wrote:
> Is it worth fixing the RTC driver or could I remove it?

I've left OpenEZX behind quite a long time ago.  Antonio was working
on it for some more time, I don't know if he's still actively using
or maintaining it.

>From my personal point of view, it's only historically relevant and
can certainly be removed from current-day mainline kernels.  That's of
course unless some other people are still actively using it, which
I somewhat doubt about a decade since those phones were last made.

Regards,
Harlad

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Re: [PATCH v2 4/4] power: supply: add Ingenic JZ47xx battery driver.

[Paul Cercueil]

Hi Sebastian,

Le dim. 7 avril 2019 à 18:52, Sebastian Reichel  a 
écrit :

Hi,

On Sun, Mar 24, 2019 at 03:31:37PM +, Jonathan Cameron wrote:

 On Sat, 23 Mar 2019 18:28:09 +0100
 Artur Rojek  wrote:

 > Add a driver for battery present on Ingenic JZ47xx SoCs.
 >
 > Signed-off-by: Artur Rojek 
 The IIO parts look fine to me.
 Reviewed-by: Jonathan Cameron 

 Sebastian, assuming you are happy with this version,


The driver itself looks ok. I'm a bit unhappy, that we already have
jz4740-battery. This driver is much cleaner, but does not yet seem
to be ready to replace it. Artur Rojek what are your plans regarding
to the existing driver? Is there currently work going on migrating
JZ47xx to DT?


Why do you think it's not ready? Feature-wise, it has everything we
need to replace jz4740-battery, which will be trashed as soon as the
LB60 board code is updated to use the new driver.

We are working on porting the JZ47xx code to devicetree, yes. The
ultimate goal is to completely get rid of
arch/mips/jz4740/board-qi_lb60.c and arch/mips/jz4740/platform.c.


 do you have any preference for how we handle this series?

 Probably needs one of us to do an immutable branch with just this
 in it.  I'm happy to do so once all the relevant Acks etc are in
 place, but don't mind if you want to!


I suppose you could provide an immutable branch with just the first
two patches in it. Then I can pull it and apply the power-supply
patches on top.

-- Sebastian


 Thanks,

 Jonathan

 > ---
 >
 > Changes:
 >
 > v2: - rework the return logic in ingenic_battery_get_property,
 > - make index offsets point forward in 
ingenic_battery_set_scale,

 > - fix spacing around scale_raw[best_idx + 1]
 >
 >  drivers/power/supply/Kconfig   |  11 ++
 >  drivers/power/supply/Makefile  |   1 +
 >  drivers/power/supply/ingenic-battery.c | 180 
+

 >  3 files changed, 192 insertions(+)
 >  create mode 100644 drivers/power/supply/ingenic-battery.c
 >
 > diff --git a/drivers/power/supply/Kconfig 
b/drivers/power/supply/Kconfig

 > index e901b9879e7e..9bfb1637ec28 100644
 > --- a/drivers/power/supply/Kconfig
 > +++ b/drivers/power/supply/Kconfig
 > @@ -169,6 +169,17 @@ config BATTERY_COLLIE
 > Say Y to enable support for the battery on the Sharp Zaurus
 > SL-5500 (collie) models.
 >
 > +config BATTERY_INGENIC
 > + tristate "Ingenic JZ47xx SoCs battery driver"
 > + depends on MIPS || COMPILE_TEST
 > + depends on INGENIC_ADC
 > + help
 > +   Choose this option if you want to monitor battery status on
 > +   Ingenic JZ47xx SoC based devices.
 > +
 > +	  This driver can also be built as a module. If so, the module 
will be

 > +   called ingenic-battery.
 > +
 >  config BATTERY_IPAQ_MICRO
 >   tristate "iPAQ Atmel Micro ASIC battery driver"
 >   depends on MFD_IPAQ_MICRO
 > diff --git a/drivers/power/supply/Makefile 
b/drivers/power/supply/Makefile

 > index b731c2a9b695..9e2c481d0187 100644
 > --- a/drivers/power/supply/Makefile
 > +++ b/drivers/power/supply/Makefile
 > @@ -34,6 +34,7 @@ obj-$(CONFIG_BATTERY_PMU)   += pmu_battery.o
 >  obj-$(CONFIG_BATTERY_OLPC)   += olpc_battery.o
 >  obj-$(CONFIG_BATTERY_TOSA)   += tosa_battery.o
 >  obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
 > +obj-$(CONFIG_BATTERY_INGENIC)+= ingenic-battery.o
 >  obj-$(CONFIG_BATTERY_IPAQ_MICRO) += ipaq_micro_battery.o
 >  obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
 >  obj-$(CONFIG_BATTERY_SBS)+= sbs-battery.o
 > diff --git a/drivers/power/supply/ingenic-battery.c 
b/drivers/power/supply/ingenic-battery.c

 > new file mode 100644
 > index ..822aee1c7b64
 > --- /dev/null
 > +++ b/drivers/power/supply/ingenic-battery.c
 > @@ -0,0 +1,180 @@
 > +// SPDX-License-Identifier: GPL-2.0
 > +/*
 > + * Battery driver for the Ingenic JZ47xx SoCs
 > + * Copyright (c) 2019 Artur Rojek 
 > + *
 > + * based on drivers/power/supply/jz4740-battery.c
 > + */
 > +
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +
 > +struct ingenic_battery {
 > + struct device *dev;
 > + struct iio_channel *channel;
 > + struct power_supply_desc desc;
 > + struct power_supply *battery;
 > + struct power_supply_battery_info info;
 > +};
 > +
 > +static int ingenic_battery_get_property(struct power_supply *psy,
 > + enum power_supply_property psp,
 > + union power_supply_propval *val)
 > +{
 > + struct ingenic_battery *bat = power_supply_get_drvdata(psy);
 > + struct power_supply_battery_info *info = &bat->info;
 > + int ret;
 > +
 > + switch (psp) {
 > + case POWER_SUPPLY_PROP_HEALTH:
 > + ret = iio_read_channel_processed(bat->channel, &val->intval);
 > + val->intval *= 1000;
 > + if (val->intval < info->voltage_min_design_uv)
 > + val->intval = POWER_SUPPLY_HEALTH_DEAD;
 > + else if (val->intval > info->voltage_max_design_uv)
 > + val->in

[GIT PULL v2] LM3532 backlight support improvements and relocation

[Jacek Anaszewski]

Changes since v1:

- synchronized DT label properties in DT bindings with what has been agreed
  for the patch "ARM: dts: omap4-droid4: Update backlight dt properties"

The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:

  Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
tags/lm3532-driver-improvements

for you to fetch changes up to bc1b8492c764fea940fc66206047e37a7f8d77e1:

  leds: lm3532: Introduce the lm3532 LED driver (2019-04-07 20:45:49 +0200)

Thanks,
Jacek Anaszewski


LM3532 backlight driver improvements and relocation

Dan Murphy (4):
  dt: lm3532: Add lm3532 dt doc and update ti_lmu doc
  ARM: dts: omap4-droid4: Update backlight dt properties
  mfd: ti-lmu: Remove LM3532 backlight driver references
  leds: lm3532: Introduce the lm3532 LED driver

 .../devicetree/bindings/leds/leds-lm3532.txt   | 101 +++
 Documentation/devicetree/bindings/mfd/ti-lmu.txt   |  20 -
 arch/arm/boot/dts/omap4-droid4-xt894.dts   |  27 +-
 drivers/leds/Kconfig   |  10 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-lm3532.c | 683 +
 drivers/mfd/ti-lmu.c   |  11 -
 include/linux/mfd/ti-lmu-register.h|  44 --
 include/linux/mfd/ti-lmu.h |   1 -
 9 files changed, 813 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3532.txt
 create mode 100644 drivers/leds/leds-lm3532.c

Re: [PATCH 1/4] dt: lm3532: Add lm3532 dt doc and update ti_lmu doc

[Jacek Anaszewski]

Hi Dan,

On 3/21/19 3:28 PM, Dan Murphy wrote:

Add the lm3532 device tree documentation.
Remove lm3532 device tree reference from the ti_lmu devicetree
documentation.

With the addition of the dedicated lm3532 documentation the device
can be removed from the ti_lmu.txt.

The reason for this is that the lm3532 dt documentation now defines
the ability to control LED output strings against different control
banks or groups multiple strings to be controlled by a single control
bank.

Another addition was for ALS lighting control and configuration.  The
LM3532 has a feature that can take in the ALS reading from 2 separate
ALS devices and adjust the brightness on the strings that are configured
to support this feature.

Finally the device specific properties were moved to the parent node as these
properties are not control bank configurable.  These include the runtime ramp
and the ALS configuration.

Reviewed-by: Rob Herring 
Signed-off-by: Dan Murphy 
---


Thank you for your work on this set. Applied.

--
Best regards,
Jacek Anaszewski

[PATCH 2/2] ARM: dts: imx6ul-pico: Add support for the dwarf baseboard

[Otavio Salvador]

From: Fabio Estevam 

Add support for the imx6ul pico board with dwarf baseboard combination.

Signed-off-by: Fabio Estevam 
Signed-off-by: Otavio Salvador 
---

 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/imx6ul-pico-dwarf.dts | 52 +
 2 files changed, 53 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-pico-dwarf.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a969ca820d41..e4a2349e130e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -566,6 +566,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-isiot-nand.dtb \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
+   imx6ul-pico-dwarf.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-pico-pi.dtb \
imx6ul-phytec-phyboard-segin-full.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-pico-dwarf.dts 
b/arch/arm/boot/dts/imx6ul-pico-dwarf.dts
new file mode 100644
index ..3edd60f46d37
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-pico-dwarf.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Copyright 2015 Technexion Ltd.
+//
+// Author: Wig Cheng  
+//Richard Hu 
+//Tapani Utriainen 
+/dts-v1/;
+
+#include "imx6ul-pico.dtsi"
+/ {
+   model = "TechNexion PICO-IMX6UL and DWARF baseboard";
+   compatible = "technexion,imx6ul-pico-dwarf", "fsl,imx6ul";
+
+   sound {
+   compatible = "fsl,imx-audio-sgtl5000";
+   model = "imx6ul-sgtl5000";
+   audio-cpu = <&sai1>;
+   audio-codec = <&sgtl5000>;
+   audio-routing =
+   "LINE_IN", "Line In Jack",
+   "MIC_IN", "Mic Jack",
+   "Mic Jack", "Mic Bias",
+   "Headphone Jack", "HP_OUT";
+   };
+
+   sys_mclk: clock-sys-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <24576000>;
+   };
+};
+
+&i2c2 {
+   clock_frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c2>;
+   status = "okay";
+
+   sgtl5000: codec@a {
+   reg = <0x0a>;
+   compatible = "fsl,sgtl5000";
+   clocks = <&sys_mclk>;
+   VDDA-supply = <®_2p5v>;
+   VDDIO-supply = <®_3p3v>;
+   };
+
+   pressure-sensor@60 {
+   compatible = "fsl,mpl3115";
+   reg = <0x60>;
+   };
+};
-- 
2.21.0

[PATCH 1/2] dt-bindings: arm: fsl: Add support for imx6ul-pico-dwarf

[Otavio Salvador]

From: Fabio Estevam 

Add support for TechNexion's imx6ul-pico-dwarf board.

Signed-off-by: Fabio Estevam 
Signed-off-by: Otavio Salvador 
---

 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 3c7ad36ebd35..944687df45b8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -123,6 +123,7 @@ properties:
 items:
   - enum:
   - fsl,imx6ul-14x14-evk  # i.MX6 UltraLite 14x14 EVK Board
+  - technexion,imx6ul-pico-dwarf # i.MX6 UltraLite Pico Dwarf Board
   - const: fsl,imx6ul
 
   - description: i.MX6ULL based Boards
-- 
2.21.0

Re: [BUG] Rockchip SPI: long burst writes produce unexpected result

[Emil Renner Berthing]

Hi Vicente,

On Sat, 6 Apr 2019 at 19:35, Vicente Bergas  wrote:
>
> Hi,
> i have been experiencing issues writing to NOR-Flash SPI Memories
> from two RK3399-based platforms: gru-kevin and sapphire board.
> For kevin, this resulted in a bricked device because that memory
> is the only boot device.
> Fortunately an external programmer is available.
>
> In order to isolate where the issue can be, several tests have been
> done, after which it makes me think the issue is related to the
> Rockchip SPI driver.
>
> 4KB burst reads work fine.
> The issue is only observed on the write burst length.
>
> Test user user/kernel kernelRK3399
> Num  spaceinterface   space   SoC   Status Notes
> 
> 1flashrom linux_mtd   MTD/RKspi RKspi   Fail
> 2flashrom linux_spi   RKspi RKspi   Fail
> 3flashrom linux_spi   spi_gpio  GPIOOK
> 4custom   linux_spi   spi_gpio  GPIOOK   260-byte burst writes
> 5custom   linux_spi   RKspi RKspi   Fail 260-byte burst writes
> 6custom   linux_spi   RKspi RKspi   OK 1-byte burst writes
> 7custom   linux_spi   RKspi RKspi   OK47-byte burst writes
> 8custom   linux_spi   RKspi RKspi   Fail  48-byte burst writes
>
> 3, 4) Unaccetably slow, device tree is
>   spi_gpio {
> compatible = "spi-gpio";
> #address-cells = <1>;
> #size-cells = <0>;
> cs-gpios   = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
> sck-gpios  = <&gpio1 RK_PB1 GPIO_ACTIVE_HIGH>;
> mosi-gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_HIGH>;
> miso-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
> num-chipselects = <1>;
> spidev@0 {
>   compatible = "spidev";
>   reg = <0>;
>   spi-max-frequency = <5000>;
> };
>   };
> 2, 5, 6, 7, 8) device tree is
>   &spi1 {

Since you say reverting the "set min/max speed" patch fixes your issues
could you try raising the spi clock like this and see if it works for you?

+   assigned-clocks = <&cru SCLK_SPI1>;
+   assigned-clock-rates = <4>;

Of course the driver shouldn't let you configure the spi-controller in a way
that makes it skip bytes, but if this works for you then I still think
you're better off explicitly setting the spi clock speed rather than having
the driver raise it for you. At least while it does it without
checking for errors
or having a way to lower it again as outlined in the commit message.

> status = "okay";
> spidev@0 {
>   compatible = "spidev";
>   reg = <0>;
>   spi-max-frequency = <5000>;
> };
>   };
> ...

/Emil

Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock

[Kirill Smelkov]

On Sat, Apr 06, 2019 at 07:07:14AM -1000, Linus Torvalds wrote:
> On Tue, Mar 26, 2019 at 12:20 PM Kirill Smelkov  wrote:
> >
> > Commit 9c225f2655 (vfs: atomic f_pos accesses as per POSIX) added locking 
> > for
> > file.f_pos access and in particular made concurrent read and write not 
> > possible
> > [...]
> 
> Ok, I have applied this patch - but this patch only - as a
> well-researched preparatory patch.
> 
> The actual conversion patch looks fine to me too, and I see a few
> acks, but I think I'd like to see it during a merge window just
> because it's large and does significant changes, while this one is
> purely preparatory.
> 
> Al, comments?

Linus, thanks a lot for feedback and for accepting the patch.

I agree that it is better to merge the bulk-conversion at the time of
next merge window. I hope Al will pick that patch up and send to you
when the next merge window time comes.

Could we please clarify one thing: is the general complete plan to deal
with this regression, as outlined in the merged patch, ok? I mean do we
agree to further proceed with fs/fuse/ FOPEN_STREAM (patch 3/3) and
backport it + stream_open to v3.14+ stable kernels? Unfortunately it
requires a bit of cooperation from userspace, but this scheme to fix the
regression is the best I could come up with.

If FUSE bits are ok, how should we go? Are we ok to merge that patch
now, or should we wait for the next merge window? I understand that
generally it should be merge window from one side, but since we are
trying to fix regression here and if the plan for regression fix is
accepted it should be merge now. If we merge now, what should be the way
for that patch to get merged?

Fixing regression on FUSE side is my reason to do this whole work -
that's why I care about it the most and ask.

> One small note: please don't use lkml.org references since they tend
> to be slow and flaky - use lore.kernel.org instead. Also, fix your git
> config to use 12-character git hashes (best done by just removing the
> explicit hash size entirely, and letting modern git shorten hashes
> appropriately automatically).

Thanks for pointing to lore.kernel.org - I'm not very keen to kernel
development and did not knew it exists. I was seeing lkml.org being
referenced here and there and that's why I used it. I will use
lore.kernel.org from now.

Short hashes were not due to git config, but due to me trimming them to
10 characters in vim manually. I will use longer hashes as you ask.

Kirill

Re: perf: perf_fuzzer crashes on Pentium 4 systems

[Cyrill Gorcunov]

On Thu, Apr 04, 2019 at 11:20:38PM +0300, Cyrill Gorcunov wrote:
> > the machine still crashes after this, but not right away.
> 
> yes, exactly, if look into disasm code we will see that 0x158
> offset points to hwc from event. Vince, gimme some time, probably
> the weekend so I would dive into the perf code more deeply and
> will try to make some debugging patch for more precise tracking
> of events. The kernel you're running is the latest -tip?

Vince, could you please disable alias events and see if it change
anything, once you have time? Note once we've aliases disabled the
counter for cpu cycles get used for NMI watchdog so PERF_COUNT_HW_CPU_CYCLES
won't be available in "perf" tool itself, but I guess perf_fuzzer uses
direct kernel syscall.
---
 arch/x86/events/intel/p4.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-tip.git/arch/x86/events/intel/p4.c
===
--- linux-tip.git.orig/arch/x86/events/intel/p4.c
+++ linux-tip.git/arch/x86/events/intel/p4.c
@@ -622,6 +622,8 @@ static u64 p4_get_alias_event(u64 config
u64 config_match;
int i;
 
+   return 0;
+
/*
 * Only event with special mark is allowed,
 * we're to be sure it didn't come as malformed

Re: [PATCH v2] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board

[Andreas Kemnade]

ping

On Fri,  1 Mar 2019 19:52:12 +0100
Andreas Kemnade  wrote:

> The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip
> with broadcom internals attached to UART1 and some gpios.
> This addition is in line with similar boards
> 
> Signed-off-by: Andreas Kemnade 
> ---
> changes in v2: remove pinctrl things
>  arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts 
> b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> index 1db2541135a7..57432d0500b1 100644
> --- a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> @@ -69,6 +69,8 @@
>   compatible = "mmc-pwrseq-simple";
>   pinctrl-names = "default";
>   reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
> + clocks = <&rtc 1>;
> + clock-names = "ext_clock";
>   };
>  };
>  
> @@ -122,7 +124,20 @@
>  &uart1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> + uart-has-rtscts;
>   status = "okay";
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + clocks = <&rtc 1>;
> + clock-names = "lpo";
> + vbat-supply = <®_vcc3v3>;
> + vddio-supply = <®_vcc3v3>;
> + device-wakeup-gpios = <&pio 6 13 GPIO_ACTIVE_HIGH>; /* PG13 */
> + host-wakeup-gpios = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
> + shutdown-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> + };
> +
>  };
>  
>  &usb_otg {
> -- 
> 2.11.0
> 
> 


pgp76JT8sTEqv.pgp
Description: OpenPGP digital signature

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/3/19 2:54 AM, Hans de Goede wrote:

> 
> Hi,
> 
> On 03-04-19 07:43, Kai-Heng Feng wrote:
>> i2c-designware-platdrv fails to work after the system restored from
>> hibernation:
>> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 
>> 0x
>>
>> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
>> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
>> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
>> doesn't gets called by acpi_lpss_resume_early(), and this causes the
>> issue.
>>
...
> 
> The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
> so I think it would be better to do this instead to fix this problem:
> 
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 1e2a10a06b9d..cf768608437e 100644
...
> If people affected by the problem can give my version of the fix a test,
> then that would be great.
> 
> Regards,
> 
> Hans

I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead 
of what I had 
been doing previously, which was reverting commit 02e45646d53b.  I tested it on 
an ASUS T100TA 
and unfortunately with both kernels after resume from hibernation I still get 
errors like those 
listed below, and sound no longer works.  I also tried applying the patch from 
Kai-Heng Feng 
(instead of Hans' patch or my revert) on both kernels and again in both cases I 
get these same errors.

In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is 
fixed.  Because 
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the 
new code 
and the 02e45646d53b revert without causing worse problems. But that's probably 
because 
I don't really understand the details of that code.

[  120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[  120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[  121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[  132.782634] i2c_designware 80860F41:01: controller timed out
[  133.806538] i2c_designware 80860F41:01: controller timed out
[  134.830991] i2c_designware 80860F41:01: controller timed out
[  135.855183] i2c_designware 80860F41:01: controller timed out

Let me know if I can do any other testing to help.

Bob Howell

[PATCH 2/8] rtc: ds1672: move oscillator handling to .read_time

[Alexandre Belloni]

Return -EINVAL when trying to read an invalid time instead of just probe
because this is a useful information for userspace.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index b9860820cc90..71645f009e04 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -29,7 +29,7 @@
 static int ds1672_get_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
unsigned long time;
-   unsigned char addr = DS1672_REG_CNT_BASE;
+   unsigned char addr = DS1672_REG_CONTROL;
unsigned char buf[4];
 
struct i2c_msg msgs[] = {
@@ -41,11 +41,25 @@ static int ds1672_get_datetime(struct i2c_client *client, 
struct rtc_time *tm)
{/* read date */
.addr = client->addr,
.flags = I2C_M_RD,
-   .len = 4,
+   .len = 1,
.buf = buf
},
};
 
+   /* read control register */
+   if ((i2c_transfer(client->adapter, &msgs[0], 2)) != 2) {
+   dev_warn(&client->dev, "Unable to read the control register\n");
+   return -EIO;
+   }
+
+   if (buf[0] & DS1672_REG_CONTROL_EOSC) {
+   dev_warn(&client->dev, "Oscillator not enabled. Set time to 
enable.\n");
+   return -EINVAL;
+   }
+
+   addr = DS1672_REG_CNT_BASE;
+   msgs[1].len = 4;
+
/* read date registers */
if ((i2c_transfer(client->adapter, &msgs[0], 2)) != 2) {
dev_err(&client->dev, "%s: read error\n", __func__);
@@ -154,7 +168,6 @@ static int ds1672_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
int err = 0;
-   u8 control;
struct rtc_device *rtc;
 
dev_dbg(&client->dev, "%s\n", __func__);
@@ -178,16 +191,6 @@ static int ds1672_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, rtc);
 
-   /* read control register */
-   err = ds1672_get_control(client, &control);
-   if (err) {
-   dev_warn(&client->dev, "Unable to read the control register\n");
-   }
-
-   if (control & DS1672_REG_CONTROL_EOSC)
-   dev_warn(&client->dev, "Oscillator not enabled. "
-"Set time to enable.\n");
-
/* Register sysfs hooks */
err = device_create_file(&client->dev, &dev_attr_control);
if (err)
-- 
2.20.1

[PATCH 6/8] rtc: ds1672: use .set_time

[Alexandre Belloni]

Use .set_time instead of the deprecated .set_mmss.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 653abef2e5cd..4997b4f3d667 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -84,11 +84,12 @@ static int ds1672_read_time(struct device *dev, struct 
rtc_time *tm)
return 0;
 }
 
-static int ds1672_set_mmss(struct device *dev, unsigned long secs)
+static int ds1672_set_time(struct device *dev, struct rtc_time *tm)
 {
struct i2c_client *client = to_i2c_client(dev);
int xfer;
unsigned char buf[6];
+   unsigned long secs = rtc_tm_to_time64(tm);
 
buf[0] = DS1672_REG_CNT_BASE;
buf[1] = secs & 0x00FF;
@@ -108,7 +109,7 @@ static int ds1672_set_mmss(struct device *dev, unsigned 
long secs)
 
 static const struct rtc_class_ops ds1672_rtc_ops = {
.read_time = ds1672_read_time,
-   .set_mmss = ds1672_set_mmss,
+   .set_time = ds1672_set_time,
 };
 
 static int ds1672_probe(struct i2c_client *client,
-- 
2.20.1

[PATCH 8/8] rtc: ds1672: switch debug message to %ptR

[Alexandre Belloni]

Use %ptR to simplify debug message.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 95c23b31c952..e9e8d02743ee 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -73,10 +73,7 @@ static int ds1672_read_time(struct device *dev, struct 
rtc_time *tm)
 
rtc_time64_to_tm(time, tm);
 
-   dev_dbg(&client->dev, "%s: tm is secs=%d, mins=%d, hours=%d, "
-   "mday=%d, mon=%d, year=%d, wday=%d\n",
-   __func__, tm->tm_sec, tm->tm_min, tm->tm_hour,
-   tm->tm_mday, tm->tm_mon, tm->tm_year, tm->tm_wday);
+   dev_dbg(&client->dev, "%s: tm is %ptR\n", __func__, tm);
 
return 0;
 }
-- 
2.20.1

[PATCH 5/8] rtc: ds1672: use rtc_time64_to_tm

[Alexandre Belloni]

Use the 64bit version of rtc_time_to_tm.rtc_time_to_tm.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 81f1aaeb8964..653abef2e5cd 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -74,7 +74,7 @@ static int ds1672_read_time(struct device *dev, struct 
rtc_time *tm)
time = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
   (buf[1] << 8) | buf[0];
 
-   rtc_time_to_tm(time, tm);
+   rtc_time64_to_tm(time, tm);
 
dev_dbg(&client->dev, "%s: tm is secs=%d, mins=%d, hours=%d, "
"mday=%d, mon=%d, year=%d, wday=%d\n",
-- 
2.20.1

[PATCH 4/8] rtc: ds1672: remove useless indirection

[Alexandre Belloni]

ds1672_get_datetime and ds1672_set_mmss are only used after casting dev
to an i2c_client. Remove that useless indirection.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 4b4757a6644d..81f1aaeb8964 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -26,8 +26,9 @@
  * rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch
  * Time is set to UTC.
  */
-static int ds1672_get_datetime(struct i2c_client *client, struct rtc_time *tm)
+static int ds1672_read_time(struct device *dev, struct rtc_time *tm)
 {
+   struct i2c_client *client = to_i2c_client(dev);
unsigned long time;
unsigned char addr = DS1672_REG_CONTROL;
unsigned char buf[4];
@@ -83,8 +84,9 @@ static int ds1672_get_datetime(struct i2c_client *client, 
struct rtc_time *tm)
return 0;
 }
 
-static int ds1672_set_mmss(struct i2c_client *client, unsigned long secs)
+static int ds1672_set_mmss(struct device *dev, unsigned long secs)
 {
+   struct i2c_client *client = to_i2c_client(dev);
int xfer;
unsigned char buf[6];
 
@@ -104,19 +106,9 @@ static int ds1672_set_mmss(struct i2c_client *client, 
unsigned long secs)
return 0;
 }
 
-static int ds1672_rtc_read_time(struct device *dev, struct rtc_time *tm)
-{
-   return ds1672_get_datetime(to_i2c_client(dev), tm);
-}
-
-static int ds1672_rtc_set_mmss(struct device *dev, unsigned long secs)
-{
-   return ds1672_set_mmss(to_i2c_client(dev), secs);
-}
-
 static const struct rtc_class_ops ds1672_rtc_ops = {
-   .read_time = ds1672_rtc_read_time,
-   .set_mmss = ds1672_rtc_set_mmss,
+   .read_time = ds1672_read_time,
+   .set_mmss = ds1672_set_mmss,
 };
 
 static int ds1672_probe(struct i2c_client *client,
-- 
2.20.1

[PATCH 3/8] rtc: ds1672: remove sysfs debug interface

[Alexandre Belloni]

Remove the control sysfs file as it is not documented, read only and was
only used to provide the oscillator state.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 51 
 1 file changed, 51 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 71645f009e04..4b4757a6644d 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -114,51 +114,6 @@ static int ds1672_rtc_set_mmss(struct device *dev, 
unsigned long secs)
return ds1672_set_mmss(to_i2c_client(dev), secs);
 }
 
-static int ds1672_get_control(struct i2c_client *client, u8 *status)
-{
-   unsigned char addr = DS1672_REG_CONTROL;
-
-   struct i2c_msg msgs[] = {
-   {/* setup read ptr */
-   .addr = client->addr,
-   .len = 1,
-   .buf = &addr
-   },
-   {/* read control */
-   .addr = client->addr,
-   .flags = I2C_M_RD,
-   .len = 1,
-   .buf = status
-   },
-   };
-
-   /* read control register */
-   if ((i2c_transfer(client->adapter, &msgs[0], 2)) != 2) {
-   dev_err(&client->dev, "%s: read error\n", __func__);
-   return -EIO;
-   }
-
-   return 0;
-}
-
-/* following are the sysfs callback functions */
-static ssize_t show_control(struct device *dev, struct device_attribute *attr,
-   char *buf)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-   u8 control;
-   int err;
-
-   err = ds1672_get_control(client, &control);
-   if (err)
-   return err;
-
-   return sprintf(buf, "%s\n", (control & DS1672_REG_CONTROL_EOSC)
-  ? "disabled" : "enabled");
-}
-
-static DEVICE_ATTR(control, S_IRUGO, show_control, NULL);
-
 static const struct rtc_class_ops ds1672_rtc_ops = {
.read_time = ds1672_rtc_read_time,
.set_mmss = ds1672_rtc_set_mmss,
@@ -191,12 +146,6 @@ static int ds1672_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, rtc);
 
-   /* Register sysfs hooks */
-   err = device_create_file(&client->dev, &dev_attr_control);
-   if (err)
-   dev_err(&client->dev, "Unable to create sysfs entry: %s\n",
-   dev_attr_control.attr.name);
-
return 0;
 }
 
-- 
2.20.1

[PATCH 7/8] rtc: ds1672: convert to SPDX identifier

[Alexandre Belloni]

Use SPDX-License-Identifier instead of a verbose license text.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index 4997b4f3d667..95c23b31c952 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * An rtc/i2c driver for the Dallas DS1672
  * Copyright 2005-06 Tower Technologies
  *
  * Author: Alessandro Zummo 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
-- 
2.20.1

[PATCH 1/8] rtc: ds1672: set range

[Alexandre Belloni]

The ds1672 is a 32bit seconds counter.

Also remove erroneous comment claiming that epoch is set to 2000, it was
not.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-ds1672.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
index b1ebca099b0d..b9860820cc90 100644
--- a/drivers/rtc/rtc-ds1672.c
+++ b/drivers/rtc/rtc-ds1672.c
@@ -21,12 +21,10 @@
 
 #define DS1672_REG_CONTROL_EOSC0x80
 
-static struct i2c_driver ds1672_driver;
-
 /*
  * In the routines that deal directly with the ds1672 hardware, we use
  * rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch
- * Epoch is initialized as 2000. Time is set to UTC.
+ * Time is set to UTC.
  */
 static int ds1672_get_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
@@ -164,8 +162,16 @@ static int ds1672_probe(struct i2c_client *client,
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
 
-   rtc = devm_rtc_device_register(&client->dev, ds1672_driver.driver.name,
- &ds1672_rtc_ops, THIS_MODULE);
+   rtc = devm_rtc_allocate_device(&client->dev);
+   if (IS_ERR(rtc))
+   return PTR_ERR(rtc);
+
+   rtc->ops = &ds1672_rtc_ops;
+   rtc->range_max = U32_MAX;
+
+   err = rtc_register_device(rtc);
+   if (err)
+   return err;
 
if (IS_ERR(rtc))
return PTR_ERR(rtc);
-- 
2.20.1

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

[Joel Fernandes]

On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote:
> 
> - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google 
> j...@joelfernandes.org wrote:
> 
> > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com wrote:
> >> 
> >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote:
> >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote:
> >> > 
> >> > [ . . . ]
> >> > 
> >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h
> >> >> > > b/include/asm-generic/vmlinux.lds.h
> >> >> > > index f8f6f04c4453..c2d919a1566e 100644
> >> >> > > --- a/include/asm-generic/vmlinux.lds.h
> >> >> > > +++ b/include/asm-generic/vmlinux.lds.h
> >> >> > > @@ -338,6 +338,10 @@
> >> >> > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer 
> >> >> > > array */ \
> >> >> > > __stop___tracepoints_ptrs = .;  
> >> >> > > \
> >> >> > > *(__tracepoints_strings)/* Tracepoints: strings */  
> >> >> > > \
> >> >> > > +   . = ALIGN(8);   
> >> >> > > \
> >> >> > > +   __start___srcu_struct = .;  
> >> >> > > \
> >> >> > > +   *(___srcu_struct_ptrs)  
> >> >> > > \
> >> >> > > +   __end___srcu_struct = .;
> >> >> > > \
> >> >> > > }   
> >> >> > > \
> >> >> > 
> >> >> > This vmlinux linker modification is not needed. I tested without it 
> >> >> > and srcu
> >> >> > torture works fine with rcutorture built as a module. Putting further 
> >> >> > prints
> >> >> > in kernel/module.c verified that the kernel is able to find the srcu 
> >> >> > structs
> >> >> > just fine. You could squash the below patch into this one or apply it 
> >> >> > on top
> >> >> > of the dev branch.
> >> >> 
> >> >> Good point, given that otherwise FORTRAN named common blocks would not
> >> >> work.
> >> >> 
> >> >> But isn't one advantage of leaving that stuff in the RO_DATA_SECTION()
> >> >> macro that it can be mapped read-only?  Or am I suffering from excessive
> >> >> optimism?
> >> > 
> >> > And to answer the other question, in the case where I am suffering from
> >> > excessive optimism, it should be a separate commit.  Please see below
> >> > for the updated original commit thus far.
> >> > 
> >> > And may I have your Tested-by?
> >> 
> >> Just to confirm: does the cleanup performed in the modules going
> >> notifier end up acting as a barrier first before freeing the memory ?
> >> If not, is it explicitly stated that a barrier must be issued before
> >> module unload ?
> >> 
> > 
> > You mean rcu_barrier? It is mentioned in the documentation that this is the
> > responsibility of the module writer to prevent delays for all modules.
> 
> It's a srcu barrier yes. Considering it would be a barrier specific to the
> srcu domain within that module, I don't see how it would cause delays for
> "all" modules if we implicitly issue the barrier on module unload. What
> am I missing ?

Yes you are right. I thought of this after I just sent my email. I think it
makes sense for srcu case to do and could avoid a class of bugs.

thanks!

> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

PRINTER BUG LINUX MINT 19 TARA

[Khz2020]

Please see attached. It was working fine prior to installing Canon linux 
drivers. CUPS disconnect maybe?


I am the only user. Local USB port. Just me. Canon D0550 image class. 
Has worked fine in the past.


Deleted printer and reinstalled but no go.

thanks

JTK

Page 1 ():
{'cups_connection_failure': False}
Page 2 ():
{'local_server_exporting_printers': False}
Page 3 ():
{'cups_dest': ,
 'cups_instance': None,
 'cups_queue': 'Canon-D500-Series',
 'cups_queue_listed': True}
Page 4 ():
{'cups_device_uri_scheme': 'cnusb',
 'cups_printer_dict': {'device-uri': 'cnusb:/dev/usb/lp0',
   'printer-info': 'Canon D500 Series',
   'printer-is-shared': True,
   'printer-location': 'hank-book-14',
   'printer-make-and-model': 'Canon D500 Series UFRII LT',
   'printer-state': 3,
   'printer-state-message': '',
   'printer-state-reasons': ['none'],
   'printer-type': 8525012,
   'printer-uri-supported': 
'ipp://localhost/printers/Canon-D500-Series'},
 'cups_printer_remote': False,
 'is_cups_class': False,
 'local_cups_queue_attributes': {'charset-configured': 'utf-8',
 'charset-supported': ['us-ascii', 'utf-8'],
 'color-supported': False,
 'compression-supported': ['none', 'gzip'],
 'copies-default': 1,
 'copies-supported': (1, ),
 'cups-version': '2.2.7',
 'device-uri': 'cnusb:/dev/usb/lp0',
 'document-format-default': 
'application/octet-stream',
 'document-format-supported': 
['application/octet-stream',
   
'application/pdf',
   
'application/postscript',
   
'application/vnd.adobe-reader-postscript',
   
'application/vnd.cups-command',
   
'application/vnd.cups-pdf',
   
'application/vnd.cups-pdf-banner',
   
'application/vnd.cups-postscript',
   
'application/vnd.cups-raster',
   
'application/vnd.cups-raw',
   
'application/x-cshell',
   
'application/x-csource',
   
'application/x-perl',
   
'application/x-shell',
   'image/gif',
   'image/jpeg',
   'image/png',
   
'image/pwg-raster',
   'image/tiff',
   'image/urf',
   'image/x-bitmap',
   
'image/x-photocd',
   
'image/x-portable-anymap',
   
'image/x-portable-bitmap',
   
'image/x-portable-graymap',
   
'image/x-portable-pixmap',
   
'image/x-sgi-rgb',
   
'image/x-sun-raster',
   
'image/x-xbitmap',
   
'image/x-xpixmap',
   
'image/x-xwindowdump',
   'text/css',
   'text/html',
   'text/plain'],
 'finishings-default': 3,
 'finishings-supported': [3, 51, 50],
 'fitplot-default': True,
 'generated-natural-language-supported': 

[PATCH 4/4] rtc: coh901331: convert to SPDX identifier

[Alexandre Belloni]

Use SPDX-License-Identifier instead of the custom license line.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-coh901331.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index bc9544329419..4ac850837153 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (C) 2007-2009 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
  * Real Time Clock interface for ST-Ericsson AB COH 901 331 RTC.
  * Author: Linus Walleij 
  * Based on rtc-pl031.c by Deepak Saxena 
-- 
2.20.1

[PATCH 1/4] rtc: coh901331: set range

[Alexandre Belloni]

The COH 901 331 is a 32bit seconds counter.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-coh901331.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 0b232c84f674..5b214db919d0 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -188,6 +188,13 @@ static int __init coh901331_probe(struct platform_device 
*pdev)
return ret;
}
 
+   rtap->rtc = devm_rtc_allocate_device(&pdev->dev);
+   if (IS_ERR(rtap->rtc))
+   return PTR_ERR(rtap->rtc);
+
+   rtap->rtc->ops = &coh901331_ops;
+   rtap->rtc->range_max = U32_MAX;
+
/* We enable/disable the clock only to assure it works */
ret = clk_prepare_enable(rtap->clk);
if (ret) {
@@ -197,12 +204,10 @@ static int __init coh901331_probe(struct platform_device 
*pdev)
clk_disable(rtap->clk);
 
platform_set_drvdata(pdev, rtap);
-   rtap->rtc = devm_rtc_device_register(&pdev->dev, "coh901331",
-   &coh901331_ops, THIS_MODULE);
-   if (IS_ERR(rtap->rtc)) {
-   ret = PTR_ERR(rtap->rtc);
+
+   ret = rtc_register_device(rtap->rtc);
+   if (ret)
goto out_no_rtc;
-   }
 
return 0;
 
-- 
2.20.1

[PATCH 2/4] rtc: coh901331: switch to rtc_time64_to_tm/rtc_tm_to_time64

[Alexandre Belloni]

Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-coh901331.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 5b214db919d0..1fd743fefe28 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -80,13 +80,14 @@ static int coh901331_read_time(struct device *dev, struct 
rtc_time *tm)
 
clk_enable(rtap->clk);
/* Check if the time is valid */
-   if (readl(rtap->virtbase + COH901331_VALID)) {
-   rtc_time_to_tm(readl(rtap->virtbase + COH901331_CUR_TIME), tm);
+   if (!readl(rtap->virtbase + COH901331_VALID)) {
clk_disable(rtap->clk);
-   return 0;
+   return -EINVAL;
}
+
+   rtc_time64_to_tm(readl(rtap->virtbase + COH901331_CUR_TIME), tm);
clk_disable(rtap->clk);
-   return -EINVAL;
+   return 0;
 }
 
 static int coh901331_set_mmss(struct device *dev, unsigned long secs)
@@ -105,7 +106,7 @@ static int coh901331_read_alarm(struct device *dev, struct 
rtc_wkalrm *alarm)
struct coh901331_port *rtap = dev_get_drvdata(dev);
 
clk_enable(rtap->clk);
-   rtc_time_to_tm(readl(rtap->virtbase + COH901331_ALARM), &alarm->time);
+   rtc_time64_to_tm(readl(rtap->virtbase + COH901331_ALARM), &alarm->time);
alarm->pending = readl(rtap->virtbase + COH901331_IRQ_EVENT) & 1U;
alarm->enabled = readl(rtap->virtbase + COH901331_IRQ_MASK) & 1U;
clk_disable(rtap->clk);
@@ -116,9 +117,8 @@ static int coh901331_read_alarm(struct device *dev, struct 
rtc_wkalrm *alarm)
 static int coh901331_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
struct coh901331_port *rtap = dev_get_drvdata(dev);
-   unsigned long time;
+   unsigned long time =  rtc_tm_to_time64(&alarm->time);
 
-   rtc_tm_to_time(&alarm->time, &time);
clk_enable(rtap->clk);
writel(time, rtap->virtbase + COH901331_ALARM);
writel(alarm->enabled, rtap->virtbase + COH901331_IRQ_MASK);
-- 
2.20.1

[PATCH 3/4] rtc: coh901331: use .set_time

[Alexandre Belloni]

Use .set_time instead of the deprecated .set_mmss.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-coh901331.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 1fd743fefe28..bc9544329419 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -90,12 +90,12 @@ static int coh901331_read_time(struct device *dev, struct 
rtc_time *tm)
return 0;
 }
 
-static int coh901331_set_mmss(struct device *dev, unsigned long secs)
+static int coh901331_set_time(struct device *dev, struct rtc_time *tm)
 {
struct coh901331_port *rtap = dev_get_drvdata(dev);
 
clk_enable(rtap->clk);
-   writel(secs, rtap->virtbase + COH901331_SET_TIME);
+   writel(rtc_tm_to_time64(tm), rtap->virtbase + COH901331_SET_TIME);
clk_disable(rtap->clk);
 
return 0;
@@ -143,7 +143,7 @@ static int coh901331_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
 
 static const struct rtc_class_ops coh901331_ops = {
.read_time = coh901331_read_time,
-   .set_mmss = coh901331_set_mmss,
+   .set_time = coh901331_set_time,
.read_alarm = coh901331_read_alarm,
.set_alarm = coh901331_set_alarm,
.alarm_irq_enable = coh901331_alarm_irq_enable,
-- 
2.20.1

[PATCH 2/4] rtc: stmp3xxx: switch to rtc_time64_to_tm/rtc_tm_to_time64

[Alexandre Belloni]

Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-stmp3xxx.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index a6a2963e89a5..dc0c6cc4849d 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -160,7 +160,7 @@ static int stmp3xxx_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
if (ret)
return ret;
 
-   rtc_time_to_tm(readl(rtc_data->io + STMP3XXX_RTC_SECONDS), rtc_tm);
+   rtc_time64_to_tm(readl(rtc_data->io + STMP3XXX_RTC_SECONDS), rtc_tm);
return 0;
 }
 
@@ -214,17 +214,15 @@ static int stmp3xxx_rtc_read_alarm(struct device *dev, 
struct rtc_wkalrm *alm)
 {
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
 
-   rtc_time_to_tm(readl(rtc_data->io + STMP3XXX_RTC_ALARM), &alm->time);
+   rtc_time64_to_tm(readl(rtc_data->io + STMP3XXX_RTC_ALARM), &alm->time);
return 0;
 }
 
 static int stmp3xxx_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 {
-   unsigned long t;
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
 
-   rtc_tm_to_time(&alm->time, &t);
-   writel(t, rtc_data->io + STMP3XXX_RTC_ALARM);
+   writel(rtc_tm_to_time64(&alm->time), rtc_data->io + STMP3XXX_RTC_ALARM);
 
stmp3xxx_alarm_irq_enable(dev, alm->enabled);
 
-- 
2.20.1

[PATCH 4/4] rtc: stmp3xxx: convert to SPDX identifier

[Alexandre Belloni]

Use SPDX-License-Identifier instead of a verbose license text.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-stmp3xxx.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index 143486f69485..ff6488be385f 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * Freescale STMP37XX/STMP378X Real Time Clock driver
  *
@@ -8,15 +9,6 @@
  * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
  * Copyright 2011 Wolfram Sang, Pengutronix e.K.
  */
-
-/*
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
 #include 
 #include 
 #include 
-- 
2.20.1

[PATCH 3/4] rtc: stmp3xxx: use .set_time

[Alexandre Belloni]

Use .set_time instead of the deprecated .set_mmss.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-stmp3xxx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index dc0c6cc4849d..143486f69485 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -164,11 +164,11 @@ static int stmp3xxx_rtc_gettime(struct device *dev, 
struct rtc_time *rtc_tm)
return 0;
 }
 
-static int stmp3xxx_rtc_set_mmss(struct device *dev, unsigned long t)
+static int stmp3xxx_rtc_settime(struct device *dev, struct rtc_time *rtc_tm)
 {
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
 
-   writel(t, rtc_data->io + STMP3XXX_RTC_SECONDS);
+   writel(rtc_tm_to_time64(rtc_tm), rtc_data->io + STMP3XXX_RTC_SECONDS);
return stmp3xxx_wait_time(rtc_data);
 }
 
@@ -233,7 +233,7 @@ static const struct rtc_class_ops stmp3xxx_rtc_ops = {
.alarm_irq_enable =
  stmp3xxx_alarm_irq_enable,
.read_time  = stmp3xxx_rtc_gettime,
-   .set_mmss   = stmp3xxx_rtc_set_mmss,
+   .set_time   = stmp3xxx_rtc_settime,
.read_alarm = stmp3xxx_rtc_read_alarm,
.set_alarm  = stmp3xxx_rtc_set_alarm,
 };
-- 
2.20.1

[PATCH 1/4] rtc: stmp3xxx: set range

[Alexandre Belloni]

>From the datasheet: "HW_RTC_SECONDS provides access to the 32-bit real-time
seconds counter."

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-stmp3xxx.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index b76318fd5bb0..a6a2963e89a5 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -361,8 +361,7 @@ static int stmp3xxx_rtc_probe(struct platform_device *pdev)
STMP3XXX_RTC_CTRL_ALARM_IRQ_EN,
rtc_data->io + STMP3XXX_RTC_CTRL + STMP_OFFSET_REG_CLR);
 
-   rtc_data->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
-   &stmp3xxx_rtc_ops, THIS_MODULE);
+   rtc_data->rtc = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc_data->rtc))
return PTR_ERR(rtc_data->rtc);
 
@@ -374,6 +373,13 @@ static int stmp3xxx_rtc_probe(struct platform_device *pdev)
return err;
}
 
+   rtc_data->rtc->ops = &stmp3xxx_rtc_ops;
+   rtc_data->rtc->range_max = U32_MAX;
+
+   err = rtc_register_device(rtc_data->rtc);
+   if (err)
+   return err;
+
stmp3xxx_wdt_register(pdev);
return 0;
 }
-- 
2.20.1

[PATCH 3/3] rtc: tegra: convert to SPDX identifier

[Alexandre Belloni]

Use SPDX-License-Identifier instead of a verbose license text.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-tegra.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index e93092aa6f7d..f0ce76865434 100644
--- a/drivers/rtc/rtc-tegra.c
+++ b/drivers/rtc/rtc-tegra.c
@@ -1,21 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * An RTC driver for the NVIDIA Tegra 200 series internal RTC.
  *
  * Copyright (c) 2010, NVIDIA Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
 #include 
-- 
2.20.1

[PATCH 1/3] rtc: tegra: set range

[Alexandre Belloni]

The Tegra 20 RTC is a 32bit seconds counter (with an unused millisecond
counter).

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-tegra.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index c6b0a99aa3a9..3f93a1f7abb5 100644
--- a/drivers/rtc/rtc-tegra.c
+++ b/drivers/rtc/rtc-tegra.c
@@ -306,6 +306,13 @@ static int __init tegra_rtc_probe(struct platform_device 
*pdev)
 
info->tegra_rtc_irq = ret;
 
+   info->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
+   if (IS_ERR(info->rtc_dev))
+   return PTR_ERR(info->rtc_dev);
+
+   info->rtc_dev->ops = &tegra_rtc_ops;
+   info->rtc_dev->range_max = U32_MAX;
+
info->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(info->clk))
return PTR_ERR(info->clk);
@@ -327,16 +334,6 @@ static int __init tegra_rtc_probe(struct platform_device 
*pdev)
 
device_init_wakeup(&pdev->dev, 1);
 
-   info->rtc_dev = devm_rtc_device_register(&pdev->dev,
-   dev_name(&pdev->dev), &tegra_rtc_ops,
-   THIS_MODULE);
-   if (IS_ERR(info->rtc_dev)) {
-   ret = PTR_ERR(info->rtc_dev);
-   dev_err(&pdev->dev, "Unable to register device (err=%d).\n",
-   ret);
-   goto disable_clk;
-   }
-
ret = devm_request_irq(&pdev->dev, info->tegra_rtc_irq,
tegra_rtc_irq_handler, IRQF_TRIGGER_HIGH,
dev_name(&pdev->dev), &pdev->dev);
@@ -347,6 +344,13 @@ static int __init tegra_rtc_probe(struct platform_device 
*pdev)
goto disable_clk;
}
 
+   ret = rtc_register_device(info->rtc_dev);
+   if (ret) {
+   dev_err(&pdev->dev, "Unable to register device (err=%d).\n",
+   ret);
+   goto disable_clk;
+   }
+
dev_notice(&pdev->dev, "Tegra internal Real Time Clock\n");
 
return 0;
-- 
2.20.1

[PATCH 2/3] rtc: tegra: switch to rtc_time64_to_tm/rtc_tm_to_time64

[Alexandre Belloni]

Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-tegra.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index 3f93a1f7abb5..e93092aa6f7d 100644
--- a/drivers/rtc/rtc-tegra.c
+++ b/drivers/rtc/rtc-tegra.c
@@ -123,7 +123,7 @@ static int tegra_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
 
spin_unlock_irqrestore(&info->tegra_rtc_lock, sl_irq_flags);
 
-   rtc_time_to_tm(sec, tm);
+   rtc_time64_to_tm(sec, tm);
 
dev_vdbg(dev, "time read as %lu. %ptR\n", sec, tm);
 
@@ -137,7 +137,7 @@ static int tegra_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
int ret;
 
/* convert tm to seconds. */
-   rtc_tm_to_time(tm, &sec);
+   sec = rtc_tm_to_time64(tm);
 
dev_vdbg(dev, "time set to %lu. %ptR\n", sec, tm);
 
@@ -166,7 +166,7 @@ static int tegra_rtc_read_alarm(struct device *dev, struct 
rtc_wkalrm *alarm)
} else {
/* alarm is enabled. */
alarm->enabled = 1;
-   rtc_time_to_tm(sec, &alarm->time);
+   rtc_time64_to_tm(sec, &alarm->time);
}
 
tmp = readl(info->rtc_base + TEGRA_RTC_REG_INTR_STATUS);
@@ -204,7 +204,7 @@ static int tegra_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alarm)
unsigned long sec;
 
if (alarm->enabled)
-   rtc_tm_to_time(&alarm->time, &sec);
+   sec = rtc_tm_to_time64(&alarm->time);
else
sec = 0;
 
-- 
2.20.1

linux-next: manual merge of the kspp-gustavo tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kspp-gustavo tree got a conflict in:

  arch/x86/include/asm/syscall.h

between commits:

  b35f549df1d7 ("syscalls: Remove start and number from syscall_get_arguments() 
args")
  32d92586629a ("syscalls: Remove start and number from syscall_set_arguments() 
args")

from Linus' tree and commit:

  1f7ae812f87e ("x86/syscalls: Mark expected switch fall-throughs")

from the kspp-gustavo tree.

I fixed it up (I just used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpH9CD8qHsVI.pgp
Description: OpenPGP digital signature

[PATCH] soc: brcmstb: Fix error path for unsupported CPUs

[Florian Fainelli]

In case setup_hifcpubiuctrl_regs() returns an error, because of e.g:
an unsupported CPU type, just catch that error and return instead of
blindly continuing with the initialization. This fixes a NULL pointer
de-reference with the code continuing without having a proper array of
registers to use.

Fixes: 22f7a9116eba ("soc: brcmstb: Correct CPU_CREDIT_REG offset for 
Brahma-B53 CPUs")
Signed-off-by: Florian Fainelli 
---
 drivers/soc/bcm/brcmstb/biuctrl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c 
b/drivers/soc/bcm/brcmstb/biuctrl.c
index 6d89ebf13b8a..c16273b31b94 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -246,7 +246,9 @@ static int __init brcmstb_biuctrl_init(void)
if (!np)
return 0;
 
-   setup_hifcpubiuctrl_regs(np);
+   ret = setup_hifcpubiuctrl_regs(np);
+   if (ret)
+   return ret;
 
ret = mcp_write_pairing_set();
if (ret) {
-- 
2.17.1

[PATCH] rtc: test: use .set_time

[Alexandre Belloni]

Use .set_time instead of the deprecated .set_mmss64.

Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/rtc-test.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-test.c b/drivers/rtc/rtc-test.c
index f1a6dc5ad013..b298e9902f45 100644
--- a/drivers/rtc/rtc-test.c
+++ b/drivers/rtc/rtc-test.c
@@ -70,11 +70,11 @@ static int test_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
return 0;
 }
 
-static int test_rtc_set_mmss64(struct device *dev, time64_t secs)
+static int test_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
struct rtc_test_data *rtd = dev_get_drvdata(dev);
 
-   rtd->offset = secs - ktime_get_real_seconds();
+   rtd->offset = rtc_tm_to_time64(tm) - ktime_get_real_seconds();
 
return 0;
 }
@@ -94,15 +94,15 @@ static int test_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enable)
 
 static const struct rtc_class_ops test_rtc_ops_noalm = {
.read_time = test_rtc_read_time,
-   .set_mmss64 = test_rtc_set_mmss64,
+   .set_time = test_rtc_set_time,
.alarm_irq_enable = test_rtc_alarm_irq_enable,
 };
 
 static const struct rtc_class_ops test_rtc_ops = {
.read_time = test_rtc_read_time,
+   .set_time = test_rtc_set_time,
.read_alarm = test_rtc_read_alarm,
.set_alarm = test_rtc_set_alarm,
-   .set_mmss64 = test_rtc_set_mmss64,
.alarm_irq_enable = test_rtc_alarm_irq_enable,
 };
 
-- 
2.20.1