Hi Stephen,
On 28 April 2016 at 17:08, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
This will allow a driver's bind function to use the driver data. One example is the Tegra186 GPIO driver, which instantiates child devices for each of its GPIO ports, yet supports two different HW instances each with a different set of ports, and identified by the udevice_id .data field.
Signed-off-by: Stephen Warren swarren@nvidia.com
drivers/core/device.c | 7 ++++--- drivers/core/lists.c | 6 +++--- drivers/gpio/dwapb_gpio.c | 2 +- drivers/gpio/s5p_gpio.c | 2 +- drivers/gpio/sunxi_gpio.c | 2 +- drivers/gpio/tegra_gpio.c | 2 +- drivers/mtd/spi/sandbox.c | 2 +- drivers/net/mvpp2.c | 3 ++- drivers/pci/pci-uclass.c | 5 ++--- drivers/power/pmic/pmic-uclass.c | 2 +- drivers/usb/host/usb-uclass.c | 5 ++--- include/dm/device-internal.h | 5 +++-- 12 files changed, 22 insertions(+), 21 deletions(-)
I'm not sure this extra parameter carries its weight:
- most callers just pass 0 - the field is supposed to be set up by device tree and probing tables, not code - bind() methods should not care about the driver data (they are not allowed to touch hardware), so setting it later is fine - you can already pass platform data to the driver which is the preferred communication method from a parent to its children
Also it's not clear from your Tegra 186 GPIO patch where you are using this.
Regards, Simon