Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
On 17.7.2018 05:44, Simon Glass wrote: > Hi Michal, > > On 16 July 2018 at 02:33, Michal Simek wrote: >> On 11.7.2018 22:13, Simon Glass wrote: >>> Hi, >>> >>> On 11 July 2018 at 07:40, Tom Rini 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 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@4838/usb@4839 usb_ether >> unbind /ocp/omap_dwc3@4838/usb@4839 >> >> 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
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
Hi Michal, On 16 July 2018 at 02:33, Michal Simek wrote: > On 11.7.2018 22:13, Simon Glass wrote: >> Hi, >> >> On 11 July 2018 at 07:40, Tom Rini 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 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@4838/usb@4839 usb_ether > unbind /ocp/omap_dwc3@4838/usb@4839 > > 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). >
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
On 11.7.2018 22:13, Simon Glass wrote: > Hi, > > On 11 July 2018 at 07:40, Tom Rini 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 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@4838/usb@4839 usb_ether unbind /ocp/omap_dwc3@4838/usb@4839 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). >>> >>>
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
Hi,
On Fri, Jun 22, 2018 at 02:25:34PM +0200, Jean-Jacques Hiblot wrote:
> +static int do_bind_unbind(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + int ret;
> + bool bind;
> + bool by_node;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + bind = (argv[0][0] == 'b');
> + by_node = (argv[1][0] == '/');
> +
> + if (by_node && bind) {
> + if (argc != 3)
> + return CMD_RET_USAGE;
> + ret = bind_by_node_path(argv[1], argv[2]);
> + } else if (by_node && !bind) {
> + if (argc != 2)
> + return CMD_RET_USAGE;
> + ret = unbind_by_node_path(argv[1]);
> + } else if (!by_node && bind) {
> + int index = (argc > 2) ? simple_strtoul(argv[2], NULL, 10) : 0;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> + ret = bind_by_class_index(argv[1], index, argv[3]);
> + } else if (!by_node && !bind) {
> + int index = (argc > 2) ? simple_strtoul(argv[2], NULL, 10) : 0;
> +
> + if (argc == 3)
> + ret = unbind_by_class_index(argv[1], index);
> + else if (argc == 4)
> + ret = unbind_child_by_class_index(argv[1], index,
> + argv[3]);
> + else
> + return CMD_RET_USAGE;
> + }
> +
> + if (ret)
FWIW, gcc 7.3.0 complains at this line:
cmd/bind.c: In function ‘do_bind_unbind’:
cmd/bind.c:236:5: warning: ‘ret’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (ret)
^
> + return CMD_RET_FAILURE;
> + else
> + return CMD_RET_SUCCESS;
> +}
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
Hi, On 11 July 2018 at 07:40, Tom Rini 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 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@4838/usb@4839 usb_ether > > > unbind /ocp/omap_dwc3@4838/usb@4839 > > > > > > 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
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
On Fri, Jun 22, 2018 at 5:55 PM, 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 Apart from having separate dm command, can't we add this as a part of 'usb reset' I'm thinking usb reset can show the all possible controllers shutdown and probe it again so-that gadget can show it like others. This is what I tried [1] [1] https://patchwork.ozlabs.org/patch/941597/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether > > unbind /ocp/omap_dwc3@4838/usb@4839 > > > > 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 signature.asc Description: PGP
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether > unbind /ocp/omap_dwc3@4838/usb@4839 > > 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 Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether > >>> unbind /ocp/omap_dwc3@4838/usb@4839 > >>> > >>> 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 signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether >>> unbind /ocp/omap_dwc3@4838/usb@4839 >>> >>> 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). When solution with bind and unbind is designed because it is giving you clear picture what has been binded and probed. You can find paths from DT but it is not giving you run time information. At least for xilinx platforms when this functionality is added (which is great) I am going to make sure that CMD_DM is also enabled because that's the way how to check status at run time. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether > >> >>> unbind /ocp/omap_dwc3@4838/usb@4839 > >> >>> > >> >>> 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether >> >>> unbind /ocp/omap_dwc3@4838/usb@4839 >> >>> >> >>> 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. -Joe > -- > Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether > >>> unbind /ocp/omap_dwc3@4838/usb@4839 > >>> > >>> 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! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether >>> unbind /ocp/omap_dwc3@4838/usb@4839 >>> >>> 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? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether >> unbind /ocp/omap_dwc3@4838/usb@4839 >> >> 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether
> unbind /ocp/omap_dwc3@4838/usb@4839
>
> 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
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 5752bf5..8c789b3 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -58,6 +58,17 @@
> reg = <2 1>;
> };
>
> + bind-test {
> + bind-test-child1 {
> + compatible = "sandbox,phy";
> + #phy-cells = <1>;
> + };
> +
> + bind-test-child2 {
> + compatible = "simple-bus";
> + };
> + };
> +
> b-test {
> reg = <3 1>;
> compatible = "denx,u-boot-fdt-test";
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 1eb55e5..d6bbfba 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -607,6 +607,15 @@ config CMD_ADC
> Shows ADC device info and permit printing one-shot analog converted
> data from a named Analog to Digital Converter.
>
> +config CMD_BIND
> + bool "bind/unbind - Bind or unbind a device to/from a driver"
> + depends on DM
> + help
> + Bind or unbind a device to/from a driver from the command line.
> + This is useful in situations where a device may be handled by several
> + drivers. For example, this can be used to bind a UDC to the usb ether
> + gadget driver from the command line.
> +
> config CMD_CLK
> bool "clk - Show clock frequencies"
> help
> diff --git a/cmd/Makefile b/cmd/Makefile
> index e0088df..b12aca3 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_SOURCE) += source.o
> obj-$(CONFIG_CMD_SOURCE) += source.o
> obj-$(CONFIG_CMD_BDI) += bdinfo.o
> obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
> +obj-$(CONFIG_CMD_BIND) += bind.o
> obj-$(CONFIG_CMD_BINOP) += binop.o
> obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
> obj-$(CONFIG_CMD_BMP) += bmp.o
> diff --git a/cmd/bind.c b/cmd/bind.c
> new file mode 100644
> index 000..a213d26
> --- /dev/null
> +++ b/cmd/bind.c
> @@ -0,0 +1,255 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 JJ Hiblot
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int bind_by_class_index(const char *uclass, int index,
> +const char *drv_name)
> +{
> + static enum uclass_id uclass_id;
> + struct udevice *dev;
> + struct udevice *parent;
> + int ret;
> + struct driver *drv;
> +
> + drv = lists_driver_lookup_name(drv_name);
> + if (!drv) {
> + printf("Cannot find driver '%s'\n", drv_name);
> + return -ENOENT;
> + }
> +
> + uclass_id = uclass_get_by_name(uclass);
> + if (uclass_id == UCLASS_INVALID) {
> + printf("%s is not a valid uclass\n", uclass);
> + return -EINVAL;
> + }
> +
> + ret = uclass_find_device(uclass_id, index, );
> + if (!parent || ret) {
> + printf("Cannot find device %d of class %s\n", index, uclass);
> + return ret;
> + }
> +
> + ret = device_bind_with_driver_data(parent, drv, drv->name, 0,
> +ofnode_null(), );
> + if (!dev || ret) {
> + printf("Unable to bind. err:%d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int find_dev(const char *uclass, int index, struct udevice **devp)
> +{
> + static enum uclass_id uclass_id;
> + int rc;
> +
> + uclass_id = uclass_get_by_name(uclass);
> +
[U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
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@4838/usb@4839 usb_ether
unbind /ocp/omap_dwc3@4838/usb@4839
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
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5752bf5..8c789b3 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -58,6 +58,17 @@
reg = <2 1>;
};
+ bind-test {
+ bind-test-child1 {
+ compatible = "sandbox,phy";
+ #phy-cells = <1>;
+ };
+
+ bind-test-child2 {
+ compatible = "simple-bus";
+ };
+ };
+
b-test {
reg = <3 1>;
compatible = "denx,u-boot-fdt-test";
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1eb55e5..d6bbfba 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -607,6 +607,15 @@ config CMD_ADC
Shows ADC device info and permit printing one-shot analog converted
data from a named Analog to Digital Converter.
+config CMD_BIND
+ bool "bind/unbind - Bind or unbind a device to/from a driver"
+ depends on DM
+ help
+ Bind or unbind a device to/from a driver from the command line.
+ This is useful in situations where a device may be handled by several
+ drivers. For example, this can be used to bind a UDC to the usb ether
+ gadget driver from the command line.
+
config CMD_CLK
bool "clk - Show clock frequencies"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index e0088df..b12aca3 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SOURCE) += source.o
obj-$(CONFIG_CMD_SOURCE) += source.o
obj-$(CONFIG_CMD_BDI) += bdinfo.o
obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
+obj-$(CONFIG_CMD_BIND) += bind.o
obj-$(CONFIG_CMD_BINOP) += binop.o
obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
obj-$(CONFIG_CMD_BMP) += bmp.o
diff --git a/cmd/bind.c b/cmd/bind.c
new file mode 100644
index 000..a213d26
--- /dev/null
+++ b/cmd/bind.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 JJ Hiblot
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static int bind_by_class_index(const char *uclass, int index,
+ const char *drv_name)
+{
+ static enum uclass_id uclass_id;
+ struct udevice *dev;
+ struct udevice *parent;
+ int ret;
+ struct driver *drv;
+
+ drv = lists_driver_lookup_name(drv_name);
+ if (!drv) {
+ printf("Cannot find driver '%s'\n", drv_name);
+ return -ENOENT;
+ }
+
+ uclass_id = uclass_get_by_name(uclass);
+ if (uclass_id == UCLASS_INVALID) {
+ printf("%s is not a valid uclass\n", uclass);
+ return -EINVAL;
+ }
+
+ ret = uclass_find_device(uclass_id, index, );
+ if (!parent || ret) {
+ printf("Cannot find device %d of class %s\n", index, uclass);
+ return ret;
+ }
+
+ ret = device_bind_with_driver_data(parent, drv, drv->name, 0,
+ ofnode_null(), );
+ if (!dev || ret) {
+ printf("Unable to bind. err:%d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int find_dev(const char *uclass, int index, struct udevice **devp)
+{
+ static enum uclass_id uclass_id;
+ int rc;
+
+ uclass_id = uclass_get_by_name(uclass);
+ if (uclass_id == UCLASS_INVALID) {
+ printf("%s is not a valid uclass\n", uclass);
+ return -EINVAL;
+ }
+
+ rc = uclass_find_device(uclass_id, index, devp);
+ if (!*devp || rc) {
+
