Date: Thu, 29 Oct 2020 12:31:50 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Dirk-Willem van Gulik <dirkx@webweaving.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: spigen under uftdi Message-ID: <20201029193150.GK31099@funkthat.com> In-Reply-To: <EC3BC708-2C2C-49A8-8602-DD8671DA9A91@webweaving.org> References: <EC3BC708-2C2C-49A8-8602-DD8671DA9A91@webweaving.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dirk-Willem van Gulik wrote this message on Wed, Oct 28, 2020 at 13:58 +0100:
> Various USB based FT2232H usb to rs232 (and cypress CY7C65211) have a variant mode where they support SPI (or I2C).
>
> I've got this working in a rudimentary way in the uftdi(4) driver.
>
> But I'd like to have this surface as a 'normal' spigen(4) device. So it works with anything that already works on that device*.
>
> However - spigen(4) seems very tied to the FDT tree.
>
> Is this a viable path ?
yes, this is possible, but it will require a bit of kernel coding...
You need to add code to uftdi, to say that it can attach as to a spibus
like one of the other spi drivers does, e.g. gpiospi...
As avg said, hints can/should be able to stand in for OFT, BUT, that would
only be needed for devices to attach to the spi bus, w/ USB, it should be
able to automatically attach a spibus instance to itself when needed...
> Or am I better off using the defintions of the ioctl(4) and simply have the uftdi create something like a /dev/uftdi-spi0.0 sort of device ?
The advantage of hooking up to the spibus is that other kernel drivers
that talk on the spi bus can use it, whereas this method, only userland
consumers would be able to use it...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201029193150.GK31099>