On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > >
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because
> > My conclusion for now is:
> >
> > There needs something to be done surely, but currently I don't have the
> > bandwidth to do it or even play around with it. I am not fully happy
> > with your patches as well because __maybe_unused has some kind of "last
> > resort" feeling to me.
>
> I
On Thursday 17 December 2015 13:01:57 Wolfram Sang wrote:
> On Mon, Dec 14, 2015 at 11:27:22PM +0100, Arnd Bergmann wrote:
> > On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > > > What about not ifdeffing the inline function and keep the build error
> > > > > whenever someone uses it
On Mon, Dec 14, 2015 at 11:27:22PM +0100, Arnd Bergmann wrote:
> On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > > What about not ifdeffing the inline function and keep the build error
> > > > whenever someone uses it without I2C_SLAVE being selected?
> > >
> > > The inline function
On Thursday 17 December 2015 13:01:57 Wolfram Sang wrote:
> On Mon, Dec 14, 2015 at 11:27:22PM +0100, Arnd Bergmann wrote:
> > On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > > > What about not ifdeffing the inline function and keep the build error
> > > > > whenever someone uses it
> > My conclusion for now is:
> >
> > There needs something to be done surely, but currently I don't have the
> > bandwidth to do it or even play around with it. I am not fully happy
> > with your patches as well because __maybe_unused has some kind of "last
> > resort" feeling to me.
>
> I
On Mon, Dec 14, 2015 at 11:27:22PM +0100, Arnd Bergmann wrote:
> On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > > What about not ifdeffing the inline function and keep the build error
> > > > whenever someone uses it without I2C_SLAVE being selected?
> > >
> > > The inline function
On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > >
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because
On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > What about not ifdeffing the inline function and keep the build error
> > > whenever someone uses it without I2C_SLAVE being selected?
> >
> > The inline function is only added there for the case that I2C_SLAVE is
> > disabled, so that
> > What about not ifdeffing the inline function and keep the build error
> > whenever someone uses it without I2C_SLAVE being selected?
>
> The inline function is only added there for the case that I2C_SLAVE is
> disabled, so that would be pointless.
>
> However, what we could do is move the
On Sunday 13 December 2015 10:09:59 Wolfram Sang wrote:
>
> What about not ifdeffing the inline function and keep the build error
> whenever someone uses it without I2C_SLAVE being selected?
The inline function is only added there for the case that I2C_SLAVE is
disabled, so that would be
On Sunday 13 December 2015 10:09:59 Wolfram Sang wrote:
>
> What about not ifdeffing the inline function and keep the build error
> whenever someone uses it without I2C_SLAVE being selected?
The inline function is only added there for the case that I2C_SLAVE is
disabled, so that would be
> > What about not ifdeffing the inline function and keep the build error
> > whenever someone uses it without I2C_SLAVE being selected?
>
> The inline function is only added there for the case that I2C_SLAVE is
> disabled, so that would be pointless.
>
> However, what we could do is move the
On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > What about not ifdeffing the inline function and keep the build error
> > > whenever someone uses it without I2C_SLAVE being selected?
> >
> > The inline function is only added there for the case that I2C_SLAVE is
> > disabled, so that
> > > The slave_cb callback function is supposed to set the 'value'
> > > here,
> >
> > Only if a master wants to READ from us.
>
> Right, and can this never fail?
Exactly. The slave can stretch the clock if the value to be sent to the
master needs some processing first, but it must deliver
> > > The slave_cb callback function is supposed to set the 'value'
> > > here,
> >
> > Only if a master wants to READ from us.
>
> Right, and can this never fail?
Exactly. The slave can stretch the clock if the value to be sent to the
master needs some processing first, but it must deliver
On Saturday 12 December 2015 17:20:57 Wolfram Sang wrote:
> Hi Arnd,
>
> thanks for looking into this, but I don't get your point yet.
>
> > The slave_cb callback function is supposed to set the 'value'
> > here,
>
> Only if a master wants to READ from us.
Right, and can this never fail?
> >
Hi Arnd,
thanks for looking into this, but I don't get your point yet.
> The slave_cb callback function is supposed to set the 'value'
> here,
Only if a master wants to READ from us.
> but it might return an error not assign the pointer,
An error is only returned if a WRITE from a master was
Hi Arnd,
thanks for looking into this, but I don't get your point yet.
> The slave_cb callback function is supposed to set the 'value'
> here,
Only if a master wants to READ from us.
> but it might return an error not assign the pointer,
An error is only returned if a WRITE from a master was
On Saturday 12 December 2015 17:20:57 Wolfram Sang wrote:
> Hi Arnd,
>
> thanks for looking into this, but I don't get your point yet.
>
> > The slave_cb callback function is supposed to set the 'value'
> > here,
>
> Only if a master wants to READ from us.
Right, and can this never fail?
> >
> Alternatively, the inline could return an error, and both bus
> drivers check for the error before using 'value'.
I'll try to check these options tomorrow.
signature.asc
Description: Digital signature
On Thursday 10 December 2015 22:54:25 kbuild test robot wrote:
>
>In file included from arch/x86/include/asm/realmode.h:5:0,
> from arch/x86/include/asm/acpi.h:33,
> from arch/x86/include/asm/fixmap.h:19,
> from
Hi Arnd,
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on next-20151210]
[cannot apply to v4.4-rc4]
url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/i2c-allow-building-emev2-without-slave-mode-again/20151210-211642
base:
On Thursday 10 December 2015 14:34:46 Wolfram Sang wrote:
> On Thu, Dec 10, 2015 at 02:14:49PM +0100, Arnd Bergmann wrote:
> > The emev2 driver stopped compiling in today's linux-next kernel:
> >
> > drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
> >
On Thu, Dec 10, 2015 at 02:14:49PM +0100, Arnd Bergmann wrote:
> The emev2 driver stopped compiling in today's linux-next kernel:
>
> drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
> drivers/i2c/busses/i2c-emev2.c:233:23: error: storage size of 'event' isn't
> known
>
The emev2 driver stopped compiling in today's linux-next kernel:
drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
drivers/i2c/busses/i2c-emev2.c:233:23: error: storage size of 'event' isn't
known
drivers/i2c/busses/i2c-emev2.c:250:3: error: implicit declaration of function
On Thu, Dec 10, 2015 at 02:14:49PM +0100, Arnd Bergmann wrote:
> The emev2 driver stopped compiling in today's linux-next kernel:
>
> drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
> drivers/i2c/busses/i2c-emev2.c:233:23: error: storage size of 'event' isn't
> known
>
On Thursday 10 December 2015 14:34:46 Wolfram Sang wrote:
> On Thu, Dec 10, 2015 at 02:14:49PM +0100, Arnd Bergmann wrote:
> > The emev2 driver stopped compiling in today's linux-next kernel:
> >
> > drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
> >
The emev2 driver stopped compiling in today's linux-next kernel:
drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
drivers/i2c/busses/i2c-emev2.c:233:23: error: storage size of 'event' isn't
known
drivers/i2c/busses/i2c-emev2.c:250:3: error: implicit declaration of function
Hi Arnd,
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on next-20151210]
[cannot apply to v4.4-rc4]
url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/i2c-allow-building-emev2-without-slave-mode-again/20151210-211642
base:
> Alternatively, the inline could return an error, and both bus
> drivers check for the error before using 'value'.
I'll try to check these options tomorrow.
signature.asc
Description: Digital signature
On Thursday 10 December 2015 22:54:25 kbuild test robot wrote:
>
>In file included from arch/x86/include/asm/realmode.h:5:0,
> from arch/x86/include/asm/acpi.h:33,
> from arch/x86/include/asm/fixmap.h:19,
> from
32 matches
Mail list logo
