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? -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
