From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 11 Jul 2018 08:46:04 -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-1-git-send-email-jjhiblot@ti.com> <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> Message-ID: <20180711124604.GG27264@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 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). -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: