[[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.
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.
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.
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
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
