On 4/21/20 7:36 PM, Simon Glass wrote:
Hi Patrice,
On Tue, 21 Apr 2020 at 08:09, Patrice Chotard patrice.chotard@st.com wrote:
Initial implementation invokes device_bind_with_driver_data() with driver_data parameter equal to 0. For driver with driver data, the bind command can't bind correctly this driver or even worse causes data abort.
Add find_udevice_id() to parse the driver's of_match list and return the entry corresponding to the driver compatible string. This allows to get access to driver_data and to use it as parameters of device_bind_with_driver_data().
Signed-off-by: Patrice Chotard patrice.chotard@st.com Cc: Jean-Jacques Hiblot jjhiblot@ti.com
cmd/bind.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-)
The thing I don't quite get here is why the driver name needs to be specified. If the device tree node is present, and it has a compatible
Sorry, i didn't get your point when you said "why the driver name needs to be specified"
Which part of this patch do you made reference to ?
string, can't DM find the driver and bind a device automatically?
Also, is there any docs for this command? It would be good to add to
Is what in cmd/bind.c not enough ?
U_BOOT_CMD( bind, 4, 0, do_bind_unbind, "Bind a device to a driver", "<node path> <driver>\n" "bind <class> <index> <driver>\n" );
U_BOOT_CMD( unbind, 4, 0, do_bind_unbind, "Unbind a device from a driver", "<node path>\n" "unbind <class> <index>\n" "unbind <class> <index> <driver>\n" );
doc/driver-model and also add a simple test.
Ok i will add an additionnal test to test/py/tests/test_bind.py
Thanks
Patrice
Regards, Simon