> Date: Tue, 26 Mar 2024 17:41:52 -0400
> From: Thor Lancelot Simon
>
> On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote:
> >
> > We should really expose a /dev/ugen* instance for _every_ USB device;
> > those that have kernel drivers attached have only limited access via
> >
> On Mar 26, 2024, at 2:41 PM, Thor Lancelot Simon wrote:
>
> I don't think this can be safely allowed at security level > 0, unless,
> perhaps, it's restricted from working on devices that would match disk
> drivers.
The driver being asked to detach could certainly refuse to do so based on
On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote:
>
> We should really expose a /dev/ugen* instance for _every_ USB device;
> those that have kernel drivers attached have only limited access via
> /dev/ugen* (no reads, writes, transfer ioctls, ), until you do
>
> On Mar 26, 2024, at 10:18 AM, Jason Thorpe wrote:
>
> Like I said in a previous message on this thread, I think the better model is
> for ugen to always exist for every USB device / interface, and for the kernel
> driver to attach there. Then it’s easy to just say “detach whatever kernel
> On Mar 26, 2024, at 9:31 AM, Brian Buhrow wrote:
>
> Isn't it possible to do most of what Jason proposes by using the drvctl
> interface to
> detach a driver from a specific USB device? Then, some glue could be added
> to the ugen driver
> to allow it to be attached to arbitrary devices
Brian Buhrow writes:
> Isn't it possible to do most of what Jason proposes by using the drvctl
> interface to
> detach a driver from a specific USB device? Then, some glue could be added
> to the ugen driver
> to allow it to be attached to arbitrary devices using the same drvctl
>
Jason Thorpe writes:
[snip]
>> What would be wrong with attaching an ugen to interface 1 instead of
>> an ucom in the ftdi driver itself?
>
> ugen can’t currently attach to things other than uhub. I think attaching
> ugen as the leaf is the wrong model, though; ugen should be what the kernel
Isn't it possible to do most of what Jason proposes by using the drvctl
interface to
detach a driver from a specific USB device? Then, some glue could be added to
the ugen driver
to allow it to be attached to arbitrary devices using the same drvctl
interface? That seems a
lot easier
> On Mar 26, 2024, at 5:37 AM, Robert Swindells wrote:
>
> I thought that all FTDI devices provided JTAG etc. functionality, just
> that the pins are not connected to anything in some devices.
I guess it depends on how your individual FTDI board is wired up. Also, for
chips without the
> On Mar 26, 2024, at 2:49 AM, Martin Husemann wrote:
> It is also not *that* intrusive as it may sound at first look:
> basically we need a central registry that collects all the
> identification data (vid,pid,strings and what have you) plus the parent
> and the device pointer, and a flag if
Robert Swindells writes:
> Jason Thorpe wrote:
>> I have a device based on the FTDI FT2232C:
>>
>> [ 3285.311079] uftdi1 at uhub1 port 2 configuration 1 interface 0
>> [ 3285.311079] uftdi1: SecuringHardware.com (0x0403) Tigard V1.1
>> (0x6010), rev 2.00/7.00, addr 3
>> [
Jason Thorpe wrote:
> I have a device based on the FTDI FT2232C:
>
> [ 3285.311079] uftdi1 at uhub1 port 2 configuration 1 interface 0
> [ 3285.311079] uftdi1: SecuringHardware.com (0x0403) Tigard V1.1
> (0x6010), rev 2.00/7.00, addr 3
> [ 3285.311079] ucom1 at uftdi1 portno 1
> [
Jason Thorpe writes:
> I have a device based on the FTDI FT2232C:
>
> [ 3285.311079] uftdi1 at uhub1 port 2 configuration 1 interface 0
> [ 3285.311079] uftdi1: SecuringHardware.com (0x0403) Tigard V1.1
> (0x6010), rev 2.00/7.00, addr 3
> [ 3285.311079] ucom1 at uftdi1 portno 1
> [
On Tue, Mar 26, 2024 at 09:09:57AM +0100, Manuel Bouyer wrote:
> On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote:
> > This is how it works in other systems like Linux with
> > USBDEVFS_CLAIMINTERFACE, and that's the model that libusb is built
> > around. It's a nontrivial change
On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote:
> > Date: Mon, 25 Mar 2024 19:47:31 -0400
> > From: Greg Troxel
> >
> > Jason Thorpe writes:
> >
> > > I should be able to do this with OpenOCD (pkgsrc/devel/openocd), but
> > > libfdti1 fails to find the device because libusb1
15 matches
Mail list logo