Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Tue, 25 Jul 2017 13:49:08 +0200
Johan Hovold jo...@kernel.org wrote:
>On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
>> On Mon, 10 Jul 2017 14:52:10 +0200
>> Johan Hovold jo...@kernel.org wrote:
>>
>> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
>> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
>> >> adapters. These allow communication with chip's control, transmit
>> >> and receive endpoints and will be used by various FT232H drivers.
>> >
>> >> +static const struct mfd_cell ftdi_cells[] = {
>> >> + { .name = "ftdi-cbus-gpio", },
>> >> + { .name = "ftdi-mpsse-i2c", },
>> >> + { .name = "ftdi-mpsse-spi", },
>> >> + { .name = "ftdi-fifo-fpp-mgr", },
>> >> +};
>> >
>> >Correct me if I'm wrong, but aren't these modes really mutually
>> >exclusive, possibly with exception of cbus-gpio (some pins are at least
>> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>> >here either.
>>
>> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
>> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
>> testing with MPSSE SPI master driver, but maybe it is a driver issue.
>
>Yes, that wasn't clear to me either from just looking at the data
>sheets. MPSSE seems to deal with its GPIOs differently.
yes, the GPIOs are at different pins in MPSSE mode and these pins are
controlled via writes/reads to/from bulk endpoint with MPSSE commands.
>> FT245 FIFO and CBUS GPIO can be switched by a control request, when
>> FIFO mode is configured in the EEPROM.
>
>Since the set_bitmode command is used to control the CBUS gpios, does
>that mean that they cannot be toggled independently while FIFO mode is
>in use (as the same command is used to set FIFO mode)?
yes.
Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Tue, 25 Jul 2017 13:52:35 +0200 Johan Hovold jo...@kernel.org wrote: >On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote: >> On Wed, 19 Jul 2017 10:59:34 +0200 >> Johan Hovold jo...@kernel.org wrote: > >> >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver >> >> seems too application specific for a generic chip like this. >> > >> >Of which this is one is one of the major. >> >> Thanks all for feedback. I'm still pondering how to interface the >> fpga manager driver to FTDI FIFO driver. >> >> >In short, your driver is much to application specific and is probably >> >something that needs to be implemented in userspace using libftdi. >> >> I have a requirement to use the fpga manager framework, therefore the >> kernel driver is needed. Our usage scenario is a multi stage fpga >> configuration process, the first stage is a pre-configuration via >> FTDI SPI/FIFO, all subsequent stages are also done by other fpga >> manager drivers. libftdi based driver already existed for hardware >> bring-up, now I need similar functionality as kernel fpga manager. > >How are you even accessing these fpga-managers from userspace? I thought >current interface was for in-kernel use only? We have different possibilities to access to these fpga-managers from userspace. On platforms with device-tree support there is a DT-Overlay configfs interface for inserting a blob with configuration data and fpga device description. After inserting the blob the fpga manager is invoked automatically. There are also fpga-mgr debugfs config interface patches in Altera linux-socfpga git tree for accessing from userspace. I used them for initial testing, but now I'm using additional kernel module with a single configuration interface for different managers. Thanks, Anatolij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote: > On Wed, 19 Jul 2017 10:59:34 +0200 > Johan Hovold jo...@kernel.org wrote: > >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver > >> seems too application specific for a generic chip like this. > > > >Of which this is one is one of the major. > > Thanks all for feedback. I'm still pondering how to interface the > fpga manager driver to FTDI FIFO driver. > > >In short, your driver is much to application specific and is probably > >something that needs to be implemented in userspace using libftdi. > > I have a requirement to use the fpga manager framework, therefore the > kernel driver is needed. Our usage scenario is a multi stage fpga > configuration process, the first stage is a pre-configuration via > FTDI SPI/FIFO, all subsequent stages are also done by other fpga > manager drivers. libftdi based driver already existed for hardware > bring-up, now I need similar functionality as kernel fpga manager. How are you even accessing these fpga-managers from userspace? I thought current interface was for in-kernel use only? Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
> On Mon, 10 Jul 2017 14:52:10 +0200
> Johan Hovold jo...@kernel.org wrote:
>
> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
> >> adapters. These allow communication with chip's control, transmit
> >> and receive endpoints and will be used by various FT232H drivers.
> >
> >> +static const struct mfd_cell ftdi_cells[] = {
> >> + { .name = "ftdi-cbus-gpio", },
> >> + { .name = "ftdi-mpsse-i2c", },
> >> + { .name = "ftdi-mpsse-spi", },
> >> + { .name = "ftdi-fifo-fpp-mgr", },
> >> +};
> >
> >Correct me if I'm wrong, but aren't these modes really mutually
> >exclusive, possibly with exception of cbus-gpio (some pins are at least
> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
> >here either.
>
> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
> testing with MPSSE SPI master driver, but maybe it is a driver issue.
Yes, that wasn't clear to me either from just looking at the data
sheets. MPSSE seems to deal with its GPIOs differently.
> FT245 FIFO and CBUS GPIO can be switched by a control request, when
> FIFO mode is configured in the EEPROM.
Since the set_bitmode command is used to control the CBUS gpios, does
that mean that they cannot be toggled independently while FIFO mode is
in use (as the same command is used to set FIFO mode)?
> >And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> >seems too application specific for a generic chip like this.
>
> Yes, I agree. I'm thinking of a rework to add a FIFO driver instead
> and use it in the fpp-mgr driver. Is that the right direction?
That sounds better, but I'm still not sure that we would be able to bind
it to devices with the default (generic) VID/PID.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, 19 Jul 2017 13:39:36 + David Laight david.lai...@aculab.com wrote: >From: Anatolij Gustschin >> Sent: 19 July 2017 14:30 >... >> >Stupid question, I know, but I cannot help thinking: If you have an >> >EEPROM then why the h... don't you use an application specific device >> >ID? >> >> It would make sense for adapter devices that you can buy and plug. >> In my particular case the configuration device with FTDI chips is >> internal part of embedded board, the configuration interface is >> never exposed to end users. I doesn't make sense to register an >> ID for such hardware. > >Sounds like you should absolutely be registering an ID so that >nothing can try to use it using the default one. The intended usage can already be enforced by rejecting not signed bootloader/kernel/firmware. Anatolij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
From: Anatolij Gustschin > Sent: 19 July 2017 14:30 ... > >Stupid question, I know, but I cannot help thinking: If you have an > >EEPROM then why the h... don't you use an application specific device > >ID? > > It would make sense for adapter devices that you can buy and plug. > In my particular case the configuration device with FTDI chips is > internal part of embedded board, the configuration interface is > never exposed to end users. I doesn't make sense to register an > ID for such hardware. Sounds like you should absolutely be registering an ID so that nothing can try to use it using the default one. David
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, 12 Jul 2017 11:11:46 +0200 Bjørn Mork bj...@mork.no wrote: >Johan Hovold writes: >> On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote: >> >>> For devices with connected EEPROM some modes (including UART) are >>> configurable in the EEPROM. For devices without EEPROM the default >>> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be >>> switched via commands to the the chip. >> >> IIRC we should be able read from the EEPROM, and I would at least expect >> there to be a way to retrieve the current mode as well. > >Stupid question, I know, but I cannot help thinking: If you have an >EEPROM then why the h... don't you use an application specific device >ID? It would make sense for adapter devices that you can buy and plug. In my particular case the configuration device with FTDI chips is internal part of embedded board, the configuration interface is never exposed to end users. I doesn't make sense to register an ID for such hardware. Thanks, Anatolij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, 19 Jul 2017 10:59:34 +0200
Johan Hovold jo...@kernel.org wrote:
...
>> > +static const struct mfd_cell ftdi_cells[] = {
>> > + { .name = "ftdi-cbus-gpio", },
>> > + { .name = "ftdi-mpsse-i2c", },
>> > + { .name = "ftdi-mpsse-spi", },
>> > + { .name = "ftdi-fifo-fpp-mgr", },
>> > +};
>>
>> Correct me if I'm wrong, but aren't these modes really mutually
>> exclusive, possibly with exception of cbus-gpio (some pins are at least
>> available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>> here either.
>
>You never replied to this, and I'm afraid there are more issue with this
>series.
Sorry, unfortunately I'm too busy with other stuff. Will try to find
time to rework.
>> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>> seems too application specific for a generic chip like this.
>
>Of which this is one is one of the major.
Thanks all for feedback. I'm still pondering how to interface the
fpga manager driver to FTDI FIFO driver.
>In short, your driver is much to application specific and is probably
>something that needs to be implemented in userspace using libftdi.
I have a requirement to use the fpga manager framework, therefore the
kernel driver is needed. Our usage scenario is a multi stage fpga
configuration process, the first stage is a pre-configuration via
FTDI SPI/FIFO, all subsequent stages are also done by other fpga
manager drivers. libftdi based driver already existed for hardware
bring-up, now I need similar functionality as kernel fpga manager.
>Speaking of libftdi, you seem to have copied or borrowed a lot of code
>and protocol from libftdi and this should have been mentioned in commit
>messages and file headers (not just in a comment to one specific
>function).
I'll mention this in next patch series.
>These chips can be used for a many different applications (also in FIFO
>mode) so you cannot tie a driver to it exposing just a specific
>interface for programming a certain class of FPGAs.
Agreed.
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Mon, 10 Jul 2017 14:52:10 +0200
Johan Hovold jo...@kernel.org wrote:
>On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
>> Add USB part with common functions for USB-GPIO/I2C/SPI master
>> adapters. These allow communication with chip's control, transmit
>> and receive endpoints and will be used by various FT232H drivers.
>
>> +static const struct mfd_cell ftdi_cells[] = {
>> +{ .name = "ftdi-cbus-gpio", },
>> +{ .name = "ftdi-mpsse-i2c", },
>> +{ .name = "ftdi-mpsse-spi", },
>> +{ .name = "ftdi-fifo-fpp-mgr", },
>> +};
>
>Correct me if I'm wrong, but aren't these modes really mutually
>exclusive, possibly with exception of cbus-gpio (some pins are at least
>available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>here either.
MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
testing with MPSSE SPI master driver, but maybe it is a driver issue.
FT245 FIFO and CBUS GPIO can be switched by a control request, when
FIFO mode is configured in the EEPROM.
>And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>seems too application specific for a generic chip like this.
Yes, I agree. I'm thinking of a rework to add a FIFO driver instead
and use it in the fpp-mgr driver. Is that the right direction?
Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Mon, Jul 10, 2017 at 02:52:10PM +0200, Johan Hovold wrote:
> On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> > Add USB part with common functions for USB-GPIO/I2C/SPI master
> > adapters. These allow communication with chip's control, transmit
> > and receive endpoints and will be used by various FT232H drivers.
>
> > +static const struct mfd_cell ftdi_cells[] = {
> > + { .name = "ftdi-cbus-gpio", },
> > + { .name = "ftdi-mpsse-i2c", },
> > + { .name = "ftdi-mpsse-spi", },
> > + { .name = "ftdi-fifo-fpp-mgr", },
> > +};
>
> Correct me if I'm wrong, but aren't these modes really mutually
> exclusive, possibly with exception of cbus-gpio (some pins are at least
> available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
> here either.
You never replied to this, and I'm afraid there are more issue with this
series.
> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> seems too application specific for a generic chip like this.
Of which this is one is one of the major.
In short, your driver is much to application specific and is probably
something that needs to be implemented in userspace using libftdi.
Speaking of libftdi, you seem to have copied or borrowed a lot of code
and protocol from libftdi and this should have been mentioned in commit
messages and file headers (not just in a comment to one specific
function).
These chips can be used for a many different applications (also in FIFO
mode) so you cannot tie a driver to it exposing just a specific
interface for programming a certain class of FPGAs.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Wed, 12 Jul 2017 10:50:03 +0200 Johan Hovold jo...@kernel.org wrote: ... >IIRC we should be able read from the EEPROM, and I would at least expect >there to be a way to retrieve the current mode as well. I've just send a patch for ftdi_sio. Thanks, Anatolij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
Johan Hovold writes: > On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote: > >> For devices with connected EEPROM some modes (including UART) are >> configurable in the EEPROM. For devices without EEPROM the default >> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be >> switched via commands to the the chip. > > IIRC we should be able read from the EEPROM, and I would at least expect > there to be a way to retrieve the current mode as well. Stupid question, I know, but I cannot help thinking: If you have an EEPROM then why the h... don't you use an application specific device ID? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
> On Mon, 10 Jul 2017 14:34:27 +0200
> Johan Hovold jo...@kernel.org wrote:
>
> >On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
> >> On Fri, 07 Jul 2017 09:48:48 +0200
> >> Bjørn Mork bj...@mork.no wrote:
> >>
> >> >[adding Johan on the CC list]
> >> >
> >> >Anatolij Gustschin writes:
> >> >
> >> >> +static struct usb_device_id ftdi_mfd_table[] = {
> >> >> + { USB_DEVICE(0x0403, 0x6014) },
> >> >> + {}
> >> >> +};
> >> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
> >> >
> >> >This device ID is currently handled by the ftdi_sio driver, so I believe
> >> >you at least have to explain how you intend these two drivers to
> >> >cooperate...
> >>
> >> these drivers cannot cooperate, the different ftdi function modes
> >> use same device pins as in UART mode. So, you either can use the
> >> device in UART interface mode or in some different mode. I do not
> >> load the ftdi_sio module or do unbind the USB device from the
> >> ftdio_sio driver and bind it to the mfd driver, e.g.:
> >>
> >> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
> >> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
> >
> >I'm afraid that's not good enough. If we're going to support a non-UART
> >mode through a separate driver, we need to have all drivers for these
> >devices be able to retrieve the current mode during probe and only bind
> >when the mode matches.
>
> Can we reliably retrieve the current mode?
You tell me. ;)
> For devices with connected EEPROM some modes (including UART) are
> configurable in the EEPROM. For devices without EEPROM the default
> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
> switched via commands to the the chip.
IIRC we should be able read from the EEPROM, and I would at least expect
there to be a way to retrieve the current mode as well.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Mon, 10 Jul 2017 14:34:27 +0200
Johan Hovold jo...@kernel.org wrote:
>On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
>> On Fri, 07 Jul 2017 09:48:48 +0200
>> Bjørn Mork bj...@mork.no wrote:
>>
>> >[adding Johan on the CC list]
>> >
>> >Anatolij Gustschin writes:
>> >
>> >> +static struct usb_device_id ftdi_mfd_table[] = {
>> >> + { USB_DEVICE(0x0403, 0x6014) },
>> >> + {}
>> >> +};
>> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
>> >
>> >This device ID is currently handled by the ftdi_sio driver, so I believe
>> >you at least have to explain how you intend these two drivers to
>> >cooperate...
>>
>> these drivers cannot cooperate, the different ftdi function modes
>> use same device pins as in UART mode. So, you either can use the
>> device in UART interface mode or in some different mode. I do not
>> load the ftdi_sio module or do unbind the USB device from the
>> ftdio_sio driver and bind it to the mfd driver, e.g.:
>>
>> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
>> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
>
>I'm afraid that's not good enough. If we're going to support a non-UART
>mode through a separate driver, we need to have all drivers for these
>devices be able to retrieve the current mode during probe and only bind
>when the mode matches.
Can we reliably retrieve the current mode? For devices with connected
EEPROM some modes (including UART) are configurable in the EEPROM. For
devices without EEPROM the default mode is always UART, but FIFO-,
Bitbang- and MPSSE-mode can be switched via commands to the the chip.
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> Add USB part with common functions for USB-GPIO/I2C/SPI master
> adapters. These allow communication with chip's control, transmit
> and receive endpoints and will be used by various FT232H drivers.
> +static const struct mfd_cell ftdi_cells[] = {
> + { .name = "ftdi-cbus-gpio", },
> + { .name = "ftdi-mpsse-i2c", },
> + { .name = "ftdi-mpsse-spi", },
> + { .name = "ftdi-fifo-fpp-mgr", },
> +};
Correct me if I'm wrong, but aren't these modes really mutually
exclusive, possibly with exception of cbus-gpio (some pins are at least
available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
here either.
And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
seems too application specific for a generic chip like this.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
> On Fri, 07 Jul 2017 09:48:48 +0200
> Bjørn Mork bj...@mork.no wrote:
>
> >[adding Johan on the CC list]
> >
> >Anatolij Gustschin writes:
> >
> >> +static struct usb_device_id ftdi_mfd_table[] = {
> >> + { USB_DEVICE(0x0403, 0x6014) },
> >> + {}
> >> +};
> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
> >
> >This device ID is currently handled by the ftdi_sio driver, so I believe
> >you at least have to explain how you intend these two drivers to
> >cooperate...
>
> these drivers cannot cooperate, the different ftdi function modes
> use same device pins as in UART mode. So, you either can use the
> device in UART interface mode or in some different mode. I do not
> load the ftdi_sio module or do unbind the USB device from the
> ftdio_sio driver and bind it to the mfd driver, e.g.:
>
> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
I'm afraid that's not good enough. If we're going to support a non-UART
mode through a separate driver, we need to have all drivers for these
devices be able to retrieve the current mode during probe and only bind
when the mode matches.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Fri, 07 Jul 2017 09:48:48 +0200
Bjørn Mork bj...@mork.no wrote:
>[adding Johan on the CC list]
>
>Anatolij Gustschin writes:
>
>> +static struct usb_device_id ftdi_mfd_table[] = {
>> +{ USB_DEVICE(0x0403, 0x6014) },
>> +{}
>> +};
>> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
>
>This device ID is currently handled by the ftdi_sio driver, so I believe
>you at least have to explain how you intend these two drivers to
>cooperate...
these drivers cannot cooperate, the different ftdi function modes
use same device pins as in UART mode. So, you either can use the
device in UART interface mode or in some different mode. I do not
load the ftdi_sio module or do unbind the USB device from the
ftdio_sio driver and bind it to the mfd driver, e.g.:
sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
[adding Johan on the CC list]
Anatolij Gustschin writes:
> +static struct usb_device_id ftdi_mfd_table[] = {
> + { USB_DEVICE(0x0403, 0x6014) },
> + {}
> +};
> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
This device ID is currently handled by the ftdi_sio driver, so I believe
you at least have to explain how you intend these two drivers to
cooperate...
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
