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.westerb...@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@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 <mika.westerb...@linux.intel.com> > > Acked-by: Wolfram Sang <w...@the-dreams.de> > > Signed-off-by: Linus Walleij <linus.wall...@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 <s...@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 > > -- _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto