Re: [linux-usb-devel] [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/15/06, Oliver Neukum <oliver@neukum.name> wrote:
Am Freitag, 15. Dezember 2006 10:30 schrieb Oleg Verych:
> On 12/14/06, Greg KH <greg@kroah.com> wrote:
> > On Thu, Dec 14, 2006 at 11:10:46PM +0200, Oleg Verych wrote:
> > > Hallo. Due to very big distance to my usual work stand, please accept this.
> >
> > Hm, I don't think this driver is "orphaned". Please work with Al to get
> > this accepted through him, I'll have to wait for his ACK on it.
> >
> After my ID patch, i don't think so. After not having sem->mutex, i
> don't think so.
> After some other issues, i don't think so. Maybe that just was summer.
>
> Mister Al, please review my patch (here
> <http://article.gmane.org/gmane.linux.usb.devel/49174>).
> All comments are welcome. I hope this will be nice little good for Debian...
It also creates an incompatibility between kernel versions and needs
I would like to know how it creates that. I wanted to make as little
changes as possible.
the firmware distributed separately. Have you made patches to the
Debian developer's question? Heh ;)
Every such (complex or simple interface) device _have_ drivers for
Offtopic System.
Firmware files(1) are there under filenames i used in the patch.
And btw, how many bug reports for ti_usb driver are there in the BTS?
<http://merkel.debian.org/~don/cgi/search.cgi?phrase=ti_usb_3410_5052&search=search&skip=0&order_field=&order_operator=STRA&max_results=10>
Only users i know, are in mspgcc mailing list. And i know what it took
developers of GCC
for msp430 to configure _this_ driver (don't check summer archives,
it was very hard, and
nobody sent a patch to buggy parameter parsing, udev, etc...) This
list of beautiful users
is added..
relevant packages and waited for them to be included into actual releases?
Well, do you mean udev? AFAIK Debian has no support for this udriver.
Symlinks of (1) to /lib/firmware/ _is_ enough. And after reading
dmesg (without stupid I/O error messages from old driver), user knows
that actual working
configuration is "the second" one, and anyone now can add
`echo 2 >/big/deep/ass/../bConfigValue`.
In case if somebody will use udev (ez430 id patch included):
,--[/etc/udev/rules.d/077-ez430.udev.rules]--
|SUBSYSTEM=="usb_device" ACTION=="add" \
|SYSFS{idVendor}=="0451" SYSFS{idProduct}=="f430" \
|SYSFS{bNumConfigurations}=="2" SYSFS{bConfigurationValue}=="1" \
|RUN+="/bin/sh -c 'echo 2 >/sys/%p/device/bConfigurationValue'"
`----
I don't use it (well, trying to do so).
Mister Greg, how to change configuration _inside_ the driver? Device
was made to be
working on second usb config after one reconnect/device change, i've
lost whole day
trying to make something with that. After all, usb_set_configuration()
isn't even
EXPORT()ED at all !
Are you handling the mails that report a device no longer working?
Yes, if i would on my working stand. Ideas were right after summer
events in mspgcc list,
but i decided to start kernel development first and stuck with kbuild
fixes, lost much time.
Now i'm long away due to loss of my close man. Nearly month ago, before package
freezing, i've made much of this, but now i'm on very short internet
and work access.
How much memory does the patch save?
Static memory ~28k. And hey, this is firmware, by the way (and i don't
suggest you to
look on sources of it, very ugly in short, but working anyways ;).
From stack usage point
of view, ti_download_firmware() was cut on some pointers and variables, but
request_firmware() was added, so i don't know exactly.
request_firmware() is allocating
buffer in virtual memory (usb download needs kmalloced one, ugly
solution for firmwares
usually 2-4 4k pages thick), another problem.
Making Debian happy is not very high on the list of goals.
Yes, thanks for the hint. I'm having enough after documentation removing...
Regards
Oliver
Sorry for long mail, cc list and little benefit, if any.
--
-o--=O`C
#oo'L O
<___=E M
Reply to: