Hi, On 11 July 2018 at 07:40, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Jul 11, 2018 at 03:31:39PM +0200, Michal Simek wrote: > > On 11.7.2018 14:46, Tom Rini wrote: > > > On Wed, Jul 11, 2018 at 07:57:13AM +0200, Michal Simek wrote: > > >> On 10.7.2018 18:40, Tom Rini wrote: > > >>> On Mon, Jul 09, 2018 at 11:59:57AM -0500, Joe Hershberger wrote: > > >>>> On Mon, Jul 9, 2018 at 9:43 AM, Tom Rini <tr...@konsulko.com> wrote: > > >>>>> On Mon, Jul 09, 2018 at 08:19:44AM +0200, Michal Simek wrote: > > >>>>>> On 30.6.2018 06:19, Simon Glass wrote: > > >>>>>>> On 27 June 2018 at 07:13, Michal Simek <michal.si...@xilinx.com> > > >>>>>>> wrote: > > >>>>>>>> On 22.6.2018 14:25, Jean-Jacques Hiblot wrote: > > >>>>>>>>> In some cases it can be useful to be able to bind a device to a > > >>>>>>>>> driver from > > >>>>>>>>> the command line. > > >>>>>>>>> The obvious example is for versatile devices such as USB gadget. > > >>>>>>>>> Another use case is when the devices are not yet ready at startup > > >>>>>>>>> and > > >>>>>>>>> require some setup before the drivers are bound (ex: FPGA which > > >>>>>>>>> bitsream is > > >>>>>>>>> fetched from a mass storage or ethernet) > > >>>>>>>>> > > >>>>>>>>> usage example: > > >>>>>>>>> > > >>>>>>>>> bind usb_dev_generic 0 usb_ether > > >>>>>>>>> unbind usb_dev_generic 0 usb_ether > > >>>>>>>>> or > > >>>>>>>>> unbind eth 1 > > >>>>>>>>> > > >>>>>>>>> bind /ocp/omap_dwc3@48380000/usb@48390000 usb_ether > > >>>>>>>>> unbind /ocp/omap_dwc3@48380000/usb@48390000 > > >>>>>>>>> > > >>>>>>>>> Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com> > > >>>>>>>>> > > >>>>>>>>> --- > > >>>>>>>>> > > >>>>>>>>> Changes in v3: > > >>>>>>>>> - factorize code based on comments from ML > > >>>>>>>>> - remove the devices before unbinding them > > >>>>>>>>> - use device_find_global_by_ofnode() to get a device by its node. > > >>>>>>>>> - Added tests > > >>>>>>>>> > > >>>>>>>>> Changes in v2: > > >>>>>>>>> - Make the bind/unbind command generic, not specific to usb > > >>>>>>>>> device. > > >>>>>>>>> - Update the API to be able to bind/unbind based on DTS node path > > >>>>>>>>> - Add a Kconfig option to select the bind/unbind commands > > >>>>>>>>> > > >>>>>>>>> arch/sandbox/dts/test.dts | 11 ++ > > >>>>>>>>> cmd/Kconfig | 9 ++ > > >>>>>>>>> cmd/Makefile | 1 + > > >>>>>>>>> cmd/bind.c | 255 > > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++++++ > > >>>>>>>>> configs/sandbox_defconfig | 1 + > > >>>>>>>>> test/py/tests/test_bind.py | 178 +++++++++++++++++++++++++++++++ > > >>>>>>>>> 6 files changed, 455 insertions(+) > > >>>>>>>>> create mode 100644 cmd/bind.c > > >>>>>>>>> create mode 100644 test/py/tests/test_bind.py > > >>>>>>> > > >>>>>>> Reviewed-by: Simon Glass <s...@chromium.org> > > >>>>>>> > > >>>>>>> Nice work > > >>>>>>> > > >>>>>>> [...] > > >>>>>>> > > >>>>>>>> > > >>>>>>>> I have tested bind/unbind with dwc3 on zynqmp for ethernet gadget > > >>>>>>>> and it > > >>>>>>>> is working fine for me. > > >>>>>>>> I have also tried to use bind/unbind for gpio zynqmp driver and it > > >>>>>>>> is > > >>>>>>>> also working fine. > > >>>>>>>> > > >>>>>>>> It means > > >>>>>>>> Tested-by: Michal Simek <michal.si...@xilinx.com> > > >>>>>>>> > > >>>>>>>> I would prefer if these commands are called as dm bind and dm > > >>>>>>>> unbind > > >>>>>>>> instead of simply bind/unbind which should also fit to dm command > > >>>>>>>> description "dm - Driver model low level access". > > >>>>>>> > > >>>>>>> Yes i can see the point. But after thinking about it, maybe it is > > >>>>>>> best > > >>>>>>> as it is? After all driver model is fundamental to U-Boot and it's > > >>>>>>> not > > >>>>>>> clear what else we might bind/unbind. > > >>>>>>> > > >>>>>>> I'd like to get other opinions here, too. > > >>>>>> > > >>>>>> Tom/Marek: Any opinion? > > >>>>> > > >>>>> I think dm bind/unbind makes sense, yes. "bind" and "unbind" are > > >>>>> pretty > > >>>>> generic terms and making it clear it's part of working "inside" of DM > > >>>>> to > > >>>>> hook/unhook things by making it a sub-command of dm sounds good. > > >>>>> Thanks! > > >>>> > > >>>> I agree with Simon here. I think bind and unbind won't have any > > >>>> plausible other meaning in U-Boot and DM is core to U-Boot > > >>>> functionality in the new world. I think it would be OK to have "dm > > >>>> bind" alias to "bind" if that's a point of confusion, but having it > > >>>> top-level seems good to me. > > >>> > > >>> They're still very generic words for something that's part of working > > >>> under the dm framework. That said, looking at test/dm/cmd_dm.c and that > > >>> it's supposed to be only for test/debug type work, yes, OK, I'll change > > >>> my mind. > > >> > > >> I would expect that almost everybody will enable CMD_DM where symbol is > > >> in cmd/Kconfig but implementation in test/dm/cmd_dm.c (it is a question > > >> if this is the right place for this file). > > > > > > It might well really belong as cmd/dm.c, but content wise it's debug > > > information that is also useful in the bind/unbind case (so you know > > > where U-Boot sees things as being at). > > > > Then we should really not enable it by default for all boards with DM on. > > > > 640 config CMD_DM > > 641 bool "dm - Access to driver model information" > > 642 depends on DM > > 643 default y > > Simon?
I'm OK with having it disabled by default - it is for debugging after all. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot