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 <email address hidden>
Acked-by: Andy Shevchenko <email address hidden>
Acked-by: Jarkko Nikula <email address hidden>
Signed-off-by: Wolfram Sang <email address hidden>
(cherry picked from commit cd86d1403bb4c80e443d736b2a692cbf68a9f471)
Signed-off-by: AceLan Kao <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
d01392d...
by
Hans de Goede <email address hidden>
i2c: i2c-designware-platdrv: Cleanup setting of the adapter number
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 <email address hidden>
Reviewed-by: Andy Shevchenko <email address hidden>
Acked-by: Jarkko Nikula <email address hidden>
Signed-off-by: Wolfram Sang <email address hidden>
(cherry picked from commit 77f3381a83c2f66daeb6719a1191a87280d57f62)
Signed-off-by: AceLan Kao <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
We don't need to allocate a new structure and copy the data from the
new one into it, because they are the same, except that the new
version has one more element at the end. We can simply send the same
structure but pass the size of the old one when we send the command.
This avoid extra stack allocations and a memcpy in the code. The
memcpy() was causing a static analyzer warning because it was not
using the size of the destination.
South Korea is adding a more strict SAR limit called "Limb SAR".
Currently, WGDS SAR offset group 3 is not used (not mapped to any country).
In order to be able to comply with South Korea new restriction:
- OEM will use WGDS SAR offset group 3 to South Korea limitation.
- OEM will change WGDS revision to 1 (currently latest revision is 0)
to notify that Korea Limb SAR applied.
- Driver will read the WGDS table and pass the values to FW (as usual)
- Driver will pass to FW an indication that Korea Limb SAR is applied
in case table revision is 1.
type=feature
ticket=none
Change-Id: I52d2afa9f243765b63da3279496c524c77b26e20
Signed-off-by: Haim Dreyfuss <email address hidden>
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/213163
Tested-by: ec ger unix iil jenkins <email address hidden>
Reviewed-by: Coelho, Luciano <email address hidden>
x-iwlwifi-stack-dev: 555b6eec8f43d85ec2073a98797bb45701960bc5
(backported from commit f86c47462c24135dc2cce72559629ebca8be2c7a https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git)
Signed-off-by: You-Sheng Yang <email address hidden>
Acked-by: Anthony Wong <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
