Re: [yocto] how to create a named_pipe in my image

[Baumann, Michael]

Thank you Ross.
Switching to rpm package showed the same behavior.
Is there another workaround than a post install script?

Regards,
Michael

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, February 08, 2016 5:15 PM
To: Baumann, Michael
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] how to create a named_pipe in my image


On 8 February 2016 at 16:12, Baumann, Michael 
> wrote:
Possibly it's because named pipes cannot be packed into an archive? If yes, how 
can I circumvent this?

It would be interesting to see what happens if you change PACKAGE_CLASSES to 
use rpm instead of ipkg.  One workaround would be to create the fifo in a 
postinst.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to create a named_pipe in my image

[Burton, Ross]

On 8 February 2016 at 16:12, Baumann, Michael 
wrote:

> Possibly it's because named pipes cannot be packed into an archive? If
> yes, how can I circumvent this?
>

It would be interesting to see what happens if you change PACKAGE_CLASSES
to use rpm instead of ipkg.  One workaround would be to create the fifo in
a postinst.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] fortran in yocto

[Liubchynskyi, Stanislav (Nokia - PL/Wroclaw)]

Hi,
I want to add fortran support to yocto build. I try different way whitch 
describe in the ethernet but enyone does't work. I use fido branch and gcc 4.9. 
Can you describe me step by step how to enable fortran in yocto or where I can 
find work instruction.
Thanks for help.



Best regards,

Stanislav Liubchynskyi
Software Developer, LFS, OPSW Wroclaw
Mobile Broadband, Nokia Networks

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 00/29] Backports and other features for Galileo

[Bruce Ashfield]

On 16-02-05 09:53 AM, Saul Wold wrote:

Bruce,

This is a set of patches that are currently being maintained in the
meta-intel-galileo BSP which we are working to merge into meta-intel
proper.

These include items that are backported from newer versions as well
as some galileo specific items.

There is one ARM patch that touches i2c and is related to handling sensors.

I pushed this patch set to linux-yocto-contrib/sgw/patched


Looks like PaulG made it through the series before I did! I really don't
have much to add on top of what he's suggested.

So if we do a v2 with those minor issues addressed, this will be a simple
merge into the tree.

Bruce



Thanks
Sau!

Andy Shevchenko (8):
   mfd: core: redo ACPI matching of the children devices
   mfd: intel_quark_i2c_gpio: load gpio driver first
   mfd: intel_quark_i2c_gpio: support devices behind i2c bus
   gpio: pca953x: store driver_data for future use
   gpio: pca953x: support ACPI devices found on Galileo Gen2
   at24: enable ACPI device found on Galileo Gen2
   pwm-pca9685: enable ACPI device found on Galileo Gen2
   gpio: pca953x: provide GPIO base based on _UID

Hanjun Guo (1):
   GPIO / ACPI: export acpi_gpiochip_request(free)_interrupts for module
 use

Ismo Puustinen (5):
   acpi: added a custom DSDT file.
   acpi: updated DSDT table for SPI devices.
   spi-pxa2xx: fixed ACPI-based enumeration of SPI devices.
   adc1x8s102: support ACPI-based enumeration.
   gpio-pca953x: add "drive" property.

Jan Luebbe (1):
   i2c: core: only use set_scl for bus recovery after calling
 prepare_recovery

Jarkko Nikula (1):
   i2c: core: Reduce stack size of acpi_i2c_space_handler()

Josef Ahmad (1):
   pca9685: PCA9685 PWM and GPIO multi-function device.

Mika Westerberg (5):
   i2c / ACPI: Use 0 to indicate that device does not have interrupt
 assigned
   i2c / ACPI: Assign IRQ for devices that have GpioInt automatically
   gpio / ACPI: Add support for retrieving GpioInt resources from a
 device
   gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
   i2c / ACPI: Rework I2C device scanning

Nishanth Menon (1):
   ARM: dts: am335x-boneblack: configure i2c1 and 2

Shailendra Verma (1):
   i2c: core: fix typo in comment

Todor Minchev (1):
   staging:iio: add support for ADC1x8s102.

Tomasz Duszynski (1):
   iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751
 ambient light sensors

Vladimir Zapolskiy (1):
   i2c: fix leaked device refcount on of_find_i2c_* error path

Wolfram Sang (2):
   i2c: slave: add error messages to slave core
   i2c: check for proper length of the reg property

  Documentation/acpi/enumeration.txt   |   11 +-
  arch/arm/boot/dts/am335x-boneblack.dts   |   30 +
  drivers/gpio/gpio-pca953x.c  |  123 +++-
  drivers/gpio/gpiolib-acpi.c  |   40 +-
  drivers/gpio/gpiolib-sysfs.c |   78 ++
  drivers/gpio/gpiolib.c   |   18 +
  drivers/gpio/gpiolib.h   |7 +-
  drivers/i2c/i2c-core.c   |  179 +++--
  drivers/iio/light/Kconfig|   10 +
  drivers/iio/light/Makefile   |1 +
  drivers/iio/light/bh1750.c   |  334 +
  drivers/mfd/Kconfig  |   10 +
  drivers/mfd/Makefile |2 +
  drivers/mfd/intel_quark_i2c_gpio.c   |   32 +-
  drivers/mfd/mfd-core.c   |   52 +-
  drivers/mfd/pca9685-core.c   |  308 
  drivers/mfd/pca9685-gpio.c   |  108 +++
  drivers/mfd/pca9685-pwm.c|  262 +++
  drivers/mfd/pca9685.h|  110 +++
  drivers/misc/eeprom/at24.c   |   22 +-
  drivers/pwm/Kconfig  |2 +-
  drivers/pwm/pwm-pca9685.c|   20 +-
  drivers/spi/spi-pxa2xx-pci.c |1 +
  drivers/staging/iio/adc/Kconfig  |   13 +
  drivers/staging/iio/adc/Makefile |1 +
  drivers/staging/iio/adc/adc1x8s102.c |  437 +++
  include/DSDT.hex | 1166 ++
  include/asm-generic/gpio.h   |5 +
  include/linux/acpi.h |7 +
  include/linux/gpio.h |   10 +
  include/linux/gpio/consumer.h|   11 +
  include/linux/gpio/driver.h  |2 +
  include/linux/mfd/core.h |   10 +-
  include/linux/platform_data/adc1x8s102.h |   30 +
  include/linux/platform_data/pca9685.h|   51 ++
  35 files changed, 3390 insertions(+), 113 deletions(-)
  create mode 100644 drivers/iio/light/bh1750.c
  create mode 100644 drivers/mfd/pca9685-core.c
  create mode 100644 drivers/mfd/pca9685-gpio.c
  create mode 100644 drivers/mfd/pca9685-pwm.c
  create mode 100644 drivers/mfd/pca9685.h
  create mode 100644 drivers/staging/iio/adc/adc1x8s102.c
  create mode 100644 include/DSDT.hex
  create mode 100644 include/linux/platform_data/adc1x8s102.h
  create mode 100644 

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

[Burton, Ross]

On 5 February 2016 at 10:45, Reshetova, Elena 
wrote:

> recipe.r_deps = d.getVar('RDEPENDS_' + recipe.name, True)
>
>
>
> or even simple:
>
>
>
> recipe.r_deps = d.getVar('RDEPENDS’, True)
>
>
Did you mean RDEPENDS_ + package name?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

[Reshetova, Elena]

 

On 5 February 2016 at 10:45, Reshetova, Elena  > wrote:

recipe.r_deps = d.getVar('RDEPENDS_' +   recipe.name, True)

 

or even simple:

 

recipe.r_deps = d.getVar('RDEPENDS’, True)


>Did you mean RDEPENDS_ + package name?

 

I have it like this: 

 

recipe.name = d.getVar('PN', True)

recipe.r_deps = d.getVar('RDEPENDS_' +   recipe.name, True)

 

Best Regards,
Elena.

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to create a named_pipe in my image

[Baumann, Michael]

To make my question more precise:

mkfifo in the do_install() section works. I can see the named pipe in 
build/tmp-glibc/work/*/*/*/ but my bitbake hangs in the  do_package_write_ipk 
and do_package_qa tasks.
Possibly it's because named pipes cannot be packed into an archive? If yes, how 
can I circumvent this?

Regards
Michael

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Baumann, Michael
>Sent: Monday, February 08, 2016 4:07 PM
>To: yocto@yoctoproject.org
>Subject: [yocto] how to create a named_pipe in my image
>
>Hi,
>
>I try to create a named pipe (fifo) for my target filesystem.
>I tried it in my .bb file in the do_install() section with "mkfifo
>"
>
>Any ideas gratefully received.
>
>Regards
>Michael
>--
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

[Burton, Ross]

On 8 February 2016 at 16:20, Reshetova, Elena 
wrote:

> >Did you mean RDEPENDS_ + package name?
>
>
>
> I have it like this:
>
>
>
> recipe.name = d.getVar('PN', True)
>
> recipe.r_deps = d.getVar('RDEPENDS_' + recipe.name, True)
>

So I wasn't quite right - I think you also need to come after
do_packagedata and also you'll need to read the subpackage metadata.
Inspired by insane.bbclass, this works:

addtask printrdeps before do_build after do_package do_packagedata
do_printrdeps[nostamp] = "1"
python do_printrdeps() {
bb.build.exec_func("read_subpackage_metadata", d)
for p in d.getVar("PACKAGES", True).split():
bb.warn("Got package %s" % p)
bb.warn("Got RDEPENDS %s" % d.getVar("RDEPENDS_" + p, True))
}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] fortran in yocto

[Ioan-Adrian Ratiu]

Hi

On Mon, 8 Feb 2016 08:19:53 +
"Liubchynskyi, Stanislav (Nokia - PL/Wroclaw)" 
 wrote:

> Hi,
> I want to add fortran support to yocto build. I try different way whitch 
> describe in the ethernet but enyone does't work. I use fido branch and gcc 
> 4.9. Can you describe me step by step how to enable fortran in yocto or where 
> I can find work instruction.
> Thanks for help.

Fortran support in gcc is disabled by default, to enable it add the following 
line to your config, then build the libgfortran package.

FORTRAN_forcevariable = ",fortran"

> 
> 
> 
> Best regards,
> 
> Stanislav Liubchynskyi
> Software Developer, LFS, OPSW Wroclaw
> Mobile Broadband, Nokia Networks
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing only part of linux-firmware

[Burton, Ross]

On 7 February 2016 at 21:49, Chris Tapp  wrote:

> I’ve now done this by creating a bbappend for linux-firmware:
>
> PACKAGES =+ "${PN}-rtl_nic"
>
> FILES_${PN}-rtl_nic = " \
>   /lib/firmware/rtl_nic/* \
> “
>
> Does what I want, but is that the best way of doing it?
>

This is the best way for you now.

That's exactly why the recipe has quite a lot of subpackages, feel free to
submit more upstream.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

[Reshetova, Elena]

>So I wasn't quite right - I think you also need to come after do_packagedata 
>and also you'll need to read the subpackage metadata.  Inspired by 
>insane.bbclass, this works:



>addtask printrdeps before do_build after do_package do_packagedata

>do_printrdeps[nostamp] = "1"

>python do_printrdeps() {

>bb.build.exec_func("read_subpackage_metadata", d)

>for p in d.getVar("PACKAGES", True).split():

>bb.warn("Got package %s" % p)

>bb.warn("Got RDEPENDS %s" % d.getVar("RDEPENDS_" + p, True))

>}



Yes, this actually works. Thank you very much Ross!



Best Regards,
Elena.





smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where should I append Yocto bitbake task to create work folder symlink ?

[Woronicz, Bartosz ( NSN - PL/Wroclaw)]

The problem is, it doesn't doit delirebately,

when I run

bitbake -f -c latest_link myrecipe , it works

when the process is in the tasks batch running
bitbake myrecipe
it doesn't
What am I doing wrong ?

Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
NSN - PL/Wroclaw

On 04.02.2016 12:07, EXT Woronicz, Bartosz ( NSN - PL/Wroclaw) wrote:

Whoa,

That's great! However I modified it, so the link will be relative

The problem is that it works until you have sstate cache empty, 
because after that it doesn't fetch and unpack when already have it in


do_latest_link() {
if [ -n "${WORKDIR}" ]; then
linkname="$(basename $(dirname ${WORKDIR}))/latest"
rm -f $linkname
ln -s ${WORKDIR} $linkname
fi
}
addtask latest_link after do_unpack


Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
NSN - PL/Wroclaw

On 03.02.2016 12:05, EXT Maciek Borzecki wrote:
On śro, 2016-02-03 at 11:13 +0100, Woronicz, Bartosz ( NSN - 
PL/Wroclaw) wrote:

Let's say I have my package at

  host-64/tmp/work/x86_64-poky-linux/mypackage/1.2.3-r4/

I would like to have symlink created

  host-64/tmp/work/x86_64-poky-linux/mypackage/latest -> 1.2.3-r4/

each time the new version is fetched and unpacked. How can I achieve
that ? Which class, task should I append, extend ?

Optionally, I would like to have that for all packages or at least
packages in my meta.


P.S. I asked the same question here:
http://stackoverflow.com/questions/35158764/where-should-i-append-yocto-bitbake-task-to- 


create-work-folder-symlink


Put that into a class in your layer, ex. latest-link.bbclass (untested):

do_latest_link() {
if [ -n "${WORKDIR}" ]; then
linkname="$(dirname ${WORKDIR})/latest"
rm -f $linkname
ln -s ${WORKDIR} $linkname
fi
}
addtask latest_link after do_unpack


If you want that applied to all the recipes then add INHERIT += 
"latest-link" in your
local.conf. The other way is just to 'inherit latest-link' in 
individual recipes.







--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [Build dependencies]

[magiczna_dupa]

Hello,

I am trying to use some things from one recipe in another the things what I 
did:

Defined default package with files the next step I added in another recipe 
dependencies field.
So as I check defaul .rpms was generated with proper contain. But when I look 
to my child recipe there is no files nor in root system path. I dont know 
what to do please help

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where should I append Yocto bitbake task to create work folder symlink ?

[Maciek Borzecki]

On pon, 2016-02-08 at 14:20 +0100, Woronicz, Bartosz ( NSN - PL/Wroclaw) wrote:
> The problem is, it doesn't doit delirebately,
> 
> when I run
> 
> bitbake -f -c latest_link myrecipe , it works
> 
> when the process is in the tasks batch running
> bitbake myrecipe
> it doesn't
> What am I doing wrong ?

Try adding:

do_latest_link[nostamp] = "1"

This should cause the task to be run each time.

-- 
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
lub poufne informacje i została wysłana wyłącznie do wiadomości i
użytku osób, do których została zaadresowana. Jeśli wiadomość została
otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
osób trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.

This message, including any attachments hereto, may contain privileged
or confidential information and is sent solely for the attention and
use of the intended addressee(s). If you are not an intended addressee,
you may neither use this message nor copy or deliver it to anyone. In
such case, you should immediately destroy this message and kindly notify
the sender by reply email. Thank you.



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to create a named_pipe in my image

[Baumann, Michael]

Hi,

I try to create a named pipe (fifo) for my target filesystem. 
I tried it in my .bb file in the do_install() section with "mkfifo 
"

Any ideas gratefully received.

Regards 
Michael
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH v2] iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors

[Saul Wold]

From: Tomasz Duszynski 

commit 3a11fbb037a1ecd3e1070ee484f1ea887133f21b upstream

Add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light
sensors.

Signed-off-by: Tomasz Duszynski 
Signed-off-by: Jonathan Cameron 
---
v2: seperate from larger set and add upstream commit info

 drivers/iio/light/Kconfig  |  10 ++
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/bh1750.c | 334 +
 3 files changed, 345 insertions(+)
 create mode 100644 drivers/iio/light/bh1750.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 3d7bafa..0ce46fd 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -37,6 +37,16 @@ config APDS9300
 To compile this driver as a module, choose M here: the
 module will be called apds9300.
 
+config BH1750
+   tristate "ROHM BH1750 ambient light sensor"
+   depends on I2C
+   help
+Say Y here to build support for the ROHM BH1710, BH1715, BH1721,
+BH1750, BH1751 ambient light sensors.
+
+To compile this driver as a module, choose M here: the module will
+be called bh1750.
+
 config CM32181
depends on I2C
tristate "CM32181 driver"
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 90e7fd2..11c181c 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
 obj-$(CONFIG_APDS9300) += apds9300.o
+obj-$(CONFIG_BH1750)   += bh1750.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
 obj-$(CONFIG_CM3323)   += cm3323.o
diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
new file mode 100644
index 000..564c2b3
--- /dev/null
+++ b/drivers/iio/light/bh1750.c
@@ -0,0 +1,334 @@
+/*
+ * ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensor driver
+ *
+ * Copyright (c) Tomasz Duszynski 
+ *
+ * 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.
+ *
+ * Data sheets:
+ *  
http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1710fvc-e.pdf
+ *  
http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1715fvc-e.pdf
+ *  
http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1721fvc-e.pdf
+ *  
http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1750fvi-e.pdf
+ *  
http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1751fvi-e.pdf
+ *
+ * 7-bit I2C slave addresses:
+ *  0x23 (ADDR pin low)
+ *  0x5C (ADDR pin high)
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BH1750_POWER_DOWN  0x00
+#define BH1750_ONE_TIME_H_RES_MODE 0x20 /* auto-mode for BH1721 */
+#define BH1750_CHANGE_INT_TIME_H_BIT   0x40
+#define BH1750_CHANGE_INT_TIME_L_BIT   0x60
+
+enum {
+   BH1710,
+   BH1721,
+   BH1750,
+};
+
+struct bh1750_chip_info;
+struct bh1750_data {
+   struct i2c_client *client;
+   struct mutex lock;
+   const struct bh1750_chip_info *chip_info;
+   u16 mtreg;
+};
+
+struct bh1750_chip_info {
+   u16 mtreg_min;
+   u16 mtreg_max;
+   u16 mtreg_default;
+   int mtreg_to_usec;
+   int mtreg_to_scale;
+
+   /*
+* For BH1710/BH1721 all possible integration time values won't fit
+* into one page so displaying is limited to every second one.
+* Note, that user can still write proper values which were not
+* listed.
+*/
+   int inc;
+
+   u16 int_time_low_mask;
+   u16 int_time_high_mask;
+}
+
+static const bh1750_chip_info_tbl[] = {
+   [BH1710] = { 140, 1022, 300, 400,  25000, 2, 0x001F, 0x03E0 },
+   [BH1721] = { 140, 1020, 300, 400,  25000, 2, 0x0010, 0x03E0 },
+   [BH1750] = { 31,  254,  69,  1740, 5750,  1, 0x001F, 0x00E0 },
+};
+
+static int bh1750_change_int_time(struct bh1750_data *data, int usec)
+{
+   int ret;
+   u16 val;
+   u8 regval;
+   const struct bh1750_chip_info *chip_info = data->chip_info;
+
+   if ((usec % chip_info->mtreg_to_usec) != 0)
+   return -EINVAL;
+
+   val = usec / chip_info->mtreg_to_usec;
+   if (val < chip_info->mtreg_min || val > chip_info->mtreg_max)
+   return -EINVAL;
+
+   ret = i2c_smbus_write_byte(data->client, BH1750_POWER_DOWN);
+   if (ret < 0)
+   return ret;
+
+   regval = (val & chip_info->int_time_high_mask) >> 5;
+   ret = i2c_smbus_write_byte(data->client,
+  BH1750_CHANGE_INT_TIME_H_BIT | regval);
+   if (ret < 0)
+   return ret;
+
+   regval = val & 

Re: [linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned

[Saul Wold]

On Sun, 2016-02-07 at 17:09 -0500, Paul Gortmaker wrote:
> [[linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that
> device does not have interrupt assigned] On 05/02/2016 (Fri 06:53)
> Saul Wold wrote:
> 
> > From: Mika Westerberg 
> 
> Normally here at this point it is nice to see:
> 
> commit dab472eb931bc2916fa779e56deccd0ec319cf5b upstream.
> 
> This is the convention used by all the stable kernel maintenance
> trees.

Paul, Thanks!  This is the first kernel patch set I am sending,
appreciate the feedback, I send patches elsewhere but the conventions
are different.

I will break this series up and add the upstream note where I find
them.

> It makes it much easier to decide when later that we can toss it
> based
> on moving to a new kernel version.  For example:
> 
> paul@yow-builder:~/git/linux-head$ git describe dab472eb931
> v4.1-rc3-44-gdab472eb931b
> 
> ...so the commit was created on a 4.1-rc3 baseline, but...
> 
> paul@yow-builder:~/git/linux-head$ git describe --contains
> dab472eb931
> v4.2-rc1~158^2~28
> 
> ...not merged to mainline until 158 commits before the 4.2-rc1 tag
> marked the end of the 4.2 development cycle.  So anything pre-4.2
> will
> need to carry this.
> 
> Normally I use some script to toss the output of the above two lines
> into a comment above the commit in the scc file, which also eases the
> carry forward load of bigger BSP patch series.
> 
Willing to share your script?

> It also permits automated "reviewbots" that can do things like look
> at
> the diffstat of the original and compare it to the backport and flag
> glaring differences.
> 
> > 
> > This is the convention used in most parts of the kernel including
> > DT
> > counterpart of I2C slave enumeration. To make things consistent do
> > the same
> > for ACPI I2C slave enumeration path as well.
> > 
> > Signed-off-by: Mika Westerberg 
> > Acked-by: Wolfram Sang 
> > Signed-off-by: Linus Walleij 
> 
> I wonder about the auto-Cc collection of mail addresses in the
> linux-yocto case.  It might be a bit of a coin toss; but I'm leaning
> towards leaving them off, esp. when the 0/N didn't include all the
> ppl
> to give them context.  Maintainers/authors probably get enough
> revisit
> spam from all the "official" stable trees, hence why I'd lean towards
> leaving them out for other custom/forked projects like this.
> 

I will ensure not to send to the Cc list in the future.

Thanks
  Sau!

> So, no real problem with the patch itself, but just a couple of
> process
> steps that I've found definitely helpful in the past.
> 
> Paul.
> --
> 
> > 
> > Upstream-status: Backport
> > Signed-off-by: Saul Wold 
> > ---
> >  drivers/i2c/i2c-core.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index 987c124..c21b3de 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -107,7 +107,7 @@ static int acpi_i2c_add_resource(struct
> > acpi_resource *ares, void *data)
> >     if (sb->access_mode ==
> > ACPI_I2C_10BIT_MODE)
> >     info->flags |= I2C_CLIENT_TEN;
> >     }
> > -   } else if (info->irq < 0) {
> > +   } else if (!info->irq) {
> >     struct resource r;
> >  
> >     if (acpi_dev_resource_interrupt(ares, 0, ))
> > @@ -134,7 +134,6 @@ static acpi_status
> > acpi_i2c_add_device(acpi_handle handle, u32 level,
> >  
> >     memset(, 0, sizeof(info));
> >     info.fwnode = acpi_fwnode_handle(adev);
> > -   info.irq = -1;
> >  
> >     INIT_LIST_HEAD(_list);
> >     ret = acpi_dev_get_resources(adev, _list,
> > -- 
> > 2.5.0
> > 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] how to create a named_pipe in my image

[Burton, Ross]

On 8 February 2016 at 16:39, Baumann, Michael 
wrote:

> Switching to rpm package showed the same behavior.
>
> Is there another workaround than a post install script?
>
>
So I had a quick look at this.  The fifo certainly ends up in the resulting
ipk at least, but as you say package_qa hangs.  It's probably encountering
a non-file and breaking somewhere.  A really nasty workaround until this is
fixed would be to put in your recipe:

python do_package_qa() {}

(to stub out the package_qa task)

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to create a named_pipe in my image

[Burton, Ross]

On 8 February 2016 at 17:36, Burton, Ross  wrote:

> So I had a quick look at this.  The fifo certainly ends up in the
> resulting ipk at least, but as you say package_qa hangs.  It's probably
> encountering a non-file and breaking somewhere.  A really nasty workaround
> until this is fixed would be to put in your recipe:
>

Found the bug - we were trying to open a fifo as a file to see if it was an
ELF binary, and reading an empty fifo blocks...  I've just send a patch to
the list that fixes this.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned

[Paul Gortmaker]

[Cc trimmed of non-yocto folks to spare them the noise]

[Re: [linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does 
not have interrupt assigned] On 08/02/2016 (Mon 09:13) Saul Wold wrote:

> On Sun, 2016-02-07 at 17:09 -0500, Paul Gortmaker wrote:
> > [[linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that
> > device does not have interrupt assigned] On 05/02/2016 (Fri 06:53)
> > Saul Wold wrote:
> > 
> > > From: Mika Westerberg 
> > 
> > Normally here at this point it is nice to see:
> > 
> > commit dab472eb931bc2916fa779e56deccd0ec319cf5b upstream.
> > 
> > This is the convention used by all the stable kernel maintenance
> > trees.
> 
> Paul, Thanks!  This is the first kernel patch set I am sending,
> appreciate the feedback, I send patches elsewhere but the conventions
> are different.

Yeah, understood; I've got the unfair advantage of spending most of my
time wading around in the kernel and did one of the stable releases too.

I've got a script for automagically insterting the upstream commit at
the time of commit extraction.  A neat trick is that you can create
a script "git-myfeature" and put it in $PATH and then you can run it
from anywhere with "git myfeature" (no dash).  And it will even tab
complete the 2nd word for you...

> 
> I will break this series up and add the upstream note where I find
> them.
> 
> > It makes it much easier to decide when later that we can toss it
> > based
> > on moving to a new kernel version.  For example:
> > 
> > paul@yow-builder:~/git/linux-head$ git describe dab472eb931
> > v4.1-rc3-44-gdab472eb931b
> > 
> > ...so the commit was created on a 4.1-rc3 baseline, but...
> > 
> > paul@yow-builder:~/git/linux-head$ git describe --contains
> > dab472eb931
> > v4.2-rc1~158^2~28
> > 
> > ...not merged to mainline until 158 commits before the 4.2-rc1 tag
> > marked the end of the 4.2 development cycle.  So anything pre-4.2
> > will
> > need to carry this.
> > 
> > Normally I use some script to toss the output of the above two lines
> > into a comment above the commit in the scc file, which also eases the
> > carry forward load of bigger BSP patch series.
> > 
> Willing to share your script?

I'll attach it (and the extraction script above).  The script was meant
to pull out a whole linear series of commits for a series file (with the
ID iterator $i), and de-number them, but the documenting part essentially
boils down to:

 
NP=`echo 0001-*patch`
P=`echo $NP | sed 's/^0001-//'`

XID=`git describe $i`

# commits not yet under a tag are not contained yet.
git describe --contains $i > /dev/null 2>&1
if [ $? = 0 ]; then
CID=`git describe --contains $i` 
else
CID="(on master)"
fi
echo "# $CID -- $XID" >> $PATCHDIR/series

echo $P >> $PATCHDIR/series
mv $NP $PATCHDIR/$P
if [ $? != 0 ]; then
echo \"mv $NP $PATCHDIR/$P\" failed, a name conflict?
exit 1
fi
 

For repos that don't use extensive use of tags that are somewhat linear
with time/development, the "--contains" info won't be as useful, but on
the kernel, I really like how it shows where it was merged as per above.

[...]

> > 
> > I wonder about the auto-Cc collection of mail addresses in the
> > linux-yocto case.  It might be a bit of a coin toss; but I'm leaning
> > towards leaving them off, esp. when the 0/N didn't include all the
> > ppl
> > to give them context.  Maintainers/authors probably get enough
> > revisit
> > spam from all the "official" stable trees, hence why I'd lean towards
> > leaving them out for other custom/forked projects like this.
> > 
> 
> I will ensure not to send to the Cc list in the future.

Yeah, I think that is probably best.  The "--suppress-cc="
cmdline option has several variations to tune it to suit.  For internal
use, we'd decided a blanket approach of $HOME/gitconfig having a:

[sendemail]
   suppresscc = all

was the only way to reliably stop developers from inadvertently spamming
the original developers when sharing patches around for backporting.
But I don't think you want that ; as you'll want proper Cc: creation for
patches to OE etc that are not kernel backports.

Paul.
#!/bin/bash
# Assume that $1 might be HEAD, or a tag, or an abbrev. ID.
GIT_ID=`git rev-parse $1`
if [ $? != 0 ]; then
echo $1 doesnt appear to be a valid git ref
exit -1
fi

TMPF=`mktemp`
git format-patch -p $1^..$1 > $TMPF 2>&1
if [ $? != 0 ]; then
echo format-patch failed
cat $TMPF
rm -f $TMPF
exit -1
fi

FILE=`cat $TMPF`
rm -f $TMPF
if [ ! -f "$FILE" ];then
echo cant find patch file $FILE
exit -1
fi

# echo Commit is $FILE

(
echo '/^$/a'
echo -e "commit $GIT_ID upstream.\n"
echo .
echo w
echo q 
) | ed -s $FILE
#!/bin/bash

Re: [linux-yocto] [PATCH 06/13] intel-common-drivers.scc: move profiling and latencytop to a new file

[Bruce Ashfield]

On 2016-02-07 6:25 PM, Paul Gortmaker wrote:

[[linux-yocto] [PATCH 06/13] intel-common-drivers.scc: move profiling and 
latencytop to a new file] On 04/02/2016 (Thu 16:25) California Sullivan wrote:


Profiling and latencytop enable DEBUG_KERNEL, which is no longer a
standard config option. Move these features to a new file called
intel-extended-drivers.scc, which is to be included in intel extended
bsps.

Signed-off-by: California Sullivan 
---
  bsp/intel-common/intel-common-drivers.scc   | 2 --
  bsp/intel-common/intel-extended-drivers.scc | 3 +++
  2 files changed, 3 insertions(+), 2 deletions(-)
  create mode 100644 bsp/intel-common/intel-extended-drivers.scc


Again, "extended" is such a content free term.  I think "profiling"
might be a more suitable subsitution.


Yup. or going with "developer" again.

Bruce



P.
--



diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index a7673e7..9beef28 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -76,5 +76,3 @@ include cfg/efi-ext.scc
  # default policy for standard kernels
  include cfg/usb-mass-storage.scc
  include cfg/boot-live.scc
-include features/latencytop/latencytop.scc
-include features/profiling/profiling.scc
diff --git a/bsp/intel-common/intel-extended-drivers.scc 
b/bsp/intel-common/intel-extended-drivers.scc
new file mode 100644
index 000..a78348e
--- /dev/null
+++ b/bsp/intel-common/intel-extended-drivers.scc
@@ -0,0 +1,3 @@
+# Additional features for extended bsps
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
--
2.5.0

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 02/13] ktypes: add extended ktype

[Bruce Ashfield]

On 2016-02-07 6:14 PM, Paul Gortmaker wrote:

[[linux-yocto] [PATCH 02/13] ktypes: add extended ktype] On 04/02/2016 (Thu 
16:25) California Sullivan wrote:


The extended ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL,
opening up more kernel options.


I wonder if adding a ktype is too heavy handed for what we are doing
here.  After all, we are just shuffling config settings and cfg files,
where historically a ktype reflected a fundamental different base branch
being used at ground zero (i.e. standard/base vs preempt-rt/base).
Can this be done as a feature and not a ktype?



I know that this has been discussed in the past about why the ktype
was being used, it would be worth summarizing the intent here, so it
can be archived and socialized .. that way we are sure that interested
parties are in agreement (or at least aware).

It is true that we don't want a lot of ktypes, and that we don't want
a lot of optional fragments being applied via KERNEL_FEATURES to change
a base ktype into something it isn't.

I'd consider a significantly different kernel configuration and purpose
as grounds for a new ktype, even if it doesn't require a new branch or
set of patches .. and I think that is the intent here.


I'd rather not get into name bike shedding, but at the same time
"extended" doesn't really convey anything concrete.  Looking at what we
are trying to compartmentalize here, I wonder if "developer" is a better
fit ; these are all things I'd expect a developer to employ when doing
their coding and testing, then they get disabled at final deployment.


That's not a bad suggestion. To me, developer does indicate more than
extended as well.

Naming things sucks, but definitely worth discussing.

Bruce



P.
--



Signed-off-by: California Sullivan 
---
  ktypes/extended/extended.cfg | 18 ++
  ktypes/extended/extended.scc | 10 ++
  2 files changed, 28 insertions(+)
  create mode 100644 ktypes/extended/extended.cfg
  create mode 100644 ktypes/extended/extended.scc

diff --git a/ktypes/extended/extended.cfg b/ktypes/extended/extended.cfg
new file mode 100644
index 000..98f79be
--- /dev/null
+++ b/ktypes/extended/extended.cfg
@@ -0,0 +1,18 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+#
+# General setup
+#
+CONFIG_EXPERT=y
+CONFIG_EMBEDDED=y
diff --git a/ktypes/extended/extended.scc b/ktypes/extended/extended.scc
new file mode 100644
index 000..eaa94c8
--- /dev/null
+++ b/ktypes/extended/extended.scc
@@ -0,0 +1,10 @@
+# Include this kernel type fragment to get the standard features and
+# configuration values, as well as extended options through EXPERT,
+# EMBEDDED, and DEBUG_KERNEL.
+
+include ktypes/standard/standard.scc
+branch standard
+
+force kconf non-hardware extended.cfg
+
+include features/debug/debug-kernel.scc
--
2.5.0

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] Release Candidate Build for yocto-2.0.1.rc6.rc6 now available.

[Poky Build User]

-e 
A release candidate build for yocto-2.0.1.rc6 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.1.rc6


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 4e87c59bdedaa8c3e44fc02fd23be726c4d1dfb9 
meta-fsl-arm : 35b8b9bd9863de208ab60e33b55f10ee43e2619b 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt4 : 80e9ccf584ea215ac0e9706bd1df852bb2bb4ba9 
meta-qt3 : b08996efbfb3b26e62b608f34ebf5e671b36ec61 
meta-fsl-ppc : d9443cbd98f2d4717d84d8325fc6099f5a3e6a25 
poky : 5b12268f6e17574999f91628a60e21711cf62ee4 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 15/19] mfd: intel_quark_i2c_gpio: support devices behind i2c bus

[Saul Wold]

From: Andy Shevchenko 

commit 9b00926f46d882429bee435960c40b49d39e6a4f upstream.

On Intel Galileo Gen2 the GPIO expanders are connected to the i2c bus. For
those devices the ACPI table has specific parameters that refer to an actual
i2c host controller. Since MFD now copes with that specific configuration we
have to provide a necessary information how to distinguish devices in ACPI
namespace. Here the _ADR values are provided.

Acked-by: Lee Jones 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 918fe70cf4750e21350a8a40b28117b9e2991a10)
---
 drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index 958c134..0421374 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -31,6 +31,10 @@
 #define MFD_I2C_BAR0
 #define MFD_GPIO_BAR   1
 
+/* ACPI _ADR value to match the child node */
+#define MFD_ACPI_MATCH_GPIO0ULL
+#define MFD_ACPI_MATCH_I2C 1ULL
+
 /* The base GPIO number under GPIOLIB framework */
 #define INTEL_QUARK_MFD_GPIO_BASE  8
 
@@ -82,16 +86,25 @@ static struct resource intel_quark_i2c_res[] = {
},
 };
 
+static struct mfd_cell_acpi_match intel_quark_acpi_match_i2c = {
+   .adr = MFD_ACPI_MATCH_I2C,
+};
+
 static struct resource intel_quark_gpio_res[] = {
[INTEL_QUARK_IORES_MEM] = {
.flags = IORESOURCE_MEM,
},
 };
 
+static struct mfd_cell_acpi_match intel_quark_acpi_match_gpio = {
+   .adr = MFD_ACPI_MATCH_GPIO,
+};
+
 static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
+   .acpi_match = _quark_acpi_match_gpio,
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
@@ -99,6 +112,7 @@ static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_I2C_BAR,
.name = "i2c_designware",
+   .acpi_match = _quark_acpi_match_i2c,
.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
.resources = intel_quark_i2c_res,
.ignore_resource_conflicts = true,
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 03/13] ktypes/base: Disable EMBEDDED and DEBUG_KERNEL

[Sullivan, California L]

On 02/07/2016 03:17 PM, Paul Gortmaker wrote:
> [[linux-yocto] [PATCH 03/13] ktypes/base: Disable EMBEDDED and DEBUG_KERNEL] 
> On 04/02/2016 (Thu 16:25) California Sullivan wrote:
>
>> DEBUG_KERNEL should not be in the base ktype, as a production kernel
>> may not necessarily want any debug turned on. EMBEDDED is also removed,
>> as EMBEDDED selects EXPERT which selects DEBUG_KERNEL.
>>
>> Signed-off-by: California Sullivan 
>> ---
>>  ktypes/base/base.cfg | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/ktypes/base/base.cfg b/ktypes/base/base.cfg
>> index 3b8ccd2..30a3f77 100644
>> --- a/ktypes/base/base.cfg
>> +++ b/ktypes/base/base.cfg
>> @@ -33,7 +33,7 @@ CONFIG_INITRAMFS_SOURCE=""
>>  # Resource Groups
>>  #
>>  CONFIG_SYSCTL=y
>> -CONFIG_EMBEDDED=y
>> +# CONFIG_EMBEDDED is not set
> Guessing this is "default n"  [which is also equivalent to no default
> setting at all].  In which case it probably is best to simply not
> specify it at all here.  That will avoid all the extended users getting
> an override warning at kernel config time.
You are are right about the options defaulting to n, but I want it to be
explicit that the base ktype sets them to off.
I believe the kernel_checkconfig task only looks at the last file that
sets a config option. In my testing of the extended ktype, no warning
was issued.

---
Cal
>
>>  CONFIG_KALLSYMS=y
>>  # CONFIG_KALLSYMS_ALL is not set
>>  CONFIG_FUTEX=y
>> @@ -1011,13 +1011,13 @@ CONFIG_NLS_DEFAULT="iso8859-1"
>>  # Kernel hacking
>>  #
>>  CONFIG_MAGIC_SYSRQ=y
>> -CONFIG_DEBUG_KERNEL=y
>> +# CONFIG_DEBUG_KERNEL is not set
> ...same here.
>
> P.
> --
>
>>  # CONFIG_SCHEDSTATS is not set
>>  # CONFIG_DEBUG_SLAB is not set
>>  # CONFIG_DEBUG_SPINLOCK is not set
>>  # CONFIG_DEBUG_KOBJECT is not set
>>  # CONFIG_DEBUG_HIGHMEM is not set
>> -CONFIG_DEBUG_INFO=y
>> +# CONFIG_DEBUG_INFO is not set
>>  
>>  #
>>  # Security options
>> -- 
>> 2.5.0
>>
>> -- 
>> ___
>> linux-yocto mailing list
>> linux-yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/linux-yocto

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 11/13] CONFIG_I2C_I801: set option to yes in intel-core* bsps

[Sullivan, California L]

On 02/07/2016 03:33 PM, Paul Gortmaker wrote:
> [[linux-yocto] [PATCH 11/13] CONFIG_I2C_I801: set option to yes in 
> intel-core* bsps] On 04/02/2016 (Thu 16:25) California Sullivan wrote:
>
>> Without EXPERT, we hit a select on I2C_I801, forcing it to yes and
>> causing a warning. Set I2C_I801 to yes, and if a bsp wants to build it
>> as a module, it can be done through an extended ktype bsp.
> What exactly was the warning?
>
> P.
> --
>
WARNING: [kernel config]: specified values did not make it into the
kernel's final configuration:

Value requested for CONFIG_I2C_I801 not in final ".config"
Requested value: "CONFIG_I2C_I801=m"
Actual value set: "CONFIG_I2C_I801=y"

---
Cal
>> Signed-off-by: California Sullivan 
>> ---
>>  bsp/haswell-wc/haswell-wc.cfg  | 2 +-
>>  bsp/mohonpeak/mohonpeak.cfg| 2 +-
>>  features/soc/baytrail/baytrail.cfg | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsp/haswell-wc/haswell-wc.cfg b/bsp/haswell-wc/haswell-wc.cfg
>> index 0402847..f2136a8 100644
>> --- a/bsp/haswell-wc/haswell-wc.cfg
>> +++ b/bsp/haswell-wc/haswell-wc.cfg
>> @@ -16,6 +16,6 @@ CONFIG_PM=y
>>  # Platform specific support for the box - LPC, SMBus
>>  CONFIG_LPC_ICH=y
>>  CONFIG_I2C=y
>> -CONFIG_I2C_I801=m
>> +CONFIG_I2C_I801=y
>>  CONFIG_I2C_CHARDEV=y
>>  
>> diff --git a/bsp/mohonpeak/mohonpeak.cfg b/bsp/mohonpeak/mohonpeak.cfg
>> index 87e4d3e..6dd26f4 100644
>> --- a/bsp/mohonpeak/mohonpeak.cfg
>> +++ b/bsp/mohonpeak/mohonpeak.cfg
>> @@ -14,7 +14,7 @@ CONFIG_CHR_DEV_SG=y
>>  
>>  # SMBus Support
>>  CONFIG_I2C=y
>> -CONFIG_I2C_I801=m
>> +CONFIG_I2C_I801=y
>>  CONFIG_I2C_ISMT=m
>>  CONFIG_I2C_CHARDEV=y
>>  
>> diff --git a/features/soc/baytrail/baytrail.cfg 
>> b/features/soc/baytrail/baytrail.cfg
>> index f6dbb9e..0a5e6c1 100644
>> --- a/features/soc/baytrail/baytrail.cfg
>> +++ b/features/soc/baytrail/baytrail.cfg
>> @@ -29,7 +29,7 @@ CONFIG_I2C_DESIGNWARE_PCI=m
>>  CONFIG_I2C_DESIGNWARE_PLATFORM=m
>>  
>>  # SMBus Support
>> -CONFIG_I2C_I801=m
>> +CONFIG_I2C_I801=y
>>  
>>  CONFIG_SPI_PXA2XX=m
>>  
>> -- 
>> 2.5.0
>>
>> -- 
>> ___
>> linux-yocto mailing list
>> linux-yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/linux-yocto

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 07/19] i2c: core: only use set_scl for bus recovery after calling prepare_recovery

[Saul Wold]

From: Jan Luebbe 

commit 49c46cd7bf99f5a5af5df9a92b73db54b94f46f0 upstream.

Using set_scl may be ineffective before calling the driver specific
prepare_recovery callback, which might change into a test mode. So
instead of setting SCL in i2c_generic_scl_recovery, move it to
i2c_generic_recovery (after the optional prepare_recovery).

Signed-off-by: Jan Luebbe 
Acked-by: Alexander Sverdlin 
Tested-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 8b06260836ab47abbb5ea49d889660a0ed8adf90)
---
 drivers/i2c/i2c-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 069a41f..be992b3 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -567,6 +567,9 @@ static int i2c_generic_recovery(struct i2c_adapter *adap)
if (bri->prepare_recovery)
bri->prepare_recovery(adap);
 
+   bri->set_scl(adap, val);
+   ndelay(RECOVERY_NDELAY);
+
/*
 * By this time SCL is high, as we need to give 9 falling-rising edges
 */
@@ -597,7 +600,6 @@ static int i2c_generic_recovery(struct i2c_adapter *adap)
 
 int i2c_generic_scl_recovery(struct i2c_adapter *adap)
 {
-   adap->bus_recovery_info->set_scl(adap, 1);
return i2c_generic_recovery(adap);
 }
 EXPORT_SYMBOL_GPL(i2c_generic_scl_recovery);
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 10/19] GPIO / ACPI: export acpi_gpiochip_request(free)_interrupts for module use

[Saul Wold]

From: Hanjun Guo 

commit dd8f9d05019c5c086113b967850bf8e2f2a964e6 upstream.

acpi_gpiochip_request(free)_interrupts can be used for modules,
so export them. This also fixs a compile error when xgene-sb
configured as kernel module.

Fixes: 733cf014f020 "gpio: xgene: add ACPI support for APM X-Gene GPIO standby 
driver"
Reviewed-by: Mark Brown 
Signed-off-by: Hanjun Guo 
(cherry picked from commit 2b528fff0905497c96566d671d47f2bbf3ae295c)
---
 drivers/gpio/gpiolib-acpi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 19b99d0..980a996 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -307,6 +307,7 @@ void acpi_gpiochip_request_interrupts(struct gpio_chip 
*chip)
acpi_walk_resources(handle, "_AEI",
acpi_gpiochip_request_interrupt, acpi_gpio);
 }
+EXPORT_SYMBOL_GPL(acpi_gpiochip_request_interrupts);
 
 /**
  * acpi_gpiochip_free_interrupts() - Free GPIO ACPI event interrupts.
@@ -346,6 +347,7 @@ void acpi_gpiochip_free_interrupts(struct gpio_chip *chip)
kfree(event);
}
 }
+EXPORT_SYMBOL_GPL(acpi_gpiochip_free_interrupts);
 
 int acpi_dev_add_driver_gpios(struct acpi_device *adev,
  const struct acpi_gpio_mapping *gpios)
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 00/19 v2] Galileo patches that are upstreamed or pending

[Saul Wold]

Bruce,

I am refactoring the large patchset I sent earlier, this includes just the
patches that have upstream commits, I have already sent one general iio, 
these are More galileo specific.

These should all have the upstream commit info in them.  These are all for
the 4.1 linux-yocto, I will send another series for the 4.4 branch tomorrow.

Thanks

Sau!

Andy Shevchenko (7):
  mfd: core: redo ACPI matching of the children devices
  mfd: intel_quark_i2c_gpio: load gpio driver first
  mfd: intel_quark_i2c_gpio: support devices behind i2c bus
  gpio: pca953x: store driver_data for future use
  gpio: pca953x: support ACPI devices found on Galileo Gen2
  at24: enable ACPI device found on Galileo Gen2
  pwm-pca9685: enable ACPI device found on Galileo Gen2

Hanjun Guo (1):
  GPIO / ACPI: export acpi_gpiochip_request(free)_interrupts for module
use

Jan Luebbe (1):
  i2c: core: only use set_scl for bus recovery after calling
prepare_recovery

Jarkko Nikula (1):
  i2c: core: Reduce stack size of acpi_i2c_space_handler()

Mika Westerberg (5):
  i2c / ACPI: Use 0 to indicate that device does not have interrupt
assigned
  i2c / ACPI: Assign IRQ for devices that have GpioInt automatically
  gpio / ACPI: Add support for retrieving GpioInt resources from a
device
  gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
  i2c / ACPI: Rework I2C device scanning

Shailendra Verma (1):
  i2c: core: fix typo in comment

Vladimir Zapolskiy (1):
  i2c: fix leaked device refcount on of_find_i2c_* error path

Wolfram Sang (2):
  i2c: slave: add error messages to slave core
  i2c: check for proper length of the reg property

 Documentation/acpi/enumeration.txt |  11 ++-
 drivers/gpio/gpio-pca953x.c|  36 ++--
 drivers/gpio/gpiolib-acpi.c|  40 -
 drivers/i2c/i2c-core.c | 179 +
 drivers/mfd/intel_quark_i2c_gpio.c |  33 ---
 drivers/mfd/mfd-core.c |  52 +++
 drivers/misc/eeprom/at24.c |  22 -
 drivers/pwm/Kconfig|   2 +-
 drivers/pwm/pwm-pca9685.c  |  20 -
 include/linux/acpi.h   |   7 ++
 include/linux/mfd/core.h   |  10 ++-
 11 files changed, 306 insertions(+), 106 deletions(-)

-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 14/19] mfd: intel_quark_i2c_gpio: load gpio driver first

[Saul Wold]

From: Andy Shevchenko 

commit b91b0d397c3b35a039867ca0f43f1a0d5965cad6 upstream.

On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.

Acked-by: Lee Jones 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 236fd469f4d1beb59a47875fa3f222d514173ad0)
---
 drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..958c134 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
 
 static struct mfd_cell intel_quark_mfd_cells[] = {
{
-   .id = MFD_I2C_BAR,
-   .name = "i2c_designware",
-   .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
-   .resources = intel_quark_i2c_res,
-   .ignore_resource_conflicts = true,
-   },
-   {
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
},
+   {
+   .id = MFD_I2C_BAR,
+   .name = "i2c_designware",
+   .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
+   .resources = intel_quark_i2c_res,
+   .ignore_resource_conflicts = true,
+   },
 };
 
 static const struct pci_device_id intel_quark_mfd_ids[] = {
@@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
 
dev_set_drvdata(>dev, quark_mfd);
 
-   ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[MFD_I2C_BAR]);
+   ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[1]);
if (ret)
return ret;
 
-   ret = intel_quark_gpio_setup(pdev,
-_quark_mfd_cells[MFD_GPIO_BAR]);
+   ret = intel_quark_gpio_setup(pdev, _quark_mfd_cells[0]);
if (ret)
return ret;
 
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 11/19] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found

[Saul Wold]

From: Mika Westerberg 

commit d8213ae03aebde8074f071d1da48007d55e3b41d upstream.

If a driver requests a GPIO described in its _CRS but the GPIO host
controller (gpiochip) driver providing the GPIO has not been loaded yet
acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail.

If the gpiochip driver is loaded afterwards the driver requesting the GPIO
will not notice this.

Better approach is to return -EPROBE_DEFER in such case. Then when the
gpiochip driver appears the driver requesting the GPIO will be probed
again. This also aligns ACPI GPIO lookup code closer to DT as it does
pretty much the same when no gpiochip driver was found.

Reported-by: Tobias Diedrich 
Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Tobias Diedrich 
Reviewed-by: Amos Kong 
Signed-off-by: Linus Walleij 
(cherry picked from commit f35bbf61ab772cc312f641c89ab161893cee)
---
 drivers/gpio/gpiolib-acpi.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 980a996..533fe5d 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -114,10 +114,11 @@ static inline int acpi_gpiochip_pin_to_gpio_offset(struct 
gpio_chip *chip,
  * @path:  ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
  * @pin:   ACPI GPIO pin number (0-based, controller-relative)
  *
- * Returns GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
- * error value
+ * Return: GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
+ * error value. Specifically returns %-EPROBE_DEFER if the referenced GPIO
+ * controller does not have gpiochip registered at the moment. This is to
+ * support probe deferral.
  */
-
 static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
 {
struct gpio_chip *chip;
@@ -131,7 +132,7 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
 
chip = gpiochip_find(handle, acpi_gpiochip_find);
if (!chip)
-   return ERR_PTR(-ENODEV);
+   return ERR_PTR(-EPROBE_DEFER);
 
offset = acpi_gpiochip_pin_to_gpio_offset(chip, pin);
if (offset < 0)
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 12/19] i2c / ACPI: Rework I2C device scanning

[Saul Wold]

From: Mika Westerberg 

commit 4bba25bbe10ace5ad135020c1e6d621872d5faf5 upstream.

The way we currently scan I2C devices behind an I2C host controller does not
work in cases where the I2C device in question is not declared directly below
the host controller ACPI node.

This is perfectly legal according the ACPI 6.0 specification and some existing
systems are doing this.

To be able to enumerate all devices which are connected to a certain I2C host
controller we need to rework the current I2C scanning routine a bit. Instead of
scanning directly below the host controller we scan the whole ACPI namespace
for present devices with valid I2cSerialBus() connection pointing to the host
controller in question.

Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Andy Shevchenko 
Tested-by: Dustin Byford 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 166c2ba398640278ae6037be4aa5562c03cf3d24)
---
 drivers/i2c/i2c-core.c | 82 --
 1 file changed, 59 insertions(+), 23 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e93dc38..372da32 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -94,27 +94,40 @@ struct gsb_buffer {
};
 } __packed;
 
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+   struct i2c_board_info *info;
+   acpi_handle adapter_handle;
+   acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
 {
-   struct i2c_board_info *info = data;
+   struct acpi_i2c_lookup *lookup = data;
+   struct i2c_board_info *info = lookup->info;
+   struct acpi_resource_i2c_serialbus *sb;
+   acpi_handle adapter_handle;
+   acpi_status status;
 
-   if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
-   struct acpi_resource_i2c_serialbus *sb;
+   if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+   return 1;
 
-   sb = >data.i2c_serial_bus;
-   if (!info->addr && sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
-   info->addr = sb->slave_address;
-   if (sb->access_mode == ACPI_I2C_10BIT_MODE)
-   info->flags |= I2C_CLIENT_TEN;
-   }
-   } else if (!info->irq) {
-   struct resource r;
+   sb = >data.i2c_serial_bus;
+   if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+   return 1;
 
-   if (acpi_dev_resource_interrupt(ares, 0, ))
-   info->irq = r.start;
+   /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+   status = acpi_get_handle(lookup->device_handle,
+sb->resource_source.string_ptr,
+_handle);
+   if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
+   info->addr = sb->slave_address;
+   if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+   info->flags |= I2C_CLIENT_TEN;
}
 
-   /* Tell the ACPI core to skip this resource */
return 1;
 }
 
@@ -123,6 +136,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle, 
u32 level,
 {
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+   struct acpi_i2c_lookup lookup;
+   struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -135,14 +150,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle 
handle, u32 level,
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
 
+   memset(, 0, sizeof(lookup));
+   lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+   lookup.device_handle = handle;
+   lookup.info = 
+
+   /*
+* Look up for I2cSerialBus resource with ResourceSource that
+* matches with this adapter.
+*/
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-acpi_i2c_add_resource, );
+acpi_i2c_find_address, );
acpi_dev_free_resource_list(_list);
 
if (ret < 0 || !info.addr)
return AE_OK;
 
+   /* Then fill IRQ number if any */
+   ret = acpi_dev_get_resources(adev, _list, NULL, NULL);
+   if (ret < 0)
+   return AE_OK;
+
+   resource_list_for_each_entry(entry, _list) {
+   if (resource_type(entry->res) == IORESOURCE_IRQ) {
+   info.irq = entry->res->start;
+   break;
+   }
+ 

[linux-yocto] [PATCH 13/19] mfd: core: redo ACPI matching of the children devices

[Saul Wold]

From: Andy Shevchenko 

commit 541019157c6b5951f2a488dbf4f7fa5f4b8f9b98 upstream.

There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.

Acked-by: Rafael J. Wysocki 
Acked-by: Lee Jones 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 98a3be44ffa67b812de7aa7aed9f2331edcfb1a5)
---
 Documentation/acpi/enumeration.txt | 11 +---
 drivers/mfd/mfd-core.c | 52 ++
 include/linux/mfd/core.h   | 10 ++--
 3 files changed, 52 insertions(+), 21 deletions(-)

diff --git a/Documentation/acpi/enumeration.txt 
b/Documentation/acpi/enumeration.txt
index 15dfce7..afd34d0 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do 
anything. The
 resulting child platform device will have its ACPI_COMPANION() set to point
 to the parent device.
 
-If the ACPI namespace has a device that we can match using an ACPI id,
-the id should be set like:
+If the ACPI namespace has a device that we can match using an ACPI id or ACPI
+adr, the cell should be set like:
+
+   static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
+   .pnpid = "XYZ0001",
+   .adr = 0,
+   };
 
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
-   .acpi_pnpid = "XYZ0001",
+   .acpi_match = _subdevice_cell_acpi_match,
};
 
 The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 1aed3b7..ea844dc 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -82,29 +82,49 @@ static int mfd_platform_add_cell(struct platform_device 
*pdev,
 static void mfd_acpi_add_device(const struct mfd_cell *cell,
struct platform_device *pdev)
 {
-   struct acpi_device *parent_adev;
+   const struct mfd_cell_acpi_match *match = cell->acpi_match;
+   struct acpi_device *parent, *child;
struct acpi_device *adev;
 
-   parent_adev = ACPI_COMPANION(pdev->dev.parent);
-   if (!parent_adev)
+   parent = ACPI_COMPANION(pdev->dev.parent);
+   if (!parent)
return;
 
/*
-* MFD child device gets its ACPI handle either from the ACPI
-* device directly under the parent that matches the acpi_pnpid or
-* it will use the parent handle if is no acpi_pnpid is given.
+* MFD child device gets its ACPI handle either from the ACPI device
+* directly under the parent that matches the either _HID or _CID, or
+* _ADR or it will use the parent handle if is no ID is given.
+*
+* Note that use of _ADR is a grey area in the ACPI specification,
+* though Intel Galileo Gen2 is using it to distinguish the children
+* devices.
 */
-   adev = parent_adev;
-   if (cell->acpi_pnpid) {
-   struct acpi_device_id ids[2] = {};
-   struct acpi_device *child_adev;
-
-   strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
-   list_for_each_entry(child_adev, _adev->children, node)
-   if (acpi_match_device_ids(child_adev, ids)) {
-   adev = child_adev;
-   break;
+   adev = parent;
+   if (match) {
+   if (match->pnpid) {
+   struct acpi_device_id ids[2] = {};
+
+   strlcpy(ids[0].id, match->pnpid, sizeof(ids[0].id));
+   list_for_each_entry(child, >children, node) {
+   if (acpi_match_device_ids(child, ids)) {
+   adev = child;
+   break;
+   }
+   }
+   } else {
+   unsigned long long adr;
+   acpi_status status;
+
+   list_for_each_entry(child, >children, node) {
+   status = acpi_evaluate_integer(child->handle,
+  "_ADR", NULL,
+  );
+   if (ACPI_SUCCESS(status) && match->adr == adr) {
+   adev = child;
+   break;
+   }
}
+   }

[linux-yocto] [PATCH 17/19] gpio: pca953x: support ACPI devices found on Galileo Gen2

[Saul Wold]

From: Andy Shevchenko 

commit 99e17e265a9df3b2ef8fbc1a568cbb2b05a1b977 upstream.

This patch adds a support of the expandes found on Intel Galileo Gen2 board.
The platform information comes from ACPI.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
(cherry picked from commit f32517bf1ae0a2de72b3f27200233bd3ad65bfeb)
---
 drivers/gpio/gpio-pca953x.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 56f679b..32a56d5 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -21,6 +21,7 @@
 #ifdef CONFIG_OF_GPIO
 #include 
 #endif
+#include 
 
 #define PCA953X_INPUT  0
 #define PCA953X_OUTPUT 1
@@ -75,6 +76,12 @@ static const struct i2c_device_id pca953x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pca953x_id);
 
+static const struct acpi_device_id pca953x_acpi_ids[] = {
+   { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
+
 #define MAX_BANK 5
 #define BANK_SZ 8
 
@@ -668,7 +675,18 @@ static int pca953x_probe(struct i2c_client *client,
 
chip->client = client;
 
-   chip->driver_data = id->driver_data;
+   if (id) {
+   chip->driver_data = id->driver_data;
+   } else {
+   const struct acpi_device_id *id;
+
+   id = acpi_match_device(pca953x_acpi_ids, >dev);
+   if (!id)
+   return -ENODEV;
+
+   chip->driver_data = id->driver_data;
+   }
+
chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
 
mutex_init(>i2c_lock);
@@ -761,6 +779,7 @@ static struct i2c_driver pca953x_driver = {
.driver = {
.name   = "pca953x",
.of_match_table = pca953x_dt_ids,
+   .acpi_match_table = ACPI_PTR(pca953x_acpi_ids),
},
.probe  = pca953x_probe,
.remove = pca953x_remove,
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 08/19] i2c: fix leaked device refcount on of_find_i2c_* error path

[Saul Wold]

From: Vladimir Zapolskiy 

commit 6b5d9d07c7ea4df3cf27f9eeb2fbb9c48a0c034b upstream.

If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find
a device by node, but its type does not match, a reference to that
device is still held. This change fixes the problem.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Wolfram Sang 
(cherry picked from commit e3311469734093724b10c2a81c1193197db03b78)
---
 drivers/i2c/i2c-core.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index be992b3..e93dc38 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1335,13 +1335,17 @@ static int of_dev_node_match(struct device *dev, void 
*data)
 struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
 {
struct device *dev;
+   struct i2c_client *client;
 
-   dev = bus_find_device(_bus_type, NULL, node,
-of_dev_node_match);
+   dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
if (!dev)
return NULL;
 
-   return i2c_verify_client(dev);
+   client = i2c_verify_client(dev);
+   if (!client)
+   put_device(dev);
+
+   return client;
 }
 EXPORT_SYMBOL(of_find_i2c_device_by_node);
 
@@ -1349,13 +1353,17 @@ EXPORT_SYMBOL(of_find_i2c_device_by_node);
 struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
 {
struct device *dev;
+   struct i2c_adapter *adapter;
 
-   dev = bus_find_device(_bus_type, NULL, node,
-of_dev_node_match);
+   dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
if (!dev)
return NULL;
 
-   return i2c_verify_adapter(dev);
+   adapter = i2c_verify_adapter(dev);
+   if (!adapter)
+   put_device(dev);
+
+   return adapter;
 }
 EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
 #else
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 04/19] i2c: check for proper length of the reg property

[Saul Wold]

From: Wolfram Sang 

commit bc280e47bc3944af5c7ca3cebaaf07819805ecb6 upstream.

int is vague, let's simply use the type of the variable in question.

Signed-off-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 4c1344f105b626c222ea64669dc6dcfe100ccf3b)
---
 drivers/i2c/i2c-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 77a2ec6..bfd8e1c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1276,7 +1276,7 @@ static struct i2c_client *of_i2c_register_device(struct 
i2c_adapter *adap,
}
 
addr = of_get_property(node, "reg", );
-   if (!addr || (len < sizeof(int))) {
+   if (!addr || (len < sizeof(*addr))) {
dev_err(>dev, "of_i2c: invalid reg on %s\n",
node->full_name);
return ERR_PTR(-EINVAL);
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 03/19] i2c: slave: add error messages to slave core

[Saul Wold]

From: Wolfram Sang 

commit 429d57334d73b2c515363d21ad58be16c01d8d25 upstream.

Inform users what went wrong from the core, so drivers don't have to do
it.

Signed-off-by: Wolfram Sang 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 0c7cab96ec413a69af86965d94fb650f01c5887a)
---
 drivers/i2c/i2c-core.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index fc2ee82..77a2ec6 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2918,18 +2918,24 @@ int i2c_slave_register(struct i2c_client *client, 
i2c_slave_cb_t slave_cb)
 {
int ret;
 
-   if (!client || !slave_cb)
+   if (!client || !slave_cb) {
+   WARN(1, "insufficent data\n");
return -EINVAL;
+   }
 
if (!(client->flags & I2C_CLIENT_TEN)) {
/* Enforce stricter address checking */
ret = i2c_check_addr_validity(client->addr);
-   if (ret)
+   if (ret) {
+   dev_err(>dev, "%s: invalid address\n", 
__func__);
return ret;
+   }
}
 
-   if (!client->adapter->algo->reg_slave)
+   if (!client->adapter->algo->reg_slave) {
+   dev_err(>dev, "%s: not supported by adapter\n", 
__func__);
return -EOPNOTSUPP;
+   }
 
client->slave_cb = slave_cb;
 
@@ -2937,8 +2943,10 @@ int i2c_slave_register(struct i2c_client *client, 
i2c_slave_cb_t slave_cb)
ret = client->adapter->algo->reg_slave(client);
i2c_unlock_adapter(client->adapter);
 
-   if (ret)
+   if (ret) {
client->slave_cb = NULL;
+   dev_err(>dev, "%s: adapter returned error %d\n", 
__func__, ret);
+   }
 
return ret;
 }
@@ -2948,8 +2956,10 @@ int i2c_slave_unregister(struct i2c_client *client)
 {
int ret;
 
-   if (!client->adapter->algo->unreg_slave)
+   if (!client->adapter->algo->unreg_slave) {
+   dev_err(>dev, "%s: not supported by adapter\n", 
__func__);
return -EOPNOTSUPP;
+   }
 
i2c_lock_adapter(client->adapter);
ret = client->adapter->algo->unreg_slave(client);
@@ -2957,6 +2967,8 @@ int i2c_slave_unregister(struct i2c_client *client)
 
if (ret == 0)
client->slave_cb = NULL;
+   else
+   dev_err(>dev, "%s: adapter returned error %d\n", 
__func__, ret);
 
return ret;
 }
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 09/19] gpio / ACPI: Add support for retrieving GpioInt resources from a device

[Saul Wold]

From: Mika Westerberg 

commit ad5b1c69a4ed2cc8486c6afa4d2545b21e5acd9b upstream.

ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:

Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
  AddressingMode7Bit, "\\_SB.PCI0.I2C6",
  0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x,
 "\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})

Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.

We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.

Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Linus Walleij 
(cherry picked from commit c884fbd452147e952ae160e750553d00ea4dc4c9)
---
 drivers/gpio/gpiolib-acpi.c | 29 +
 include/linux/acpi.h|  7 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 725d161..19b99d0 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -514,6 +514,35 @@ struct gpio_desc *acpi_get_gpiod_by_index(struct 
acpi_device *adev,
return lookup.desc ? lookup.desc : ERR_PTR(-ENOENT);
 }
 
+/**
+ * acpi_dev_gpio_irq_get() - Find GpioInt and translate it to Linux IRQ number
+ * @adev: pointer to a ACPI device to get IRQ from
+ * @index: index of GpioInt resource (starting from %0)
+ *
+ * If the device has one or more GpioInt resources, this function can be
+ * used to translate from the GPIO offset in the resource to the Linux IRQ
+ * number.
+ *
+ * Return: Linux IRQ number (>%0) on success, negative errno on failure.
+ */
+int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
+{
+   int idx, i;
+
+   for (i = 0, idx = 0; idx <= index; i++) {
+   struct acpi_gpio_info info;
+   struct gpio_desc *desc;
+
+   desc = acpi_get_gpiod_by_index(adev, NULL, i, );
+   if (IS_ERR(desc))
+   break;
+   if (info.gpioint && idx++ == index)
+   return gpiod_to_irq(desc);
+   }
+   return -ENOENT;
+}
+EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get);
+
 static acpi_status
 acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address,
u32 bits, u64 *value, void *handler_context,
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 808c43a..2a662cb 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -723,6 +723,8 @@ static inline void acpi_dev_remove_driver_gpios(struct 
acpi_device *adev)
if (adev)
adev->driver_gpios = NULL;
 }
+
+int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index);
 #else
 static inline int acpi_dev_add_driver_gpios(struct acpi_device *adev,
  const struct acpi_gpio_mapping *gpios)
@@ -730,6 +732,11 @@ static inline int acpi_dev_add_driver_gpios(struct 
acpi_device *adev,
return -ENXIO;
 }
 static inline void acpi_dev_remove_driver_gpios(struct acpi_device *adev) {}
+
+static inline int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
+{
+   return -ENXIO;
+}
 #endif
 
 /* Device properties */
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 05/19] i2c: core: fix typo in comment

[Saul Wold]

From: Shailendra Verma 

commit 891e1f106f375232431587baa8a72e2be39a845a upstream.

Signed-off-by: Shailendra Verma 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 95cc1e3d76398c4e8003dafe652285e43be90ee7)
---
 drivers/i2c/i2c-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index bfd8e1c..eefb200 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1677,7 +1677,7 @@ void i2c_del_adapter(struct i2c_adapter *adap)
 * FIXME: This is old code and should ideally be replaced by an
 * alternative which results in decoupling the lifetime of the struct
 * device from the i2c_adapter, like spi or netdev do. Any solution
-* should be throughly tested with DEBUG_KOBJECT_RELEASE enabled!
+* should be thoroughly tested with DEBUG_KOBJECT_RELEASE enabled!
 */
init_completion(>dev_released);
device_unregister(>dev);
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 01/19] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned

[Saul Wold]

From: Mika Westerberg 

commit ad5f75aed7f6241aeaf4de293b7caedbc794dcae upstream.

This is the convention used in most parts of the kernel including DT
counterpart of I2C slave enumeration. To make things consistent do the same
for ACPI I2C slave enumeration path as well.

Signed-off-by: Mika Westerberg 
Acked-by: Wolfram Sang 
Signed-off-by: Linus Walleij 
(cherry picked from commit dab472eb931bc2916fa779e56deccd0ec319cf5b)
---
 drivers/i2c/i2c-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 987c124..c21b3de 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -107,7 +107,7 @@ static int acpi_i2c_add_resource(struct acpi_resource 
*ares, void *data)
if (sb->access_mode == ACPI_I2C_10BIT_MODE)
info->flags |= I2C_CLIENT_TEN;
}
-   } else if (info->irq < 0) {
+   } else if (!info->irq) {
struct resource r;
 
if (acpi_dev_resource_interrupt(ares, 0, ))
@@ -134,7 +134,6 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle, 
u32 level,
 
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
-   info.irq = -1;
 
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 06/19] i2c: core: Reduce stack size of acpi_i2c_space_handler()

[Saul Wold]

From: Jarkko Nikula 

commit 8e5d11906f6409f0374527d181808411fa6001e1 upstream.

sizeof(struct i2c_client) is 1088 bytes on a CONFIG_X86_64=y build and
produces following warning when CONFIG_FRAME_WARN is set to 1024:

drivers/i2c/i2c-core.c: In function ‘acpi_i2c_space_handler’:
drivers/i2c/i2c-core.c:367:1: warning: the frame size of 1152 bytes is
larger than 1024 bytes [-Wframe-larger-than=]

This is not critical given that kernel stack is 16 kB on x86_64 but lets
reduce the stack usage by allocating the struct i2c_client from the heap.

Signed-off-by: Jarkko Nikula 
Acked-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 7ef85f5fdd081b982d43b95b06272f8646a98818)
---
 drivers/i2c/i2c-core.c | 37 +
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index eefb200..069a41f 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -257,7 +257,7 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address 
command,
struct acpi_connection_info *info = >info;
struct acpi_resource_i2c_serialbus *sb;
struct i2c_adapter *adapter = data->adapter;
-   struct i2c_client client;
+   struct i2c_client *client;
struct acpi_resource *ares;
u32 accessor_type = function >> 16;
u8 action = function & ACPI_IO_MASK;
@@ -268,6 +268,12 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address 
command,
if (ACPI_FAILURE(ret))
return ret;
 
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client) {
+   ret = AE_NO_MEMORY;
+   goto err;
+   }
+
if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) {
ret = AE_BAD_PARAMETER;
goto err;
@@ -279,75 +285,73 @@ acpi_i2c_space_handler(u32 function, 
acpi_physical_address command,
goto err;
}
 
-   memset(, 0, sizeof(client));
-   client.adapter = adapter;
-   client.addr = sb->slave_address;
-   client.flags = 0;
+   client->adapter = adapter;
+   client->addr = sb->slave_address;
 
if (sb->access_mode == ACPI_I2C_10BIT_MODE)
-   client.flags |= I2C_CLIENT_TEN;
+   client->flags |= I2C_CLIENT_TEN;
 
switch (accessor_type) {
case ACPI_GSB_ACCESS_ATTRIB_SEND_RCV:
if (action == ACPI_READ) {
-   status = i2c_smbus_read_byte();
+   status = i2c_smbus_read_byte(client);
if (status >= 0) {
gsb->bdata = status;
status = 0;
}
} else {
-   status = i2c_smbus_write_byte(, gsb->bdata);
+   status = i2c_smbus_write_byte(client, gsb->bdata);
}
break;
 
case ACPI_GSB_ACCESS_ATTRIB_BYTE:
if (action == ACPI_READ) {
-   status = i2c_smbus_read_byte_data(, command);
+   status = i2c_smbus_read_byte_data(client, command);
if (status >= 0) {
gsb->bdata = status;
status = 0;
}
} else {
-   status = i2c_smbus_write_byte_data(, command,
+   status = i2c_smbus_write_byte_data(client, command,
gsb->bdata);
}
break;
 
case ACPI_GSB_ACCESS_ATTRIB_WORD:
if (action == ACPI_READ) {
-   status = i2c_smbus_read_word_data(, command);
+   status = i2c_smbus_read_word_data(client, command);
if (status >= 0) {
gsb->wdata = status;
status = 0;
}
} else {
-   status = i2c_smbus_write_word_data(, command,
+   status = i2c_smbus_write_word_data(client, command,
gsb->wdata);
}
break;
 
case ACPI_GSB_ACCESS_ATTRIB_BLOCK:
if (action == ACPI_READ) {
-   status = i2c_smbus_read_block_data(, command,
+   status = i2c_smbus_read_block_data(client, command,
gsb->data);
if (status >= 0) {
gsb->len = status;
status = 0;
}
} else {
-   status = i2c_smbus_write_block_data(, command,
+   status = 

[linux-yocto] [PATCH 02/19] i2c / ACPI: Assign IRQ for devices that have GpioInt automatically

[Saul Wold]

From: Mika Westerberg 

commit ed457856e712370c6e77303d103ec0103a44e4e9 upstream.

Following what DT already does. If the device does not have ACPI Interrupt
resource but instead it has one or more GpioInt resources listed below it,
we take the first GpioInt resource, convert it to suitable Linux IRQ number
and pass it to the driver instead.

This makes drivers simpler because the don't need to care about GPIOs at
all if only thing they need is interrupt.

Signed-off-by: Mika Westerberg 
Acked-by: Wolfram Sang 
Signed-off-by: Linus Walleij 
(cherry picked from commit 845c877009cf014b971aab7f54613f9185a824b0)
---
 drivers/i2c/i2c-core.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c21b3de..fc2ee82 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -631,8 +631,13 @@ static int i2c_device_probe(struct device *dev)
if (!client)
return 0;
 
-   if (!client->irq && dev->of_node) {
-   int irq = of_irq_get(dev->of_node, 0);
+   if (!client->irq) {
+   int irq = -ENOENT;
+
+   if (dev->of_node)
+   irq = of_irq_get(dev->of_node, 0);
+   else if (ACPI_COMPANION(dev))
+   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
 
if (irq == -EPROBE_DEFER)
return irq;
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 18/19] at24: enable ACPI device found on Galileo Gen2

[Saul Wold]

From: Andy Shevchenko 

commit afbc80ff5adf081edaa2ecb62e291580988f6643 upstream.

There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
(cherry picked from commit 40d8edc9bf056ea83e50152a4ccd33048d26ccde)
---
 drivers/misc/eeprom/at24.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2d3db81..f837060 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -131,6 +132,12 @@ static const struct i2c_device_id at24_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, at24_ids);
 
+static const struct acpi_device_id at24_acpi_ids[] = {
+   { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
+
 /*-*/
 
 /*
@@ -495,21 +502,29 @@ static void at24_get_ofdata(struct i2c_client *client,
 static int at24_probe(struct i2c_client *client, const struct i2c_device_id 
*id)
 {
struct at24_platform_data chip;
+   kernel_ulong_t magic = 0;
bool writable;
int use_smbus = 0;
int use_smbus_write = 0;
struct at24_data *at24;
int err;
unsigned i, num_addresses;
-   kernel_ulong_t magic;
 
if (client->dev.platform_data) {
chip = *(struct at24_platform_data *)client->dev.platform_data;
} else {
-   if (!id->driver_data)
+   if (id) {
+   magic = id->driver_data;
+   } else {
+   const struct acpi_device_id *aid;
+
+   aid = acpi_match_device(at24_acpi_ids, >dev);
+   if (aid)
+   magic = aid->driver_data;
+   }
+   if (!magic)
return -ENODEV;
 
-   magic = id->driver_data;
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
@@ -690,6 +705,7 @@ static struct i2c_driver at24_driver = {
.driver = {
.name = "at24",
.owner = THIS_MODULE,
+   .acpi_match_table = ACPI_PTR(at24_acpi_ids),
},
.probe = at24_probe,
.remove = at24_remove,
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 19/19] pwm-pca9685: enable ACPI device found on Galileo Gen2

[Saul Wold]

From: Andy Shevchenko 

commit c28d0a843b44f79f71249d5612804c29483b586d upstream.

There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.

Cc: Thierry Reding 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Thierry Reding 
(cherry picked from commit 912b8439041317a0562609ad892eeab9ba2f0cb2)
---
 drivers/pwm/Kconfig   |  2 +-
 drivers/pwm/pwm-pca9685.c | 20 
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..749198f 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -223,7 +223,7 @@ config PWM_MXS
 
 config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
-   depends on OF && I2C
+   depends on I2C
select REGMAP_I2C
help
  Generic PWM framework driver for NXP PCA9685 LED controller.
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index 34b5c27..8a1bd49 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -18,9 +18,11 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -212,7 +214,6 @@ static const struct regmap_config pca9685_regmap_i2c_config 
= {
 static int pca9685_pwm_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
-   struct device_node *np = client->dev.of_node;
struct pca9685 *pca;
int ret;
int mode2;
@@ -233,12 +234,12 @@ static int pca9685_pwm_probe(struct i2c_client *client,
 
regmap_read(pca->regmap, PCA9685_MODE2, );
 
-   if (of_property_read_bool(np, "invert"))
+   if (device_property_read_bool(>dev, "invert"))
mode2 |= MODE2_INVRT;
else
mode2 &= ~MODE2_INVRT;
 
-   if (of_property_read_bool(np, "open-drain"))
+   if (device_property_read_bool(>dev, "open-drain"))
mode2 &= ~MODE2_OUTDRV;
else
mode2 |= MODE2_OUTDRV;
@@ -276,17 +277,28 @@ static const struct i2c_device_id pca9685_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pca9685_id);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pca9685_acpi_ids[] = {
+   { "INT3492", 0 },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
+#endif
+
+#ifdef CONFIG_OF
 static const struct of_device_id pca9685_dt_ids[] = {
{ .compatible = "nxp,pca9685-pwm", },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
+#endif
 
 static struct i2c_driver pca9685_i2c_driver = {
.driver = {
.name = "pca9685-pwm",
.owner = THIS_MODULE,
-   .of_match_table = pca9685_dt_ids,
+   .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
+   .of_match_table = of_match_ptr(pca9685_dt_ids),
},
.probe = pca9685_pwm_probe,
.remove = pca9685_pwm_remove,
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 16/19] gpio: pca953x: store driver_data for future use

[Saul Wold]

From: Andy Shevchenko 

commit e0599e216341d4e0b69b57145c956a7028f06a81 upstream.

Instead of using id->driver_data directly we copied it to the internal
structure. This will help to adapt driver for ACPI use.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
(cherry picked from commit c6664149af2939b8bbaef0711b3ca5469bed33fb)
---
 drivers/gpio/gpio-pca953x.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index e2da64a..56f679b 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -42,6 +42,9 @@
 #define PCA_INT0x0100
 #define PCA953X_TYPE   0x1000
 #define PCA957X_TYPE   0x2000
+#define PCA_TYPE_MASK  0xF000
+
+#define PCA_CHIP_TYPE(x)   ((x) & PCA_TYPE_MASK)
 
 static const struct i2c_device_id pca953x_id[] = {
{ "pca9505", 40 | PCA953X_TYPE | PCA_INT, },
@@ -95,6 +98,7 @@ struct pca953x_chip {
struct gpio_chip gpio_chip;
const char *const *names;
int chip_type;
+   unsigned long driver_data;
 };
 
 static inline struct pca953x_chip *to_pca(struct gpio_chip *gc)
@@ -514,14 +518,13 @@ static irqreturn_t pca953x_irq_handler(int irq, void 
*devid)
 }
 
 static int pca953x_irq_setup(struct pca953x_chip *chip,
-const struct i2c_device_id *id,
 int irq_base)
 {
struct i2c_client *client = chip->client;
int ret, i, offset = 0;
 
if (client->irq && irq_base != -1
-   && (id->driver_data & PCA_INT)) {
+   && (chip->driver_data & PCA_INT)) {
 
switch (chip->chip_type) {
case PCA953X_TYPE:
@@ -574,12 +577,11 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
 
 #else /* CONFIG_GPIO_PCA953X_IRQ */
 static int pca953x_irq_setup(struct pca953x_chip *chip,
-const struct i2c_device_id *id,
 int irq_base)
 {
struct i2c_client *client = chip->client;
 
-   if (irq_base != -1 && (id->driver_data & PCA_INT))
+   if (irq_base != -1 && (chip->driver_data & PCA_INT))
dev_warn(>dev, "interrupt support not compiled in\n");
 
return 0;
@@ -666,14 +668,15 @@ static int pca953x_probe(struct i2c_client *client,
 
chip->client = client;
 
-   chip->chip_type = id->driver_data & (PCA953X_TYPE | PCA957X_TYPE);
+   chip->driver_data = id->driver_data;
+   chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
 
mutex_init(>i2c_lock);
 
/* initialize cached registers from their original values.
 * we can't share this chip with another i2c master.
 */
-   pca953x_setup_gpio(chip, id->driver_data & PCA_GPIO_MASK);
+   pca953x_setup_gpio(chip, chip->driver_data & PCA_GPIO_MASK);
 
if (chip->chip_type == PCA953X_TYPE)
ret = device_pca953x_init(chip, invert);
@@ -686,7 +689,7 @@ static int pca953x_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = pca953x_irq_setup(chip, id, irq_base);
+   ret = pca953x_irq_setup(chip, irq_base);
if (ret)
return ret;
 
-- 
2.5.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto