> > If I complete my tasks I've listed above, do you still
> > don't want to see this patch in the mainstream ftdi_sio driver?
>
> I'd like to see what the patch actually looks like, and the 64bit
> thunking layer, before making up my mind.
> (hint, you're wearing me down :)
:-)
I think I'll con
> > > That would be a good reason to check for valid data, right?
> >
> > A complete valid data check would be too much for kernel space,
> > but I could add a check if the CRC add the end of the eeprom is correct.
> > Would that be sufficient?
>
> For firmware download, yes, that should not be c
> > > You're letting any user do this ioctl. If that's ok, fine.
> > > You are also accepting data directly from the user, without validating
> > > the input at all. It looks like you can send a mis-formed data packet
> > > to the device by doing this. What happens to the device if you do that?
Greg,
> > > (but if you do, watch out for the security problems in your ioctl
> > > implementation, it didn't look secure at first glance...)
> >
> > Ooops :-) What's wrong with it?
>
> You're letting any user do this ioctl. If that's ok, fine.
> You are also accepting data directly from the us
> Looks like you already have a working patch that you could put on
> those 100+ machines today :)
As many other people wanted this feature (I can forward you the
mails), it would be far better, if it becomes part of the stock
kernel. I could even do the 64 bit thunking layer if you want...
> (bu
> > > I still do not want/understand the need to create new ioctls for this
> > > driver. If you rip that part out of the patch, I'd be glad to take the
> > > rest of it, and then we can work on the ioctl issue together.
> >
> > Why don't you want the ioctls? Is there another way to communicate
>
> I still do not want/understand the need to create new ioctls for this
> driver. If you rip that part out of the patch, I'd be glad to take the
> rest of it, and then we can work on the ioctl issue together.
Why don't you want the ioctls? Is there another way to communicate
with the driver for t
Greg,
> > > > This is a patch against the ftdi_sio 1.3.0 driver + interim patch.
> > > > The new driver should be out soon...
> > >
> > > Can you post it not compressed so we can read it?
> >
> > Sure. I compressed it to save bandwith...
>
> Hm, seems to have dropped all tabs, can you try sending
> Hm, seems to have dropped all tabs, can you try sending it again so that
> it could be applied properly?
Hmm, just save the compressed version to disk :-)
> One small comment on the code:
> > +typedef struct {
> > + unsigned char enable;
> > + unsigned char bitmask; /* description of bitmask: s
> On Fri, Feb 21, 2003 at 10:04:14PM +0100, Thomas Jarosch wrote:
> > This is a patch against the ftdi_sio 1.3.0 driver + interim patch.
> > The new driver should be out soon...
>
> Can you post it not compressed so we can read it?
Sure. I compressed it to save bandwith...
> > Ahh, now I see :-) Thanks.
> > I didn't know about those special thunking handlers
> > needed for 64 bit systems.
> >
> > Is it sufficient to list the new ioctls
> > in the ioctl32_handler_table/ioctl_translations table?
>
> Depending on the data provided, you might have to write a function too
> > But why is it working anyway even though I haven't modified
> > any arch//kernel/ioctl32.c handler,
> > just the ftdi_sio ioctl() handler?
>
> Are you using a ppc64 or sparc64 or ia64 or x86-64 machine with a 64 bit
> kernel? If not, then yes, it works just fine on 32 bit kernels.
Ahh,
> > > No, those macros don't do it. If you have a strong stomach, look at:
> > > arch/sparc64/kernel/ioctl32.c
> > > for just one of the arch specific files that you will have to modify.
> > > Make sure you get them all, or you will have some angry maintainers to
> > > deal with...
> >
> > But th
> > > > I found Documentation/ioctl-numbers.txt for new-style ioctls.
> > > > Currently I'm using 'N' with a range of 20 to 3F.
> > > > Before a final release, I'll check if they're still unused.
> > >
> > > Heh, good luck, I don't think I'll take a patch adding new ioctls
> > > without a _very_ g
Greg,
> > So in short, fix the application and then see if you are still having
> > messed up data.
>
> ...
>
> But I'll add explicit initialization code
> now and post the results soon.
Yes, it works now!
I had to add the initialization code + use the newest
soon-to-be-released ftdi_sio beta dr
> > Attached you'll find the source of my test application.
>
> This is a tty port, so you can't just open it and start writing data to
> it and expect everything to be ok. You need to make sure the line
> settings are set up properly first. Take a look at one of the many
> serial port programmin
> > > Seriously, something is wrong in the locking code, unfortunatly it does
> > > work just fine for me, and a lot of other people. But not for
> > > others...
> >
> > Maybe you could add some debug output and I can send
> > you the results using my machine?
>
> Try loading the usbserial core an
> > I found Documentation/ioctl-numbers.txt for new-style ioctls.
> > Currently I'm using 'N' with a range of 20 to 3F.
> > Before a final release, I'll check if they're still unused.
>
> Heh, good luck, I don't think I'll take a patch adding new ioctls
> without a _very_ good reason.
What about
> > > ftdi_sio.c: write request of 0 bytes
> >
> > Like I posted yesterday on the list, something in the usbserial layer
> > or some other upstream layer seems screwed up.
>
> Works for me :)
>
> Seriously, something is wrong in the locking code, unfortunatly it does
> work just fine for me, and
> > Okay, I've collected more information:
> > I commented out the ftdi_write/ftdi_read function pointers in ftdi_sio.c,
> > so that the generic handler of usbserial handles the write calls.
> >
> > Attached you'll find the debug log of usbserial showing the same behavior.
> > Looks like the probl
> And again a similar oops as the last one. And perhaps another hint which
> may help you: I got several of the following line while sending to
> ttyUSB0:
>
> ftdi_sio.c: write request of 0 bytes
Like I posted yesterday on the list, something in the usbserial layer
or some other upstream layer see
> Could it even be a problem with the usbserial layer?
> Any help is really appreciated as I'm not familiar
> with the USB part of the kernel!
Okay, I've collected more information:
I commented out the ftdi_write/ftdi_read function pointers in ftdi_sio.c,
so that the generic handler of usbserial h
Hi!
I'm currently tracking down a bug in the ftdi_sio driver.
It seems to lose/falsify data under certain circumstances,
several people have experienced it.
The driver version is 1.2.1 (latest) using kernel 2.4.20.
In my setup, a FT245BM chip is used to talk to a VFD display.
I've wrote a small p
> I've tried to document the "common" ones in a linux journal article a
> few months ago. But for the others, you'll just have to dig through the
> code, both kernel, and userspace programs.
I found Documentation/ioctl-numbers.txt for new-style ioctls.
Currently I'm using 'N' with a range of 20 t
> My problem is: What do all these short names mean?
> Is there somewhere a table describing their function?
> And how do I know which ioctl could be already
> in use by a higher layer of the usb system?
>
> I was just curious if there's some kind of custom_ioctl_base ;-)
Ok, seems like none of t
> > I want to implement a special ioctl (enable "bit bang" mode)
> > for the ftdi_sio usb-serial driver.
>
> Are you sure there's nothing in the 60+ different tty ioctls in the
> kernel that would work for you?
My problem is: What do all these short names mean?
Is there somewhere a table describ
Hi!
I want to implement a special ioctl (enable "bit bang" mode)
for the ftdi_sio usb-serial driver.
My question: What value (name) should I use for the ioctl?
Is there a TIOCCUSTOM_BASE value where I just can add +1/+2/+3?
I've looked at include/asm-i386/ioctls.h but I couldn't
spot anything re
> we are about to switch from CYPRESS to philips... would appreciate
> any input (dos and don'ts or pitfalls) about philips chip
I didn't spend much time with the Philips chip as I didn't
like the parallel interface data handling.
We've switched to FTDI's FT245BM (http://www.ftdichip.com)
as you c
> It's a long time ago that I made the initial implementation for the MCT
> U232 device. And just now I realized that Julian Highfield has pointed
> out that there is a Philips PDIUSBD12 USB chip inside. Well, as I never
> really cared about the USB transfer, I can not really help. But very
> likel
29 matches
Mail list logo
