From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 11 Jul 2018 09:40:07 -0400 Subject: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line In-Reply-To: References: <1529670334-21974-8-git-send-email-jjhiblot@ti.com> <242671f8-f197-7b51-a419-be4e6f36b66f@xilinx.com> <20180709144342.GN27264@bill-the-cat> <20180710164001.GH27264@bill-the-cat> <20180711124604.GG27264@bill-the-cat> Message-ID: <20180711134007.GJ27264@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 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 at 48380000/usb at 48390000 usb_ether > >>>>>>>>> unbind /ocp/omap_dwc3 at 48380000/usb at 48390000 > >>>>>>>>> > >>>>>>>>> Signed-off-by: Jean-Jacques Hiblot > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>> > >>>>>>> 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 > >>>>>>>> > >>>>>>>> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: