Re: [PATCH-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Wolfram Sang]

> And the i2c binding documentation, which says,
> for platforms using REGS_PXA2XX, they need to provide additional node
> "mrvl,pxa-i2c". Which is confusing :)

Yes, the description of the compatible entry is pretty bogus. Could you
fix that?



signature.asc
Description: Digital signature

Re: [PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 08:25:08 schrieb Doug Anderson:
> On Fri, Oct 23, 2015 at 4:25 AM, Caesar Wang  wrote:
> > Add the "init" anf "sleep" pinctrl as the OTP gpio state.
> > We need the OTP pin is gpio state before resetting the TSADC controller,
> > since the tshut polarity will generate a high signal.
> > 
> > "init" pinctrl property is defined by Doug's Patch[0].
> > 
> > Patch[0]:
> > https://patchwork.kernel.org/patch/7454311/
> > 
> > Signed-off-by: Caesar Wang 
> > Reviewed-by: Douglas Anderson 
> > ---
> > 
> > Changes in v4: None
> > 
> > Changes in v3:
> >   - Add the "sleep" pinctrl as the gpio state in PATCH[3/3]
> > 
> > Changes in v2:
> >   - Add some commits for more obvious in PATCH[2/2]
> > 
> > Changes in v1:
> >   - As the Doug comments, drop the thermal driver patchs since
> >   
> > we can with pinctrl changing to work.
> >   
> >   - As the Doug's patch to add the 'init' property.
> >  
> >  arch/arm/boot/dts/rk3288.dtsi | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> I realized that the subject of this patch should probably contain the
> word rk3288, but I presume Heiko would rather add that himself than
> for you to spin this again.  ;)

yep :-) ... no need to respin for such an easy change.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Wolfram Sang]

On Mon, Aug 24, 2015 at 11:29:36AM +0530, Vaibhav Hiremath wrote:
> TWSI_ILCR & TWSI_IWCR registers are used to adjust clock rate
> of standard & fast mode in pxa910/988; so this patch adds these two new
> entries to "struct pxa_reg_layout" and "struct pxa_i2c".
> 
> As discussed in the previous patch-series, the idea here is to add standard
> DT properties for ilcr and iwcr configuration fields.
> In case of Master ilcr is used for low/high time and in case of slave mode
> of operation iwcr is used for setup/hold time.
> 
> Signed-off-by: Jett.Zhou 
> Signed-off-by: Yi Zhang 
> Signed-off-by: Vaibhav Hiremath 
> Tested-by: Robert Jarzmik 

Fixed this checkpatch warning:

CHECK: Please don't use multiple blank lines
#82: FILE: drivers/i2c/busses/i2c-pxa.c:157:
+
+

and applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer

[Wolfram Sang]

> >>Enable i2c module/unit before transmission and disable when it
> >>finishes.
> 
> >Can't you use Runtime PM for that?
> >
> 
> I haven't tried it though, I can give a try and check.

It should work. Other I2C drivers are doing exactly that.



signature.asc
Description: Digital signature

Re: [PATCH-v5 RESEND 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa

[Wolfram Sang]

On Mon, Aug 24, 2015 at 11:29:37AM +0530, Vaibhav Hiremath wrote:
> With addition of PXA910 family of devices, the TWSI module supports
> new feature which allows us to adjust SCLK. i2c-pxa driver takes input
> configuration in nsec and converts it to respective bit-fields,
> 
>  - i2c-sclk-low-time-ns : SCLK low time (tlow)
>This property is used along with mode selection.
>  - i2c-sclk-high-time-ns : SCLK high time (thigh)
>  - i2c-start-hold-time-ns : Used in case of high speed mode for start bit
>hold/setup wait counter.
>  - i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
>hold/setup wait counter.
>  - i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
>standard and fast mode.
> 
> Signed-off-by: Vaibhav Hiremath 

Ooookay, after checking some datasheets, I finally stumbled over the
fact that this driver is not using "clock-frequency" to determine the
bus speed. However, this is the standard way of defining that in DT, so
this driver should adhere to that, too, and not invent something new.
Previously, I was under the impression that the above parameters were
needed for fine-tuning and couldn't fully grasp why. But this is for
defining the bus speed which is a no-go.

It looks to me that older PXA only have a bit to select between 100 and
400kHz while this newer one can have arbitrary frequencies. Correct?

So, what the driver should do:

- Keep support for the old "mrvl,i2c-fast-mode" binding which should be
  marked as deprecated

- get the value of the standard property "clock-frequency"

- for old PXAs, complain if not 100 or 400kHz, otherwise set the bit
  accordingly

- for new PXAs, calculate the ilcr and iwcr values from
  "clock-frequency"

Makes sense?

Regards,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCHv2 2/2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs

[Jonathan Cameron]

On 13/10/15 10:38, Paul Cercueil wrote:
> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
> ADC/DAC devices.
> 
> Signed-off-by: Paul Cercueil 
A few minor questions inline...
> ---
>  drivers/iio/dac/Kconfig   |  27 
>  drivers/iio/dac/Makefile  |   3 +
>  drivers/iio/dac/ad5592r-base.c| 289 
> ++
>  drivers/iio/dac/ad5592r-base.h|  56 +++
>  drivers/iio/dac/ad5592r.c | 126 +++
>  drivers/iio/dac/ad5593r.c | 121 ++
>  include/dt-bindings/iio/adi,ad5592r.h |  13 ++
>  7 files changed, 635 insertions(+)
>  create mode 100644 drivers/iio/dac/ad5592r-base.c
>  create mode 100644 drivers/iio/dac/ad5592r-base.h
>  create mode 100644 drivers/iio/dac/ad5592r.c
>  create mode 100644 drivers/iio/dac/ad5593r.c
>  create mode 100644 include/dt-bindings/iio/adi,ad5592r.h
> 
>  v2: Introduced changes suggested by upstream feedback
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..be7bb04 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -72,6 +72,33 @@ config AD5449
> To compile this driver as a module, choose M here: the
> module will be called ad5449.
>  
> +config AD5592R_BASE
> + tristate
> +
> +config AD5592R
> + tristate "Analog Devices AD5592R ADC/DAC driver"
> + depends on SPI_MASTER
> + depends on OF
> + select AD5592R_BASE
> + help
> +   Say yes here to build support for Analog Devices AD5592R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5592r.
> +
> +config AD5593R
> + tristate "Analog Devices AD5593R ADC/DAC driver"
> + depends on I2C
> + depends on OF
> + select AD5592R_BASE
> + help
> +   Say yes here to build support for Analog Devices AD5593R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5593r.
> +
>  config AD5504
>   tristate "Analog Devices AD5504/AD5501 DAC SPI driver"
>   depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..ae00b67 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -11,6 +11,9 @@ obj-$(CONFIG_AD5064) += ad5064.o
>  obj-$(CONFIG_AD5504) += ad5504.o
>  obj-$(CONFIG_AD5446) += ad5446.o
>  obj-$(CONFIG_AD5449) += ad5449.o
> +obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o
> +obj-$(CONFIG_AD5592R) += ad5592r.o
> +obj-$(CONFIG_AD5593R) += ad5593r.o
>  obj-$(CONFIG_AD5755) += ad5755.o
>  obj-$(CONFIG_AD5764) += ad5764.o
>  obj-$(CONFIG_AD5791) += ad5791.o
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
> new file mode 100644
> index 000..c1132fd
> --- /dev/null
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -0,0 +1,289 @@
> +/*
> + * AD5592R Digital <-> Analog converters driver
> + *
> + * Copyright 2014 Analog Devices Inc.
> + * Author: Paul Cercueil 
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +/*
> + * TODO:
> + * - Add support for using channels as GPIOs
> + */
> +
> +#include "ad5592r-base.h"
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int ad5592r_set_channel_modes(struct ad5592r_state *st)
> +{
> + const struct ad5592r_rw_ops *ops = st->ops;
> + int ret;
> + unsigned i;
> + struct iio_dev *iio_dev = iio_priv_to_dev(st);
> + u8 pulldown = 0, open_drain = 0, tristate = 0,
> +dac = 0, adc = 0, gpio_in = 0, gpio_out = 0;
> + u16 read_back;
> +
> + for (i = 0; i < st->num_channels; i++) {
> + switch (st->channel_modes[i]) {
> + case CH_MODE_DAC:
> + dac |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_ADC:
> + adc |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OUT:
> + gpio_out |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_GPIO_IN:
> + gpio_in |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OPEN_DRAIN:
> + open_drain |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_TRISTATE:
> + tristate |= BIT(i);
> + break;
> +
> + default:
> + pulldown |= BIT(i);
> + break;
> + }
> + }
> +
> + mutex_lock(_dev->mlock);
> +
> + /* Configure pins that we use */
> + ret = ops->reg_write(st, AD5592R_REG_DAC_EN, dac);
> + if (ret)
> + goto err_unlock;
> +
> + ret = ops->reg_write(st, AD5592R_REG_ADC_EN, adc);
> + if 

Re: [PATCH v3 6/8] scsi: ufs: make the UFS variant a platform device

[ygardi]

> On Sun, Aug 30, 2015 at 3:43 AM,   wrote:
>>> On Sun, Aug 23, 2015 at 8:09 AM, Yaniv Gardi 
>>> wrote:
 This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
 a platform device.
 In order to do so a few additional changes are required:
 1. The ufshcd-pltfrm is no longer serves as a platform device.
Now it only serves as a group of platform APIs such as PM APIs
(runtime suspend/resume, system suspend/resume etc), parsers of
clocks, regulators and pm_levels from DT.
 2. What used to be the old platform "probe" is now "only"
a pltfrm_init() routine, that does exactly the same, but only
being called by the new probe function of the UFS variant.

 Signed-off-by: Yaniv Gardi 

 ---
  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  2 +-
  drivers/scsi/ufs/ufs-qcom.c| 78
 +-
  drivers/scsi/ufs/ufshcd-pltfrm.c   | 92
 ++
  drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 ++
  drivers/scsi/ufs/ufshcd.c  | 10 +++
  drivers/scsi/ufs/ufshcd.h  |  1 +
  6 files changed, 152 insertions(+), 72 deletions(-)
  create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h

 diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
 b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
 index 5357919..b39e765 100644
 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
 +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
 @@ -4,7 +4,7 @@ UFSHC nodes are defined to describe on-chip UFS host
 controllers.
  Each UFS controller instance should have its own node.

  Required properties:
 -- compatible: compatible list, contains "jedec,ufs-1.1"
 +- compatible: compatible list, contains "jedec,ufs-1.1" or
 "qcom,ufshc"
>>>
>>> Replying again as I inadvertently dropped everyone.
>>>
>>> This should also have a more specific compatible string with the SOC
>>> name/number in it. It may be "the same in all SOCs", but there is
>>> always the possibility for bugs/limitations to be found that are
>>> specific to an SOC even if all RTL versions are identical (e.g.
>>> different max clock speeds). It is about making the dtb future proof,
>>> not about what exactly you need today. You can keep qcom,ufshc for
>>> driver matching if you want.
>>
>> I see your point.
>> I just would like to make sure, syntactically speaking, if what you mean
>> should look like:
>>
>> compatible: compatible list, contains "jedec,ufs-1.1" or
>> "qcom,ufshc" for msm8994, msm8996 SOCs.
>
> No, you need actual compatible strings:
>
> contains one of:
>   "jedec,ufs-1.1"
>   "qcom,msm8994-ufshc" or "qcom,msm8996-ufshc" followed by "qcom,ufshc"
>
> Really, we should probably never had allowed "jedec,ufs-1.1" by itself.
>
  - interrupts: 
  - reg   : 
>>>
>>> What about phy properties? No Unipro PHY block that requires setup?
>>>
>>
>> yes, i will add another documentation file for it.
>
> And you need the "phy" property here with the phandle to the phy node.
>

The "phy" properties will be updated in V8 i'm about to uploade

> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


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

Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

[Jonathan Cameron]

On 22/10/15 19:22, Rob Herring wrote:
> On Thu, Oct 15, 2015 at 8:10 AM, Martin Kepplinger  wrote:
>> This change is important in order for everyone to be easily able to use the
>> driver for one of the supported accelerometer chips!
>>
>> Until now, the driver blindly assumed that the INT1 interrupt line is wired
>> on a user's board. But these devices have 2 interrupt lines and can route
>> their interrupt sources to one of them. Now, if "INT2" is found and matches
>> i2c_client->irq, INT2 will be used.
>>
>> The chip's default actually is INT2, which is why probably many boards will
>> have it wired and can make use of this.
>>
>> Of course, this also falls back to assuming INT1, so for existing users
>> nothing will break. The new functionality is described in the bindings doc.
>>
>> Signed-off-by: Martin Kepplinger 
>> ---
>> changelog:
>> v4: use irq that matches client->irq, backwards compatible
>> v3: correctly assign irq if both pins are described in DT
>> v2: don't warn but normally handle if both pins are described in dts
>> thanks Mark Rutland
>> v1: initial post
>>
>>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
> 
> For the binding:
> 
> Rob Herring 
I've guessed that was an Acked-by :)

Anyhow, applied to the togreg branch of iio.git.

I'm afraid after my hiatus for a couple of weeks (day job work crisis now
over) this has missed going in for the current cycle.

IIO merge closes more than a week before the merge window opens and Linus
just announced probably release a week today.

Sorry about that, will be queued up for an early entry into linux next
after the merge window closes.

Jonathan
> 
>>  drivers/iio/accel/mma8452.c | 21 
>> +++--
>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
>> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> index e3c3746..3c10e85 100644
>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> @@ -7,13 +7,18 @@ Required properties:
>>  * "fsl,mma8453"
>>  * "fsl,mma8652"
>>  * "fsl,mma8653"
>> +
>>- reg: the I2C address of the chip
>>
>>  Optional properties:
>>
>>- interrupt-parent: should be the phandle for the interrupt controller
>> +
>>- interrupts: interrupt mapping for GPIO IRQ
>>
>> +  - interrupt-names: should contain "INT1" and/or "INT2", the 
>> accelerometer's
>> +interrupt line in use.
>> +
>>  Example:
>>
>> mma8453fc@1d {
>> @@ -21,4 +26,5 @@ Example:
>> reg = <0x1d>;
>> interrupt-parent = <>;
>> interrupts = <5 0>;
>> +   interrupt-names = "INT2";
>> };
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 1eccc2d..116a6e4 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define MMA8452_STATUS 0x00
>>  #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
>> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
>>MMA8452_INT_FF_MT;
>> int enabled_interrupts = MMA8452_INT_TRANS |
>>  MMA8452_INT_FF_MT;
>> +   int irq2;
>>
>> -   /* Assume wired to INT1 pin */
>> -   ret = i2c_smbus_write_byte_data(client,
>> -   MMA8452_CTRL_REG5,
>> -   supported_interrupts);
>> -   if (ret < 0)
>> -   return ret;
>> +   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
>> +
>> +   if (irq2 == client->irq) {
>> +   dev_dbg(>dev, "using interrupt line INT2\n");
>> +   } else {
>> +   ret = i2c_smbus_write_byte_data(client,
>> +   MMA8452_CTRL_REG5,
>> +   
>> supported_interrupts);
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   dev_dbg(>dev, "using interrupt line INT1\n");
>> +   }
>>
>> ret = i2c_smbus_write_byte_data(client,
>> MMA8452_CTRL_REG4,
>> --
>> 2.1.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a 

Re: [PATCH v3 6/8] scsi: ufs: make the UFS variant a platform device

[ygardi]

> On Sun, Aug 23, 2015 at 8:09 AM, Yaniv Gardi 
> wrote:
>> This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
>> a platform device.
>> In order to do so a few additional changes are required:
>> 1. The ufshcd-pltfrm is no longer serves as a platform device.
>>Now it only serves as a group of platform APIs such as PM APIs
>>(runtime suspend/resume, system suspend/resume etc), parsers of
>>clocks, regulators and pm_levels from DT.
>> 2. What used to be the old platform "probe" is now "only"
>>a pltfrm_init() routine, that does exactly the same, but only
>>being called by the new probe function of the UFS variant.
>>
>> Signed-off-by: Yaniv Gardi 
>>
>> ---
>>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  2 +-
>>  drivers/scsi/ufs/ufs-qcom.c| 78
>> +-
>>  drivers/scsi/ufs/ufshcd-pltfrm.c   | 92
>> ++
>>  drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 ++
>>  drivers/scsi/ufs/ufshcd.c  | 10 +++
>>  drivers/scsi/ufs/ufshcd.h  |  1 +
>>  6 files changed, 152 insertions(+), 72 deletions(-)
>>  create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index 5357919..b39e765 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -4,7 +4,7 @@ UFSHC nodes are defined to describe on-chip UFS host
>> controllers.
>>  Each UFS controller instance should have its own node.
>>
>>  Required properties:
>> -- compatible: compatible list, contains "jedec,ufs-1.1"
>> +- compatible: compatible list, contains "jedec,ufs-1.1" or
>> "qcom,ufshc"
>
> Replying again as I inadvertently dropped everyone.
>
> This should also have a more specific compatible string with the SOC
> name/number in it. It may be "the same in all SOCs", but there is
> always the possibility for bugs/limitations to be found that are
> specific to an SOC even if all RTL versions are identical (e.g.
> different max clock speeds). It is about making the dtb future proof,
> not about what exactly you need today. You can keep qcom,ufshc for
> driver matching if you want.
>
>>  - interrupts: 
>>  - reg   : 
>
> What about phy properties? No Unipro PHY block that requires setup?

phy properties will be updated in V8 that shortly will be uploaded.

>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


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

Re: [PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix

[Jonathan Cameron]

On 14/10/15 13:54, Javier Martinez Canillas wrote:
> The Microchip Analog to Digital Converter (ADC) Device Tree binding
> documents compatible strings with no vendor prefix. Since it should
> compatible strings with also a vendor, add these to the binding doc
> and mark the old ones as deprecated.
> 
> The driver says that the device is from Microchip Technology which
> is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
> so use the documented prefix.
> 
> Signed-off-by: Javier Martinez Canillas 
Applied to the togreg branch of iio.git - initially pushed out as testing.
Thanks,
> ---
> 
>  .../devicetree/bindings/iio/adc/mcp320x.txt| 30 
> +++---
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt 
> b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> index 2a1f3af30155..bcd3ac8e6e0c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> @@ -10,16 +10,28 @@ must be specified.
>  Required properties:
>   - compatible:   Must be one of the following, depending on the
>   model:
> - "mcp3001"
> - "mcp3002"
> - "mcp3004"
> - "mcp3008"
> - "mcp3201"
> - "mcp3202"
> - "mcp3204"
> - "mcp3208"
> - "mcp3301"
> + "mcp3001" (DEPRECATED)
> + "mcp3002" (DEPRECATED)
> + "mcp3004" (DEPRECATED)
> + "mcp3008" (DEPRECATED)
> + "mcp3201" (DEPRECATED)
> + "mcp3202" (DEPRECATED)
> + "mcp3204" (DEPRECATED)
> + "mcp3208" (DEPRECATED)
> + "mcp3301" (DEPRECATED)
>  
> + "microchip,mcp3001"
> + "microchip,mcp3002"
> + "microchip,mcp3004"
> + "microchip,mcp3008"
> + "microchip,mcp3201"
> + "microchip,mcp3202"
> + "microchip,mcp3204"
> + "microchip,mcp3208"
> + "microchip,mcp3301"
> +
> + NOTE: The use of the compatibles with no vendor prefix
> + is deprecated and only listed because old DT use them.
>  
>  Examples:
>  spi_controller {
> 

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

Re: [PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix

[Jonathan Cameron]

On 14/10/15 16:27, Michael Welling wrote:
> On Wed, Oct 14, 2015 at 02:54:38PM +0200, Javier Martinez Canillas wrote:
>> The Microchip Analog to Digital Converter (ADC) Device Tree binding
>> documents compatible strings with no vendor prefix. Since it should
>> compatible strings with also a vendor, add these to the binding doc
>> and mark the old ones as deprecated.
>>
>> The driver says that the device is from Microchip Technology which
>> is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
>> so use the documented prefix.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  .../devicetree/bindings/iio/adc/mcp320x.txt| 30 
>> +++---
>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt 
>> b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> index 2a1f3af30155..bcd3ac8e6e0c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> @@ -10,16 +10,28 @@ must be specified.
>>  Required properties:
>>  - compatible:   Must be one of the following, depending on the
>>  model:
>> -"mcp3001"
>> -"mcp3002"
>> -"mcp3004"
>> -"mcp3008"
>> -"mcp3201"
>> -"mcp3202"
>> -"mcp3204"
>> -"mcp3208"
>> -"mcp3301"
>> +"mcp3001" (DEPRECATED)
>> +"mcp3002" (DEPRECATED)
>> +"mcp3004" (DEPRECATED)
>> +"mcp3008" (DEPRECATED)
>> +"mcp3201" (DEPRECATED)
>> +"mcp3202" (DEPRECATED)
>> +"mcp3204" (DEPRECATED)
>> +"mcp3208" (DEPRECATED)
>> +"mcp3301" (DEPRECATED)
>>  
>> +"microchip,mcp3001"
>> +"microchip,mcp3002"
>> +"microchip,mcp3004"
>> +"microchip,mcp3008"
>> +"microchip,mcp3201"
>> +"microchip,mcp3202"
>> +"microchip,mcp3204"
>> +"microchip,mcp3208"
>> +"microchip,mcp3301"
>> +
>> +NOTE: The use of the compatibles with no vendor prefix
>> +is deprecated and only listed because old DT use them.
>>
> 
> Acked-by: Michael Welling 
Small point, Michael. Please add such acks below the the Author sign off.
Otherwise sometimes I miss them!  Added it now for this one.
>   
>>  Examples:
>>  spi_controller {
>> -- 
>> 2.4.3
>>

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

[PATCH v8 6/8] scsi: ufs: make the UFS variant a platform device

[Yaniv Gardi]

This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
a platform device.
In order to do so a few additional changes are required:
1. The ufshcd-pltfrm is no longer serves as a platform device.
   Now it only serves as a group of platform APIs such as PM APIs
   (runtime suspend/resume, system suspend/resume etc), parsers of
   clocks, regulators and pm_levels from DT.
2. What used to be the old platform "probe" is now "only"
   a pltfrm_init() routine, that does exactly the same, but only
   being called by the new probe function of the UFS variant.

Signed-off-by: Yaniv Gardi 

---
 Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 58 +
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  | 11 ++-
 drivers/scsi/ufs/ufs-qcom.c| 62 +-
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 98 ++
 drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 +
 drivers/scsi/ufs/ufshcd.c  | 10 +++
 drivers/scsi/ufs/ufshcd.h  |  1 +
 7 files changed, 207 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt
 create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt 
b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
new file mode 100644
index 000..070baf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
@@ -0,0 +1,58 @@
+* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY
+
+UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
+Each UFS PHY node should have its own node.
+
+To bind UFS PHY with UFS host controller, the controller node should
+contain a phandle reference to UFS PHY node.
+
+Required properties:
+- compatible: compatible list, contains "qcom,ufs-phy-qmp-20nm"
+ or "qcom,ufs-phy-qmp-14nm" according to the relevant phy 
in use.
+- reg   : should contain PHY register address space (mandatory),
+- reg-names : indicates various resources passed to driver (via reg 
proptery) by name.
+  Required "reg-names" is "phy_mem".
+- #phy-cells: This property shall be set to 0
+- vdda-phy-supply   : phandle to main PHY supply for analog domain
+- vdda-pll-supply   : phandle to PHY PLL and Power-Gen block power supply
+- clocks   : List of phandle and clock specifier pairs
+- clock-names   : List of clock input name strings sorted in the same
+ order as the clocks property. "ref_clk_src", "ref_clk",
+ "tx_iface_clk" & "rx_iface_clk" are mandatory but
+ "ref_clk_parent" is optional
+
+Optional properties:
+- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply
+- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply
+- vddp-ref-clk-supply   : phandle to UFS device ref_clk pad power supply
+- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this 
supply
+- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on
+
+Example:
+
+   ufsphy1: ufsphy@0xfc597000 {
+   compatible = "qcom,ufs-phy-qmp-20nm";
+   reg = <0xfc597000 0x800>;
+   reg-names = "phy_mem";
+   #phy-cells = <0>;
+   vdda-phy-supply = <_l4>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-max-microamp = <5>;
+   vdda-pll-max-microamp = <1000>;
+   clock-names = "ref_clk_src",
+   "ref_clk_parent",
+   "ref_clk",
+   "tx_iface_clk",
+   "rx_iface_clk";
+   clocks = <_rpm clk_ln_bb_clk>,
+   <_gcc clk_pcie_1_phy_ldo >,
+   <_gcc clk_ufs_phy_ldo>,
+   <_gcc clk_gcc_ufs_tx_cfg_clk>,
+   <_gcc clk_gcc_ufs_rx_cfg_clk>;
+   };
+
+   ufshc@0xfc598000 {
+   ...
+   phys = <>;
+   phy-names = "ufsphy";
+   };
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 5357919..03c0e98 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host 
controllers.
 Each UFS controller instance should have its own node.
 
 Required properties:
-- compatible: compatible list, contains "jedec,ufs-1.1"
+- compatible   : must contain "jedec,ufs-1.1", may also list one or 
more
+ of the following:
+ "qcom,msm8994-ufshc"
+ "qcom,msm8996-ufshc"
+  

Re: [PATCH v3 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Jonathan Cameron]

On 16/10/15 13:53, H. Nikolaus Schaller wrote:
> This driver code was found as:
> 
> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> 
> Fixed various compilation issues and test this driver on omap5 evm.
> 
> Signed-off-by: Pradeep Goudagunta 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 
> Acked-by: Laxman Dewangan 
> Reviewed-by: Jonathan Cameron 
> Acked-by: Lee Jones 
Applied to the togreg branch of iio.git - initially pushed out as testing.
Unfortunately the timing is such that it's not going to make the upcoming
merge window so will be an early entry to linux-next after the merge window
closes.

Jonathan
> ---
>  drivers/iio/adc/Kconfig|   8 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/palmas_gpadc.c | 817 
> +
>  include/linux/mfd/palmas.h |  75 ++--
>  4 files changed, 877 insertions(+), 24 deletions(-)
>  create mode 100644 drivers/iio/adc/palmas_gpadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 50c103d..5100e56 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -264,6 +264,14 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config PALMAS_GPADC
> + tristate "TI Palmas General Purpose ADC"
> + depends on MFD_PALMAS
> + help
> +   Palmas series pmic chip by Texas Instruments (twl6035/6037)
> +   is used in smartphones and tablets and supports a 16 channel
> +   general purpose ADC.
> +
>  config QCOM_SPMI_IADC
>   tristate "Qualcomm SPMI PMIC current ADC"
>   depends on SPMI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..716f112 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
>  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> new file mode 100644
> index 000..71763c5
> --- /dev/null
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -0,0 +1,817 @@
> +/*
> + * palmas-adc.c -- TI PALMAS GPADC.
> + *
> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> + *
> + * Author: Pradeep Goudagunta 
> + *
> + * 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 version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MOD_NAME "palmas-gpadc"
> +#define PALMAS_ADC_CONVERSION_TIMEOUT(msecs_to_jiffies(5000))
> +#define PALMAS_TO_BE_CALCULATED 0
> +#define PALMAS_GPADC_TRIMINVALID -1
> +
> +struct palmas_gpadc_info {
> +/* calibration codes and regs */
> + int x1; /* lower ideal code */
> + int x2; /* higher ideal code */
> + int v1; /* expected lower volt reading */
> + int v2; /* expected higher volt reading */
> + u8 trim1_reg;   /* register number for lower trim */
> + u8 trim2_reg;   /* register number for upper trim */
> + int gain;   /* calculated from above (after reading trim regs) */
> + int offset; /* calculated from above (after reading trim regs) */
> + int gain_error; /* calculated from above (after reading trim regs) */
> + bool is_uncalibrated;   /* if channel has calibration data */
> +};
> +
> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
> _is_uncalibrated) \
> + [PALMAS_ADC_CH_##_chan] = { \
> + .x1 = _x1, \
> + .x2 = _x2, \
> + .v1 = _v1, \
> + .v2 = _v2, \
> + .gain = PALMAS_TO_BE_CALCULATED, \
> + .offset = PALMAS_TO_BE_CALCULATED, \
> + .gain_error = PALMAS_TO_BE_CALCULATED, \
> + .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
> + .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
> + .is_uncalibrated = _is_uncalibrated \
> + }
> +
> +static struct palmas_gpadc_info palmas_gpadc_info[] = {
> + PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
> + PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
> + 

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

[Jonathan Cameron]

On 16/10/15 13:53, H. Nikolaus Schaller wrote:
> From: Marek Belisko 
> 
> Code was found at:
> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
> 
> Signed-off-by: Laxman Dewangan 
> Signed-off-by: Marek Belisko  [Fixed minor typos + add 
> channels list to documentation]
I am happy with your responses to Lars and that kind of covers what Mark raised 
as well.

One typo correction applied.

Applied to the togreg branch of iio.git

Thanks,

Jonathan
> ---
>  .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 48 
>  drivers/iio/adc/palmas_gpadc.c | 52 
> +++---
>  2 files changed, 95 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> new file mode 100644
> index 000..a6de996
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> @@ -0,0 +1,48 @@
> +* Palmas general purpose ADC IP block devicetree bindings
> +
> +Channels list:
> + 0 battery type
> + 1 battery temp NTC (optional current source)
> + 2 GP
> + 3 temp (with ext. diode, optional current source)
> + 4 GP
> + 5 GP
> + 6 VBAT_SENSE
> + 7 VCC_SENSE
> + 8 Backup Battery voltage
> + 9 external charger (VCHG)
> + 10 VBUS
> + 11 DC-DC current probe (how does this work?)
> + 12 internal die temp
> + 13 internal die temp
> + 14 USB ID pin voltage
> + 15 test network
> +
> +Required properties:
> +- compatible : Must be "ti,palmas-gpadc".
> +- #io-channel-cells: Should be set to <1>.
> +
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
Values

> +ti,enable-extended-delay: Enable extended delay.
> +
> +Example:
> +
> +pmic {
> + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> + ...
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> +   16 0
> +   17 0>;
> + #io-channel-cells = <1>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + };
> + };
> + ...
> +};
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> index 71763c5..f42eb8a 100644
> --- a/drivers/iio/adc/palmas_gpadc.c
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -460,6 +462,34 @@ static const struct iio_chan_spec 
> palmas_gpadc_iio_channel[] = {
>   PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
>  };
>  
> +static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
> + struct palmas_gpadc_platform_data **gpadc_pdata)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct palmas_gpadc_platform_data *gp_data;
> + int ret;
> + u32 pval;
> +
> + gp_data = devm_kzalloc(>dev, sizeof(*gp_data), GFP_KERNEL);
> + if (!gp_data)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32(np, "ti,channel0-current-microamp", );
> + if (!ret)
> + gp_data->ch0_current = pval;
> +
> + ret = of_property_read_u32(np, "ti,channel3-current-microamp", );
> + if (!ret)
> + gp_data->ch3_current = pval;
> +
> + gp_data->extended_delay = of_property_read_bool(np,
> + "ti,enable-extended-delay");
> +
> + *gpadc_pdata = gp_data;
> +
> + return 0;
> +}
> +
>  static int palmas_gpadc_probe(struct platform_device *pdev)
>  {
>   struct palmas_gpadc *adc;
> @@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
> *pdev)
>   int ret, i;
>  
>   pdata = dev_get_platdata(pdev->dev.parent);
> - if (!pdata || !pdata->gpadc_pdata) {
> - dev_err(>dev, "No platform data\n");
> - return -ENODEV;
> - }
>  
> - gpadc_pdata = pdata->gpadc_pdata;
> + if (pdata && pdata->gpadc_pdata)
> + gpadc_pdata = pdata->gpadc_pdata;
> +
> + if (!gpadc_pdata && pdev->dev.of_node) {
> + ret = palmas_gpadc_get_adc_dt_data(pdev, _pdata);
> + if (ret < 0)
> + return ret;
> + }
> + if (!gpadc_pdata)
> + return -EINVAL;
>  
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*adc));
>   if (!indio_dev) {
> @@ -790,12 +825,19 @@ static const struct dev_pm_ops palmas_pm_ops = {
>   palmas_gpadc_resume)

Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs

[Alim Akhtar]

Hi Kishon
Thanks again for you review.

On Fri, Oct 23, 2015 at 8:48 PM, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Thursday 15 October 2015 08:38 AM, Alim Akhtar wrote:
>> +CCing kishon Vijay,
>>
>> On 10/14/2015 06:25 PM, Alim Akhtar wrote:
>>> From: Seungwon Jeon 
>>>
>>> This patch introduces Exynos UFS host controller driver,
>>> which mainly handles vendor-specific operations including
>>> link startup, power mode change and hibernation/unhibernation.
>>>
>>> Signed-off-by: Seungwon Jeon 
>>> Signed-off-by: Alim Akhtar 
>>> ---
>>>   drivers/scsi/ufs/Kconfig |   12 +
>>>   drivers/scsi/ufs/Makefile|1 +
>>>   drivers/scsi/ufs/ufs-exynos-hw.c |  131 
>>>   drivers/scsi/ufs/ufs-exynos-hw.h |   43 ++
>>>   drivers/scsi/ufs/ufs-exynos.c| 1317
>>> ++
>>>   drivers/scsi/ufs/ufs-exynos.h|  247 +++
>>>   drivers/scsi/ufs/ufshci.h|   26 +-
>>>   drivers/scsi/ufs/unipro.h|   47 ++
>>>   8 files changed, 1823 insertions(+), 1 deletion(-)
>>>   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
>>>   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
>>>   create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>>>   create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>>>
> .
> .
> 
> .
> .
>>> diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c
>>> b/drivers/scsi/ufs/ufs-exynos-hw.c
>>> new file mode 100644
>>> index ..be6c61541a8f
>>> --- /dev/null
>>> +++ b/drivers/scsi/ufs/ufs-exynos-hw.c
>>> @@ -0,0 +1,131 @@
> .
> .
> 
> .
> .
>>> +
>>> +#define PWR_MODE_STR_LEN64
>>> +static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
>>> +struct ufs_pa_layer_attr *pwr_max,
>>> +struct ufs_pa_layer_attr *pwr_req)
>>> +{
>>> +struct exynos_ufs *ufs = to_exynos_ufs(hba);
>>> +struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);
>
> This is abusing the interface. phy_get_drvdata is meant to be used only
> by the PHY driver.
>>> +struct exynos_ufs_phy_specific_ops *phy_ops =
>>> +phy_info->phy_specific_ops;
>
> I'm really not happy about having platform specific ops for PHY. We have
> to see if existing PHY ops can be used for this or in worst case add new
> PHY ops.
Well you said you like the controller driver to use only PHY ops[1], I
am sorry If I misunderstood that point, can you please help me to
understand that?
[1]-> https://lkml.org/lkml/2015/9/18/29

>>> +struct uic_pwr_mode *pwr = >pwr_act;
>>> +char pwr_str[PWR_MODE_STR_LEN] = "";
>>> +int ret = 0;
>>> +
>>> +if (ufs->drv_data->post_pwr_change)
>>> +ufs->drv_data->post_pwr_change(ufs, pwr);
>>> +
>>> +if (IS_UFS_PWR_MODE_HS(pwr->mode)) {
>>> +switch (pwr->hs_series) {
>>> +case PA_HS_MODE_A:
>>> +case PA_HS_MODE_B:
>>> +phy_ops->calibrate_phy(ufs->phy, CFG_POST_PWR_HS,
>>> +PWR_MODE_HS(pwr->gear, pwr->hs_series));
>>> +break;
>>> +}
>>> +
>>> +ret = phy_ops->wait_for_lock_acq(ufs->phy);
>>> +snprintf(pwr_str, sizeof(pwr_str), "Fast%s series_%s G_%d L_%d",
>>> +pwr->mode == FASTAUTO_MODE ? "_Auto" : "",
>>> +pwr->hs_series == PA_HS_MODE_A ? "A" : "B",
>>> +pwr->gear, pwr->lane);
>>> +} else if (IS_UFS_PWR_MODE_PWM(pwr->mode)) {
>>> +snprintf(pwr_str, sizeof(pwr_str), "Slow%s G_%d L_%d",
>>> +pwr->mode == SLOWAUTO_MODE ? "_Auto" : "",
>>> +pwr->gear, pwr->lane);
>>> +}
>>> +
>>> +dev_info(hba->dev, "Power mode change %d : %s\n", ret, pwr_str);
>>> +return ret;
>>> +}
>>> +
>>> +static void exynos_ufs_specify_nexus_t_xfer_req(struct ufs_hba *hba,
>>> +int tag, struct scsi_cmnd *cmd)
>>> +{
>>> +struct exynos_ufs *ufs = to_exynos_ufs(hba);
>>> +u32 type;
>>> +
>>> +type =  hci_readl(ufs, HCI_UTRL_NEXUS_TYPE);
>>> +
>>> +if (cmd)
>>> +hci_writel(ufs, type | (1 << tag), HCI_UTRL_NEXUS_TYPE);
>>> +else
>>> +hci_writel(ufs, type & ~(1 << tag), HCI_UTRL_NEXUS_TYPE);
>>> +}
>>> +
>>> +static void exynos_ufs_specify_nexus_t_tm_req(struct ufs_hba *hba,
>>> +int tag, u8 func)
>>> +{
>>> +struct exynos_ufs *ufs = to_exynos_ufs(hba);
>>> +u32 type;
>>> +
>>> +type =  hci_readl(ufs, HCI_UTMRL_NEXUS_TYPE);
>>> +
>>> +switch (func) {
>>> +case UFS_ABORT_TASK:
>>> +case UFS_QUERY_TASK:
>>> +hci_writel(ufs, type | (1 << tag), HCI_UTMRL_NEXUS_TYPE);
>>> +break;
>>> +case UFS_ABORT_TASK_SET:
>>> +case UFS_CLEAR_TASK_SET:
>>> +case UFS_LOGICAL_RESET:
>>> +case UFS_QUERY_TASK_SET:
>>> +hci_writel(ufs, type & ~(1 << tag), HCI_UTMRL_NEXUS_TYPE);
>>> +break;
>>> +}
>>> +}
>>> +
>>> +static void exynos_ufs_phy_init(struct exynos_ufs *ufs)
>>> +{
>>> +struct ufs_hba *hba = ufs->hba;
>>> +

Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation

[Jonathan Cameron]

On 13/10/15 10:37, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil 
Looks good to me, but as it is a little bit 'different' and we are
defining entirely new generic bindings (the channel modes stuff)
I would like some more input.  It might be overkill but we do
of course have the pinctl framework which covers this sort of
thing... Might be worth considering if using that to get the unified
bindings might make sense here...

cc'd Linus in case he wants to comment on this.

It would obviously be a very heavy weight solution to the problem
so I'm far from convinced it makes sense - or even fits the usecase
terrible well.  Just thought I'd mention the possibility.
> ---
>  .../devicetree/bindings/iio/dac/ad5592r.txt| 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> 
>  v2: Fix indentation issue
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5592r.txt 
> b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> new file mode 100644
> index 000..12b8d0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> @@ -0,0 +1,43 @@
> +Analog Devices AD5592R/AD5593R DAC/ADC device driver
> +
> +Required properties for the AD5592R:
> + - compatible: Must be "adi,ad5592r"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 3000)
> + - spi-cpol: The AD5592R requires inverse clock polarity (CPOL) mode
> +
> +Required properties for the AD5593R:
> + - compatible: Must be "adi,ad5593r"
> + - reg: I2C address of the device
> +
> +Required properties for all supported chips:
> + - channel-modes: An array of eight 8-bit values (one per channel)
> +   describing the mode of each channel. Macros specifying the valid 
> values
> +   can be found in .
> +   The following values are currently supported:
> + * CH_MODE_UNUSED (the pin is pulled down)
> + * CH_MODE_DAC
> + * CH_MODE_ADC
> + * CH_MODE_GPIO_TRISTATE
> +
> +Example:
> +
> + #include 
> +
> + ad5592r@0 {
> + compatible = "adi,ad5592r";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpol;
> +
> + channel-modes = /bits/ 8 <
> + CH_MODE_DAC
> + CH_MODE_ADC
> + CH_MODE_ADC
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + >;
> + };
> 

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

Re: [PATCH v4 1/2] iio: adc: Add TI ADS8688

[Jonathan Cameron]

On 13/10/15 10:46, Sean Nyekjær wrote:
> Hi
> 
> I'm having a problems with the ads8688_write_raw_get_fmt function.
> 
> Firstly the OFFSET and the SCALE its switched around. Ill fix that :-)
> Secondly the i'm not allowed to return IIO_VAL_INT, this results in the
> iio_write_channel_info() is returning -EINVAL. The iio_write_channel_info() 
> only checks if the write_raw_get_fmt is existing...
> Do I need to convert the OFFSET to a IIO_VAL_INT_PLUS_NANO aswell or ?
Nope. The core needs extending to actually support IIO_VAL_INT.  Though 
cynically
setting it to IIO_VAL_INT_PLUS_MICRO and checking the val2 is 0 would work
as well if you want a quick solution.

Adding IIO_VAL_INT support should be fairly straightforward, though I'd
bypass the string to fixedpoint convertor in this case and do it with an
scanf.  


> 
> /Sean
> 
> On 2015-10-11 16:53, Jonathan Cameron wrote:
>> On 06/10/15 09:12, Sean Nyekjaer wrote:
>>> This patch adds support for the Texas Intruments ADS8688 ADC.
>>>
>>> Signed-off-by: Sean Nyekjaer 
>>> Reviewed-by: Martin Hundebøll 
>> only one issue that I can see.  You do need locking to protect
>> your local buffers.  A local lock in the same structure would be
>> appropriate for this.
>>
>> Neither sysfs nor IIO provide any serialization guarantees
>> so multiple concurrent reads are more than possible and may
>> cause you data corruption as it stands.
>>
>> Other than that, it's looking very nice.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>> Changes since v3:
>>> - fixed multiline comments
>>> - write_raw_get_fmt _SCALE is nano, _OFFSET is int
>>>
>>> Changes since v2:
>>> - Removed unused variables
>>> - Removed unnecessary mutex lock
>>> - Range array is a enum
>>> - Made the read and write functions less complex and easier to read
>>> - Added inline comments
>>> - Added callback to write_raw_get_fmt
>>>
>>> Changes since v1:
>>> - Now possible to read and write the actual offset and scale values
>>> - Removed unused includes
>>> - Removed unused buffer references
>>>   drivers/iio/adc/Kconfig  |  10 +
>>>   drivers/iio/adc/Makefile |   1 +
>>>   drivers/iio/adc/ti-ads8688.c | 472 
>>> +++
>>>   3 files changed, 483 insertions(+)
>>>   create mode 100644 drivers/iio/adc/ti-ads8688.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 7868c74..4135d17 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -333,6 +333,16 @@ config TI_ADC128S052
>>> This driver can also be built as a module. If so, the module will be
>>> called ti-adc128s052.
>>>   +config TI_ADS8688
>>> +tristate "Texas Instruments ADS8688"
>>> +depends on SPI && OF
>>> +help
>>> +  If you say yes here you get support for Texas Instruments ADS8684 and
>>> +  and ADS8688 ADC chips
>>> +
>>> +  This driver can also be built as a module. If so, the module will be
>>> +  called ti-ads8688.
>>> +
>>>   config TI_AM335X_ADC
>>>   tristate "TI's AM335X ADC driver"
>>>   depends on MFD_TI_AM335X_TSCADC
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 99b37a9..04ab2c8 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>   obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>> +obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>>   obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>>>   obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>> diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti-ads8688.c
>>> new file mode 100644
>>> index 000..537bb0a
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/ti-ads8688.c
>>> @@ -0,0 +1,472 @@
>>> +/*
>>> + * Copyright (C) 2015 Prevas A/S
>>> + *
>>> + * 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 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define ADS8688_CMD_REG(x)(x << 8)
>>> +#define ADS8688_CMD_REG_NOOP0x00
>>> +#define ADS8688_CMD_REG_RST0x85
>>> +#define ADS8688_CMD_REG_MAN_CH(chan)(0xC0 | (4 * chan))
>>> +#define ADS8688_CMD_DONT_CARE_BITS16
>>> +
>>> +#define ADS8688_PROG_REG(x)(x << 9)
>>> +#define ADS8688_PROG_REG_RANGE_CH(chan)(0x05 + chan)
>>> +#define ADS8688_PROG_WR_BITBIT(8)
>>> +#define ADS8688_PROG_DONT_CARE_BITS8
>>> +
>>> +#define ADS8688_REG_PLUSMINUS25VREF0
>>> +#define ADS8688_REG_PLUSMINUS125VREF1
>>> +#define 

Re: [PATCH v7 6/8] scsi: ufs: make the UFS variant a platform device

[ygardi]

> On Thursday 22 October 2015 07:02:14 subha...@codeaurora.org wrote:
>> >
>> >  Required properties:
>> > -- compatible: compatible list, contains "jedec,ufs-1.1"
>> > +- compatible: compatible list, contains "jedec,ufs-1.1" or
>> > +"qcom,msm8994-ufshc" or "qcom,msm8996-ufshc"
>>
>> Are we really using these "qcom,msm8994-ufshc" or "qcom,msm8996-ufshc"
>> compatible string anywhere?
>
> We should list them in either case, but it could be clarified as:
>
> compatible: must contain "jedec,ufs-1.1", may also list one or more
> of the following:
>   "qcom,msm8994-ufshc"
>   "qcom,msm8996-ufshc"
>   "qcom,ufshc"
>
>   Arnd
>

Shortly i will upload an updated v8.
Yaniv



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

Re: [PATCH v3 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

Am 25.10.2015 um 13:04 schrieb Jonathan Cameron :

> On 16/10/15 13:53, H. Nikolaus Schaller wrote:
>> This driver code was found as:
>> 
>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>> 
>> Fixed various compilation issues and test this driver on omap5 evm.
>> 
>> Signed-off-by: Pradeep Goudagunta 
>> Signed-off-by: H. Nikolaus Schaller 
>> Signed-off-by: Marek Belisko 
>> Acked-by: Laxman Dewangan 
>> Reviewed-by: Jonathan Cameron 
>> Acked-by: Lee Jones 
> Applied to the togreg branch of iio.git - initially pushed out as testing.

Thanks! I was just working on a V4 - but that is a fix for omap5-uevm DT only. 
So I will remove the driver code and submit separately.

> Unfortunately the timing is such that it's not going to make the upcoming
> merge window so will be an early entry to linux-next after the merge window
> closes.

Well, that happens. We can forward-port it to our distribution kernel so that 
it is
already available to users.

> 
> Jonathan

BR,
Nikolaus

>> ---
>> drivers/iio/adc/Kconfig|   8 +
>> drivers/iio/adc/Makefile   |   1 +
>> drivers/iio/adc/palmas_gpadc.c | 817 
>> +
>> include/linux/mfd/palmas.h |  75 ++--
>> 4 files changed, 877 insertions(+), 24 deletions(-)
>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>> 
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 50c103d..5100e56 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -264,6 +264,14 @@ config NAU7802
>>To compile this driver as a module, choose M here: the
>>module will be called nau7802.
>> 
>> +config PALMAS_GPADC
>> +tristate "TI Palmas General Purpose ADC"
>> +depends on MFD_PALMAS
>> +help
>> +  Palmas series pmic chip by Texas Instruments (twl6035/6037)
>> +  is used in smartphones and tablets and supports a 16 channel
>> +  general purpose ADC.
>> +
>> config QCOM_SPMI_IADC
>>  tristate "Qualcomm SPMI PMIC current ADC"
>>  depends on SPMI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index a096210..716f112 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> obj-$(CONFIG_MCP3422) += mcp3422.o
>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> obj-$(CONFIG_NAU7802) += nau7802.o
>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>> new file mode 100644
>> index 000..71763c5
>> --- /dev/null
>> +++ b/drivers/iio/adc/palmas_gpadc.c
>> @@ -0,0 +1,817 @@
>> +/*
>> + * palmas-adc.c -- TI PALMAS GPADC.
>> + *
>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>> + *
>> + * Author: Pradeep Goudagunta 
>> + *
>> + * 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 version 2.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MOD_NAME "palmas-gpadc"
>> +#define PALMAS_ADC_CONVERSION_TIMEOUT   (msecs_to_jiffies(5000))
>> +#define PALMAS_TO_BE_CALCULATED 0
>> +#define PALMAS_GPADC_TRIMINVALID-1
>> +
>> +struct palmas_gpadc_info {
>> +/* calibration codes and regs */
>> +int x1; /* lower ideal code */
>> +int x2; /* higher ideal code */
>> +int v1; /* expected lower volt reading */
>> +int v2; /* expected higher volt reading */
>> +u8 trim1_reg;   /* register number for lower trim */
>> +u8 trim2_reg;   /* register number for upper trim */
>> +int gain;   /* calculated from above (after reading trim regs) */
>> +int offset; /* calculated from above (after reading trim regs) */
>> +int gain_error; /* calculated from above (after reading trim regs) */
>> +bool is_uncalibrated;   /* if channel has calibration data */
>> +};
>> +
>> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
>> _is_uncalibrated) \
>> +[PALMAS_ADC_CH_##_chan] = { \
>> +.x1 = _x1, \
>> +.x2 = _x2, \
>> +.v1 = _v1, \
>> +.v2 = _v2, \
>> +.gain = PALMAS_TO_BE_CALCULATED, \
>> +.offset = PALMAS_TO_BE_CALCULATED, \
>> +.gain_error = PALMAS_TO_BE_CALCULATED, \
>> +.trim1_reg = PALMAS_GPADC_TRIM##_t1, \
>> +.trim2_reg = 

Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

[Martin Kepplinger]

Am 25. Oktober 2015 12:05:05 MEZ, schrieb Jonathan Cameron :
>On 22/10/15 19:22, Rob Herring wrote:
>> On Thu, Oct 15, 2015 at 8:10 AM, Martin Kepplinger
> wrote:
>>> This change is important in order for everyone to be easily able to
>use the
>>> driver for one of the supported accelerometer chips!
>>>
>>> Until now, the driver blindly assumed that the INT1 interrupt line
>is wired
>>> on a user's board. But these devices have 2 interrupt lines and can
>route
>>> their interrupt sources to one of them. Now, if "INT2" is found and
>matches
>>> i2c_client->irq, INT2 will be used.
>>>
>>> The chip's default actually is INT2, which is why probably many
>boards will
>>> have it wired and can make use of this.
>>>
>>> Of course, this also falls back to assuming INT1, so for existing
>users
>>> nothing will break. The new functionality is described in the
>bindings doc.
>>>
>>> Signed-off-by: Martin Kepplinger
>
>>> ---
>>> changelog:
>>> v4: use irq that matches client->irq, backwards compatible
>>> v3: correctly assign irq if both pins are described in DT
>>> v2: don't warn but normally handle if both pins are described in dts
>>> thanks Mark Rutland
>>> v1: initial post
>>>
>>>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
>> 
>> For the binding:
>> 
>> Rob Herring 
>I've guessed that was an Acked-by :)
>
>Anyhow, applied to the togreg branch of iio.git.
>
>I'm afraid after my hiatus for a couple of weeks (day job work crisis
>now
>over) this has missed going in for the current cycle.
>
>IIO merge closes more than a week before the merge window opens and
>Linus
>just announced probably release a week today.
>
>Sorry about that, will be queued up for an early entry into linux next
>after the merge window closes.
>
>Jonathan

That's fine. Thanks

>> 
>>>  drivers/iio/accel/mma8452.c | 21
>+++--
>>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> index e3c3746..3c10e85 100644
>>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> @@ -7,13 +7,18 @@ Required properties:
>>>  * "fsl,mma8453"
>>>  * "fsl,mma8652"
>>>  * "fsl,mma8653"
>>> +
>>>- reg: the I2C address of the chip
>>>
>>>  Optional properties:
>>>
>>>- interrupt-parent: should be the phandle for the interrupt
>controller
>>> +
>>>- interrupts: interrupt mapping for GPIO IRQ
>>>
>>> +  - interrupt-names: should contain "INT1" and/or "INT2", the
>accelerometer's
>>> +interrupt line in use.
>>> +
>>>  Example:
>>>
>>> mma8453fc@1d {
>>> @@ -21,4 +26,5 @@ Example:
>>> reg = <0x1d>;
>>> interrupt-parent = <>;
>>> interrupts = <5 0>;
>>> +   interrupt-names = "INT2";
>>> };
>>> diff --git a/drivers/iio/accel/mma8452.c
>b/drivers/iio/accel/mma8452.c
>>> index 1eccc2d..116a6e4 100644
>>> --- a/drivers/iio/accel/mma8452.c
>>> +++ b/drivers/iio/accel/mma8452.c
>>> @@ -29,6 +29,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #define MMA8452_STATUS 0x00
>>>  #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) |
>BIT(0))
>>> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client
>*client,
>>>MMA8452_INT_FF_MT;
>>> int enabled_interrupts = MMA8452_INT_TRANS |
>>>  MMA8452_INT_FF_MT;
>>> +   int irq2;
>>>
>>> -   /* Assume wired to INT1 pin */
>>> -   ret = i2c_smbus_write_byte_data(client,
>>> -   MMA8452_CTRL_REG5,
>>> -  
>supported_interrupts);
>>> -   if (ret < 0)
>>> -   return ret;
>>> +   irq2 = of_irq_get_byname(client->dev.of_node,
>"INT2");
>>> +
>>> +   if (irq2 == client->irq) {
>>> +   dev_dbg(>dev, "using interrupt line
>INT2\n");
>>> +   } else {
>>> +   ret = i2c_smbus_write_byte_data(client,
>>> +  
>MMA8452_CTRL_REG5,
>>> +  
>supported_interrupts);
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   dev_dbg(>dev, "using interrupt line
>INT1\n");
>>> +   }
>>>
>>> ret = i2c_smbus_write_byte_data(client,
>>> MMA8452_CTRL_REG4,
>>> --
>>> 2.1.4
>>>
>> --
>> To unsubscribe from this list: send the line 

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine on a given
> system so it's constantly being highlighted to people in a way that
> other issues aren't if you're not directly having problems.
>
> There's also the understanding people had that the order things get
> bound changes the ordering for some of the other cases (perhaps it's a
> good idea to do that, it seems likely to be sensible?).

But it really doesn't do that.  Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).

If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe.  That should help to reduce the
noise you're referring to.

If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/35] nfc: nci: Add a call to nci_hci_clear_all_pipes at HCI initial activation.

[Christophe Ricard]

When session_id is filled to ff, the pipe configuration is probably
incorrect.

Signed-off-by: Christophe Ricard 
---
 net/nfc/nci/hci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 43d7931..a937bc6 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -701,6 +701,10 @@ int nci_hci_dev_session_init(struct nci_dev *ndev)
/* Restore gate<->pipe table from some proprietary location. */
r = ndev->ops->hci_load_session(ndev);
} else {
+   r = nci_hci_clear_all_pipes(ndev);
+   if (r < 0)
+   goto exit;
+
r = nci_hci_dev_connect_gates(ndev,
  
ndev->hci_dev->init_data.gate_count,
  ndev->hci_dev->init_data.gates);
-- 
2.1.4

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

[PATCH v2 14/35] nfc: st21nfca: Open NFC_HCI_LINK_MGMT_PIPE

[Christophe Ricard]

NFC_HCI_LINK_MGMT_PIPE was never open in nfc_hci_load_session.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index 67d1c27..819a94a 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -203,22 +203,13 @@ static int st21nfca_hci_load_session(struct nfc_hci_dev 
*hdev)
}
 
/*
-* 3 gates have a well known pipe ID.
-* They will never appear in the pipe list
+* 3 gates have a well known pipe ID. Only NFC_HCI_LINK_MGMT_GATE
+* is not yet open at this stage.
 */
-   if (skb_pipe_list->len + 3 < ARRAY_SIZE(st21nfca_gates)) {
-   for (i = skb_pipe_list->len + 3;
-   i < ARRAY_SIZE(st21nfca_gates) - 2; i++) {
-   r = nfc_hci_connect_gate(hdev,
-   NFC_HCI_HOST_CONTROLLER_ID,
-   st21nfca_gates[i].gate,
-   st21nfca_gates[i].pipe);
-   if (r < 0)
-   goto free_list;
-   }
-   }
+   r = nfc_hci_connect_gate(hdev, NFC_HCI_HOST_CONTROLLER_ID,
+NFC_HCI_LINK_MGMT_GATE,
+NFC_HCI_LINK_MGMT_PIPE);
 
-free_list:
kfree_skb(skb_pipe_list);
return r;
 }
-- 
2.1.4

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

[PATCH v2 20/35] nfc: st21nfca: Change st21nfca_gates offset when looking for a pipe in the table

[Christophe Ricard]

It is useless to start from index 0 when looking for a gate because only
dynamic pipes are retrieved with 
ST21NFCA_DM_GETINFO(ST21NFCA_DM_GETINFO_PIPE_LIST).

The first dynamic pipe is present at index 3.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index b4451f8..814d8ff4 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -85,12 +85,13 @@ static DECLARE_BITMAP(dev_mask, ST21NFCA_NUM_DEVICES);
 
 static struct nfc_hci_gate st21nfca_gates[] = {
{NFC_HCI_ADMIN_GATE, NFC_HCI_ADMIN_PIPE},
+   {NFC_HCI_LINK_MGMT_GATE, NFC_HCI_LINK_MGMT_PIPE},
+   {ST21NFCA_DEVICE_MGNT_GATE, ST21NFCA_DEVICE_MGNT_PIPE},
+
{NFC_HCI_LOOPBACK_GATE, NFC_HCI_INVALID_PIPE},
{NFC_HCI_ID_MGMT_GATE, NFC_HCI_INVALID_PIPE},
-   {NFC_HCI_LINK_MGMT_GATE, NFC_HCI_LINK_MGMT_PIPE},
{NFC_HCI_RF_READER_B_GATE, NFC_HCI_INVALID_PIPE},
{NFC_HCI_RF_READER_A_GATE, NFC_HCI_INVALID_PIPE},
-   {ST21NFCA_DEVICE_MGNT_GATE, ST21NFCA_DEVICE_MGNT_PIPE},
{ST21NFCA_RF_READER_F_GATE, NFC_HCI_INVALID_PIPE},
{ST21NFCA_RF_READER_14443_3_A_GATE, NFC_HCI_INVALID_PIPE},
{ST21NFCA_RF_READER_ISO15693_GATE, NFC_HCI_INVALID_PIPE},
@@ -183,7 +184,7 @@ static int st21nfca_hci_load_session(struct nfc_hci_dev 
*hdev)
continue;
}
 
-   for (j = 0; (j < ARRAY_SIZE(st21nfca_gates)) &&
+   for (j = 3; (j < ARRAY_SIZE(st21nfca_gates)) &&
(st21nfca_gates[j].gate != info->dst_gate_id) ; j++)
;
 
-- 
2.1.4

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

[PATCH v2 02/35] nfc: st-nci: include st-nci.h instead of ndlc.h

[Christophe Ricard]

st-nci.h already include ndlc.h.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/i2c.c  | 2 +-
 drivers/nfc/st-nci/ndlc.c | 1 -
 drivers/nfc/st-nci/spi.c  | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 707ed2e..02e585f 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include "ndlc.h"
+#include "st-nci.h"
 
 #define DRIVER_DESC "NCI NFC driver for ST_NCI"
 
diff --git a/drivers/nfc/st-nci/ndlc.c b/drivers/nfc/st-nci/ndlc.c
index d2cf84e..fb50007 100644
--- a/drivers/nfc/st-nci/ndlc.c
+++ b/drivers/nfc/st-nci/ndlc.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 
-#include "ndlc.h"
 #include "st-nci.h"
 
 #define NDLC_TIMER_T1  100
diff --git a/drivers/nfc/st-nci/spi.c b/drivers/nfc/st-nci/spi.c
index 598a58c..9a39871 100644
--- a/drivers/nfc/st-nci/spi.c
+++ b/drivers/nfc/st-nci/spi.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include "ndlc.h"
+#include "st-nci.h"
 
 #define DRIVER_DESC "NCI NFC driver for ST_NCI"
 
-- 
2.1.4

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

[PATCH v2 18/35] nfc: st-nci: Add support for NCI_HCI_IDENTITY_MGMT_GATE

[Christophe Ricard]

NCI_HCI_IDENTITY_MGMT_GATE might be useful to get information for example
about hardware or firmware version.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c| 3 +++
 include/net/nfc/nci_core.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 11e49a5..5d1747d 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -112,6 +112,9 @@ static struct nci_hci_gate st_nci_gates[] = {
{ST_NCI_DEVICE_MGNT_GATE, ST_NCI_DEVICE_MGNT_PIPE,
ST_NCI_HOST_CONTROLLER_ID},
 
+   {NCI_HCI_IDENTITY_MGMT_GATE, NCI_HCI_INVALID_PIPE,
+   ST_NCI_HOST_CONTROLLER_ID},
+
/* Secure element pipes are created by secure element host */
{ST_NCI_CONNECTIVITY_GATE, NCI_HCI_DO_NOT_OPEN_PIPE,
ST_NCI_HOST_CONTROLLER_ID},
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index b2f2e04..377f3de 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -125,6 +125,7 @@ struct nci_conn_info {
 
 /* Gates */
 #define NCI_HCI_ADMIN_GATE 0x00
+#define NCI_HCI_IDENTITY_MGMT_GATE 0x05
 #define NCI_HCI_LINK_MGMT_GATE 0x06
 
 /* Pipes */
-- 
2.1.4

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

[PATCH v2 08/35] nfc: nci: add nci_hci_clear_all_pipes functions

[Christophe Ricard]

nci_hci_clear_all_pipes might be use full in some cases for example after
a firmware update.

Signed-off-by: Christophe Ricard 
---
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/hci.c  | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index d0d0f1e..b2f2e04 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -305,6 +305,7 @@ int nci_hci_set_param(struct nci_dev *ndev, u8 gate, u8 idx,
  const u8 *param, size_t param_len);
 int nci_hci_get_param(struct nci_dev *ndev, u8 gate, u8 idx,
  struct sk_buff **skb);
+int nci_hci_clear_all_pipes(struct nci_dev *ndev);
 int nci_hci_dev_session_init(struct nci_dev *ndev);
 
 static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index abe0200..43d7931 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -70,6 +70,7 @@ struct nci_hcp_packet {
 #define NCI_HCI_ANY_SET_PARAMETER  0x01
 #define NCI_HCI_ANY_GET_PARAMETER  0x02
 #define NCI_HCI_ANY_CLOSE_PIPE 0x04
+#define NCI_HCI_ADM_CLEAR_ALL_PIPE 0x14
 
 #define NCI_HFP_NO_CHAINING0x80
 
@@ -265,6 +266,20 @@ int nci_hci_send_cmd(struct nci_dev *ndev, u8 gate, u8 cmd,
 }
 EXPORT_SYMBOL(nci_hci_send_cmd);
 
+int nci_hci_clear_all_pipes(struct nci_dev *ndev)
+{
+   int r;
+
+   r = nci_hci_send_cmd(ndev, NCI_HCI_ADMIN_GATE,
+NCI_HCI_ADM_CLEAR_ALL_PIPE, NULL, 0, NULL);
+   if (r < 0)
+   return r;
+
+   nci_hci_reset_pipes(ndev->hci_dev);
+   return r;
+}
+EXPORT_SYMBOL(nci_hci_clear_all_pipes);
+
 static void nci_hci_event_received(struct nci_dev *ndev, u8 pipe,
   u8 event, struct sk_buff *skb)
 {
-- 
2.1.4

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

[PATCH v2 03/35] nfc: st21nfca: Align st21nfca driver with other nfc driver

[Christophe Ricard]

Align st21nfca driver with or nfc driver:
- Remove st21nfca_ prefix
- Merge st21nfca_se.h, st21nfca_dep.h in st21nfca.h

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/Makefile   |2 +-
 drivers/nfc/st21nfca/core.c | 1062 ++
 drivers/nfc/st21nfca/dep.c  |  688 ++
 drivers/nfc/st21nfca/se.c   |  419 ++
 drivers/nfc/st21nfca/st21nfca.c | 1064 ---
 drivers/nfc/st21nfca/st21nfca.h |   98 +++-
 drivers/nfc/st21nfca/st21nfca_dep.c |  689 ---
 drivers/nfc/st21nfca/st21nfca_dep.h |   43 --
 drivers/nfc/st21nfca/st21nfca_se.c  |  420 --
 drivers/nfc/st21nfca/st21nfca_se.h  |   63 ---
 10 files changed, 2249 insertions(+), 2299 deletions(-)
 create mode 100644 drivers/nfc/st21nfca/core.c
 create mode 100644 drivers/nfc/st21nfca/dep.c
 create mode 100644 drivers/nfc/st21nfca/se.c
 delete mode 100644 drivers/nfc/st21nfca/st21nfca.c
 delete mode 100644 drivers/nfc/st21nfca/st21nfca_dep.c
 delete mode 100644 drivers/nfc/st21nfca/st21nfca_dep.h
 delete mode 100644 drivers/nfc/st21nfca/st21nfca_se.c
 delete mode 100644 drivers/nfc/st21nfca/st21nfca_se.h

diff --git a/drivers/nfc/st21nfca/Makefile b/drivers/nfc/st21nfca/Makefile
index 97edab4..82434c3 100644
--- a/drivers/nfc/st21nfca/Makefile
+++ b/drivers/nfc/st21nfca/Makefile
@@ -2,7 +2,7 @@
 # Makefile for ST21NFCA HCI based NFC driver
 #
 
-st21nfca_hci-objs = st21nfca.o st21nfca_dep.o st21nfca_se.o
+st21nfca_hci-objs = core.o dep.o se.o
 obj-$(CONFIG_NFC_ST21NFCA) += st21nfca_hci.o
 
 st21nfca_i2c-objs  = i2c.o
diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
new file mode 100644
index 000..42f1974
--- /dev/null
+++ b/drivers/nfc/st21nfca/core.c
@@ -0,0 +1,1062 @@
+/*
+ * HCI based Driver for STMicroelectronics NFC Chip
+ *
+ * Copyright (C) 2014  STMicroelectronics SAS. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "st21nfca.h"
+
+#define DRIVER_DESC "HCI NFC driver for ST21NFCA"
+
+#define FULL_VERSION_LEN 3
+
+/* Proprietary gates, events, commands and registers */
+
+/* Commands that apply to all RF readers */
+#define ST21NFCA_RF_READER_CMD_PRESENCE_CHECK  0x30
+
+#define ST21NFCA_RF_READER_ISO15693_GATE   0x12
+#define ST21NFCA_RF_READER_ISO15693_INVENTORY  0x01
+
+/*
+ * Reader gate for communication with contact-less cards using Type A
+ * protocol ISO14443-3 but not compliant with ISO14443-4
+ */
+#define ST21NFCA_RF_READER_14443_3_A_GATE  0x15
+#define ST21NFCA_RF_READER_14443_3_A_UID   0x02
+#define ST21NFCA_RF_READER_14443_3_A_ATQA  0x03
+#define ST21NFCA_RF_READER_14443_3_A_SAK   0x04
+
+#define ST21NFCA_RF_READER_F_DATARATE  0x01
+#define ST21NFCA_RF_READER_F_DATARATE_106  0x01
+#define ST21NFCA_RF_READER_F_DATARATE_212  0x02
+#define ST21NFCA_RF_READER_F_DATARATE_424  0x04
+#define ST21NFCA_RF_READER_F_POL_REQ   0x02
+#define ST21NFCA_RF_READER_F_POL_REQ_DEFAULT   0x
+#define ST21NFCA_RF_READER_F_NFCID20x03
+#define ST21NFCA_RF_READER_F_NFCID10x04
+
+#define ST21NFCA_RF_CARD_F_MODE0x01
+#define ST21NFCA_RF_CARD_F_NFCID2_LIST 0x04
+#define ST21NFCA_RF_CARD_F_NFCID1  0x05
+#define ST21NFCA_RF_CARD_F_SENS_RES0x06
+#define ST21NFCA_RF_CARD_F_SEL_RES 0x07
+#define ST21NFCA_RF_CARD_F_DATARATE0x08
+#define ST21NFCA_RF_CARD_F_DATARATE_212_4240x01
+
+#define ST21NFCA_DEVICE_MGNT_PIPE  0x02
+
+#define ST21NFCA_DM_GETINFO0x13
+#define ST21NFCA_DM_GETINFO_PIPE_LIST  0x02
+#define ST21NFCA_DM_GETINFO_PIPE_INFO  0x01
+#define ST21NFCA_DM_PIPE_CREATED   0x02
+#define ST21NFCA_DM_PIPE_OPEN  0x04
+#define ST21NFCA_DM_RF_ACTIVE  0x80
+#define ST21NFCA_DM_DISCONNECT 0x30
+
+#define ST21NFCA_DM_IS_PIPE_OPEN(p) \
+   ((p & 0x0f) == (ST21NFCA_DM_PIPE_CREATED | ST21NFCA_DM_PIPE_OPEN))
+
+#define ST21NFCA_NFC_MODE  0x03/* NFC_MODE parameter*/
+
+#define ST21NFCA_EVT_HOT_PLUG  0x03
+#define ST21NFCA_EVT_HOT_PLUG_IS_INHIBITED(x) (x->data[0] & 0x80)
+
+#define ST21NFCA_SE_TO_PIPES   

[PATCH v2 13/35] nfc: st-nci: Open NCI_HCI_LINK_MGMT_PIPE

[Christophe Ricard]

NCI_HCI_LINK_MGMT_PIPE was never open in st_nci_hci_load_session.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 3ffac0e..3522165 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -244,6 +244,14 @@ int st_nci_hci_load_session(struct nci_dev *ndev)
kfree_skb(skb_pipe_info);
}
 
+   /*
+* 3 gates have a well known pipe ID. Only NCI_HCI_LINK_MGMT_GATE
+* is not yet open at this stage.
+*/
+   r = nci_hci_connect_gate(ndev, ST_NCI_HOST_CONTROLLER_ID,
+NCI_HCI_LINK_MGMT_GATE,
+NCI_HCI_LINK_MGMT_PIPE);
+
kfree_skb(skb_pipe_list);
return r;
 }
-- 
2.1.4

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

[PATCH v2 11/35] nfc: st-nci: Remove ndev->hci_dev->init_data.gates initialization in load_session

[Christophe Ricard]

ndev->hci_dev->init_data.gates is already initialized in st_nci_hci_network.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 4acb945..3ffac0e 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -244,9 +244,6 @@ int st_nci_hci_load_session(struct nci_dev *ndev)
kfree_skb(skb_pipe_info);
}
 
-   memcpy(ndev->hci_dev->init_data.gates, st_nci_gates,
-  sizeof(st_nci_gates));
-
kfree_skb(skb_pipe_list);
return r;
 }
-- 
2.1.4

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

[PATCH v2 10/35] nfc: nci: add capability to create pipe on specific gate in nci_hci_connect_gate

[Christophe Ricard]

Some gates might be interesting to have their pipes created.
Add in nci_hci_connect_gate a call to nci_hci_create_pipe for every gate
different than NCI_HCI_LINK_MGMT_GATE or NCI_HCI_ADMIN_GATE.

In case of an error when opening a pipe, like in hci layer, delete the pipe
if it was created.

Signed-off-by: Christophe Ricard 
---
 net/nfc/nci/hci.c | 55 ++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index a937bc6..1d6aa5d 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -79,6 +79,8 @@ struct nci_hcp_packet {
 #define NCI_EVT_HOT_PLUG   0x03
 
 #define NCI_HCI_ADMIN_PARAM_SESSION_IDENTITY   0x01
+#define NCI_HCI_ADM_CREATE_PIPE0x10
+#define NCI_HCI_ADM_DELETE_PIPE0x11
 
 /* HCP headers */
 #define NCI_HCI_HCP_PACKET_HEADER_LEN  1
@@ -520,6 +522,42 @@ int nci_hci_open_pipe(struct nci_dev *ndev, u8 pipe)
 }
 EXPORT_SYMBOL(nci_hci_open_pipe);
 
+static u8 nci_hci_create_pipe(struct nci_dev *ndev, u8 dest_host,
+ u8 dest_gate, int *result)
+{
+   u8 pipe;
+   struct sk_buff *skb;
+   struct nci_hci_create_pipe_params params;
+   struct nci_hci_create_pipe_resp *resp;
+
+   pr_debug("gate=%d\n", dest_gate);
+
+   params.src_gate = NCI_HCI_ADMIN_GATE;
+   params.dest_host = dest_host;
+   params.dest_gate = dest_gate;
+
+   *result = nci_hci_send_cmd(ndev, NCI_HCI_ADMIN_GATE, 
NCI_HCI_ADM_CREATE_PIPE,
+  (u8 *), sizeof(params), );
+   if (*result < 0)
+   return NCI_HCI_INVALID_PIPE;
+
+   resp = (struct nci_hci_create_pipe_resp *)skb->data;
+   pipe = resp->pipe;
+   kfree_skb(skb);
+
+   pr_debug("pipe created=%d\n", pipe);
+
+   return pipe;
+}
+
+static int nci_hci_delete_pipe(struct nci_dev *ndev, u8 pipe)
+{
+   pr_debug("\n");
+
+   return nci_hci_send_cmd(ndev, NCI_HCI_ADMIN_GATE,
+   NCI_HCI_ADM_DELETE_PIPE, , 1, NULL);
+}
+
 int nci_hci_set_param(struct nci_dev *ndev, u8 gate, u8 idx,
  const u8 *param, size_t param_len)
 {
@@ -611,6 +649,7 @@ EXPORT_SYMBOL(nci_hci_get_param);
 int nci_hci_connect_gate(struct nci_dev *ndev,
 u8 dest_host, u8 dest_gate, u8 pipe)
 {
+   bool pipe_created = false;
int r;
 
if (pipe == NCI_HCI_DO_NOT_OPEN_PIPE)
@@ -629,12 +668,26 @@ int nci_hci_connect_gate(struct nci_dev *ndev,
case NCI_HCI_ADMIN_GATE:
pipe = NCI_HCI_ADMIN_PIPE;
break;
+   default:
+   pipe = nci_hci_create_pipe(ndev, dest_host, dest_gate, );
+   if (pipe < 0)
+   return r;
+   pipe_created = true;
+   break;
}
 
 open_pipe:
r = nci_hci_open_pipe(ndev, pipe);
-   if (r < 0)
+   if (r < 0) {
+   if (pipe_created) {
+   if (nci_hci_delete_pipe(ndev, pipe) < 0) {
+   /* TODO: Cannot clean by deleting pipe...
+* -> inconsistent state
+*/
+   }
+   }
return r;
+   }
 
ndev->hci_dev->pipes[pipe].gate = dest_gate;
ndev->hci_dev->pipes[pipe].host = dest_host;
-- 
2.1.4

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

[PATCH v2 21/35] nfc: st-nci: Add support for proprietary commands for factory tests

[Christophe Ricard]

Add support for proprietary commands useful mainly for factory testings.
Here is a list:
- FACTORY_MODE: Allow to set the driver into a mode where no secure element
are activated. It does not consider any NFC_ATTR_VENDOR_DATA.
- HCI_CLEAR_ALL_PIPES: Allow to execute a HCI clear all pipes command.
It does not consider any NFC_ATTR_VENDOR_DATA.
- HCI_DM_PUT_DATA: Allow to configure specific CLF registry as for example
RF trimmings or low level drivers configurations (I2C, SPI, SWP).
- HCI_DM_UPDATE_AID: Allow to configure an AID routing into the CLF routing
table following RF technology, CLF mode or protocol.
- HCI_DM_GET_INFO: Allow to retrieve CLF information.
- HCI_DM_GET_DATA: Allow to retrieve CLF configurable data such as low
level drivers configurations or RF trimmings.
- HCI_DM_DIRECT_LOAD: Allow to load a firmware into the CLF. A complete
packet can be more than 8KB.
- HCI_DM_RESET: Allow to run a CLF reset in order to "commit" CLF
configuration changes without CLF power off.
-  HCI_GET_PARAM: Allow to retrieve an HCI CLF parameter (for example the
white list).
- HCI_DM_FIELD_GENERATOR: Allow to generate different kind of RF
technology. When using this command to anti-collision is done.
- HCI_LOOPBACK: Allow to echo a command and test the Dh to CLF
connectivity.
- HCI_DM_VDC_MEASUREMENT_VALUE: Allow to measure the field applied on the
CLF antenna. A value between 0 and 0x0f is returned. 0 is maximum.
- HCI_DM_FWUPD_START: Allow to put CLF into firmware update mode. It is a
specific CLF command as there is no GPIO for this.
- HCI_DM_FWUPD_END:  Allow to complete firmware update.
- HCI_DM_VDC_VALUE_COMPARISON: Allow to compare the field applied on the
CLF antenna to a reference value.
- MANUFACTURER_SPECIFIC: Allow to retrieve manufacturer specific data
received during a NCI_CORE_INIT_CMD.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/Makefile  |   2 +-
 drivers/nfc/st-nci/core.c|  13 +-
 drivers/nfc/st-nci/se.c  |  29 ++-
 drivers/nfc/st-nci/st-nci.h  |  68 ++
 drivers/nfc/st-nci/vendor_cmds.c | 516 +++
 include/net/nfc/nci_core.h   |   1 +
 6 files changed, 619 insertions(+), 10 deletions(-)
 create mode 100644 drivers/nfc/st-nci/vendor_cmds.c

diff --git a/drivers/nfc/st-nci/Makefile b/drivers/nfc/st-nci/Makefile
index 594c63d..ea40ace 100644
--- a/drivers/nfc/st-nci/Makefile
+++ b/drivers/nfc/st-nci/Makefile
@@ -2,7 +2,7 @@
 # Makefile for ST21NFCB NCI based NFC driver
 #
 
-st-nci-objs = ndlc.o core.o se.o
+st-nci-objs = ndlc.o core.o se.o vendor_cmds.o
 obj-$(CONFIG_NFC_ST_NCI) += st-nci.o
 
 st-nci_i2c-objs = i2c.o
diff --git a/drivers/nfc/st-nci/core.c b/drivers/nfc/st-nci/core.c
index 96997e6..6b083ed 100644
--- a/drivers/nfc/st-nci/core.c
+++ b/drivers/nfc/st-nci/core.c
@@ -152,14 +152,23 @@ int st_nci_probe(struct llt_ndlc *ndlc, int phy_headroom,
 
nci_set_drvdata(ndlc->ndev, info);
 
+   r = st_nci_vendor_cmds_init(ndlc->ndev);
+   if (r) {
+   pr_err("Cannot register proprietary vendor cmds\n");
+   goto err_reg_dev;
+   }
+
r = nci_register_device(ndlc->ndev);
if (r) {
pr_err("Cannot register nfc device to nci core\n");
-   nci_free_device(ndlc->ndev);
-   return r;
+   goto err_reg_dev;
}
 
return st_nci_se_init(ndlc->ndev);
+
+err_reg_dev:
+   nci_free_device(ndlc->ndev);
+   return r;
 }
 EXPORT_SYMBOL_GPL(st_nci_probe);
 
diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 4c98346..7ec4dba 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -39,7 +39,6 @@ struct st_nci_pipe_info {
 #define ST_NCI_ESE_HOST_ID0xc0
 
 /* Gates */
-#define ST_NCI_DEVICE_MGNT_GATE   0x01
 #define ST_NCI_APDU_READER_GATE   0xf0
 #define ST_NCI_CONNECTIVITY_GATE  0x41
 
@@ -114,6 +113,8 @@ static struct nci_hci_gate st_nci_gates[] = {
 
{NCI_HCI_IDENTITY_MGMT_GATE, NCI_HCI_INVALID_PIPE,
ST_NCI_HOST_CONTROLLER_ID},
+   {NCI_HCI_LOOPBACK_GATE, NCI_HCI_INVALID_PIPE,
+   ST_NCI_HOST_CONTROLLER_ID},
 
/* Secure element pipes are created by secure element host */
{ST_NCI_CONNECTIVITY_GATE, NCI_HCI_DO_NOT_OPEN_PIPE,
@@ -376,8 +377,10 @@ void st_nci_hci_event_received(struct nci_dev *ndev, u8 
pipe,
st_nci_hci_apdu_reader_event_received(ndev, event, skb);
break;
case ST_NCI_CONNECTIVITY_GATE:
-   st_nci_hci_connectivity_event_received(ndev, host, event,
-skb);
+   st_nci_hci_connectivity_event_received(ndev, host, event, skb);
+   break;
+   case NCI_HCI_LOOPBACK_GATE:
+   st_nci_hci_loopback_event_received(ndev, event, skb);
break;
}
 }
@@ -509,6 +512,7 @@ 

[PATCH v2 33/35] nfc: st-nci: Make sure irq is not already active when powering the device

[Christophe Ricard]

Upon some conditions (timing, CLF errors, platform errors...), the irq might
be already active when powering the device.

Add irq_active variable as a guard to avoid kernel warning message

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/i2c.c | 8 +++-
 drivers/nfc/st-nci/spi.c | 8 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 2a96f1a..25e5042 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -50,6 +50,8 @@ struct st_nci_i2c_phy {
struct i2c_client *i2c_dev;
struct llt_ndlc *ndlc;
 
+   bool irq_active;
+
unsigned int gpio_reset;
unsigned int irq_polarity;
 
@@ -72,8 +74,10 @@ static int st_nci_i2c_enable(void *phy_id)
gpio_set_value(phy->gpio_reset, 1);
usleep_range(8, 85000);
 
-   if (phy->ndlc->powered == 0)
+   if (phy->ndlc->powered == 0 && phy->irq_active == 0) {
enable_irq(phy->i2c_dev->irq);
+   phy->irq_active = true;
+   }
 
return 0;
 }
@@ -83,6 +87,7 @@ static void st_nci_i2c_disable(void *phy_id)
struct st_nci_i2c_phy *phy = phy_id;
 
disable_irq_nosync(phy->i2c_dev->irq);
+   phy->irq_active = false;
 }
 
 /*
@@ -342,6 +347,7 @@ static int st_nci_i2c_probe(struct i2c_client *client,
return r;
}
 
+   phy->irq_active = true;
r = devm_request_threaded_irq(>dev, client->irq, NULL,
st_nci_irq_thread_fn,
phy->irq_polarity | IRQF_ONESHOT,
diff --git a/drivers/nfc/st-nci/spi.c b/drivers/nfc/st-nci/spi.c
index 8897203..bf6643c 100644
--- a/drivers/nfc/st-nci/spi.c
+++ b/drivers/nfc/st-nci/spi.c
@@ -51,6 +51,8 @@ struct st_nci_spi_phy {
struct spi_device *spi_dev;
struct llt_ndlc *ndlc;
 
+   bool irq_active;
+
unsigned int gpio_reset;
unsigned int irq_polarity;
 
@@ -73,8 +75,10 @@ static int st_nci_spi_enable(void *phy_id)
gpio_set_value(phy->gpio_reset, 1);
usleep_range(8, 85000);
 
-   if (phy->ndlc->powered == 0)
+   if (phy->ndlc->powered == 0 && phy->irq_active == 0) {
enable_irq(phy->spi_dev->irq);
+   phy->irq_active = true;
+   }
 
return 0;
 }
@@ -84,6 +88,7 @@ static void st_nci_spi_disable(void *phy_id)
struct st_nci_spi_phy *phy = phy_id;
 
disable_irq_nosync(phy->spi_dev->irq);
+   phy->irq_active = false;
 }
 
 /*
@@ -358,6 +363,7 @@ static int st_nci_spi_probe(struct spi_device *dev)
return r;
}
 
+   phy->irq_active = true;
r = devm_request_threaded_irq(>dev, dev->irq, NULL,
st_nci_irq_thread_fn,
phy->irq_polarity | IRQF_ONESHOT,
-- 
2.1.4

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

[PATCH v2 06/35] nfc: nci: Fix improper management of HCI return code

[Christophe Ricard]

When sending HCI data over NCI, HCI return code is part of the NCI data.
In order to get correctly the HCI return code, we assume the NCI
communication is successful and extract the return code for the nci_hci
functions return code.

This is done because nci_to_errno does not match hci return code value.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 net/nfc/nci/hci.c | 60 ---
 1 file changed, 44 insertions(+), 16 deletions(-)

diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index bc6b9d5..73afb47 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -101,6 +101,20 @@ struct nci_hcp_packet {
 #define NCI_HCP_MSG_GET_CMD(header)  (header & 0x3f)
 #define NCI_HCP_MSG_GET_PIPE(header) (header & 0x7f)
 
+static int nci_hci_result_to_errno(u8 result)
+{
+   switch (result) {
+   case NCI_HCI_ANY_OK:
+   return 0;
+   case NCI_HCI_ANY_E_REG_PAR_UNKNOWN:
+   return -EOPNOTSUPP;
+   case NCI_HCI_ANY_E_TIMEOUT:
+   return -ETIME;
+   default:
+   return -1;
+   }
+}
+
 /* HCI core */
 static void nci_hci_reset_pipes(struct nci_hci_dev *hdev)
 {
@@ -217,7 +231,8 @@ int nci_hci_send_cmd(struct nci_dev *ndev, u8 gate, u8 cmd,
 const u8 *param, size_t param_len,
 struct sk_buff **skb)
 {
-   struct nci_conn_info*conn_info;
+   struct nci_hcp_message *message;
+   struct nci_conn_info   *conn_info;
struct nci_data data;
int r;
u8 pipe = ndev->hci_dev->gate2pipe[gate];
@@ -237,9 +252,14 @@ int nci_hci_send_cmd(struct nci_dev *ndev, u8 gate, u8 cmd,
 
r = nci_request(ndev, nci_hci_send_data_req, (unsigned long),
msecs_to_jiffies(NCI_DATA_TIMEOUT));
+   if (r == NCI_STATUS_OK) {
+   message = (struct nci_hcp_message *)conn_info->rx_skb->data;
+   r = 
nci_hci_result_to_errno(NCI_HCP_MSG_GET_CMD(message->header));
+   skb_pull(conn_info->rx_skb, NCI_HCI_HCP_MESSAGE_HEADER_LEN);
 
-   if (r == NCI_STATUS_OK && skb)
-   *skb = conn_info->rx_skb;
+   if (!r && skb)
+   *skb = conn_info->rx_skb;
+   }
 
return r;
 }
@@ -333,9 +353,6 @@ static void nci_hci_resp_received(struct nci_dev *ndev, u8 
pipe,
struct nci_conn_info*conn_info;
u8 status = result;
 
-   if (result != NCI_HCI_ANY_OK)
-   goto exit;
-
conn_info = ndev->hci_dev->conn_info;
if (!conn_info) {
status = NCI_STATUS_REJECTED;
@@ -345,7 +362,7 @@ static void nci_hci_resp_received(struct nci_dev *ndev, u8 
pipe,
conn_info->rx_skb = skb;
 
 exit:
-   nci_req_complete(ndev, status);
+   nci_req_complete(ndev, NCI_STATUS_OK);
 }
 
 /* Receive hcp message for pipe, with type and cmd.
@@ -400,7 +417,7 @@ void nci_hci_data_received_cb(void *context,
 {
struct nci_dev *ndev = (struct nci_dev *)context;
struct nci_hcp_packet *packet;
-   u8 pipe, type, instruction;
+   u8 pipe, type;
struct sk_buff *hcp_skb;
struct sk_buff *frag_skb;
int msg_len;
@@ -439,7 +456,7 @@ void nci_hci_data_received_cb(void *context,
*skb_put(hcp_skb, NCI_HCI_HCP_PACKET_HEADER_LEN) = pipe;
 
skb_queue_walk(>hci_dev->rx_hcp_frags, frag_skb) {
-  msg_len = frag_skb->len - NCI_HCI_HCP_PACKET_HEADER_LEN;
+   msg_len = frag_skb->len - NCI_HCI_HCP_PACKET_HEADER_LEN;
memcpy(skb_put(hcp_skb, msg_len), frag_skb->data +
   NCI_HCI_HCP_PACKET_HEADER_LEN, msg_len);
}
@@ -457,11 +474,9 @@ void nci_hci_data_received_cb(void *context,
packet = (struct nci_hcp_packet *)hcp_skb->data;
type = NCI_HCP_MSG_GET_TYPE(packet->message.header);
if (type == NCI_HCI_HCP_RESPONSE) {
-   pipe = packet->header;
-   instruction = NCI_HCP_MSG_GET_CMD(packet->message.header);
-   skb_pull(hcp_skb, NCI_HCI_HCP_PACKET_HEADER_LEN +
-NCI_HCI_HCP_MESSAGE_HEADER_LEN);
-   nci_hci_hcp_message_rx(ndev, pipe, type, instruction, hcp_skb);
+   pipe = NCI_HCP_MSG_GET_PIPE(packet->header);
+   skb_pull(hcp_skb, NCI_HCI_HCP_PACKET_HEADER_LEN);
+   nci_hci_hcp_message_rx(ndev, pipe, type, NCI_STATUS_OK, 
hcp_skb);
} else {
skb_queue_tail(>hci_dev->msg_rx_queue, hcp_skb);
schedule_work(>hci_dev->msg_rx_work);
@@ -493,6 +508,7 @@ EXPORT_SYMBOL(nci_hci_open_pipe);
 int nci_hci_set_param(struct nci_dev *ndev, u8 gate, u8 idx,
  const u8 *param, size_t param_len)
 {
+   struct nci_hcp_message *message;
struct nci_conn_info *conn_info;
struct nci_data data;
int r;
@@ -525,6 +541,11 @@ 

[PATCH v2 17/35] nfc: st-nci: initialize gate_count in st_nci_hci_network_init

[Christophe Ricard]

When initializing ndev->hci_dev->init_data, only gates field was set.
gate_count needs to be initialized as well.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index df2dc54..11e49a5 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -536,6 +536,7 @@ static int st_nci_hci_network_init(struct nci_dev *ndev)
if (!conn_info)
goto free_dest_params;
 
+   ndev->hci_dev->init_data.gate_count = ARRAY_SIZE(st_nci_gates);
memcpy(ndev->hci_dev->init_data.gates, st_nci_gates,
   sizeof(st_nci_gates));
 
-- 
2.1.4

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

[PATCH v2 34/35] nfc: st-nci: remove duplicated skb dump

[Christophe Ricard]

Remove SPI_DUMP_SKB and I2C_DUMP_SKB as skb is already dumped in ndlc
layer.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/i2c.c | 11 ---
 drivers/nfc/st-nci/spi.c | 11 ---
 2 files changed, 22 deletions(-)

diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 25e5042..15e3ce2 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -58,13 +58,6 @@ struct st_nci_i2c_phy {
struct st_nci_se_status se_status;
 };
 
-#define I2C_DUMP_SKB(info, skb)\
-do {   \
-   pr_debug("%s:\n", info);\
-   print_hex_dump(KERN_DEBUG, "i2c: ", DUMP_PREFIX_OFFSET, \
-  16, 1, (skb)->data, (skb)->len, 0);  \
-} while (0)
-
 static int st_nci_i2c_enable(void *phy_id)
 {
struct st_nci_i2c_phy *phy = phy_id;
@@ -101,8 +94,6 @@ static int st_nci_i2c_write(void *phy_id, struct sk_buff 
*skb)
struct st_nci_i2c_phy *phy = phy_id;
struct i2c_client *client = phy->i2c_dev;
 
-   I2C_DUMP_SKB("st_nci_i2c_write", skb);
-
if (phy->ndlc->hard_fault != 0)
return phy->ndlc->hard_fault;
 
@@ -173,8 +164,6 @@ static int st_nci_i2c_read(struct st_nci_i2c_phy *phy,
skb_put(*skb, len);
memcpy((*skb)->data + ST_NCI_I2C_MIN_SIZE, buf, len);
 
-   I2C_DUMP_SKB("i2c frame read", *skb);
-
return 0;
 }
 
diff --git a/drivers/nfc/st-nci/spi.c b/drivers/nfc/st-nci/spi.c
index bf6643c..cf7ad81 100644
--- a/drivers/nfc/st-nci/spi.c
+++ b/drivers/nfc/st-nci/spi.c
@@ -59,13 +59,6 @@ struct st_nci_spi_phy {
struct st_nci_se_status se_status;
 };
 
-#define SPI_DUMP_SKB(info, skb)\
-do {   \
-   pr_debug("%s:\n", info);\
-   print_hex_dump(KERN_DEBUG, "spi: ", DUMP_PREFIX_OFFSET, \
-  16, 1, (skb)->data, (skb)->len, 0);  \
-} while (0)
-
 static int st_nci_spi_enable(void *phy_id)
 {
struct st_nci_spi_phy *phy = phy_id;
@@ -110,8 +103,6 @@ static int st_nci_spi_write(void *phy_id, struct sk_buff 
*skb)
.len = skb->len,
};
 
-   SPI_DUMP_SKB("st_nci_spi_write", skb);
-
if (phy->ndlc->hard_fault != 0)
return phy->ndlc->hard_fault;
 
@@ -188,8 +179,6 @@ static int st_nci_spi_read(struct st_nci_spi_phy *phy,
skb_put(*skb, len);
memcpy((*skb)->data + ST_NCI_SPI_MIN_SIZE, buf, len);
 
-   SPI_DUMP_SKB("spi frame read", *skb);
-
return 0;
 }
 
-- 
2.1.4

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

[PATCH v2 05/35] nfc: nci: Fix incorrect data chaining when sending data

[Christophe Ricard]

When sending HCI data over NCI, cmd information should be present only on
the first packet. Each packet shall be specifically allocated and sent to
the NCI layer.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 net/nfc/nci/hci.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 609f922..bc6b9d5 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -146,18 +146,18 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 
pipe,
if (!conn_info)
return -EPROTO;
 
-   skb = nci_skb_alloc(ndev, 2 + conn_info->max_pkt_payload_len +
+   i = 0;
+   skb = nci_skb_alloc(ndev, conn_info->max_pkt_payload_len +
NCI_DATA_HDR_SIZE, GFP_KERNEL);
if (!skb)
return -ENOMEM;
 
-   skb_reserve(skb, 2 + NCI_DATA_HDR_SIZE);
+   skb_reserve(skb, NCI_DATA_HDR_SIZE + 2);
*skb_push(skb, 1) = data_type;
 
-   i = 0;
-   len = conn_info->max_pkt_payload_len;
-
do {
+   len = conn_info->max_pkt_payload_len;
+
/* If last packet add NCI_HFP_NO_CHAINING */
if (i + conn_info->max_pkt_payload_len -
(skb->len + 1) >= data_len) {
@@ -177,9 +177,14 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,
return r;
 
i += len;
+
if (i < data_len) {
-   skb_trim(skb, 0);
-   skb_pull(skb, len);
+   skb = nci_skb_alloc(ndev, 
conn_info->max_pkt_payload_len +
+   NCI_DATA_HDR_SIZE, GFP_KERNEL);
+   if (!skb)
+   return -ENOMEM;
+
+   skb_reserve(skb, NCI_DATA_HDR_SIZE + 1);
}
} while (i < data_len);
 
-- 
2.1.4

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

[PATCH v2 29/35] nfc: st-nci: Add few code style fixes

[Christophe Ricard]

Add some few code style fixes.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/i2c.c | 2 +-
 drivers/nfc/st-nci/se.c  | 2 +-
 net/nfc/nci/hci.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 172cbc3..2a96f1a 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -32,7 +32,7 @@
 #define DRIVER_DESC "NCI NFC driver for ST_NCI"
 
 /* ndlc header */
-#define ST_NCI_FRAME_HEADROOM  1
+#define ST_NCI_FRAME_HEADROOM 1
 #define ST_NCI_FRAME_TAILROOM 0
 
 #define ST_NCI_I2C_MIN_SIZE 4   /* PCB(1) + NCI Packet header(3) */
diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 1cc24b6..dbab722 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -62,7 +62,7 @@ struct st_nci_pipe_info {
 
 #define ST_NCI_EVT_SE_HARD_RESET   0x20
 #define ST_NCI_EVT_TRANSMIT_DATA   0x10
-#define ST_NCI_EVT_WTX_REQUEST 0x11
+#define ST_NCI_EVT_WTX_REQUEST 0x11
 #define ST_NCI_EVT_SE_SOFT_RESET   0x11
 #define ST_NCI_EVT_SE_END_OF_APDU_TRANSFER 0x21
 #define ST_NCI_EVT_HOT_PLUG0x03
diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 1d6aa5d..984d451 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -405,7 +405,7 @@ static void nci_hci_hcp_message_rx(struct nci_dev *ndev, u8 
pipe,
break;
}
 
-   nci_req_complete(ndev, 0);
+   nci_req_complete(ndev, NCI_STATUS_OK);
 }
 
 static void nci_hci_msg_rx_work(struct work_struct *work)
-- 
2.1.4

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

[PATCH v2 04/35] nfc: st-nci: Fix incorrect spi buffer size

[Christophe Ricard]

When sending data over SPI, the maximum expected length is the maximum
nci packet payload + data header size + the frame head room (1 for the
ndlc header) + the frame trail room (0).

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/spi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nfc/st-nci/spi.c b/drivers/nfc/st-nci/spi.c
index 9a39871..b43f448 100644
--- a/drivers/nfc/st-nci/spi.c
+++ b/drivers/nfc/st-nci/spi.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "st-nci.h"
@@ -94,7 +95,8 @@ static int st_nci_spi_write(void *phy_id, struct sk_buff *skb)
struct st_nci_spi_phy *phy = phy_id;
struct spi_device *dev = phy->spi_dev;
struct sk_buff *skb_rx;
-   u8 buf[ST_NCI_SPI_MAX_SIZE];
+   u8 buf[ST_NCI_SPI_MAX_SIZE + NCI_DATA_HDR_SIZE +
+  ST_NCI_FRAME_HEADROOM + ST_NCI_FRAME_TAILROOM];
struct spi_transfer spi_xfer = {
.tx_buf = skb->data,
.rx_buf = buf,
-- 
2.1.4

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

[PATCH v2 16/35] nfc: st21nfca: Keep st21nfca_gates unchanged in load_session

[Christophe Ricard]

We need to keep initial st_nci_gates values in order for
nfc_hci_dev_connect_gates to create and open pipe when necessary.

For example after a firmware update CLF pipes are cleared. Changing pipe
values in st21nfca_gates was causing nfc_hci_dev_connect_gates not using
accurate pipes value.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index 819a94a..b4451f8 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -190,14 +190,14 @@ static int st21nfca_hci_load_session(struct nfc_hci_dev 
*hdev)
if (j < ARRAY_SIZE(st21nfca_gates) &&
st21nfca_gates[j].gate == info->dst_gate_id &&
ST21NFCA_DM_IS_PIPE_OPEN(info->pipe_state)) {
-   st21nfca_gates[j].pipe = pipe_info[2];
+   hdev->init_data.gates[j].pipe = pipe_info[2];
 
hdev->gate2pipe[st21nfca_gates[j].gate] =
-   st21nfca_gates[j].pipe;
-   hdev->pipes[st21nfca_gates[j].pipe].gate =
-   st21nfca_gates[j].gate;
-   hdev->pipes[st21nfca_gates[j].pipe].dest_host =
-   info->src_host_id;
+   pipe_info[2];
+   hdev->pipes[pipe_info[2]].gate =
+   st21nfca_gates[j].gate;
+   hdev->pipes[pipe_info[2]].dest_host =
+   info->src_host_id;
}
kfree_skb(skb_pipe_info);
}
-- 
2.1.4

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

[PATCH v2 12/35] nfc: st21nfca: Remove hdev->init_data.gates initialization in load_session

[Christophe Ricard]

hdev->init_data.gates is already initialized in st21nfca_hci_probe.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index 42f1974..67d1c27 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -218,7 +218,6 @@ static int st21nfca_hci_load_session(struct nfc_hci_dev 
*hdev)
}
}
 
-   memcpy(hdev->init_data.gates, st21nfca_gates, sizeof(st21nfca_gates));
 free_list:
kfree_skb(skb_pipe_list);
return r;
-- 
2.1.4

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

[PATCH v2 19/35] nfc: st-nci: Change st_nci_gates offset when looking for a pipe in the table

[Christophe Ricard]

It is useless to start from index 0 when looking for a gate because only
dynamic pipes are retrieved with ST_NCI_DM_GETINFO(ST_NCI_DM_GETINFO_PIPE_LIST).

The first dynamic pipe is present at index 3.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 5d1747d..4c98346 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -228,7 +228,7 @@ int st_nci_hci_load_session(struct nci_dev *ndev)
continue;
}
 
-   for (j = 0; (j < ARRAY_SIZE(st_nci_gates)) &&
+   for (j = 3; (j < ARRAY_SIZE(st_nci_gates)) &&
 (st_nci_gates[j].gate != dm_pipe_info->dst_gate_id); j++)
;
 
-- 
2.1.4

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

[PATCH v2 07/35] nfc: nci: extract pipe value using NCI_HCP_MSG_GET_PIPE

[Christophe Ricard]

When receiving data in nci_hci_msg_rx_work, extract pipe value using
NCI_HCP_MSG_GET_PIPE macro.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 net/nfc/nci/hci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 73afb47..abe0200 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -400,7 +400,7 @@ static void nci_hci_msg_rx_work(struct work_struct *work)
u8 pipe, type, instruction;
 
while ((skb = skb_dequeue(>msg_rx_queue)) != NULL) {
-   pipe = skb->data[0];
+   pipe = NCI_HCP_MSG_GET_PIPE(skb->data[0]);
skb_pull(skb, NCI_HCI_HCP_PACKET_HEADER_LEN);
message = (struct nci_hcp_message *)skb->data;
type = NCI_HCP_MSG_GET_TYPE(message->header);
@@ -437,7 +437,7 @@ void nci_hci_data_received_cb(void *context,
 
/* it's the last fragment. Does it need re-aggregation? */
if (skb_queue_len(>hci_dev->rx_hcp_frags)) {
-   pipe = packet->header & NCI_HCI_FRAGMENT;
+   pipe = NCI_HCP_MSG_GET_PIPE(packet->header);
skb_queue_tail(>hci_dev->rx_hcp_frags, skb);
 
msg_len = 0;
-- 
2.1.4

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

Re: [PATCH v4 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver

[Laurent Pinchart]

Hi Geert,

On Saturday 24 October 2015 19:34:03 Geert Uytterhoeven wrote:
> On Sat, Oct 24, 2015 at 3:10 AM, Stephen Boyd  wrote:
> > On 10/22, Geert Uytterhoeven wrote:
> >> On Tue, Oct 20, 2015 at 3:07 PM, Geert Uytterhoeven wrote:
> >>> On Tue, Oct 20, 2015 at 3:00 PM, Michael Turquette wrote:
>  Quoting Geert Uytterhoeven (2015-10-20 05:31:12)
> > On Tue, Oct 20, 2015 at 2:24 PM, Michael Turquette wrote:
>  The bindings should go in for 4.4, but if the driver is slated for 4.5
>  then can you investigate this some more? Stephen and I are on a
>  mission to have _real_ clk drivers.
> >>> 
> >>> Sure, I'll have a deeper look.
> >> 
> >> And so I did (on r8a7791/koelsch).
> >> 
> >> As I want to have as much clock data/code __init as possible (think
> >> multi-platform kernels --- pinmux data is a disaster here), I have to use
> >> platform_driver_probe().

That sounds like an __init issue, doesn't it ? The CPG driver will always be 
builtin and probed during the init process, what's preventing us from using 
normal driver probing ?

> >>   - Calling platform_driver_probe() from core_initcall() or
> >> postcore_initcall() is too early, as the platform device for the CPG
> >> hasn't been created yet. Hence the CPG Clock Domain isn't registered,
> >> and all devices fail to probe as they can't be attached to their
> >> Clock Domain.
> >> 
> >>   -> This is where the -ENOENT came from (I incorrectly assumed it
> >>  came from the clock code; sorry for that), and it's converted
> >>  into -EPROBE_DEFER by genpd_dev_pm_attach().
> >>   
> >>   - Calling platform_driver_probe() from arch_initcall() is too late, as
> >> the IRQC is initialized first (it's located before the CPG in .dtsi).
> >> Hence the IRQC can't find it's Clock Domain, and its probe is
> >> deferred. IRQC will be reprobed later, but in the mean time the
> >> Ethernet PHY can't find its IRQ, as the of_mdio code uses
> >> irq_of_parse_and_map(), which plainly ignores EPROBE_DEFER :-(
> >> Nevertheless, Ethernet works...
> >>   
> >>   - Using subsys_initcall() and later causes even more probe deferral.
> >> 
> >> So that's why I went with CLK_OF_DECLARE() again...
> > 
> > Understandable for the few clocks that are used by the interrupt
> > controller, but for the other clocks, could those be registered
> > from a real platform device driver probe path? I've been
> 
> In this particular case, that would be the IRQC module clocks and its
> parent, the CP clock, which is derived directly from the external crystal.
> 
> If we ever have to do this for the GIC, that's gonna be several more
> clocks (INTC-SYS / ZS / PLL1 / MAIN / external crystal).
> 
> > considering making some API that lets devices associate with the
> > clocks that the file had to register with CLK_OF_DECLARE(). The
> > driver would have to be builtin then (no modules) but otherwise
> > we would be able to benefit from the device driver model for most
> > other clocks.
> 
> To be honest, that still feels like a hack to me.
> 
> I hope dependencies and probe order, and obscure drivers not handling
> deferred probe correctly, will be solved later sooner or later,
> so hacks like that are no longer needed.
> 
> For new SoCs like r8a7795 we can probably just make it a real platform
> driver, and make sure the irqc node is located after the cpg node in the
> .dtsi.

That's another hack :-) We really shouldn't depend on DT nodes order.

I'm all for getting rid of CLK_OF_DECLARE

> Upon second thought, that may even be feasible for existing SoCs, as
> they would need a DTS update to make use of the new bindings/driver anyway,
> so the irqc node can be moved at the same time. Backwards compatibility
> through the old bindings/drivers would keep on using CLK_OF_DECLARE().

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Mark Brown]

On Mon, Oct 26, 2015 at 03:48:44AM +0100, Rafael J. Wysocki wrote:
> On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown  wrote:

> > Should we try to schedule an ad-hoc session today (Monday) for those of
> > us who are here to talk this over?

> I won't mind doing that, what about after the Linus+Dirk session?

It's looking hard to round people up...  I asked Ted for a slot
tomorrow, hopefully we can get one and if not it's probably going to be
easier to find everyone at once.


signature.asc
Description: PGP signature

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Rob Herring]

On 10/24/2015 08:55 AM, Rafael J. Wysocki wrote:
> On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
>> On 22 October 2015 at 03:06, Rafael J. Wysocki  wrote:
>>> On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
 Walks the OF tree up and finds the closest ancestor that has a struct
 device associated with it, probing it if isn't bound to a driver yet.

 The above should ensure that the dependency represented by the passed OF
 node is available, because probing a device should cause its descendants
 to be probed as well (when they get registered).

 Subsystems can use this when looking up resources for drivers, to reduce
 the chances of deferred probes because of the probing order of devices.

 Signed-off-by: Tomeu Vizoso 
 ---

 Changes in v5:
 - Move the assignment to device_node->device for AMBA devices to another
   commit.
 - Hold a reference to the struct device while it's in use in
   of_device_probe().

 Changes in v4:
 - Rename of_platform_probe to of_device_probe
 - Use device_node.device instead of device_node.platform_dev

 Changes in v3:
 - Set and use device_node.platform_dev instead of reversing the logic to
   find the platform device that encloses a device node.
 - Drop the fwnode API to probe firmware nodes and add OF-only API for
   now. I think this same scheme could be used for machines with ACPI,
   but I haven't been able to find one that had to defer its probes because
   of the device probe order.

  drivers/of/device.c   | 61 
 +++
  include/linux/of_device.h |  3 +++
  2 files changed, 64 insertions(+)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 8b91ea241b10..836be71fc90e 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, 
 struct kobj_uevent_env *env)

   return 0;
  }
 +
 +/**
 + * of_device_probe() - Probe device associated with OF node
 + * @np: node to probe
 + *
 + * Probe the device associated with the passed device node.
 + */
 +void of_device_probe(struct device_node *np)
>>>
>>> Same question as from Greg: How does a subsystem know whether or not to use
>>> this function?
>>
>> Maybe I don't understand the comment, but as the commit message says,
>> subsystems can use this when looking up resources for drivers. Or you
>> mean that this information should be in the API docs?
> 
> I'm not really sure this is the only case.
> 
> Most likely, you'd end up with that being called by every subsystem using DT
> just in case.

No, it is binding dependent. If a consumer is looking up the provider
from the binding, then yes it needs a call. There may be some cases
where it doesn't make sense. But that is why it is called from the
binding specific code.

> And then each of those subsystems would need to call acpi_device_probe(), and
> then another_platform_firmware_interface_device_probe() and so on.
> 
> Don't you see a problem here?

Only for the 3rd firmware interface. ;)

Let's get agreement on the flow and structure and how to address other
issues like suspend, then we can worry about whether this needs to be
abstracted from subsystems. We can discuss more this week at KS.

Rob

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

[PATCH v5 2/8] clk: rockchip: add dt-binding header for rk3036

[Xing Zheng]

Add the dt-bindings header for the rk3036, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v5: None

 include/dt-bindings/clock/rk3036-cru.h |  195 
 1 file changed, 195 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/include/dt-bindings/clock/rk3036-cru.h 
b/include/dt-bindings/clock/rk3036-cru.h
new file mode 100644
index 000..b0da216
--- /dev/null
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+
+/* core clocks */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_GPLL   3
+#define ARMCLK 4
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU   64
+#define SCLK_SPI   65
+#define SCLK_SDMMC 68
+#define SCLK_SDIO  69
+#define SCLK_EMMC  71
+#define SCLK_NANDC 76
+#define SCLK_UART0 77
+#define SCLK_UART1 78
+#define SCLK_UART2 79
+#define SCLK_I2S   82
+#define SCLK_SPDIF 83
+#define SCLK_TIMER085
+#define SCLK_TIMER186
+#define SCLK_TIMER287
+#define SCLK_TIMER388
+#define SCLK_OTGPHY0   93
+#define SCLK_LCDC  100
+#define SCLK_HDMI  109
+#define SCLK_HEVC  111
+#define SCLK_I2S_OUT   113
+#define SCLK_SDMMC_DRV 114
+#define SCLK_SDIO_DRV  115
+#define SCLK_EMMC_DRV  117
+#define SCLK_SDMMC_SAMPLE  118
+#define SCLK_SDIO_SAMPLE   119
+#define SCLK_EMMC_SAMPLE   121
+#define SCLK_PVTM_CORE  123
+#define SCLK_PVTM_GPU   124
+#define SCLK_PVTM_VIDEO 125
+#define SCLK_MAC   151
+#define SCLK_MACREF152
+#define SCLK_SFC   160
+
+#define DCLK_LCDC  190
+
+/* aclk gates */
+#define ACLK_DMAC2 194
+#define ACLK_LCDC  197
+#define ACLK_VIO   203
+#define ACLK_VCODEC208
+#define ACLK_CPU   209
+#define ACLK_PERI  210
+
+/* pclk gates */
+#define PCLK_GPIO0 320
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GRF   329
+#define PCLK_I2C0  332
+#define PCLK_I2C1  333
+#define PCLK_I2C2  334
+#define PCLK_SPI   338
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_PWM   350
+#define PCLK_TIMER 353
+#define PCLK_HDMI  360
+#define PCLK_CPU   362
+#define PCLK_PERI  363
+#define PCLK_DDRUPCTL  364
+#define PCLK_WDT   368
+#define PCLK_ACODEC369
+
+/* hclk gates */
+#define HCLK_OTG0  449
+#define HCLK_OTG1  450
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO  457
+#define HCLK_EMMC  459
+#define HCLK_I2S   462
+#define HCLK_LCDC  465
+#define HCLK_ROM   467
+#define HCLK_VIO_BUS   472
+#define HCLK_VCODEC476
+#define HCLK_CPU   477
+#define HCLK_PERI  478
+
+#define CLK_NR_CLKS(HCLK_PERI + 1)
+
+/* soft-reset indices */
+#define SRST_CORE0 0
+#define SRST_CORE1 1
+#define SRST_CORE0_DBG 4
+#define SRST_CORE1_DBG 5
+#define SRST_CORE0_POR 8
+#define SRST_CORE1_POR 9
+#define SRST_L2C   12
+#define SRST_TOPDBG13
+#define SRST_STRC_SYS_A14
+#define SRST_PD_CORE_NIU   15
+
+#define SRST_TIMER216
+#define SRST_CPUSYS_H  17
+#define SRST_AHB2APB_H 19
+#define SRST_TIMER320
+#define SRST_INTMEM21
+#define SRST_ROM   22
+#define SRST_PERI_NIU  23
+#define SRST_I2S   24
+#define SRST_DDR_PLL   25
+#define SRST_GPU_DLL   26
+#define SRST_TIMER027
+#define SRST_TIMER1 

[PATCH v5 1/8] dt-bindings: add documentation of rk3036 clock controller

[Xing Zheng]

Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v5: None

 .../bindings/clock/rockchip,rk3036-cru.txt |   56 
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt 
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
new file mode 100644
index 000..ace0599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,56 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+   cru: cru@2000 {
+   compatible = "rockchip,rk3036-cru";
+   reg = <0x2000 0x1000>;
+   rockchip,grf = <>;
+
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+   uart0: serial@2006 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x2006 0x100>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < SCLK_UART0>;
+   };
-- 
1.7.9.5


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

[PATCH v2 30/35] nfc: st21nfca: Add few code style fixes

[Christophe Ricard]

Add a minor code style fixes

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 2 --
 drivers/nfc/st21nfca/i2c.c  | 1 +
 drivers/nfc/st21nfca/se.c   | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index 814d8ff4..6fc60bb 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -162,7 +162,6 @@ static int st21nfca_hci_load_session(struct nfc_hci_dev 
*hdev)
r = nfc_hci_send_cmd(hdev, ST21NFCA_DEVICE_MGNT_GATE,
ST21NFCA_DM_GETINFO, pipe_info,
sizeof(pipe_info), _pipe_info);
-
if (r)
continue;
 
@@ -982,7 +981,6 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
 * persistent info to discriminate 2 identical chips
 */
dev_num = find_first_zero_bit(dev_mask, ST21NFCA_NUM_DEVICES);
-
if (dev_num >= ST21NFCA_NUM_DEVICES)
return -ENODEV;
 
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index b2c914b..84c2cb0 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -94,6 +94,7 @@ struct st21nfca_i2c_phy {
int hard_fault;
struct mutex phy_lock;
 };
+
 static u8 len_seq[] = { 16, 24, 12, 29 };
 static u16 wait_tab[] = { 2, 3, 5, 15, 20, 40};
 
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 8e05d73..d3347c7 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -19,7 +19,7 @@
 #include "st21nfca.h"
 
 #define ST21NFCA_EVT_UICC_ACTIVATE 0x10
-#define ST21NFCA_EVT_UICC_DEACTIVATE   0x13
+#define ST21NFCA_EVT_UICC_DEACTIVATE   0x13
 #define ST21NFCA_EVT_SE_HARD_RESET 0x20
 #define ST21NFCA_EVT_SE_SOFT_RESET 0x11
 #define ST21NFCA_EVT_SE_END_OF_APDU_TRANSFER   0x21
-- 
2.1.4

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

[PATCH v2 32/35] nfc: st21nfca: Add error messages when an unexpected HCI event occurs

[Christophe Ricard]

Potentially an unexpected HCI event may occur because of a firmware bug.
It could be transparent for the user but at least log this.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/core.c | 2 ++
 drivers/nfc/st21nfca/dep.c  | 1 +
 drivers/nfc/st21nfca/se.c   | 4 
 3 files changed, 7 insertions(+)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index d36e290..dd8b150 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -893,6 +893,8 @@ static int st21nfca_admin_event_received(struct nfc_hci_dev 
*hdev, u8 event,
}
}
break;
+   default:
+   nfc_err(>ndev->dev, "Unexpected event on admin gate\n");
}
kfree_skb(skb);
return 0;
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index c011712..798a32b 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -435,6 +435,7 @@ int st21nfca_dep_event_received(struct nfc_hci_dev *hdev,
return r;
return 0;
default:
+   nfc_err(>ndev->dev, "Unexpected event on card f gate\n");
return 1;
}
kfree_skb(skb);
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index e04f603..85fe3cc 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -344,6 +344,7 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
default:
+   nfc_err(>ndev->dev, "Unexpected event on connectivity 
gate\n");
return 1;
}
kfree_skb(skb);
@@ -375,6 +376,9 @@ int st21nfca_apdu_reader_event_received(struct nfc_hci_dev 
*hdev,
mod_timer(>se_info.bwi_timer, jiffies +
msecs_to_jiffies(info->se_info.wt_timeout));
break;
+   default:
+   nfc_err(>nfc_dev->dev, "Unexpected event on apdu reader 
gate\n");
+   return 1;
}
 
 exit:
-- 
2.1.4

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

[PATCH v2 31/35] nfc: st21nfca: Add support for proprietary commands for factory tests

[Christophe Ricard]

Add support for proprietary commands useful mainly for factory testings.
Here is a list:
- FACTORY_MODE: Allow to set the driver into a mode where no secure element
are activated. It does not consider any NFC_ATTR_VENDOR_DATA.
- HCI_CLEAR_ALL_PIPES: Allow to execute a HCI clear all pipes command.
It does not consider any NFC_ATTR_VENDOR_DATA.
- HCI_DM_PUT_DATA: Allow to configure specific CLF registry as for example
RF trimmings or low level drivers configurations (I2C, SPI, SWP).
- HCI_DM_UPDATE_AID: Allow to configure an AID routing into the CLF routing
table following RF technology, CLF mode or protocol.
- HCI_DM_GET_INFO: Allow to retrieve CLF information.
- HCI_DM_GET_DATA: Allow to retrieve CLF configurable data such as low
level drivers configurations or RF trimmings.
- HCI_DM_LOAD: Allow to load a firmware into the CLF. A complete
packet can be more than 8KB.
- HCI_DM_RESET: Allow to run a CLF reset in order to "commit" CLF
configuration changes without CLF power off.
-  HCI_GET_PARAM: Allow to retrieve an HCI CLF parameter (for example the
white list).
- HCI_DM_FIELD_GENERATOR: Allow to generate different kind of RF
technology. When using this command to anti-collision is done.
- HCI_LOOPBACK: Allow to echo a command and test the Dh to CLF
connectivity.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/Makefile  |   2 +-
 drivers/nfc/st21nfca/core.c|   3 +
 drivers/nfc/st21nfca/se.c  |   4 +-
 drivers/nfc/st21nfca/st21nfca.h|  54 +-
 drivers/nfc/st21nfca/vendor_cmds.c | 370 +
 5 files changed, 430 insertions(+), 3 deletions(-)
 create mode 100644 drivers/nfc/st21nfca/vendor_cmds.c

diff --git a/drivers/nfc/st21nfca/Makefile b/drivers/nfc/st21nfca/Makefile
index 82434c3..ded6489 100644
--- a/drivers/nfc/st21nfca/Makefile
+++ b/drivers/nfc/st21nfca/Makefile
@@ -2,7 +2,7 @@
 # Makefile for ST21NFCA HCI based NFC driver
 #
 
-st21nfca_hci-objs = core.o dep.o se.o
+st21nfca_hci-objs = core.o dep.o se.o vendor_cmds.o
 obj-$(CONFIG_NFC_ST21NFCA) += st21nfca_hci.o
 
 st21nfca_i2c-objs  = i2c.o
diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index 6fc60bb..d36e290 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -921,6 +921,8 @@ static int st21nfca_hci_event_received(struct nfc_hci_dev 
*hdev, u8 pipe,
event, skb);
case ST21NFCA_APDU_READER_GATE:
return st21nfca_apdu_reader_event_received(hdev, event, skb);
+   case NFC_HCI_LOOPBACK_GATE:
+   return st21nfca_hci_loopback_event_received(hdev, event, skb);
default:
return 1;
}
@@ -1022,6 +1024,7 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
*hdev = info->hdev;
st21nfca_dep_init(info->hdev);
st21nfca_se_init(info->hdev);
+   st21nfca_vendor_cmds_init(info->hdev);
 
return 0;
 
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index d3347c7..e04f603 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -167,6 +167,9 @@ int st21nfca_hci_discover_se(struct nfc_hci_dev *hdev)
struct st21nfca_hci_info *info = nfc_hci_get_clientdata(hdev);
int se_count = 0;
 
+   if (test_bit(ST21NFCA_FACTORY_MODE, >quirks))
+   return 0;
+
if (info->se_status->is_uicc_present) {
nfc_add_se(hdev->ndev, NFC_HCI_UICC_HOST_ID, NFC_SE_UICC);
se_count++;
@@ -191,7 +194,6 @@ int st21nfca_hci_enable_se(struct nfc_hci_dev *hdev, u32 
se_idx)
 * Same for eSE.
 */
r = st21nfca_hci_control_se(hdev, se_idx, ST21NFCA_SE_MODE_ON);
-
if (r == ST21NFCA_ESE_HOST_ID) {
st21nfca_se_get_atr(hdev);
r = nfc_hci_send_event(hdev, ST21NFCA_APDU_READER_GATE,
diff --git a/drivers/nfc/st21nfca/st21nfca.h b/drivers/nfc/st21nfca/st21nfca.h
index 70e2d43..94ffb05 100644
--- a/drivers/nfc/st21nfca/st21nfca.h
+++ b/drivers/nfc/st21nfca/st21nfca.h
@@ -66,6 +66,9 @@
 #define ST21NFCA_HCI_MODE  0
 #define ST21NFCA_NUM_DEVICES   256
 
+#define ST21NFCA_VENDOR_OUI0x0080E1 /* STMicroelectronics */
+#define ST21NFCA_FACTORY_MODE  2
+
 struct st21nfca_se_status {
bool is_ese_present;
bool is_uicc_present;
@@ -76,6 +79,50 @@ enum st21nfca_state {
ST21NFCA_ST_READY,
 };
 
+/**
+ * enum nfc_vendor_cmds - supported nfc vendor commands
+ *
+ * @FACTORY_MODE: Allow to set the driver into a mode where no secure element
+ * are activated. It does not consider any NFC_ATTR_VENDOR_DATA.
+ * @HCI_CLEAR_ALL_PIPES: Allow to execute a HCI clear all pipes command.
+ * It does not consider any NFC_ATTR_VENDOR_DATA.
+ * @HCI_DM_PUT_DATA: Allow to configure specific CLF registry as for example
+ * RF trimmings or low level drivers configurations (I2C, 

[PATCH v2 15/35] nfc: st-nci: Keep st_nci_gates unchanged in load_session

[Christophe Ricard]

We need to keep initial st_nci_gates values in order for
nci_hci_dev_connect_gates to create and open pipe when necessary.

For example after a firmware update CLF pipes are cleared. Changing pipe
values in st_nci_gates was causing nci_hci_dev_connect_gates not using
accurate pipes value.

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 3522165..df2dc54 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -232,13 +232,13 @@ int st_nci_hci_load_session(struct nci_dev *ndev)
if (j < ARRAY_SIZE(st_nci_gates) &&
st_nci_gates[j].gate == dm_pipe_info->dst_gate_id &&
ST_NCI_DM_IS_PIPE_OPEN(dm_pipe_info->pipe_state)) {
-   st_nci_gates[j].pipe = pipe_info[2];
+   ndev->hci_dev->init_data.gates[j].pipe = pipe_info[2];
 
ndev->hci_dev->gate2pipe[st_nci_gates[j].gate] =
-   st_nci_gates[j].pipe;
-   ndev->hci_dev->pipes[st_nci_gates[j].pipe].gate =
+   pipe_info[2];
+   ndev->hci_dev->pipes[pipe_info[2]].gate =
st_nci_gates[j].gate;
-   ndev->hci_dev->pipes[st_nci_gates[j].pipe].host =
+   ndev->hci_dev->pipes[pipe_info[2]].host =
dm_pipe_info->src_host_id;
}
kfree_skb(skb_pipe_info);
-- 
2.1.4

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

[PATCH v2 35/35] nfc: st-nci: Replace st21nfcb by st_nci in makefile

[Christophe Ricard]

Replace 1 missing st21nfcb by st_nci

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/st-nci/Makefile b/drivers/nfc/st-nci/Makefile
index ea40ace..439b2fa 100644
--- a/drivers/nfc/st-nci/Makefile
+++ b/drivers/nfc/st-nci/Makefile
@@ -1,5 +1,5 @@
 #
-# Makefile for ST21NFCB NCI based NFC driver
+# Makefile for ST_NCI NCI based NFC driver
 #
 
 st-nci-objs = ndlc.o core.o se.o vendor_cmds.o
-- 
2.1.4

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

[PATCH v2 24/35] nfc: st-nci: Add ese-present/uicc-present dts properties

[Christophe Ricard]

In order to align with st21nfca, dts configuration properties ese_present
and uicc_present are made available in st-nci driver.

So far, in early development firmware, because nci_nfcee_mode_set(DISABLE)
was not supported pushed us to try to enable during the secure element
discovery phase.

After several trials on commercial and qualified firmware it appears that
nci_nfcee_mode_set(ENABLE) and nci_nfcee_mode_set(DISABLE) are properly
supported.

Such feature also help us to eventually save some time (~5ms) if only
one secure element is connected.

Acked-by: Rob Herring 
Signed-off-by: Christophe Ricard 
---
 .../devicetree/bindings/net/nfc/st-nci-i2c.txt |  7 ++
 .../devicetree/bindings/net/nfc/st-nci-spi.txt |  9 +-
 drivers/nfc/st-nci/core.c  |  4 +-
 drivers/nfc/st-nci/i2c.c   | 12 ++-
 drivers/nfc/st-nci/ndlc.c  |  6 +-
 drivers/nfc/st-nci/ndlc.h  |  5 +-
 drivers/nfc/st-nci/se.c| 98 ++
 drivers/nfc/st-nci/spi.c   | 12 ++-
 drivers/nfc/st-nci/st-nci.h| 13 ++-
 include/linux/platform_data/st-nci.h   |  2 +
 10 files changed, 122 insertions(+), 46 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt 
b/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt
index d707588..263732e 100644
--- a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt
+++ b/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt
@@ -11,6 +11,10 @@ Required properties:
 Optional SoC Specific Properties:
 - pinctrl-names: Contains only one value - "default".
 - pintctrl-0: Specifies the pin control groups used for this controller.
+- ese-present: Specifies that an ese is physically connected to the nfc
+controller.
+- uicc-present: Specifies that the uicc swp signal can be physically
+connected to the nfc controller.
 
 Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2):
 
@@ -29,5 +33,8 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2):
interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
 
reset-gpios = < 29 GPIO_ACTIVE_HIGH>;
+
+   ese-present;
+   uicc-present;
};
 };
diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt 
b/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt
index 525681b..711ca85 100644
--- a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt
+++ b/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt
@@ -2,7 +2,7 @@
 
 Required properties:
 - compatible: Should be "st,st21nfcb-spi"
-- spi-max-frequency: Maximum SPI frequency (<= 1000).
+- spi-max-frequency: Maximum SPI frequency (<= 400).
 - interrupt-parent: phandle for the interrupt gpio controller
 - interrupts: GPIO interrupt to which the chip is connected
 - reset-gpios: Output GPIO pin used to reset the ST21NFCB
@@ -10,6 +10,10 @@ Required properties:
 Optional SoC Specific Properties:
 - pinctrl-names: Contains only one value - "default".
 - pintctrl-0: Specifies the pin control groups used for this controller.
+- ese-present: Specifies that an ese is physically connected to the nfc
+controller.
+- uicc-present: Specifies that the uicc swp signal can be physically
+connected to the nfc controller.
 
 Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4):
 
@@ -27,5 +31,8 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4):
interrupts = <2 IRQ_TYPE_EDGE_RISING>;
 
reset-gpios = < 29 GPIO_ACTIVE_HIGH>;
+
+   ese-present;
+   uicc-present;
};
 };
diff --git a/drivers/nfc/st-nci/core.c b/drivers/nfc/st-nci/core.c
index 6b083ed..ccf7237 100644
--- a/drivers/nfc/st-nci/core.c
+++ b/drivers/nfc/st-nci/core.c
@@ -123,7 +123,7 @@ static struct nci_ops st_nci_ops = {
 };
 
 int st_nci_probe(struct llt_ndlc *ndlc, int phy_headroom,
-  int phy_tailroom)
+int phy_tailroom, struct st_nci_se_status *se_status)
 {
struct st_nci_info *info;
int r;
@@ -164,7 +164,7 @@ int st_nci_probe(struct llt_ndlc *ndlc, int phy_headroom,
goto err_reg_dev;
}
 
-   return st_nci_se_init(ndlc->ndev);
+   return st_nci_se_init(ndlc->ndev, se_status);
 
 err_reg_dev:
nci_free_device(ndlc->ndev);
diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 02e585f..172cbc3 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -52,6 +52,8 @@ struct st_nci_i2c_phy {
 
unsigned int gpio_reset;
unsigned int irq_polarity;
+
+   struct st_nci_se_status se_status;
 };
 
 #define I2C_DUMP_SKB(info, skb)\
@@ -245,6 +247,11 @@ static int st_nci_i2c_of_request_resources(struct 
i2c_client *client)
 
phy->irq_polarity = 

[PATCH v2 23/35] nfc: netlink: Add missing NFC_ATTR comments

[Christophe Ricard]

NFC_CMD_ACTIVATE_TARGET and NFC_ATTR_SE_PARAMS comments are missing.

Signed-off-by: Christophe Ricard 
---
 include/uapi/linux/nfc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
index dd3f753..399f39f 100644
--- a/include/uapi/linux/nfc.h
+++ b/include/uapi/linux/nfc.h
@@ -86,6 +86,7 @@
  * for this event is the application ID (AID).
  * @NFC_CMD_GET_SE: Dump all discovered secure elements from an NFC controller.
  * @NFC_CMD_SE_IO: Send/Receive APDUs to/from the selected secure element.
+ * @NFC_CMD_ACTIVATE_TARGET: Request NFC controller to reactivate target.
  * @NFC_CMD_VENDOR: Vendor specific command, to be implemented directly
  * from the driver in order to support hardware specific operations.
  */
@@ -156,6 +157,7 @@ enum nfc_commands {
  * @NFC_ATTR_APDU: Secure element APDU
  * @NFC_ATTR_TARGET_ISO15693_DSFID: ISO 15693 Data Storage Format Identifier
  * @NFC_ATTR_TARGET_ISO15693_UID: ISO 15693 Unique Identifier
+ * @NFC_ATTR_SE_PARAMS: Parameters data from an evt_transaction
  * @NFC_ATTR_VENDOR_ID: NFC manufacturer unique ID, typically an OUI
  * @NFC_ATTR_VENDOR_SUBCMD: Vendor specific sub command
  * @NFC_ATTR_VENDOR_DATA: Vendor specific data, to be optionally passed
-- 
2.1.4

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

[PATCH v2 26/35] nfc: st-nci: Fix host_list verification after secure element activation

[Christophe Ricard]

A secure element can be activated in different order. The host_list is
updated keeping a fixed order: .

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 3059baa..1cc24b6 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -423,7 +423,7 @@ static int st_nci_control_se(struct nci_dev *ndev, u8 
se_idx,
 u8 state)
 {
struct st_nci_info *info = nci_get_drvdata(ndev);
-   int r;
+   int r, i;
struct sk_buff *sk_host_list;
u8 host_id;
 
@@ -470,7 +470,10 @@ static int st_nci_control_se(struct nci_dev *ndev, u8 
se_idx,
if (r != NCI_HCI_ANY_OK)
return r;
 
-   host_id = sk_host_list->data[sk_host_list->len - 1];
+   for (i = 0; i < sk_host_list->len &&
+   sk_host_list->data[i] != se_idx; i++)
+   ;
+   host_id = sk_host_list->data[i];
kfree_skb(sk_host_list);
if (state == ST_NCI_SE_MODE_ON && host_id == se_idx)
return se_idx;
-- 
2.1.4

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

[PATCH v2 27/35] nfc: st21nfca: Fix host_list verification after secure element activation

[Christophe Ricard]

A secure element can be activated in different order. The host_list is
updated keeping a fixed order: .

Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st21nfca/se.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 6aa4e34..8e05d73 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -100,7 +100,7 @@ static int st21nfca_hci_control_se(struct nfc_hci_dev 
*hdev, u32 se_idx,
u8 state)
 {
struct st21nfca_hci_info *info = nfc_hci_get_clientdata(hdev);
-   int r;
+   int r, i;
struct sk_buff *sk_host_list;
u8 se_event, host_id;
 
@@ -148,7 +148,10 @@ static int st21nfca_hci_control_se(struct nfc_hci_dev 
*hdev, u32 se_idx,
if (r < 0)
return r;
 
-   host_id = sk_host_list->data[sk_host_list->len - 1];
+   for (i = 0; i < sk_host_list->len &&
+   sk_host_list->data[i] != se_idx; i++)
+   ;
+   host_id = sk_host_list->data[i];
kfree_skb(sk_host_list);
 
if (state == ST21NFCA_SE_MODE_ON && host_id == se_idx)
-- 
2.1.4

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

[PATCH v2 28/35] nfc: netlink: Add mode parameter to deactivate_target functions

[Christophe Ricard]

In order to manage in a better way the nci poll mode state machine, add
mode parameter to deactivate_target functions. This way we can manage
different target state. mode parameter make sense only in nci core.

Signed-off-by: Christophe Ricard 
---
 include/net/nfc/nfc.h  |  2 +-
 net/nfc/core.c |  4 ++--
 net/nfc/digital_core.c |  3 ++-
 net/nfc/hci/core.c |  3 ++-
 net/nfc/nci/core.c | 15 +++
 net/nfc/netlink.c  |  2 +-
 net/nfc/nfc.h  |  5 -
 net/nfc/rawsock.c  |  3 ++-
 8 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/include/net/nfc/nfc.h b/include/net/nfc/nfc.h
index 30afc9a..dcfcfc9 100644
--- a/include/net/nfc/nfc.h
+++ b/include/net/nfc/nfc.h
@@ -68,7 +68,7 @@ struct nfc_ops {
int (*activate_target)(struct nfc_dev *dev, struct nfc_target *target,
   u32 protocol);
void (*deactivate_target)(struct nfc_dev *dev,
- struct nfc_target *target);
+ struct nfc_target *target, u8 mode);
int (*im_transceive)(struct nfc_dev *dev, struct nfc_target *target,
 struct sk_buff *skb, data_exchange_cb_t cb,
 void *cb_context);
diff --git a/net/nfc/core.c b/net/nfc/core.c
index cff3f16..1fe3d3b 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -449,7 +449,7 @@ error:
  * @dev: The nfc device that found the target
  * @target_idx: index of the target that must be deactivated
  */
-int nfc_deactivate_target(struct nfc_dev *dev, u32 target_idx)
+int nfc_deactivate_target(struct nfc_dev *dev, u32 target_idx, u8 mode)
 {
int rc = 0;
 
@@ -476,7 +476,7 @@ int nfc_deactivate_target(struct nfc_dev *dev, u32 
target_idx)
if (dev->ops->check_presence)
del_timer_sync(>check_pres_timer);
 
-   dev->ops->deactivate_target(dev, dev->active_target);
+   dev->ops->deactivate_target(dev, dev->active_target, mode);
dev->active_target = NULL;
 
 error:
diff --git a/net/nfc/digital_core.c b/net/nfc/digital_core.c
index 009bcf3..23c2a11 100644
--- a/net/nfc/digital_core.c
+++ b/net/nfc/digital_core.c
@@ -631,7 +631,8 @@ static int digital_activate_target(struct nfc_dev *nfc_dev,
 }
 
 static void digital_deactivate_target(struct nfc_dev *nfc_dev,
- struct nfc_target *target)
+ struct nfc_target *target,
+ u8 mode)
 {
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
 
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index 6e061da..2b0f0ac 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -678,7 +678,8 @@ static int hci_activate_target(struct nfc_dev *nfc_dev,
 }
 
 static void hci_deactivate_target(struct nfc_dev *nfc_dev,
- struct nfc_target *target)
+ struct nfc_target *target,
+ u8 mode)
 {
 }
 
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 0909720..b7f548b 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -802,9 +802,11 @@ static int nci_activate_target(struct nfc_dev *nfc_dev,
 }
 
 static void nci_deactivate_target(struct nfc_dev *nfc_dev,
- struct nfc_target *target)
+ struct nfc_target *target,
+ __u8 mode)
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
+   u8 nci_mode = NCI_DEACTIVATE_TYPE_IDLE_MODE;
 
pr_debug("entry\n");
 
@@ -815,9 +817,14 @@ static void nci_deactivate_target(struct nfc_dev *nfc_dev,
 
ndev->target_active_prot = 0;
 
+   switch (mode) {
+   case NFC_TARGET_MODE_SLEEP:
+   nci_mode = NCI_DEACTIVATE_TYPE_SLEEP_MODE;
+   break;
+   }
+
if (atomic_read(>state) == NCI_POLL_ACTIVE) {
-   nci_request(ndev, nci_rf_deactivate_req,
-   NCI_DEACTIVATE_TYPE_IDLE_MODE,
+   nci_request(ndev, nci_rf_deactivate_req, nci_mode,
msecs_to_jiffies(NCI_RF_DEACTIVATE_TIMEOUT));
}
 }
@@ -851,7 +858,7 @@ static int nci_dep_link_down(struct nfc_dev *nfc_dev)
pr_debug("entry\n");
 
if (nfc_dev->rf_mode == NFC_RF_INITIATOR) {
-   nci_deactivate_target(nfc_dev, NULL);
+   nci_deactivate_target(nfc_dev, NULL, 
NCI_DEACTIVATE_TYPE_IDLE_MODE);
} else {
if (atomic_read(>state) == NCI_LISTEN_ACTIVE ||
atomic_read(>state) == NCI_DISCOVERY) {
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index f040532..f58c1fb 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -885,7 +885,7 @@ static int nfc_genl_activate_target(struct sk_buff *skb, 
struct genl_info *info)
target_idx = nla_get_u32(info->attrs[NFC_ATTR_TARGET_INDEX]);

[PATCH v2 25/35] nfc: st-nci: Increase waiting time between 2 secure element activation

[Christophe Ricard]

After internal discussion, it appears this timing should be increase to
20 ms for interoperability reason.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 147e2d9..3059baa 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -463,7 +463,7 @@ static int st_nci_control_se(struct nci_dev *ndev, u8 
se_idx,
 */
if (info->se_info.se_status->is_ese_present &&
info->se_info.se_status->is_uicc_present)
-   usleep_range(3000, 5000);
+   usleep_range(15000, 2);
 
r = nci_hci_get_param(ndev, NCI_HCI_ADMIN_GATE,
NCI_HCI_ADMIN_PARAM_HOST_LIST, _host_list);
-- 
2.1.4

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

[PATCH v2 22/35] nfc: st-nci: Add error messages when an unexpected HCI event occurs

[Christophe Ricard]

Potentially an unexpected HCI event may occur because of a firmware bug.
It could be transparent for the user but at least log this.

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/se.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 7ec4dba..2812884 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -280,6 +280,8 @@ static void st_nci_hci_admin_event_received(struct nci_dev 
*ndev,
}
}
break;
+   default:
+   nfc_err(>nfc_dev->dev, "Unexpected event on admin 
gate\n");
}
 }
 
@@ -303,6 +305,9 @@ static int st_nci_hci_apdu_reader_event_received(struct 
nci_dev *ndev,
mod_timer(>se_info.bwi_timer, jiffies +
  msecs_to_jiffies(info->se_info.wt_timeout));
break;
+   default:
+   nfc_err(>nfc_dev->dev, "Unexpected event on apdu reader 
gate\n");
+   return 1;
}
 
kfree_skb(skb);
@@ -357,6 +362,7 @@ static int st_nci_hci_connectivity_event_received(struct 
nci_dev *ndev,
r = nfc_se_transaction(ndev->nfc_dev, host, transaction);
break;
default:
+   nfc_err(>nfc_dev->dev, "Unexpected event on connectivity 
gate\n");
return 1;
}
kfree_skb(skb);
-- 
2.1.4

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

Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Sun, Oct 25, 2015 at 03:45:43PM -0500, Andrew F. Davis wrote:
> On 10/24/2015 05:14 PM, Mark Brown wrote:

> >Tbe binding document is buggy and doesn't reflect the code, there's no
> >compatible string in the driver.

> Sure there is:

> drivers/mfd/mt6397-core.c:48:
> .of_compatible = "mediatek,mt6397-regulator",

This is in the MFD, this is not used in actual systems.

> Then mfd_add_devices uses this to find the regulator node and fill
> in .of_node, then in the regulator driver:

> drivers/regulator/mt6397-regulator.c:48:
> .of_match = of_match_ptr(match),

> which uses your helper to match the nodes in the filled in .of_node.

This is in a regulator definition, it is using the regulator framework
support for parsing DT which must be used by modern drivers.  It is not
part of how the Linux driver model device is instantiated, that is done
using the struct platform_driver which is what we are talking about
here.

Please stop this, it is getting very tiresome.  

> >No, that's not the case - remember, users don't have to write a new
> >driver every time they instantiate a device on a board.  They're going
> >to have to list the in-use regulators one way or another but if we have
> >the extra compatible for regulators they have to bind both the core
> >device (which is going to be required anyway due to the control bus) and
> >the subnode saying that it has regulators (which we knew anyway as soon
> >as we knew we had the core device).

> We don't know what sub-devices the core device has, PMICs are more like
> SoCs on a bus than a regular device, the sub-parts change with every spin and
> we can represent this in DT like we do with SoCs. Else we would have to have
> a new core binding for every spin. We know what devices are on a particular
> SoC too, but we still list them and match them in DT so some SoC driver
> doesn't have to.

PMICs are very much smaller than SoCs, and again if you're not able to
usefully represent individual IPs in the DT (as is *clearly* the case
here where you are trying to make one node for the entire collection of
regulators) we're not getting any value.


signature.asc
Description: PGP signature

Re: [GIT PULL] On-demand device probing

[Mark Brown]

On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:

> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).

> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).

Yeah, people seem to have that impression though. :(

> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

This links back to the idea of having generic support for pre-probe
actions which is also generally useful (the ability to do things like
power on regulators for devices on enumerable buses so they can be
enumerated as standard).  


signature.asc
Description: PGP signature

Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Masahiro Yamada]

Hi Arnd,


2015-10-10 15:59 GMT+09:00 Masahiro Yamada :
> Hi Arnd,
>
>
> 2015-10-06 15:22 GMT+01:00 Arnd Bergmann :
>> On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote:
>>> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote:
>>> > Hi Olof,
>>> >
>>> > Now Linux 4.3-rc1 is out, so I am back to this.
>>> >
>>> > 1/3: add outer cache support
>>> > 2/3: rework SMP operations
>>> > 3/3: add device tree nodes
>>> >
>>> > Because 2/3 highly depends on 1/3, I hope whole of this series
>>> > is applied through ARM-SOC tree.
>>>
>>> Sorry for the long delay here. Is this the latest version of these
>>> patches?
>>>
>>> Did Russell King review the first patch?
>>> Is he ok with merging this through arm-soc?
>>>
>>
>> I found an answer to the first question, as I see you posted
>> v5 of the patchset in the meantime.
>
>
> Yes, v5 is my latest version.
>
>
> For the second question, Russell gave me some comments on the 1/3
> and I answered.
>
> He mentioned nothing about merging the whole series thru arm-soc.
> (At least, he was not opposed to it, I guess)
>

Is it difficult to apply this series for the next merge window?
V5 is the latest.
No comment, but not applied.

Is there anything I can do but wait?



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Rafael J. Wysocki]

On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown  wrote:
> On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:
>
>> Let's get agreement on the flow and structure and how to address other
>> issues like suspend, then we can worry about whether this needs to be
>> abstracted from subsystems. We can discuss more this week at KS.
>
> Should we try to schedule an ad-hoc session today (Monday) for those of
> us who are here to talk this over?

I won't mind doing that, what about after the Linus+Dirk session?

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/8] Build and support rk3036 SoC platform

[Xing Zheng]

Hi,
  We need to support rk3036 soc platform via upstream, there are
3 primary parts for the initial release of minimum system: dts,
pinctrl, and clock tree for rk3036, and additional, we can use
these startup and run to init processs.

Thanks.

Changed in v5:
- don't use clk_ APIs in the pll init-callback

Changed in v4:
- add some basic IP modules on rk3036.dtsi
- optimized supporting smp codes

Changed in v3:
- optimized some codes based on v2
- removed the patch "initial set time for rtc-hym8563" (useless)
- removed the patch "pinctrl" (approved)

Changed in v2:
- based on v1, add clock controller documentation
- enable timer5 startup
- add smp for cpu1
- initial set time for rtc-hym8563

Changes in v1:
- add dts, pinctrl and clock tree for rk3036 soc platform

The patchset (8):
8) rockchip: make sure timer5 is enabled on rk3036 platforms
7) ARM: dts: enable smp for rk3036
6) ARM: rockchip: add support smp for rk3036
5) ARM: dts: rockchip: add core rk3036 dts
4) clk: rockchip: add new pll-type for rk3036 and similar socs
3) clk: rockchip: add clock controller for rk3036
2) clk: rockchip: add dt-binding header for rk3036
1) dt-bindings: add documentation of rk3036 clock controller


Changes in v5:
Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 

Heiko Stuebner (1):
  ARM: rockchip: add support smp for rk3036

Xing Zheng (7):
  dt-bindings: add documentation of rk3036 clock controller
  clk: rockchip: add dt-binding header for rk3036
  clk: rockchip: add clock controller for rk3036
  clk: rockchip: add new pll-type for rk3036 and similar socs
  ARM: dts: rockchip: add core rk3036 dts
  ARM: dts: enable smp for rk3036
  rockchip: make sure timer5 is enabled on rk3036 platforms

 Documentation/devicetree/bindings/arm/cpus.txt |1 +
 .../bindings/clock/rockchip,rk3036-cru.txt |   56 ++
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/rk3036-evb.dts   |   64 +++
 arch/arm/boot/dts/rk3036.dtsi  |  541 
 arch/arm/mach-rockchip/platsmp.c   |   45 +-
 arch/arm/mach-rockchip/rockchip.c  |   44 +-
 drivers/clk/rockchip/Makefile  |1 +
 drivers/clk/rockchip/clk-pll.c |  249 -
 drivers/clk/rockchip/clk-rk3036.c  |  500 ++
 drivers/clk/rockchip/clk.h |   30 ++
 include/dt-bindings/clock/rk3036-cru.h |  195 +++
 12 files changed, 1697 insertions(+), 30 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

-- 
1.7.9.5


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

Re: [PATCH v6 3/4] arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms

[Ming Lei]

On Mon, Oct 26, 2015 at 11:50 AM, Ganapatrao Kulkarni
 wrote:
> On Mon, Oct 26, 2015 at 7:14 AM, Ming Lei  wrote:
>> On Tue, Oct 20, 2015 at 6:45 PM, Ganapatrao Kulkarni
>>  wrote:
>>> Adding numa dt binding support for arm64 based platforms.
>>> dt node parsing for numa topology is done using device property
>>> proximity and device node distance-map.
>>>
>>> Reviewed-by: Robert Richter 
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  arch/arm64/Kconfig|  10 ++
>>>  arch/arm64/include/asm/numa.h |  10 ++
>>>  arch/arm64/kernel/Makefile|   1 +
>>>  arch/arm64/kernel/of_numa.c   | 221 
>>> ++
>>>  arch/arm64/kernel/smp.c   |   1 +
>>>  arch/arm64/mm/numa.c  |  10 +-
>>>  6 files changed, 252 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/arm64/kernel/of_numa.c
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 0f9cdc7..6cf8d20 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -426,6 +426,16 @@ config NUMA
>>>   local memory controller of the CPU and add some more
>>>   NUMA awareness to the kernel.
>>>
>>> +config OF_NUMA
>>> +   bool "Device Tree NUMA support"
>>> +   depends on NUMA
>>> +   depends on OF
>>> +   default y
>>> +   help
>>> + Enable Device Tree NUMA support.
>>> + This enables the numa mapping of cpu, memory, io and
>>> + inter node distances using dt bindings.
>>
>> Enabling the above config option can cause numa_init() warning in
>> numa-less arm64 system, please see the following report:
> this is taken care. which version are you using?

V5.

>
>>
>>   https://bugs.launchpad.net/bugs/1509221
>>
>> Thanks,
>
> Thanks
> Ganapat
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: sun6i-a31: Add pins definitions for more UARTs

[Chen-Yu Tsai]

Hi,

On Mon, Oct 26, 2015 at 11:07 AM, Luis Araneda  wrote:
> Two additional UARTs tested on the GPIO pins from the
> Banana Pi M2 board
>
> Signed-off-by: Luis Araneda 
> ---

IIRC the policy we have is only add stuff that is actually used. I don't
see a follow up patch using these in any boards.

Also, please Cc LAKML for DT patches.


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

[PATCH v5 7/8] ARM: dts: enable smp for rk3036

[Xing Zheng]

Enable smp for rk3036, and add the smp sram name for adapting.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v5: None

 arch/arm/boot/dts/rk3036.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 8f3a069..61352be 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -72,6 +72,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "rockchip,rk3036-smp";
 
cpu0: cpu@f00 {
device_type = "cpu";
@@ -146,6 +147,10 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1008 0x2000>;
+   smp-sram@0 {
+   compatible = "rockchip,rk3066-smp-sram";
+   reg = <0x00 0x10>;
+   };
};
 
cru: clock-controller@2000 {
-- 
1.7.9.5


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

[PATCH v5 6/8] ARM: rockchip: add support smp for rk3036

[Xing Zheng]

From: Heiko Stuebner 

The dual-core Cortex A7 rk3036 is a bit special in that it does not allow
to control the actual powerdomain of the cpu cores, while the rest of the
smp-bringup like reset control and entry address handling stays the same.
Its bigger sibling, the quad-core rk3128 again allows powerdomain control.

So allow that case by introducing a separate smp-enable-method, that simply
disables powerdomain handling in the common code.

Signed-off-by: Heiko Stuebner 
Tested-by: Xing Zheng 
Signed-off-by: Xing Zheng 
---

Changes in v5: None

 Documentation/devicetree/bindings/arm/cpus.txt |1 +
 arch/arm/mach-rockchip/platsmp.c   |   45 +---
 2 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..261cc27 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -198,6 +198,7 @@ nodes to be present and contain the properties described 
below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
+   "rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
 
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 3e7a4b7..5c138f9 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -42,6 +42,7 @@ static int ncores;
 #define PMU_PWRDN_SCU  4
 
 static struct regmap *pmu;
+static int has_pmu = true;
 
 static int pmu_power_domain_is_on(int pd)
 {
@@ -89,20 +90,23 @@ static int pmu_set_power_domain(int pd, bool on)
if (!IS_ERR(rstc) && !on)
reset_control_assert(rstc);
 
-   ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
-   if (ret < 0) {
-   pr_err("%s: could not update power domain\n", __func__);
-   return ret;
-   }
-
-   ret = -1;
-   while (ret != on) {
-   ret = pmu_power_domain_is_on(pd);
+   if (has_pmu) {
+   ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
if (ret < 0) {
-   pr_err("%s: could not read power domain state\n",
+   pr_err("%s: could not update power domain\n",
   __func__);
return ret;
}
+
+   ret = -1;
+   while (ret != on) {
+   ret = pmu_power_domain_is_on(pd);
+   if (ret < 0) {
+   pr_err("%s: could not read power domain 
state\n",
+  __func__);
+   return ret;
+   }
+   }
}
 
if (!IS_ERR(rstc)) {
@@ -122,7 +126,7 @@ static int rockchip_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 {
int ret;
 
-   if (!sram_base_addr || !pmu) {
+   if (!sram_base_addr || (has_pmu && !pmu)) {
pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
return -ENXIO;
}
@@ -275,7 +279,7 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
return;
}
 
-   if (rockchip_smp_prepare_pmu())
+   if (has_pmu && rockchip_smp_prepare_pmu())
return;
 
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
@@ -318,6 +322,13 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
pmu_set_power_domain(0 + i, false);
 }
 
+static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus)
+{
+   has_pmu = false;
+
+   rockchip_smp_prepare_cpus(max_cpus);
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 static int rockchip_cpu_kill(unsigned int cpu)
 {
@@ -340,6 +351,15 @@ static void rockchip_cpu_die(unsigned int cpu)
 }
 #endif
 
+static struct smp_operations rk3036_smp_ops __initdata = {
+   .smp_prepare_cpus   = rk3036_smp_prepare_cpus,
+   .smp_boot_secondary = rockchip_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+   .cpu_kill   = rockchip_cpu_kill,
+   .cpu_die= rockchip_cpu_die,
+#endif
+};
+
 static struct smp_operations rockchip_smp_ops __initdata = {
.smp_prepare_cpus   = rockchip_smp_prepare_cpus,
.smp_boot_secondary = rockchip_boot_secondary,
@@ -349,4 +369,5 @@ static struct smp_operations rockchip_smp_ops __initdata = {
 #endif
 };
 
+CPU_METHOD_OF_DECLARE(rk3036_smp, "rockchip,rk3036-smp", _smp_ops);
 CPU_METHOD_OF_DECLARE(rk3066_smp, "rockchip,rk3066-smp", _smp_ops);
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to 

Re: [PATCH] ARM: dts: sun6i-a31: Add pins definitions for more UARTs

[Luis Araneda]

Hi,

You're right on that these pins aren't currently in use by any .dts
file, but the manufacturer, Sinovoip,
should be submitting a .dts file for the board soon, and if they
don't, I'm sure the Linux-Sunxi community will do.
You can see a work-in-progress device tree at:
https://github.com/BPI-SINOVOIP/BPI-Mainline-kernel/blob/master/arch/arm/boot/dts/sun6i-a31s-bananapi-m2.dts

Apologies in advance if some of what I've written is against any rule,
I read them, but something might be wrong because this is my first
attempt to submit a patch.

Cheers,
Luis Araneda.

On Mon, Oct 26, 2015 at 12:47 AM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Mon, Oct 26, 2015 at 11:07 AM, Luis Araneda  wrote:
>> Two additional UARTs tested on the GPIO pins from the
>> Banana Pi M2 board
>>
>> Signed-off-by: Luis Araneda 
>> ---
>
> IIRC the policy we have is only add stuff that is actually used. I don't
> see a follow up patch using these in any boards.
>
> Also, please Cc LAKML for DT patches.
>
>
> Regards
> ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Mark Brown]

On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:

> Let's get agreement on the flow and structure and how to address other
> issues like suspend, then we can worry about whether this needs to be
> abstracted from subsystems. We can discuss more this week at KS.

Should we try to schedule an ad-hoc session today (Monday) for those of
us who are here to talk this over?


signature.asc
Description: PGP signature

Re: [PATCH v6 3/4] arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms

[Ming Lei]

On Tue, Oct 20, 2015 at 6:45 PM, Ganapatrao Kulkarni
 wrote:
> Adding numa dt binding support for arm64 based platforms.
> dt node parsing for numa topology is done using device property
> proximity and device node distance-map.
>
> Reviewed-by: Robert Richter 
> Signed-off-by: Ganapatrao Kulkarni 
> ---
>  arch/arm64/Kconfig|  10 ++
>  arch/arm64/include/asm/numa.h |  10 ++
>  arch/arm64/kernel/Makefile|   1 +
>  arch/arm64/kernel/of_numa.c   | 221 
> ++
>  arch/arm64/kernel/smp.c   |   1 +
>  arch/arm64/mm/numa.c  |  10 +-
>  6 files changed, 252 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/kernel/of_numa.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 0f9cdc7..6cf8d20 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -426,6 +426,16 @@ config NUMA
>   local memory controller of the CPU and add some more
>   NUMA awareness to the kernel.
>
> +config OF_NUMA
> +   bool "Device Tree NUMA support"
> +   depends on NUMA
> +   depends on OF
> +   default y
> +   help
> + Enable Device Tree NUMA support.
> + This enables the numa mapping of cpu, memory, io and
> + inter node distances using dt bindings.

Enabling the above config option can cause numa_init() warning in
numa-less arm64 system, please see the following report:

  https://bugs.launchpad.net/bugs/1509221

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

[PATCH] ARM: dts: sun6i-a31: Add pins definitions for more UARTs

[Luis Araneda]

Two additional UARTs tested on the GPIO pins from the
Banana Pi M2 board

Signed-off-by: Luis Araneda 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 83c1879..eb02d57 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -654,6 +654,20 @@
allwinner,pull = ;
};
 
+   uart2_pins_a: uart2@0 {
+   allwinner,pins = "PG6", "PG7", "PG8", "PG9";
+   allwinner,function = "uart2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   uart5_pins_a: uart5@0 {
+   allwinner,pins = "PE4", "PE5", "PE6", "PE7";
+   allwinner,function = "uart5";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
i2c0_pins_a: i2c0@0 {
allwinner,pins = "PH14", "PH15";
allwinner,function = "i2c0";
-- 
1.9.1

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

[PATCH v2 01/35] nfc: st-nci: Align st-nci driver with other nfc driver

[Christophe Ricard]

Align st-nci driver with or nfc driver:
- Remove st-nci_ prefix
- Merge se.h in st-nci.h

Signed-off-by: Christophe Ricard 
---
 drivers/nfc/st-nci/core.c   |  1 -
 drivers/nfc/st-nci/se.c |  1 -
 drivers/nfc/st-nci/se.h | 61 -
 drivers/nfc/st-nci/st-nci.h | 40 -
 4 files changed, 39 insertions(+), 64 deletions(-)
 delete mode 100644 drivers/nfc/st-nci/se.h

diff --git a/drivers/nfc/st-nci/core.c b/drivers/nfc/st-nci/core.c
index c419d39..96997e6 100644
--- a/drivers/nfc/st-nci/core.c
+++ b/drivers/nfc/st-nci/core.c
@@ -24,7 +24,6 @@
 #include 
 
 #include "st-nci.h"
-#include "st-nci_se.h"
 
 #define DRIVER_DESC "NCI NFC driver for ST_NCI"
 
diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index c742ef6..4acb945 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -23,7 +23,6 @@
 #include 
 
 #include "st-nci.h"
-#include "st-nci_se.h"
 
 struct st_nci_pipe_info {
u8 pipe_state;
diff --git a/drivers/nfc/st-nci/se.h b/drivers/nfc/st-nci/se.h
deleted file mode 100644
index ea66e87..000
--- a/drivers/nfc/st-nci/se.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Secure Element Driver for STMicroelectronics NFC NCI Chip
- *
- * Copyright (C) 2014-2015 STMicroelectronics SAS. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-#ifndef __LOCAL_ST_NCI_SE_H_
-#define __LOCAL_ST_NCI_SE_H_
-
-/*
- * ref ISO7816-3 chap 8.1. the initial character TS is followed by a
- * sequence of at most 32 characters.
- */
-#define ST_NCI_ESE_MAX_LENGTH  33
-#define ST_NCI_HCI_HOST_ID_ESE 0xc0
-
-struct st_nci_se_info {
-   u8 atr[ST_NCI_ESE_MAX_LENGTH];
-   struct completion req_completion;
-
-   struct timer_list bwi_timer;
-   int wt_timeout; /* in msecs */
-   bool bwi_active;
-
-   struct timer_list se_active_timer;
-   bool se_active;
-
-   bool xch_error;
-
-   se_io_cb_t cb;
-   void *cb_context;
-};
-
-int st_nci_se_init(struct nci_dev *ndev);
-void st_nci_se_deinit(struct nci_dev *ndev);
-
-int st_nci_discover_se(struct nci_dev *ndev);
-int st_nci_enable_se(struct nci_dev *ndev, u32 se_idx);
-int st_nci_disable_se(struct nci_dev *ndev, u32 se_idx);
-int st_nci_se_io(struct nci_dev *ndev, u32 se_idx,
-   u8 *apdu, size_t apdu_length,
-   se_io_cb_t cb, void *cb_context);
-int st_nci_hci_load_session(struct nci_dev *ndev);
-void st_nci_hci_event_received(struct nci_dev *ndev, u8 pipe,
-   u8 event, struct sk_buff *skb);
-void st_nci_hci_cmd_received(struct nci_dev *ndev, u8 pipe, u8 cmd,
-   struct sk_buff *skb);
-
-
-#endif /* __LOCAL_ST_NCI_SE_H_ */
diff --git a/drivers/nfc/st-nci/st-nci.h b/drivers/nfc/st-nci/st-nci.h
index 850a239..5d3f4d9 100644
--- a/drivers/nfc/st-nci/st-nci.h
+++ b/drivers/nfc/st-nci/st-nci.h
@@ -19,7 +19,6 @@
 #ifndef __LOCAL_ST_NCI_H_
 #define __LOCAL_ST_NCI_H_
 
-#include "st-nci_se.h"
 #include "ndlc.h"
 
 /* Define private flags: */
@@ -28,6 +27,13 @@
 #define ST_NCI_CORE_PROP0x01
 #define ST_NCI_SET_NFC_MODE 0x02
 
+/*
+ * ref ISO7816-3 chap 8.1. the initial character TS is followed by a
+ * sequence of at most 32 characters.
+ */
+#define ST_NCI_ESE_MAX_LENGTH  33
+#define ST_NCI_HCI_HOST_ID_ESE 0xc0
+
 struct nci_mode_set_cmd {
u8 cmd_type;
u8 mode;
@@ -37,6 +43,23 @@ struct nci_mode_set_rsp {
u8 status;
 } __packed;
 
+struct st_nci_se_info {
+   u8 atr[ST_NCI_ESE_MAX_LENGTH];
+   struct completion req_completion;
+
+   struct timer_list bwi_timer;
+   int wt_timeout; /* in msecs */
+   bool bwi_active;
+
+   struct timer_list se_active_timer;
+   bool se_active;
+
+   bool xch_error;
+
+   se_io_cb_t cb;
+   void *cb_context;
+};
+
 struct st_nci_info {
struct llt_ndlc *ndlc;
unsigned long flags;
@@ -47,4 +70,19 @@ void st_nci_remove(struct nci_dev *ndev);
 int st_nci_probe(struct llt_ndlc *ndlc, int phy_headroom,
int phy_tailroom);
 
+int st_nci_se_init(struct nci_dev *ndev);
+void st_nci_se_deinit(struct nci_dev *ndev);
+
+int st_nci_discover_se(struct nci_dev *ndev);
+int st_nci_enable_se(struct nci_dev *ndev, u32 se_idx);
+int st_nci_disable_se(struct nci_dev *ndev, u32 se_idx);
+int st_nci_se_io(struct nci_dev *ndev, u32 se_idx,
+   

[PATCH v2 00/35] Few fixes and st21nfca/st-nci vendor_cmds support

[Christophe Ricard]

Hi Samuel,

Please find in the following patchset severals fixes as well as vendor_cmds 
support
for st21nfca and st-nci.
vendor_cmds includes production test, trimmings & firmware update commands.

v2:
- Propose a more elegant way to switch between NFC target mode (SLEEP, IDLE).
- Remove st21nfca_ and st-nci_ file name prefix.
- Merge st21nfca_xxx.h headers into st21nfca.h. Same for st-nci_xxx.h

Best Regards
Christophe
Christophe Ricard (35):
  nfc: st-nci: Align st-nci driver with other nfc driver
  nfc: st-nci: include st-nci.h instead of ndlc.h
  nfc: st21nfca: Align st21nfca driver with other nfc driver
  nfc: st-nci: Fix incorrect spi buffer size
  nfc: nci: Fix incorrect data chaining when sending data
  nfc: nci: Fix improper management of HCI return code
  nfc: nci: extract pipe value using NCI_HCP_MSG_GET_PIPE
  nfc: nci: add nci_hci_clear_all_pipes functions
  nfc: nci: Add a call to nci_hci_clear_all_pipes at HCI initial
activation.
  nfc: nci: add capability to create pipe on specific gate in
nci_hci_connect_gate
  nfc: st-nci: Remove ndev->hci_dev->init_data.gates initialization in
load_session
  nfc: st21nfca: Remove hdev->init_data.gates initialization in
load_session
  nfc: st-nci: Open NCI_HCI_LINK_MGMT_PIPE
  nfc: st21nfca: Open NFC_HCI_LINK_MGMT_PIPE
  nfc: st-nci: Keep st_nci_gates unchanged in load_session
  nfc: st21nfca: Keep st21nfca_gates unchanged in load_session
  nfc: st-nci: initialize gate_count in st_nci_hci_network_init
  nfc: st-nci: Add support for NCI_HCI_IDENTITY_MGMT_GATE
  nfc: st-nci: Change st_nci_gates offset when looking for a pipe in the
table
  nfc: st21nfca: Change st21nfca_gates offset when looking for a pipe in
the table
  nfc: st-nci: Add support for proprietary commands for factory tests
  nfc: st-nci: Add error messages when an unexpected HCI event occurs
  nfc: netlink: Add missing NFC_ATTR comments
  nfc: st-nci: Add ese-present/uicc-present dts properties
  nfc: st-nci: Increase waiting time between 2 secure element activation
  nfc: st-nci: Fix host_list verification after secure element
activation
  nfc: st21nfca: Fix host_list verification after secure element
activation
  nfc: netlink: Add mode parameter to deactivate_target functions
  nfc: st-nci: Add few code style fixes
  nfc: st21nfca: Add few code style fixes
  nfc: st21nfca: Add support for proprietary commands for factory tests
  nfc: st21nfca: Add error messages when an unexpected HCI event occurs
  nfc: st-nci: Make sure irq is not already active when powering the
device
  nfc: st-nci: remove duplicated skb dump
  nfc: st-nci: Replace st21nfcb by st_nci in makefile

 .../devicetree/bindings/net/nfc/st-nci-i2c.txt |7 +
 .../devicetree/bindings/net/nfc/st-nci-spi.txt |9 +-
 drivers/nfc/st-nci/Makefile|4 +-
 drivers/nfc/st-nci/core.c  |   18 +-
 drivers/nfc/st-nci/i2c.c   |   35 +-
 drivers/nfc/st-nci/ndlc.c  |7 +-
 drivers/nfc/st-nci/ndlc.h  |5 +-
 drivers/nfc/st-nci/se.c|  166 ++-
 drivers/nfc/st-nci/se.h|   61 --
 drivers/nfc/st-nci/spi.c   |   37 +-
 drivers/nfc/st-nci/st-nci.h|  117 ++-
 drivers/nfc/st-nci/vendor_cmds.c   |  516 ++
 drivers/nfc/st21nfca/Makefile  |2 +-
 drivers/nfc/st21nfca/core.c| 1056 +++
 drivers/nfc/st21nfca/dep.c |  689 +
 drivers/nfc/st21nfca/i2c.c |1 +
 drivers/nfc/st21nfca/se.c  |  428 
 drivers/nfc/st21nfca/st21nfca.c| 1064 
 drivers/nfc/st21nfca/st21nfca.h|  148 ++-
 drivers/nfc/st21nfca/st21nfca_dep.c|  689 -
 drivers/nfc/st21nfca/st21nfca_dep.h|   43 -
 drivers/nfc/st21nfca/st21nfca_se.c |  420 
 drivers/nfc/st21nfca/st21nfca_se.h |   63 --
 drivers/nfc/st21nfca/vendor_cmds.c |  370 +++
 include/linux/platform_data/st-nci.h   |2 +
 include/net/nfc/nci_core.h |3 +
 include/net/nfc/nfc.h  |2 +-
 include/uapi/linux/nfc.h   |2 +
 net/nfc/core.c |4 +-
 net/nfc/digital_core.c |3 +-
 net/nfc/hci/core.c |3 +-
 net/nfc/nci/core.c |   15 +-
 net/nfc/nci/hci.c  |  159 ++-
 net/nfc/netlink.c  |2 +-
 net/nfc/nfc.h  |5 +-
 net/nfc/rawsock.c  |3 +-
 36 files changed, 

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Dmitry Torokhov]

On October 26, 2015 9:13:01 AM GMT+09:00, Mark Brown  wrote:
>On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:
>
>> Let's get agreement on the flow and structure and how to address
>other
>> issues like suspend, then we can worry about whether this needs to be
>> abstracted from subsystems. We can discuss more this week at KS.
>
>Should we try to schedule an ad-hoc session today (Monday) for those of
>us who are here to talk this over?


That would be great.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

[Kevin Hilman]

Hello,

On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen  wrote:
> Add arch timer node to enable arch-timer support. MT8135 firmware
> doesn't correctly setup arch-timer frequency and CNTVOFF, add
> properties to workaround this.
>
> This also set cpu enable-method to enable SMP.
>
> Signed-off-by: Yingjoe Chen 

kernelci.org started detecting new boot failures for the mt8135-evb in
the arm-soc tree[1], and the boot failures were bisected down to this
patch, which landed upstream in the form of commit d186a394bb98 (ARM:
dts: mt8135: enable basic SMP bringup for mt8135)

Maybe this new SMP support requires updating the firmware on the board
as well?  If so, the changelog should've been a bit more explicit
about firmware dependencies.

Kevin

[1] 
http://kernelci.org/boot/mt8135-evbp1/job/arm-soc/kernel/v4.3-rc5-795-ga4b616012d2e/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=562b1cf959b5149e07111471
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Chen-Yu Tsai]

On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar
 wrote:
> Allwinner A83T is new octa-core cortex-a7 SOC.
> This adds the basic dtsi, the clocks differs from
> earlier sun8i SOCs.
>
> Signed-off-by: Vishnu Patekar 
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 247 
> ++
>  1 file changed, 247 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> new file mode 100644
> index 000..e85995f
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -0,0 +1,247 @@
> +   cpu@100 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <4>;
> +   };
> +
> +   cpu@101 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <5>;
> +   };
> +   cpu@102 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <6>;
> +   };
> +
> +   cpu@103 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <7>;
> +   };

The reg values are still wrong for the second cluster.

ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/4] arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms

[Ganapatrao Kulkarni]

On Mon, Oct 26, 2015 at 7:14 AM, Ming Lei  wrote:
> On Tue, Oct 20, 2015 at 6:45 PM, Ganapatrao Kulkarni
>  wrote:
>> Adding numa dt binding support for arm64 based platforms.
>> dt node parsing for numa topology is done using device property
>> proximity and device node distance-map.
>>
>> Reviewed-by: Robert Richter 
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  arch/arm64/Kconfig|  10 ++
>>  arch/arm64/include/asm/numa.h |  10 ++
>>  arch/arm64/kernel/Makefile|   1 +
>>  arch/arm64/kernel/of_numa.c   | 221 
>> ++
>>  arch/arm64/kernel/smp.c   |   1 +
>>  arch/arm64/mm/numa.c  |  10 +-
>>  6 files changed, 252 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm64/kernel/of_numa.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 0f9cdc7..6cf8d20 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -426,6 +426,16 @@ config NUMA
>>   local memory controller of the CPU and add some more
>>   NUMA awareness to the kernel.
>>
>> +config OF_NUMA
>> +   bool "Device Tree NUMA support"
>> +   depends on NUMA
>> +   depends on OF
>> +   default y
>> +   help
>> + Enable Device Tree NUMA support.
>> + This enables the numa mapping of cpu, memory, io and
>> + inter node distances using dt bindings.
>
> Enabling the above config option can cause numa_init() warning in
> numa-less arm64 system, please see the following report:
this is taken care. which version are you using?

>
>   https://bugs.launchpad.net/bugs/1509221
>
> Thanks,

Thanks
Ganapat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/4] arm64, numa: adding numa support for arm64 platforms.

[Ganapatrao Kulkarni]

On Wed, Oct 21, 2015 at 2:24 PM, Ganapatrao Kulkarni
 wrote:
> On Tue, Oct 20, 2015 at 8:17 PM, Mark Rutland  wrote:
>> Hi,
>>
>> I'm away for the rest of this week and don't have the time to give this
>> a full review, but I've given this a first pass and have some high-level
>> comments:
>>
>> First, most of this is copy+paste from x86. We should try to share code
>> rather than duplicating it. Especially as it looks like there's cleanup
>> (and therefore divergence) that could happen.
> this is arch specific glue layer for numa.
> there might be some common functions and there will be arch specific
> hacks/exceptions.
> if we try to pull out common code then still will have some arch
> specific code or end up with unavoidable ifdefs.
> IMHO, this code better to be in arch (in single file).
>>
>> Second, this reimplements memblock to associate nids with memory
>> regions. I think we should keep memblock around for this (I'm under the
>> impression that Ard also wants that for memory attributes), rather than
>> creating a new memblock-like API that we then have to reconcile with
>> actual memblock information.
> thanks, this seems to be good idea to reuse the memblock code/infrastructures.
> will work on this.
this i have added and will be part of v7 patchset.
please review other changes.
>>
>> Third, NAK to the changes to /proc/cpuinfo, please drop that from the
>> patch. Further comments on that matter are inline below.
> ok.
>>
>> On Tue, Oct 20, 2015 at 04:15:28PM +0530, Ganapatrao Kulkarni wrote:
>>> Adding numa support for arm64 based platforms.
>>> This patch adds by default the dummy numa node and
>>> maps all memory and cpus to node 0.
>>> using this patch, numa can be simulated on single node arm64 platforms.
>>>
>>> Reviewed-by: Robert Richter 
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  arch/arm64/Kconfig  |  25 ++
>>>  arch/arm64/include/asm/mmzone.h |  17 ++
>>>  arch/arm64/include/asm/numa.h   |  63 +
>>>  arch/arm64/kernel/setup.c   |   9 +
>>>  arch/arm64/kernel/smp.c |   2 +
>>>  arch/arm64/mm/Makefile  |   1 +
>>>  arch/arm64/mm/init.c|  31 ++-
>>>  arch/arm64/mm/numa.c| 531 
>>> 
>>>  8 files changed, 675 insertions(+), 4 deletions(-)
>>>  create mode 100644 arch/arm64/include/asm/mmzone.h
>>>  create mode 100644 arch/arm64/include/asm/numa.h
>>>  create mode 100644 arch/arm64/mm/numa.c
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 7d95663..0f9cdc7 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -68,6 +68,7 @@ config ARM64
>>>   select HAVE_GENERIC_DMA_COHERENT
>>>   select HAVE_HW_BREAKPOINT if PERF_EVENTS
>>>   select HAVE_MEMBLOCK
>>> + select HAVE_MEMBLOCK_NODE_MAP if NUMA
>>>   select HAVE_PATA_PLATFORM
>>>   select HAVE_PERF_EVENTS
>>>   select HAVE_PERF_REGS
>>> @@ -414,6 +415,30 @@ config HOTPLUG_CPU
>>> Say Y here to experiment with turning CPUs off and on.  CPUs
>>> can be controlled through /sys/devices/system/cpu.
>>>
>>> +# Common NUMA Features
>>> +config NUMA
>>> + bool "Numa Memory Allocation and Scheduler Support"
>>> + depends on SMP
>>> + help
>>> +   Enable NUMA (Non Uniform Memory Access) support.
>>> +
>>> +   The kernel will try to allocate memory used by a CPU on the
>>> +   local memory controller of the CPU and add some more
>>> +   NUMA awareness to the kernel.
>>> +
>>> +config NODES_SHIFT
>>> + int "Maximum NUMA Nodes (as a power of 2)"
>>> + range 1 10
>>> + default "2"
>>> + depends on NEED_MULTIPLE_NODES
>>> + help
>>> +   Specify the maximum number of NUMA Nodes available on the target
>>> +   system.  Increases memory reserved to accommodate various tables.
>>
>> How much memory do we end up requiring per node?
> not much. however it is proportional to number of max nodes supported
> by the system.
>>
>>> +
>>> +config USE_PERCPU_NUMA_NODE_ID
>>> + def_bool y
>>> + depends on NUMA
>>> +
>>>  source kernel/Kconfig.preempt
>>>
>>>  config HZ
>>> diff --git a/arch/arm64/include/asm/mmzone.h 
>>> b/arch/arm64/include/asm/mmzone.h
>>> new file mode 100644
>>> index 000..6ddd468
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/mmzone.h
>>> @@ -0,0 +1,17 @@
>>> +#ifndef __ASM_ARM64_MMZONE_H_
>>> +#define __ASM_ARM64_MMZONE_H_
>>> +
>>> +#ifdef CONFIG_NUMA
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +extern struct pglist_data *node_data[];
>>> +
>>> +#define NODE_DATA(nid)   (node_data[(nid)])
>>> +
>>> +#endif /* CONFIG_NUMA */
>>> +#endif /* __ASM_ARM64_MMZONE_H_ */
>>> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
>>> new file mode 100644
>>> index 000..cadbd24
>>> --- /dev/null
>>> +++ 

Re: [PATCH] arm: Test for CONFIG_USE_OF to handle the USE_OF=n/OF=y case

[Rob Herring]

On Sun, Oct 25, 2015 at 10:25 AM, Geert Uytterhoeven
 wrote:
> Until commit 0166dc11be911213 ("of: make CONFIG_OF user selectable"),
> CONFIG_OF=y implied CONFIG_USE_OF=y on ARM, as the former could solely
> be enabled by being selected by the latter.

Arnd sent a similar fix[1] which I prefer.

> However, if the user now manually enables CONFIG_OF=y while
> CONFIG_USE_OF=n:
>
> arch/arm/kernel/devtree.c: In function 'setup_machine_fdt':
> arch/arm/kernel/devtree.c:215:2: error: implicit declaration of function 
> 'early_init_dt_verify' [-Werror=implicit-function-declaration]
>   if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
>   ^
> arch/arm/kernel/devtree.c:218:2: error: implicit declaration of function 
> 'of_flat_dt_match_machine' [-Werror=implicit-function-declaration]
>   mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>   ^
> arch/arm/kernel/devtree.c:218:8: warning: assignment makes pointer from 
> integer without a cast
>   mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
> ^
> arch/arm/kernel/devtree.c:228:3: error: implicit declaration of function 
> 'of_get_flat_dt_root' [-Werror=implicit-function-declaration]
>dt_root = of_get_flat_dt_root();
>^
> arch/arm/kernel/devtree.c:229:3: error: implicit declaration of function 
> 'of_get_flat_dt_prop' [-Werror=implicit-function-declaration]
>prop = of_get_flat_dt_prop(dt_root, "compatible", );
>^
> arch/arm/kernel/devtree.c:229:8: warning: assignment makes pointer from 
> integer without a cast
>prop = of_get_flat_dt_prop(dt_root, "compatible", );
> ^
> arch/arm/kernel/devtree.c:244:2: error: implicit declaration of function 
> 'early_init_dt_scan_nodes' [-Werror=implicit-function-declaration]
>   early_init_dt_scan_nodes();
>   ^
>
> and
>
> arch/arm/kernel/built-in.o: In function `setup_arch':
> arch/arm/kernel/setup.c:940: undefined reference to `setup_machine_fdt'
> arch/arm/kernel/setup.c:979: undefined reference to `arm_dt_init_cpu_maps'
>
> Replace tests for CONFIG_OF by tests for CONFIG_USE_OF where appropriate
> to fix this.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/12531538/
>
> I only fixed the particular issue with the randconfig from the build
> above.  Are there more tests for CONFIG_OF that should be converted to
> CONFIG_USE_OF?

I'd rather move toward removing USE_OF and having arches select if
they use EARLY_FLATTREE.

Rob

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376484.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/8] ARM: dts: rockchip: add core rk3036 dts

[Xing Zheng]

Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v5: None

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3036-evb.dts |   64 +
 arch/arm/boot/dts/rk3036.dtsi|  536 ++
 3 files changed, 601 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d3e495..3e4e089 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+   rk3036-evb.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
new file mode 100644
index 000..28a0336
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -0,0 +1,64 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+   model = "Rockchip RK3036 Evaluation board";
+   compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
+};
+
+ {
+   status = "okay";
+
+   hym8563: hym8563@51 {
+   compatible = "haoyu,hym8563";
+   reg = <0x51>;
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "xin32k";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..8f3a069
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,536 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is 

Re: [PATCH 5/5] arm64: dts: spi bus dts support multiple devices

[lei liu]

Hi Sascha,

On Wed, 2015-10-14 at 07:58 +0200, Sascha Hauer wrote:
> On Wed, Oct 14, 2015 at 11:23:35AM +0800, Leilk Liu wrote:
> > This patch support multiple devices for MT8173.
> 
> The subject of this patch and also the above sentence should contain the
> board name this patch is changing so that the reader knows this is about
> a single board, and not arm64 in general.
> 
OK, I'll fix it.

> Sascha
> 
> > 
> > Signed-off-by: Leilk Liu 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index 04b38ed..1c8c407 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -194,7 +194,7 @@
> > pinmux = ,
> > ,
> > ,
> > -   ;
> > +   ;
> > };
> > };
> >  };
> > @@ -399,6 +399,7 @@
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pins_a>;
> > +   cs-gpios = < 72 0>;
> > mediatek,pad-select = <0>;
> > status = "okay";
> >  };
> > -- 
> > 1.8.1.1.dirty
> > 
> > 
> 


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

Re: [PATCH] ARM: dts: uniphier: add I2C aliases for ProXstream2 boards

[Olof Johansson]

On Sat, Oct 24, 2015 at 12:25:31PM +0900, Masahiro Yamada wrote:
> Add aliases to fix the I2C indexes like the other UniPhier boards.
> 
> Signed-off-by: Masahiro Yamada 

Thanks, applied!


-Olof

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

Re: [PATCH v5 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Wed, 2015-10-14 at 14:53 +0200, Joerg Roedel wrote:
> On Fri, Oct 09, 2015 at 10:23:07AM +0800, Yong Wu wrote:
> > +   /*
> > +* There is a domain for each a iommu device in normal case.
> > +* But MTK only has one iommu domain called the m4u domain which all
> > +* the multimedia HW share. Here we reserve one as the m4u domain and
> > +* free the others.
> > +*
> > +* And the attach_device that from __iommu_setup_dma_ops
> > +* will be called earlier than probe.
> > +*/
> 
> Okay, with this being the case, you need to put all devices behind one
> IOMMU into the same iommu-group, because the IOMMU can't really isolate
> the devices from each other.
> 
> > +static int mtk_iommu_add_device(struct device *dev)
> > +{
> > +   struct iommu_group *group;
> > +   struct mtk_iommu_client_priv *priv;
> > +   struct mtk_iommu_domain *m4udom;
> > +   struct iommu_domain *domain;
> > +   int ret;
> > +
> > +   if (!dev->archdata.iommu) /* Not a iommu client device */
> > +   return -ENODEV;
> > +
> > +   group = iommu_group_get(dev);
> > +   if (!group) {
> > +   group = iommu_group_alloc();
> > +   if (IS_ERR(group)) {
> > +   dev_err(dev, "Failed to allocate IOMMU group\n");
> > +   return PTR_ERR(group);
> > +   }
> > +   }
> > +
> > +   ret = iommu_group_add_device(group, dev);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to add IOMMU group\n");
> > +   goto err_group_put;
> > +   }
> > +
> > +   domain = iommu_get_domain_for_dev(dev);
> > +   if (!domain) {
> > +   /*
> > +* Get the m4u iommu domain from the m4u device.
> > +* Attach all the client devices into the m4u domain.
> > +*/
> > +   priv = dev->archdata.iommu;
> > +   m4udom = dev_get_drvdata(priv->m4udev);
> > +   ret = iommu_attach_group(>domain, group);
> > +   if (ret)
> > +   dev_err(dev, "Failed to attach IOMMU group\n");
> > +   }
> > +
> > +err_group_put:
> > +   iommu_group_put(group);
> > +   return ret;
> > +}
> 
> Here it looks like you are allocating one group for each device. As I
> said, all devices need to be in one group.
> 
>   Joerg
> 

Thanks for this suggestion. I have put all the iommu client devices into
the same iommu group, the code looks like below.
And I will send this in the next version after the Short descriptor is
reviewed.


static int mtk_iommu_add_device(struct device *dev)
{
struct iommu_group *group;
struct mtk_iommu_client_priv *priv;
struct mtk_iommu_domain *m4udom;
struct iommu_domain *domain;
int ret;

priv = dev->archdata.iommu;
if (!priv) /* Not a iommu client device */
return -ENODEV;
m4udom = dev_get_drvdata(priv->m4udev);

group = iommu_group_get(dev);
if (!group) {
/*
 * All the iommu client devices are in the m4u domain,
 * they all are in the same m4u iommu-group too here.
 */
if (!m4udom->m4u_group) {
group = iommu_group_alloc();
if (IS_ERR(group)) {
dev_err(dev, "Failed to allocate IOMMU 
group\n");
return PTR_ERR(group);
}
m4udom->m4u_group = group;
} else {
group = m4udom->m4u_group;
}
}

ret = iommu_group_add_device(group, dev);
if (ret) {
dev_err(dev, "Failed to add IOMMU group\n");
goto err_group_put;
}

domain = iommu_get_domain_for_dev(dev);
if (!domain)
ret = iommu_attach_group(>domain, group);

err_group_put:
iommu_group_put(group);
return ret;
}

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

Re: [PATCH 0/5] mt8173 spi multiple devices support

[lei liu]

Hi Mark,

On Mon, 2015-10-19 at 20:27 +0100, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 11:23:30AM +0800, Leilk Liu wrote:
> > This series are based on 4.3-rc1 and provide 5 patches to support
> > mt8173 spi multiple devices.
> 
> This doesn't apply against current code, please check and resend.  Also
> note that it looks like you've got the execute bit set on some of the
> files.  The code itself looks fine.

OK, I will fix it.

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

Re: [PATCH 18/30] nfc: st-nci: Add support for proprietary commands for factory tests

[Samuel Ortiz]

Hi Christophe,

On Sat, Oct 24, 2015 at 02:19:03PM +0200, Christophe Ricard wrote:
> Hi Samuel,
> 
> On 24/10/2015 08:48, Samuel Ortiz wrote:
> >Hi Christophe,
> >
> >Just a couple of nitpicks:
> >
> >On Tue, Oct 20, 2015 at 11:48:09PM +0200, Christophe Ricard wrote:
> >>diff --git a/drivers/nfc/st-nci/Makefile b/drivers/nfc/st-nci/Makefile
> >>index 348ce76..60e569b 100644
> >>--- a/drivers/nfc/st-nci/Makefile
> >>+++ b/drivers/nfc/st-nci/Makefile
> >>@@ -2,7 +2,7 @@
> >>  # Makefile for ST21NFCB NCI based NFC driver
> >>  #
> >>-st-nci-objs = ndlc.o core.o st-nci_se.o
> >>+st-nci-objs = ndlc.o core.o st-nci_se.o st-nci_vendor_cmds.o
> >Please rename that file to vendor_cmds.c.
> >I pushed a change to rename st-nci_se.c to se.c already, to keep the
> >file names consistent there.
> I think your latest change introduced a build break :(. The log
> message mention also MFC instead of NFC ;).
> 
> "In file included from drivers/nfc/st-nci/ndlc.c:23:0:
> drivers/nfc/st-nci/st-nci.h:22:23: fatal error: st-nci_se.h: No such
> file or directory
> #include "st-nci_se.h""
> I will send a fix in the v2 ;).
Sorry about that. I'll fix it up.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: vf6xx: Cosmic+: M4(nommu) initial support

[Afzal Mohammed]

Minimal Cortex-M4 device tree to boot Linux to shell. M4 is booted via
Cortex-A5 running Linux using Stefan Agner's  "m4boot"
utility.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/boot/dts/Makefile   |  1 +
 arch/arm/boot/dts/vf610m4-cosmic.dts | 90 
 2 files changed, 91 insertions(+)
 create mode 100644 arch/arm/boot/dts/vf610m4-cosmic.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa023d574..06a1a7a1d104 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_VF610) += \
vf610-colibri-eval-v3.dtb \
vf610m4-colibri.dtb \
vf610-cosmic.dtb \
+   vf610m4-cosmic.dtb \
vf610-twr.dtb
 dtb-$(CONFIG_ARCH_MXS) += \
imx23-evk.dtb \
diff --git a/arch/arm/boot/dts/vf610m4-cosmic.dts 
b/arch/arm/boot/dts/vf610m4-cosmic.dts
new file mode 100644
index ..8944a2d2054c
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4-cosmic.dts
@@ -0,0 +1,90 @@
+/*
+ * Device tree for Cosmic+ VF6xx Cortex-M4 support
+ *
+ * Copyright (C) 2015
+ *
+ * Based on vf610m4 Colibri
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "vf610m4.dtsi"
+
+/ {
+   model = "VF610 Cortex-M4";
+   compatible = "fsl,vf610m4";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart3>;
+   status = "okay";
+};
+
+ {
+   vf610-cosmic {
+   pinctrl_uart3: uart3grp {
+   fsl,pins = <
+   VF610_PAD_PTA20__UART3_TX   0x21a2
+   VF610_PAD_PTA21__UART3_RX   0x21a1
+   >;
+   };
+   };
+};
-- 
2.5.1

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

[PATCH 1/3] devicetree: mfd: Add binding for the TI LM3533

[Bjorn Andersson]

Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson 
---
 Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++
 1 file changed, 183 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index ..3cc41695a544
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,183 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be:
+   "ti,lm3533"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: i2c address of the LM3533 chip
+
+- ti,hwen-gpios:
+   Usage: required
+   Value type: 
+   Definition: reference to gpio pin connected to the HWEN input; as
+   specified in "gpio/gpio.txt"
+
+- ti,als-supply:
+   Usage: optional
+   Value type: 
+   Definition: reference to regulator powering the V_als input; as
+   specified in "regulator/regulator.txt"
+
+- ti,boost-freq:
+   Usage: required
+   Value type: 
+   Definition: switch-frequency of the boost converter, must be either:
+   50 or 100
+
+- ti,boost-ovp:
+   Usage: required
+   Value type: 
+   Definition: over voltage protection limit, must be one of: 16, 24, 32
+   or 40
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= ALS SUBNODE
+The als subnode must be named "als", it carries the als related properties.
+
+- ti,als-resistance:
+   Usage: required (unless ti,pwm-mode is specified)
+   Value type: 
+   Definition: specifies the resistor value (R_als), in Ohm. Valid values
+   ranges from 200kOhm to 1574Ohm.
+
+- ti,pwm-mode:
+   Usage: optional
+   Value type: 
+   Definition: specifies, if present, that the als should operate in pwm
+   mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the two backlights this node corresponds
+   to
+
+- default-brightness:
+   Usage: optional
+   Value type: <32>
+   Definition: specifies the default brightness for the backlight, in
+   units of brightness [0-255]
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this backlight
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this backlight, in uA, as
+   described in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this backlight,
+   the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+   Usage: optional
+   Value type: 
+   Definition: specifies the default trigger for the LED, as described in
+   "leds/common.txt"
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this LED, as described in
+   "leds/common.txt"
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this LED, in uA, as described
+   in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this LED, the
+   values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@1246 {
+   compatible = "qcom,i2c-qup-v1.1.1";
+   ...
+
+   lm3533@36 {
+   compatible = "ti,lm3533";
+   reg = <0x36>;
+
+   ti,hwen-gpios = <_gpio 26 GPIO_ACTIVE_HIGH>;
+   ti,als-supply = <_l11>;
+
+   ti,boost-freq = <50>;
+   ti,boost-ovp = <24>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   als {
+   ti,als-resistance = 

Re: [PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Maxime Ripard]

Hi,

On Fri, Oct 23, 2015 at 07:46:16AM +0800, Vishnu Patekar wrote:
> + memory {
> + reg = <0x4000 0x8000>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>;

Shouldn't the number of CPUs be 8?

> + clock-frequency = <2400>;
> + arm,cpu-registers-not-fw-configured;
> + };

Is there some u-boot support for this SoC yet?

If so, both the memory node and the clock-frequency and
arm,cpu-registers-not-fw-configured properties are useless (and
harmful for the latter).

> + soc@01c0 {

Please remove the address. It's both wrong and useless.

> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + gic: interrupt-controller@01c81000 {
> + compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
> + reg = <0x01c81000 0x1000>,
> +   <0x01c82000 0x1000>,
> +   <0x01c84000 0x2000>,
> +   <0x01c86000 0x2000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + pio: pinctrl@01c20800 {
> + compatible = "allwinner,sun8i-a83t-pinctrl";
> + interrupts = ,
> + ,
> + ;

Please align these lines with the first one, like you did for the
GIC's reg for example.

> + reg = <0x01c20800 0x400>;
> + clocks = <>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #gpio-cells = <3>;
> +
> + i2c0_pins_a: i2c0@0 {
> + allwinner,pins = "PH0", "PH1";
> + allwinner,function = "i2c0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + i2c1_pins_a: i2c1@0 {
> + allwinner,pins = "PH2", "PH3";
> + allwinner,function = "i2c1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + i2c2_pins_a: i2c2@0 {
> + allwinner,pins = "PH4", "PH5";
> + allwinner,function = "i2c2";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + mmc0_pins_a: mmc0@0 {
> + allwinner,pins = "PF0", "PF1", "PF2",
> +  "PF3", "PF4", "PF5";
> + allwinner,function = "mmc0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + mmc1_pins_a: mmc1@0 {
> + allwinner,pins = "PG0", "PG1", "PG2",
> +  "PG3", "PG4", "PG5";
> + allwinner,function = "mmc1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + mmc2_8bit_pins: mmc2_8bit {
> + allwinner,pins = "PC5", "PC6", "PC8",
> +  "PC9", "PC10", "PC11",
> +  "PC12", "PC13", "PC14",
> +  "PC15";
> + allwinner,function = "mmc2";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart0_pins_a: uart0@0 {
> + allwinner,pins = "PF2", "PF4";
> + allwinner,function = "uart0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart0_pins_b: uart0@1 {
> + allwinner,pins = "PB9", "PB10";
> + allwinner,function = "uart0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };

Are you going to use all these options?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 

Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 10/24/2015 05:14 PM, Mark Brown wrote:

On Fri, Oct 23, 2015 at 07:11:56PM -0500, Andrew F. Davis wrote:

On 10/23/2015 06:18 PM, Mark Brown wrote:



mt6397 doesn't do this, it doesn't have a compatible string at all (it's
doing what I'm recommending that you do).  The SPMI devices are
standalone devices, their parent device is actually functioning as a bus
controller here (it's really a microcontroller inside the SoC).  The
Palmas is part of how we realised this was a problem.



mt6397: Documentation/devicetree/bindings/mfd/mt6397.txt
Doing exactly what I'm doing,


Tbe binding document is buggy and doesn't reflect the code, there's no
compatible string in the driver.



Sure there is:

drivers/mfd/mt6397-core.c:48:
.of_compatible = "mediatek,mt6397-regulator",

Then mfd_add_devices uses this to find the regulator node and fill
in .of_node, then in the regulator driver:

drivers/regulator/mt6397-regulator.c:48:
.of_match = of_match_ptr(match),

which uses your helper to match the nodes in the filled in .of_node.


The Palmas is a great example of why this is a good idea, there are
so many spins on this common base, and look how we can re-use sub-nodes:


There's no real reuse here, we have to have a table in both the MFD and
regulator listing every variant.


That's not true, the only variant that needs its own table is the tps65917,
and that's for the IRQ and regulator differences. The RTC, pwrbutton, and
GPIO nodes are completely variant agnostic and their drivers are reused
by just adding their subnode to a new PMIC device node.


Remember that the only reason the user
is having to type most of those subnodes at all is that we pushed things
into the DT, if someone forgot to include one of the nodes in their
board DT then they won't be able to use the relevant feature even if
it's there.



This is what DT is for, we want to push this kind of thing into DT, the
driver should not have to know the devices hardware configuration anymore
that in needs to.


The fact that the SoC DT is not distinct from the board DT is actually
one of the problems with the way we're using DT at the minute, it means
that DTBs are much less stable than they should be since we can enhance
support for SoCs but DTBs need regenerating to take advantage of it.  It
would be much better if the boards just referenced the SoC they use and
pulled in a separate definition of the SoC (DT overlays will make it
much more tractable to implement that if someone has time...).



I figured this can already be done by keeping the SoC stuff in dtsi files?


That doesn't help with the above issue, include files get processed at
the time the binary is generated.



Yeah so the board DT and the SoC DT are already mostly separate, it would
then just be a matter enforcing where nodes are defined.


Well I have to match the sub-devices on something, it's ether the node name
or the compatible string, so they might have to get used to typing :)


No, that's not the case - remember, users don't have to write a new
driver every time they instantiate a device on a board.  They're going
to have to list the in-use regulators one way or another but if we have
the extra compatible for regulators they have to bind both the core
device (which is going to be required anyway due to the control bus) and
the subnode saying that it has regulators (which we knew anyway as soon
as we knew we had the core device).



We don't know what sub-devices the core device has, PMICs are more like
SoCs on a bus than a regular device, the sub-parts change with every spin and
we can represent this in DT like we do with SoCs. Else we would have to have
a new core binding for every spin. We know what devices are on a particular
SoC too, but we still list them and match them in DT so some SoC driver
doesn't have to.

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

[PATCH] arm: Test for CONFIG_USE_OF to handle the USE_OF=n/OF=y case

[Geert Uytterhoeven]

Until commit 0166dc11be911213 ("of: make CONFIG_OF user selectable"),
CONFIG_OF=y implied CONFIG_USE_OF=y on ARM, as the former could solely
be enabled by being selected by the latter.

However, if the user now manually enables CONFIG_OF=y while
CONFIG_USE_OF=n:

arch/arm/kernel/devtree.c: In function 'setup_machine_fdt':
arch/arm/kernel/devtree.c:215:2: error: implicit declaration of function 
'early_init_dt_verify' [-Werror=implicit-function-declaration]
  if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
  ^
arch/arm/kernel/devtree.c:218:2: error: implicit declaration of function 
'of_flat_dt_match_machine' [-Werror=implicit-function-declaration]
  mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
  ^
arch/arm/kernel/devtree.c:218:8: warning: assignment makes pointer from 
integer without a cast
  mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
^
arch/arm/kernel/devtree.c:228:3: error: implicit declaration of function 
'of_get_flat_dt_root' [-Werror=implicit-function-declaration]
   dt_root = of_get_flat_dt_root();
   ^
arch/arm/kernel/devtree.c:229:3: error: implicit declaration of function 
'of_get_flat_dt_prop' [-Werror=implicit-function-declaration]
   prop = of_get_flat_dt_prop(dt_root, "compatible", );
   ^
arch/arm/kernel/devtree.c:229:8: warning: assignment makes pointer from 
integer without a cast
   prop = of_get_flat_dt_prop(dt_root, "compatible", );
^
arch/arm/kernel/devtree.c:244:2: error: implicit declaration of function 
'early_init_dt_scan_nodes' [-Werror=implicit-function-declaration]
  early_init_dt_scan_nodes();
  ^

and

arch/arm/kernel/built-in.o: In function `setup_arch':
arch/arm/kernel/setup.c:940: undefined reference to `setup_machine_fdt'
arch/arm/kernel/setup.c:979: undefined reference to `arm_dt_init_cpu_maps'

Replace tests for CONFIG_OF by tests for CONFIG_USE_OF where appropriate
to fix this.

Signed-off-by: Geert Uytterhoeven 
---
Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/12531538/

I only fixed the particular issue with the randconfig from the build
above.  Are there more tests for CONFIG_OF that should be converted to
CONFIG_USE_OF?
---
 arch/arm/include/asm/prom.h | 6 +++---
 arch/arm/kernel/Makefile| 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index cd94ef2ef283e14e..aac51015d18e27fb 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -11,12 +11,12 @@
 #ifndef __ASMARM_PROM_H
 #define __ASMARM_PROM_H
 
-#ifdef CONFIG_OF
+#ifdef CONFIG_USE_OF
 
 extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
 extern void __init arm_dt_init_cpu_maps(void);
 
-#else /* CONFIG_OF */
+#else /* CONFIG_USE_OF */
 
 static inline const struct machine_desc *setup_machine_fdt(unsigned int 
dt_phys)
 {
@@ -25,5 +25,5 @@ static inline const struct machine_desc 
*setup_machine_fdt(unsigned int dt_phys)
 
 static inline void arm_dt_init_cpu_maps(void) { }
 
-#endif /* CONFIG_OF */
+#endif /* CONFIG_USE_OF */
 #endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index af9e59bf3831b9fd..4f6014eee0fe65bd 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_ARM_THUMBEE) += thumbee.o
 obj-$(CONFIG_KGDB) += kgdb.o patch.o
 obj-$(CONFIG_ARM_UNWIND)   += unwind.o
 obj-$(CONFIG_HAVE_TCM) += tcm.o
-obj-$(CONFIG_OF)   += devtree.o
+obj-$(CONFIG_USE_OF)   += devtree.o
 obj-$(CONFIG_CRASH_DUMP)   += crash_dump.o
 obj-$(CONFIG_SWP_EMULATE)  += swp_emulate.o
 CFLAGS_swp_emulate.o   := -Wa,-march=armv7-a
-- 
1.9.1

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

Re: [PATCH 18/30] nfc: st-nci: Add support for proprietary commands for factory tests

[Christophe Ricard]

Hi Samuel,

I think my last last answer:
"I believe a "complete regardless of the event" we are receiving (on the 
loopback gate) may hide a CLF firmware bug and should not happen...


Are you in favour of hiding a potential bug ?"

Was not so smart from my side.

You are right considering a system should not be locked because of a 
buggy NFC controller.

Also an error message will be enough to notify a potential bug...

I will apply your remark where possible.

Sorry for that.

Best Regards
Christophe

On 24/10/2015 14:19, Christophe Ricard wrote:

Hi Samuel,

On 24/10/2015 08:48, Samuel Ortiz wrote:

Hi Christophe,

Just a couple of nitpicks:

On Tue, Oct 20, 2015 at 11:48:09PM +0200, Christophe Ricard wrote:

diff --git a/drivers/nfc/st-nci/Makefile b/drivers/nfc/st-nci/Makefile
index 348ce76..60e569b 100644
--- a/drivers/nfc/st-nci/Makefile
+++ b/drivers/nfc/st-nci/Makefile
@@ -2,7 +2,7 @@
  # Makefile for ST21NFCB NCI based NFC driver
  #
  -st-nci-objs = ndlc.o core.o st-nci_se.o
+st-nci-objs = ndlc.o core.o st-nci_se.o st-nci_vendor_cmds.o

Please rename that file to vendor_cmds.c.
I pushed a change to rename st-nci_se.c to se.c already, to keep the
file names consistent there.
I think your latest change introduced a build break :(. The log 
message mention also MFC instead of NFC ;).


"In file included from drivers/nfc/st-nci/ndlc.c:23:0:
drivers/nfc/st-nci/st-nci.h:22:23: fatal error: st-nci_se.h: No such 
file or directory

#include "st-nci_se.h""
I will send a fix in the v2 ;).




  obj-$(CONFIG_NFC_ST_NCI) += st-nci.o
st-nci_i2c-objs = i2c.o
diff --git a/drivers/nfc/st-nci/core.c b/drivers/nfc/st-nci/core.c
index c419d39..fd2a5ca 100644
--- a/drivers/nfc/st-nci/core.c
+++ b/drivers/nfc/st-nci/core.c
@@ -25,6 +25,7 @@
#include "st-nci.h"
  #include "st-nci_se.h"
+#include "st-nci_vendor_cmds.h"

Ditto: Please rename it to vendor_cmds.h.

Don't you think it would be better for headers to either:
- merge st-nci_se.h and st-nci_vendor_cmds.h in st-nci.h
- or keep st-nci_ prefix for header files only.
Which option do you prefer ?

I have no concern to remove the st-nci prefix and the st21nfca for .c 
file in their respective directory.


+void st_nci_hci_loopback_event_received(struct nci_dev *ndev, u8 
event,

+struct sk_buff *skb)
+{
+struct st_nci_info *info = nci_get_drvdata(ndev);
+
+switch (event) {
+case ST_NCI_EVT_POST_DATA:
+info->vendor_info.rx_skb = skb;
+
+complete(>vendor_info.req_completion);
+break;
+}

Wouldn't it make sense to complete regardless of the event you're
receiving ?
Since you're checking for rx_skb after the completion, it's safe and
would prevent you from being stuck waiting for the right event in the
below routine.
The only reason for receiving a EVT_POST_DATA from the CLF loopback 
gate should come from a

previous EVT_POST_DATA sent from the Device Host.
The loopback gate is a standard hci echo test mechanism.

Also, according to etsi 102 622 and ST implementation, the loopback 
gate only support EVT_POST_DATA.


I believe a "complete regardless of the event" we are receiving (on 
the loopback gate) may hide a CLF firmware bug and should not happen...


Are you in favour of hiding a potential bug ?

[snip]

Best Regards
Christophe


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

Re: [PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix

[Michael Welling]

On Sun, Oct 25, 2015 at 12:36:37PM +, Jonathan Cameron wrote:
> Small point, Michael. Please add such acks below the the Author sign off.
> Otherwise sometimes I miss them!  Added it now for this one.

Okay sorry about the misplacement.

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

Re: [linux-nfc] [PATCH 18/30] nfc: st-nci: Add support for proprietary commands for factory tests

[Samuel Ortiz]

On Sun, Oct 25, 2015 at 06:17:48PM +0100, Samuel Ortiz wrote:
> > >Please rename that file to vendor_cmds.c.
> > >I pushed a change to rename st-nci_se.c to se.c already, to keep the
> > >file names consistent there.
> > I think your latest change introduced a build break :(. The log
> > message mention also MFC instead of NFC ;).
> > 
> > "In file included from drivers/nfc/st-nci/ndlc.c:23:0:
> > drivers/nfc/st-nci/st-nci.h:22:23: fatal error: st-nci_se.h: No such
> > file or directory
> > #include "st-nci_se.h""
> > I will send a fix in the v2 ;).
> Sorry about that. I'll fix it up.
Should be fixed now.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Andrew F. Davis]

On 10/23/2015 10:45 AM, Tim Bird wrote:

I've been worried about DT overhead adding to boot time for a while.
And IMHO probe deferral is just about the lamest way to solve boot
order dependencies I can imagine, from a computer science perspective.
(Well, there's a certain elegance to it, but it's a stupid "make
everything re-doable, back up and start over, time-wasting" elegance.)



It has a bogosort kind of elegance. :)

Also this might be a silly question (I haven't been following this issue
for very long), but as the only place that can really know what devices
depend on each other, in a generic kernel, is the DT (or whatever
abstraction) will we not eventually need to solve this issue there? Could
we just add a "depends-on = <>;" to nodes when we know they are
needed for our board?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html