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