On Mon, Jan 26, 2015 at 08:59:31PM +0100, Jean Delvare wrote:
> Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
> included unconditionally, even when it is not needed.
>
> I2C bus drivers which implement slave support must select
> I2C_SLAVE.
>
> Signed-off-by: Jean Delvare
On Mon, Jan 26, 2015 at 07:55:02PM +0300, Dmitry Osipenko wrote:
> Support CPU BE mode by adding endianness conversion for memcpy interactions.
>
> Signed-off-by: Dmitry Osipenko
> Acked-by: Alexandre Courbot
Applied to for-next, thanks!
signature.asc
Description: Digital signature
On Mon, Jan 26, 2015 at 05:49:34PM +0100, Wolfram Sang wrote:
> IOSF_MBI depends on PCI, so we should not select it but depend on it.
> This ensures also we compile on X86 only, other archs will break because
> of an arch specific include. Also depend on ACPI since this driver uses
> it.
>
> Signe
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.
I2C bus drivers which implement slave support must select
I2C_SLAVE.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
Changes since v2:
* Added missing #if around i2c_algo
> > Which is going in when?
>
> Can you apply it since it is a dependency on this bug fix patch.
I can but I don't have it in my inbox. So, I need a resent version with
a DT maintainer's ack.
signature.asc
Description: Digital signature
On Mon, Jan 26, 2015 at 9:55 AM, Wolfram Sang wrote:
> On Sat, Jan 24, 2015 at 09:16:16AM +0200, Pantelis Antoniou wrote:
>> Hi Wolfram,
>>
>> > On Jan 24, 2015, at 06:26 , Wolfram Sang wrote:
>> >
>> >
>> >> Feel free to apply it for 3.19 with my ack. You then want to pick up
>> >> v1 of this pa
On Mon, 26 Jan 2015 19:05:09 +0100, Wolfram Sang wrote:
> On Mon, Jan 26, 2015 at 07:00:47PM +0100, Jean Delvare wrote:
> > Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
> > included unconditionally, even when it is not needed.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Wo
On Mon, Jan 26, 2015 at 05:49:34PM +0100, Wolfram Sang wrote:
> IOSF_MBI depends on PCI, so we should not select it but depend on it.
> This ensures also we compile on X86 only, other archs will break because
> of an arch specific include. Also depend on ACPI since this driver uses
> it.
>
> Signe
On Mon, Jan 26, 2015 at 10:01:10AM -0800, David E. Box wrote:
> On Mon, Jan 26, 2015 at 05:49:34PM +0100, Wolfram Sang wrote:
> > IOSF_MBI depends on PCI, so we should not select it but depend on it.
> > This ensures also we compile on X86 only, other archs will break because
> > of an arch specifi
On Mon, Jan 26, 2015 at 05:49:34PM +0100, Wolfram Sang wrote:
> IOSF_MBI depends on PCI, so we should not select it but depend on it.
> This ensures also we compile on X86 only, other archs will break because
> of an arch specific include. Also depend on ACPI since this driver uses
> it.
>
> Signe
On Mon, Jan 26, 2015 at 07:00:47PM +0100, Jean Delvare wrote:
> Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
> included unconditionally, even when it is not needed.
>
> Signed-off-by: Jean Delvare
> Cc: Wolfram Sang
> ---
> Changes since v1:
> * Let I2C_RCAR select I2C_SL
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
Changes since v1:
* Let I2C_RCAR select I2C_SLAVE
Wolfram, you mentioned i2c-sh_mobile but that driver doesn't seem to
impl
> Hmm, what about bus drivers with slave mode support must select
> CONFIG_I2C_SLAVE? This solves my problem nicely, and makes no change
> compared to the current situation for people using slave mode.
I like that! Let's do it this way.
signature.asc
Description: Digital signature
You can check if ret == -ETIMEDOUT in the error path instead of
allocating another variable.
You also generated the patch with your /arch/arm/boot/dts/Makefile changes.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
Mor
On Mon, 26 Jan 2015 17:30:13 +0100, Wolfram Sang wrote:
>
> > > Own module: Again, undecided. On the one hand it makes for a nice
> > > encapsulation, on the other hand there is overhead for having another
> > > module. I am very happy that the core code for slave support is so slim.
> >
> > I ga
Support CPU BE mode by adding endianness conversion for memcpy interactions.
Signed-off-by: Dmitry Osipenko
Acked-by: Alexandre Courbot
---
Changelog:
v2: For consistency cpu_to_le32() changed to le32_to_cpu() because
i2c_writel() takes BE value in BE CPU mode and value is in LE format.
v3:
On Mon, Jan 26, 2015 at 05:49:34PM +0100, Wolfram Sang wrote:
> IOSF_MBI depends on PCI, so we should not select it but depend on it.
> This ensures also we compile on X86 only, other archs will break because
> of an arch specific include. Also depend on ACPI since this driver uses
> it.
>
> Signe
IOSF_MBI depends on PCI, so we should not select it but depend on it.
This ensures also we compile on X86 only, other archs will break because
of an arch specific include. Also depend on ACPI since this driver uses
it.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/Kconfig | 3 +--
1 file ch
> > Own module: Again, undecided. On the one hand it makes for a nice
> > encapsulation, on the other hand there is overhead for having another
> > module. I am very happy that the core code for slave support is so slim.
>
> I gave a try to the separate module approach and I have to agree that
>
Hi Wolfram,
On Mon, 26 Jan 2015 12:33:29 +0100, Wolfram Sang wrote:
> > I find it confusing that I2C slave support is included even when
> > CONFIG_I2C_SLAVE is not set. I don't know if this was discussed before?
>
> I was thinking about it but was undecided between "size of code added
> uncondit
26.01.2015 19:03, Wolfram Sang пишет:
Gaahh! I'm sure it wasn't working before! I'll make more testing and send v3
without "val = 0", if all will be fine.
Please either send V3 or explicitly say V2 is OK. No need to hurry, just
saying that I am waiting for updates here...
Sure!
--
Dmitry
-
> Gaahh! I'm sure it wasn't working before! I'll make more testing and send v3
> without "val = 0", if all will be fine.
Please either send V3 or explicitly say V2 is OK. No need to hurry, just
saying that I am waiting for updates here...
signature.asc
Description: Digital signature
On Fri, Jan 23, 2015 at 11:35:55AM +0200, Jarkko Nikula wrote:
> Do SCL timing parameter calculation conditionally depending are custom
> parameters provided since calculated values will get instantly overwritten
> by provided parameters.
>
> Signed-off-by: Jarkko Nikula
Applied to for-next, tha
On Sat, Jan 24, 2015 at 09:16:16AM +0200, Pantelis Antoniou wrote:
> Hi Wolfram,
>
> > On Jan 24, 2015, at 06:26 , Wolfram Sang wrote:
> >
> >
> >> Feel free to apply it for 3.19 with my ack. You then want to pick up
> >> v1 of this patch.
> >
> > Sigh, I give up, this is too confusing. I don'
On Fri, Jan 16, 2015 at 12:07:22AM -0800, Dmitry Torokhov wrote:
> Trying to register an I2C device asynchronously (via async_schedule() call)
> results in an ugly warning from request_module() warning about potential
> deadlock (because request_module tries to wait for async works to
> complete).
On Sat, Jan 24, 2015 at 05:19:14AM +0100, Wolfram Sang wrote:
> On Fri, Jan 23, 2015 at 03:04:06PM +0200, Andy Shevchenko wrote:
> > On Fri, 2015-01-23 at 14:48 +0200, Mika Westerberg wrote:
> > > On Fri, Jan 23, 2015 at 01:41:55PM +0100, Wolfram Sang wrote:
> > > > On Fri, Jan 23, 2015 at 01:54:03
On Thu, Jan 15, 2015 at 04:54:14PM +0200, Laurent Pinchart wrote:
> DT nodes should use the more specific adi,adxl345 and adi,adxl346
> compatible values instead. As the ADXL346 is backward-compatible with
> the ADXL345, ADXL346 nodes must list both adi,adxl346 and adi,adxl345,
> in that order.
>
> >> If you drop adi,adxl346, checkpatch will start complaining if it encounters
> >> it in a .dts.
> >
> > Boah, this is annoying. That means we need an 346 entry even if it is
> > not different from 345 (which is fine by me).
>
> To be clear: you need the entry in the documentation. It can be o
On Thu, 22 Jan 2015 14:28:10 +0100, Michael Mercier wrote:
> I have only tested read_i2c_block_data write_i2c_block_data for python
> 3.2 and python 2.7.
>
> I think you can push these patchs upstream.
I committed both patches. I also added python 3 support to the stable
branch.
--
Jean Delvar
> I find it confusing that I2C slave support is included even when
> CONFIG_I2C_SLAVE is not set. I don't know if this was discussed before?
I was thinking about it but was undecided between "size of code added
unconditionally" and "ugly #ifdeffing the code".
> I am considering adding ifdefs aro
On Thu, Jan 15, 2015 at 01:12:15AM -0800, David E. Box wrote:
> V4: - Added bus lock to i2c_dw_init() as suggested by Jarrko Nikula
> . Addresses infrequent hang that was
> seen occuring during probe.
> - Added label in i2c_dw_xfer() to bypass unnecessary lock release when
>
31 matches
Mail list logo
