[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 <mika.westerberg at linux.intel.com>
> 
> 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 at 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 at 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 <mika.westerberg at linux.intel.com>
> > Acked-by: Wolfram Sang <wsa at the-dreams.de>
> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> 
> 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 <sgw at linux.intel.com>
> > ---
> >  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, &r))
> > @@ -134,7 +134,6 @@ static acpi_status
> > acpi_i2c_add_device(acpi_handle handle, u32 level,
> >  
> >  	memset(&info, 0, sizeof(info));
> >  	info.fwnode = acpi_fwnode_handle(adev);
> > -	info.irq = -1;
> >  
> >  	INIT_LIST_HEAD(&resource_list);
> >  	ret = acpi_dev_get_resources(adev, &resource_list,
> > -- 
> > 2.5.0
> >