Hi, Andy
Thanks for your comments.
[Andy] Don't see a relationship between PCI driver and this ACPI stuff.
Although this is a pci driver, we may enumerate the i2c devices from
DSDT table while i2c controllers are enumerated via PCI. In this
scenario, in DSDT, there are descriptions of i2c devices
And add the original patch author to CC when resending.
signature.asc
Description: Digital signature
On Mon, 2015-10-12 at 15:41 +0800, Xiang Wang wrote:
> Hi, Andy
> Thanks for your comments.
>
> [Andy] Don't see a relationship between PCI driver and this ACPI
> stuff.
> Although this is a pci driver, we may enumerate the i2c devices from
> DSDT table while i2c controllers are enumerated via
Hi Kiera,
On Sun, Oct 11, 2015 at 12:39:31PM +0100, Kieran Bingham wrote:
> A change of return status was introduced in commit 3fffd1283927
> ("i2c: allow specifying separate wakeup interrupt in device tree")
Thanks for catching this!
> The commit prevents the defer status being passed up the
Hey guys,
I have a non-Linux i2c-hid related issue that I hope I could get some help
with. I have been porting the bus drivers for the Lynxpoint LPSS I2C
controllers and also the i2c-hid device drivers to OS X. Thanks to help from
this list earlier last year, the porting is almost finished. I
It seems as if the second check for I2C_FUNC_I2C functionality had been
introduced accidentally during a merge. Tt's reduntant, so remove it.
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/at24.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
In preparation for supporting the at24cs EEPROM series add a new flag to
platform data. When set, it should tell the driver that the chip has an
additional read-only memory area that holds a factory pre-programmed serial
number.
Signed-off-by: Bartosz Golaszewski
---
Improve the readability of the device table by separating columns with
tabs.
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/at24.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c
There is some code duplication in i2c-designware-platdrv and
i2c-designware-pcidrv probe functions. What is even worse that duplication
requires i2c_dw_xfer(), i2c_dw_func() and i2c_dw_isr() i2c-designware-core
functions to be exported.
Therefore move common code into new i2c_dw_probe() and make
Move the macro definitions above the struct definitions and add some
tabs for better readability.
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/at24.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
The infrastructure for reading of the factory-programmed serial number
for at24cs EEPROM series is now in place. Add the chips that are actually
equipped with the serial number memory area to the list of supported
devices.
Signed-off-by: Bartosz Golaszewski
---
Chips from the at24cs EEPROM series have an additional read-only memory area
containing a factory pre-programmed serial number. In order to access it, a
dummy write must be executed before reading the serial number bytes.
This series adds support for reading the serial number through a sysfs
On 10/10/15 16:24, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The core may register clients attached to this master which may use
> funtionality from the master. So, RuntimePM must be enabled before, otherwise
> this will fail. While here, move drvdata, too.
>
On Friday, October 09, 2015 05:41:46 PM Dustin Byford wrote:
> An I2cSerialBus connection resource descriptor may indicate a
> ResourceSource (a string uniquely identifying the I2C bus controller)
> anywhere in the ACPI namespace. However, when enumerating connections to a
> I2C bus controller,
On Mon Oct 12 21:01, Rafael J. Wysocki wrote:
> On Friday, October 09, 2015 05:41:46 PM Dustin Byford wrote:
> > An I2cSerialBus connection resource descriptor may indicate a
> > ResourceSource (a string uniquely identifying the I2C bus controller)
> > anywhere in the ACPI namespace. However,
On 12 October 2015 at 20:40, Wolfram Sang wrote:
>
>> Should I add Cc: stable? or are they notified from the Fixes: tag?
>
> My preference is: I'll add stable when I commit to my tree. I am happy
> if people tell me when they think this should be done.
>
> In this case, it
On Mon, Oct 12, 2015 at 12:49 PM, Kieran Bingham
wrote:
> A change of return status was introduced in commit 3fffd1283927
> ("i2c: allow specifying separate wakeup interrupt in device tree")
>
> The commit prevents the defer status being passed up the call stack
>
> Should I add Cc: stable? or are they notified from the Fixes: tag?
My preference is: I'll add stable when I commit to my tree. I am happy
if people tell me when they think this should be done.
In this case, it should :)
signature.asc
Description: Digital signature
On 12 October 2015 at 21:17, Dmitry Torokhov wrote:
> On Mon, Oct 12, 2015 at 12:49 PM, Kieran Bingham
> wrote:
>> A change of return status was introduced in commit 3fffd1283927
>> ("i2c: allow specifying separate wakeup interrupt in device
A change of return status was introduced in commit 3fffd1283927
("i2c: allow specifying separate wakeup interrupt in device tree")
The commit prevents the defer status being passed up the call stack
appropriately when dev_pm_domain_attach returns -EPROBE_DEFER.
Catch the PROBE_DEFER and clear up
On Mon, Oct 12, 2015 at 09:54:43PM +0100, Kieran Bingham wrote:
> A change of return status was introduced in commit 3fffd1283927
> ("i2c: allow specifying separate wakeup interrupt in device tree")
>
> The commit prevents the defer status being passed up the call stack
> appropriately when
21 matches
Mail list logo