Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1691675 > unrolled thread

Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

Started byAnatolij Gustschin <agust@denx.de>
First post2017-07-19 15:30 +0200
Last post2017-07-19 17:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices Anatolij Gustschin <agust@denx.de> - 2017-07-19 15:30 +0200
    RE: [PATCH 1/3] mfd: Add support for FTDI FT232H devices David Laight <David.Laight@ACULAB.COM> - 2017-07-19 15:40 +0200
      Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices Anatolij Gustschin <agust@denx.de> - 2017-07-19 17:10 +0200

#1691675 — Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

FromAnatolij Gustschin <agust@denx.de>
Date2017-07-19 15:30 +0200
SubjectRe: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
Message-ID<u4Xd8-Hy-3@gated-at.bofh.it>
On Wed, 12 Jul 2017 11:11:46 +0200
Bjørn Mork bjorn@mork.no wrote:

>Johan Hovold <johan@kernel.org> 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

[toc] | [next] | [standalone]


#1691682

FromDavid Laight <David.Laight@ACULAB.COM>
Date2017-07-19 15:40 +0200
Message-ID<u4XmO-Lg-35@gated-at.bofh.it>
In reply to#1691675
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

[toc] | [prev] | [next] | [standalone]


#1691829

FromAnatolij Gustschin <agust@denx.de>
Date2017-07-19 17:10 +0200
Message-ID<u4YLV-1Q5-31@gated-at.bofh.it>
In reply to#1691682
On Wed, 19 Jul 2017 13:39:36 +0000
David Laight David.Laight@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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web