[PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

AceLan Kao
BugLink: https://bugs.launchpad.net/bugs/1835150

[Impact]
I2C designware fails to get its adapter number, and this may lead to fail to access touchpad through I2C bus.
[ 6.476367] WARNING: CPU: 9 PID: 567 at /build/linux-oem-osp1-bkWHJC/linux-oem-osp1-5.0.0/drivers/i2c/i2c-core-base.c:1322 i2c_add_numbered_adapter+0x81/0x90

[Fix]
The 2 commits from v5.1-rc1 fix this issue.
   cd86d1403bb4 i2c: i2c-designware-platdrv: Always use a dynamic adapter number
   77f3381a83c2 i2c: i2c-designware-platdrv: Cleanup setting of the adapter number

[Test]
Verified on Dell machine which had this issue.

[Regression Potential]
Low, the 2 commits make it always use dynamic adapter-numbers which does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops.

Hans de Goede (2):
  i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
  i2c: i2c-designware-platdrv: Always use a dynamic adapter number

 drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

--
2.17.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/2][SRU][D][OEM-OSP1-B] i2c: i2c-designware-platdrv: Cleanup setting of the adapter number

AceLan Kao
From: Hans de Goede <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1835150

i2c-designware-platdrv assumes that if the pdev has an apci-companion
it should use a dynamic adapter-nr and otherwise it will use pdev->id
as adapter-nr.

Before this commit the setting of the adapter.nr was somewhat convoluted,
in the acpi_companion case it was set from dw_i2c_acpi_configure, in the
non acpi_companion case it was set from dw_i2c_set_fifo_size based on
tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was
not executed.

This cleans this up, directly setting the adapter-nr from
dw_i2c_plat_probe for both cases.

Signed-off-by: Hans de Goede <[hidden email]>
Reviewed-by: Andy Shevchenko <[hidden email]>
Acked-by: Jarkko Nikula <[hidden email]>
Signed-off-by: Wolfram Sang <[hidden email]>
(cherry picked from commit 77f3381a83c2f66daeb6719a1191a87280d57f62)
Signed-off-by: AceLan Kao <[hidden email]>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index ead5e7de3e4d..30529839cbd2 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -86,7 +86,6 @@ static int dw_i2c_acpi_configure(struct platform_device *pdev)
  struct i2c_timings *t = &dev->timings;
  u32 ss_ht = 0, fp_ht = 0, hs_ht = 0, fs_ht = 0;
 
- dev->adapter.nr = -1;
  dev->tx_fifo_depth = 32;
  dev->rx_fifo_depth = 32;
 
@@ -219,7 +218,7 @@ static void i2c_dw_configure_slave(struct dw_i2c_dev *dev)
  dev->mode = DW_IC_SLAVE;
 }
 
-static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id)
+static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev)
 {
  u32 param, tx_fifo_depth, rx_fifo_depth;
 
@@ -233,7 +232,6 @@ static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id)
  if (!dev->tx_fifo_depth) {
  dev->tx_fifo_depth = tx_fifo_depth;
  dev->rx_fifo_depth = rx_fifo_depth;
- dev->adapter.nr = id;
  } else if (tx_fifo_depth >= 2) {
  dev->tx_fifo_depth = min_t(u32, dev->tx_fifo_depth,
  tx_fifo_depth);
@@ -358,13 +356,17 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
  div_u64(clk_khz * t->sda_hold_ns + 500000, 1000000);
  }
 
- dw_i2c_set_fifo_size(dev, pdev->id);
+ dw_i2c_set_fifo_size(dev);
 
  adap = &dev->adapter;
  adap->owner = THIS_MODULE;
  adap->class = I2C_CLASS_DEPRECATED;
  ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
  adap->dev.of_node = pdev->dev.of_node;
+ if (has_acpi_companion(&pdev->dev))
+ adap->nr = -1;
+ else
+ adap->nr = pdev->id;
 
  dev_pm_set_driver_flags(&pdev->dev,
  DPM_FLAG_SMART_PREPARE |
--
2.17.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/2][SRU][D][OEM-OSP1-B] i2c: i2c-designware-platdrv: Always use a dynamic adapter number

AceLan Kao
In reply to this post by AceLan Kao
From: Hans de Goede <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1835150

Before this commit the i2c-designware-platdrv assumes that if the pdev
has an apci-companion it should use a dynamic adapter-nr and it sets
adapter->nr to -1, otherwise it will use pdev->id as adapter->nr.

There are 3 ways how platform_device-s to which i2c-designware-platdrv
will bind can be instantiated:

1) Through of / devicetree
2) Through ACPI enumeration
3) Explicitly instantiated through platform_device_create + add

1) In case of devicetree-instantiation the drivers/of code always sets
pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths
to set adapter->nr end up doing the same thing.

2) In case of ACPI instantiation the device will always have an
ACPI-companion, so we are already using dynamic adapter-nrs.

3) There are 2 places manually instantiating a designware_i2c platform_dev:
drivers/mfd/intel_quark_i2c_gpio.c
drivers/mfd/intel-lpss.c

In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to
dynamic adapter-nrs here could lead to the bus-number no longer being
stable, but the quark X1000 only has 1 i2c-controller, which will also
be assigned bus-number 0 when using dynamic adapter-nrs.

In the intel-lpss.c case intel_lpss_probe() is called from either
intel-lpss-acpi.c in which case there always is an ACPI-companion, or
from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c
also have an ACPI-companion, so we use a dynamic adapter-nr. But in some
cases the ACPI-companion is missing and we would use pdev->id (allocated
from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code
typically have many i2c busses, so using pdev->id in this case may lead
to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr")
in i2c-core-base.c causing an oops an the adapter registration to fail.
So in this case using non dynamic adapter-nrs is actually undesirable.

One machine on which this oops was triggering is the Apollo Lake based
Acer TravelMate Spin B118.

TL;DR: Switching to always using dynamic adapter-numbers does not make
any difference in most cases and in the one case where it does make a
difference the behavior change is desirable because the old behavior
caused an oops.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065
Signed-off-by: Hans de Goede <[hidden email]>
Acked-by: Andy Shevchenko <[hidden email]>
Acked-by: Jarkko Nikula <[hidden email]>
Signed-off-by: Wolfram Sang <[hidden email]>
(cherry picked from commit cd86d1403bb4c80e443d736b2a692cbf68a9f471)
Signed-off-by: AceLan Kao <[hidden email]>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 30529839cbd2..416f89b8f881 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -363,10 +363,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
  adap->class = I2C_CLASS_DEPRECATED;
  ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
  adap->dev.of_node = pdev->dev.of_node;
- if (has_acpi_companion(&pdev->dev))
- adap->nr = -1;
- else
- adap->nr = pdev->id;
+ adap->nr = -1;
 
  dev_pm_set_driver_flags(&pdev->dev,
  DPM_FLAG_SMART_PREPARE |
--
2.17.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/2][SRU][B][OEM-B] i2c: i2c-designware-platdrv: Cleanup setting of the adapter number

AceLan Kao
In reply to this post by AceLan Kao
From: Hans de Goede <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1835150

i2c-designware-platdrv assumes that if the pdev has an apci-companion
it should use a dynamic adapter-nr and otherwise it will use pdev->id
as adapter-nr.

Before this commit the setting of the adapter.nr was somewhat convoluted,
in the acpi_companion case it was set from dw_i2c_acpi_configure, in the
non acpi_companion case it was set from dw_i2c_set_fifo_size based on
tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was
not executed.

This cleans this up, directly setting the adapter-nr from
dw_i2c_plat_probe for both cases.

Signed-off-by: Hans de Goede <[hidden email]>
Reviewed-by: Andy Shevchenko <[hidden email]>
Acked-by: Jarkko Nikula <[hidden email]>
Signed-off-by: Wolfram Sang <[hidden email]>
(cherry picked from commit 77f3381a83c2f66daeb6719a1191a87280d57f62)
Signed-off-by: AceLan Kao <[hidden email]>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 58add69a441c..7bb147cface3 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -101,7 +101,6 @@ static int dw_i2c_acpi_configure(struct platform_device *pdev)
  struct acpi_device *adev;
  const char *uid;
 
- dev->adapter.nr = -1;
  dev->tx_fifo_depth = 32;
  dev->rx_fifo_depth = 32;
 
@@ -226,7 +225,7 @@ static int i2c_dw_plat_prepare_clk(struct dw_i2c_dev *i_dev, bool prepare)
  return 0;
 }
 
-static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id)
+static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev)
 {
  u32 param, tx_fifo_depth, rx_fifo_depth;
 
@@ -240,7 +239,6 @@ static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id)
  if (!dev->tx_fifo_depth) {
  dev->tx_fifo_depth = tx_fifo_depth;
  dev->rx_fifo_depth = rx_fifo_depth;
- dev->adapter.nr = id;
  } else if (tx_fifo_depth >= 2) {
  dev->tx_fifo_depth = min_t(u32, dev->tx_fifo_depth,
  tx_fifo_depth);
@@ -364,13 +362,17 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
  1000000);
  }
 
- dw_i2c_set_fifo_size(dev, pdev->id);
+ dw_i2c_set_fifo_size(dev);
 
  adap = &dev->adapter;
  adap->owner = THIS_MODULE;
  adap->class = I2C_CLASS_DEPRECATED;
  ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
  adap->dev.of_node = pdev->dev.of_node;
+ if (has_acpi_companion(&pdev->dev))
+ adap->nr = -1;
+ else
+ adap->nr = pdev->id;
 
  /* The code below assumes runtime PM to be disabled. */
  WARN_ON(pm_runtime_enabled(&pdev->dev));
--
2.17.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/2][SRU][B][OEM-B] i2c: i2c-designware-platdrv: Always use a dynamic adapter number

AceLan Kao
In reply to this post by AceLan Kao
From: Hans de Goede <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1835150

Before this commit the i2c-designware-platdrv assumes that if the pdev
has an apci-companion it should use a dynamic adapter-nr and it sets
adapter->nr to -1, otherwise it will use pdev->id as adapter->nr.

There are 3 ways how platform_device-s to which i2c-designware-platdrv
will bind can be instantiated:

1) Through of / devicetree
2) Through ACPI enumeration
3) Explicitly instantiated through platform_device_create + add

1) In case of devicetree-instantiation the drivers/of code always sets
pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths
to set adapter->nr end up doing the same thing.

2) In case of ACPI instantiation the device will always have an
ACPI-companion, so we are already using dynamic adapter-nrs.

3) There are 2 places manually instantiating a designware_i2c platform_dev:
drivers/mfd/intel_quark_i2c_gpio.c
drivers/mfd/intel-lpss.c

In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to
dynamic adapter-nrs here could lead to the bus-number no longer being
stable, but the quark X1000 only has 1 i2c-controller, which will also
be assigned bus-number 0 when using dynamic adapter-nrs.

In the intel-lpss.c case intel_lpss_probe() is called from either
intel-lpss-acpi.c in which case there always is an ACPI-companion, or
from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c
also have an ACPI-companion, so we use a dynamic adapter-nr. But in some
cases the ACPI-companion is missing and we would use pdev->id (allocated
from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code
typically have many i2c busses, so using pdev->id in this case may lead
to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr")
in i2c-core-base.c causing an oops an the adapter registration to fail.
So in this case using non dynamic adapter-nrs is actually undesirable.

One machine on which this oops was triggering is the Apollo Lake based
Acer TravelMate Spin B118.

TL;DR: Switching to always using dynamic adapter-numbers does not make
any difference in most cases and in the one case where it does make a
difference the behavior change is desirable because the old behavior
caused an oops.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065
Signed-off-by: Hans de Goede <[hidden email]>
Acked-by: Andy Shevchenko <[hidden email]>
Acked-by: Jarkko Nikula <[hidden email]>
Signed-off-by: Wolfram Sang <[hidden email]>
(cherry picked from commit cd86d1403bb4c80e443d736b2a692cbf68a9f471)
Signed-off-by: AceLan Kao <[hidden email]>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 7bb147cface3..662704541acd 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -369,10 +369,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
  adap->class = I2C_CLASS_DEPRECATED;
  ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
  adap->dev.of_node = pdev->dev.of_node;
- if (has_acpi_companion(&pdev->dev))
- adap->nr = -1;
- else
- adap->nr = pdev->id;
+ adap->nr = -1;
 
  /* The code below assumes runtime PM to be disabled. */
  WARN_ON(pm_runtime_enabled(&pdev->dev));
--
2.17.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED Re: [PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

Timo Aaltonen-6
In reply to this post by AceLan Kao
On 3.7.2019 6.16, AceLan Kao wrote:

> BugLink: https://bugs.launchpad.net/bugs/1835150
>
> [Impact]
> I2C designware fails to get its adapter number, and this may lead to fail to access touchpad through I2C bus.
> [ 6.476367] WARNING: CPU: 9 PID: 567 at /build/linux-oem-osp1-bkWHJC/linux-oem-osp1-5.0.0/drivers/i2c/i2c-core-base.c:1322 i2c_add_numbered_adapter+0x81/0x90
>
> [Fix]
> The 2 commits from v5.1-rc1 fix this issue.
>    cd86d1403bb4 i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>    77f3381a83c2 i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>
> [Test]
> Verified on Dell machine which had this issue.
>
> [Regression Potential]
> Low, the 2 commits make it always use dynamic adapter-numbers which does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops.
>
> Hans de Goede (2):
>   i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>   i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>
>  drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>

applied to osp1 oem-next, thanks

--
t

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

Stefan Bader-2
In reply to this post by AceLan Kao
On 03.07.19 05:16, AceLan Kao wrote:

> BugLink: https://bugs.launchpad.net/bugs/1835150
>
> [Impact]
> I2C designware fails to get its adapter number, and this may lead to fail to access touchpad through I2C bus.
> [ 6.476367] WARNING: CPU: 9 PID: 567 at /build/linux-oem-osp1-bkWHJC/linux-oem-osp1-5.0.0/drivers/i2c/i2c-core-base.c:1322 i2c_add_numbered_adapter+0x81/0x90
>
> [Fix]
> The 2 commits from v5.1-rc1 fix this issue.
>    cd86d1403bb4 i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>    77f3381a83c2 i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>
> [Test]
> Verified on Dell machine which had this issue.
>
> [Regression Potential]
> Low, the 2 commits make it always use dynamic adapter-numbers which does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops.
>
> Hans de Goede (2):
>   i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>   i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>
>  drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
Acked-by: Stefan Bader <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

Kleber Souza
In reply to this post by AceLan Kao
On 03.07.19 05:16, AceLan Kao wrote:

> BugLink: https://bugs.launchpad.net/bugs/1835150
>
> [Impact]
> I2C designware fails to get its adapter number, and this may lead to fail to access touchpad through I2C bus.
> [ 6.476367] WARNING: CPU: 9 PID: 567 at /build/linux-oem-osp1-bkWHJC/linux-oem-osp1-5.0.0/drivers/i2c/i2c-core-base.c:1322 i2c_add_numbered_adapter+0x81/0x90
>
> [Fix]
> The 2 commits from v5.1-rc1 fix this issue.
>    cd86d1403bb4 i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>    77f3381a83c2 i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>
> [Test]
> Verified on Dell machine which had this issue.
>
> [Regression Potential]
> Low, the 2 commits make it always use dynamic adapter-numbers which does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops.
>
> Hans de Goede (2):
>   i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>   i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>
>  drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>

Acked-by: Kleber Sacilotto de Souza <[hidden email]>

Thank you,
Kleber

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED: [PATCH 0/2][SRU][B][D][OEM-B][OEM-OSP1-B]Sometimes touchpad detected as mouse(i2c designware fails to get adapter number)

Kleber Souza
In reply to this post by AceLan Kao
On 03.07.19 05:16, AceLan Kao wrote:

> BugLink: https://bugs.launchpad.net/bugs/1835150
>
> [Impact]
> I2C designware fails to get its adapter number, and this may lead to fail to access touchpad through I2C bus.
> [ 6.476367] WARNING: CPU: 9 PID: 567 at /build/linux-oem-osp1-bkWHJC/linux-oem-osp1-5.0.0/drivers/i2c/i2c-core-base.c:1322 i2c_add_numbered_adapter+0x81/0x90
>
> [Fix]
> The 2 commits from v5.1-rc1 fix this issue.
>    cd86d1403bb4 i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>    77f3381a83c2 i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>
> [Test]
> Verified on Dell machine which had this issue.
>
> [Regression Potential]
> Low, the 2 commits make it always use dynamic adapter-numbers which does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops.
>
> Hans de Goede (2):
>   i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
>   i2c: i2c-designware-platdrv: Always use a dynamic adapter number
>
>  drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>

Applied to bionic/master-next and disco/master-next branches.

Thanks,
Kleber

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team