On Wed, 2007-06-27 at 00:35 -0700, Andrew Morton wrote:
> make[2]: *** No rule to make target
> `/usr/src/devel/include/linux/usb_gadgetfs.h', needed by
> `/usr/src/devel/usr/include/linux/usb_gadgetfs.h'. Stop.
i.e. "Cannot export file to ./usr/include/linux/ because it doesn't
exist in ./inclu
On Thu, 2007-05-24 at 12:50 -0700, Linus Torvalds wrote:
> There's a huge difference between "You killed my father, prepare to
> die", and "Btw, I didn't like that, but I'll just continue".
There are three cases, not two:
1. Something slightly suboptimal happened. We didn't like it.
2. Something
t;
> commit 914e26379decf1fd984b22e51fd2e4209b7a7f1b
> Handled-By : David Woodhouse <[EMAIL PROTECTED]>
> Status : patch available
Linus, please pull from git://git.infradead.org/mtd-2.6.git
This fixes the above bug along with a few others. It does also contain a
small amount of new code which
On Mon, 2006-06-05 at 09:14 -0300, Luiz Fernando N. Capitulino wrote:
> I was going to try it last night and realized that my cell phone
> can't answer data calls. :((
Often you have to contact your provider and ask them to give you a 'data
number', then you can answer calls to _that_ number.
U
On Fri, 2006-06-02 at 10:45 -0300, Luiz Fernando N. Capitulino wrote:
> Unfortunally my cables only connects devices to the computers
> (ie, I can't connect two computers).
>
> Don't know if exists a Prolific USB <-> DB9, but if it does, would
> be good if someone could make the test. Seems easy
On Thu, 2006-06-01 at 23:48 -0700, Pete Zaitcev wrote:
>
> > The tests I've done so far weren't anything serious: as the mobile
> > supports a
> > AT command set, I have used the ones (with minicom) which transfers more
> > data.
> > Of course that I also did module load/unload tests, tried to
On Wed, 2006-01-04 at 14:27 -0800, Greg KH wrote:
> +static ssize_t usblp_show_ieee1284_id(struct device *dev, struct
> device_attribute *attr, char *buf)
> +{
> + struct usb_interface *intf = to_usb_interface(dev);
> + struct usblp *usblp = usb_get_intfdata (intf);
> +
> + if (u
On Wed, 2005-11-02 at 08:42 +0100, Duncan Sands wrote:
> we could do this for the speedtouch - in fact we used to do this: when
> someone tried to open a connection, we loaded the firmware if it
> hadn't been loaded yet. The problem is with other modems, like the
> connexant access runner, for whi
On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> this code looks like a 'orrible hack to work around a common problem
> with USB modem's of this type: if the modem is plugged in while the
> system boots, the driver may look for firmware before the filesystem
> holding the firmware is mounte
On Thu, 2005-03-31 at 12:00 +0400, Roman Kagan wrote:
> Then, if you forget to turn FW_LOADER on, USBATM won't even be offered
> to you by make config.
>
> Besides, the rest of the kernel uses "select" for FW_LOADER, as well
> as for other library stuff like CRC32.
Those can be considered a speci
On Thu, 2005-03-31 at 09:50 +0200, Duncan Sands wrote:
> I'd rather have "select". I'm considering having it select ATM as well...
> I think select is more logical: if someone has this modem, it's natural
> that they simply choose to build the driver, and that dependencies are
> automatically take
On Wed, 2005-01-19 at 14:07 -0800, Greg KH wrote:
> I have been running with just the code portion of this patch for a while
> now, with good results (no Kconfig changes.)
>
> Pete and Matt, do you mind me applying the following portion of the
> patch to the kernel tree?
>
> > -#if !defined(CONFI
On Fri, 2004-10-01 at 16:34 +0200, Duncan Sands wrote:
> On Thursday 30 September 2004 23:40, David Woodhouse wrote:
> > On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> > > I will check it all out tonight.
> >
> > Any comments?
>
> Here is an in
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> I will check it all out tonight.
Any comments?
--
dwmw2
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> this races with modem_run: since the firmware loading is done in a separate
> kernel thread, it is possible to do:
>
> (1) probe completes
> (2) hotplug call - modem_run tries to grab the interface and fails
> (3) firmware loading code fails
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> Hi David,
>
> > OK... if the firmware is found in /lib/firmware this loads it, then
> > starts up the modem and monitors the status. If the firmware _isn't_
> > found it waits for modem_run as before.
>
> this races with modem_run: since t
On Wed, 2004-09-29 at 08:50 +0200, Duncan Sands wrote:
> > I'll fix your version, and merge in the missing parts from mine.
>
> Great, thanks. I will try to do some polishing/testing/thinking
> tonight.
OK... if the firmware is found in /lib/firmware this loads it, then
starts up the modem and m
I found the problem. The buffer returned by request_firmware() is in
vmalloc space; we can't DMA from that.
By copying into a kmalloc'd buffer we can make it work.
I'll fix your version, and merge in the missing parts from mine.
--
dwmw2
--
On Tue, 2004-09-28 at 20:48 +0200, Duncan Sands wrote:
> > > By the way, the symptoms you have are those you get if the firmware is
> > > already loaded. Are you sure it wasn't loaded previously by modem_run?
> >
> > Very sure.
>
> I had to ask :)
Fair enough :)
I'm half inclined to blame my
On Tue, 2004-09-28 at 19:11 +0200, Duncan Sands wrote:
> > I'm beginning to wonder if it's purely timing-related. But it doesn't
> > matter how long I leave it between connecting the modem and running the
> > userspace program -- and it doesn't work if I connect the modem then
> > wait a while befo
On Tue, 2004-09-28 at 19:05 +0200, Duncan Sands wrote:
> > It appears to confirm my belief that the userspace program is doing
> > _precisely_ what both Duncan's and my kernel versions do nothing but
> > the bulk transfer. I've already triple-checked the endpoints and the
> > data. We show a CR
On Tue, 2004-09-28 at 11:29 -0400, Alan Stern wrote:
> On Tue, 28 Sep 2004, David Woodhouse wrote:
>
> > I don't understand why modem_run works but two entirely separate
> > reimplementations of exactly the same thing in the kernel don't work.
> > What are we doi
On Tue, 2004-09-28 at 10:53 +0200, Duncan Sands wrote:
> > The userspace monitoring dÃmon uses an ioctl to tell the kernel when the
> > link goes up or down. The driver then sets atm_dev->signal to
> > ATM_PHY_SIG_{FOUND,LOST} which prevents pppd from attempting to dial up
> > while there's no link
On Tue, 2004-09-28 at 09:42 +0200, Duncan Sands wrote:
> > Now, should I forget this and wait for your version? Could I have a
> > copy of what you did, and work from that instead? Did it at least manage
> > to get as far as loading the firmware of the poxy thing? :)
>
> Hi David, here's a dump o
On Tue, 2004-09-28 at 09:56 +0200, Duncan Sands wrote:
> However line monitoring is entirely informative: it's not like the driver needs
> to do anything different if the line goes down.
The userspace monitoring dÃmon uses an ioctl to tell the kernel when the
link goes up or down. The driver then
On Tue, 2004-09-28 at 09:31 +0200, Duncan Sands wrote:
> I've been wondering the same thing. Maybe it a possible to do a "light"
> reset of the modem that doesn't disconnect us, but does stick it in a
> receptive state...
I suppose once the firmware loading is working reliably it should
suffice j
On Tue, 2004-09-28 at 08:58 +0200, Duncan Sands wrote:
> I did a version myself six months ago, but I never got round to polishing and
> sending it... So thanks for doing this - at least it will push me to finish
> my version!
:)
> I notice that you are uploading the firmware on interface 2 from
On Tue, 2004-09-28 at 08:44 +0200, Duncan Sands wrote:
> Hi Phil, the main difficulty with the kernel driver is getting a pppoa
> aware pppd. Also, the website is out of date. However once it is set
> up it does have some advantages - lower latency and lower overhead (only
> important for old mac
On Mon, 2004-09-27 at 22:53 -0700, Phil Dibowitz wrote:
> David Woodhouse wrote:
> > The speedtch driver offended me by needing a userspace tool 'modem_run'
> > to load its firmware and -- worse -- to monitor the line state as a
> > dÃmon too.
> >
The speedtch driver offended me by needing a userspace tool 'modem_run'
to load its firmware and -- worse -- to monitor the line state as a
dÃmon too.
So I tried to convert it to use request_firmware() and monitor the line
for itself. The results are below -- but it doesn't actually work.
Sending
On Fri, 2004-08-27 at 09:26 -0700, Greg KH wrote:
> Q: But you took away my freedom! Isn't Linux about freedom?
The GPL provides is a very _specific_ kind of freedom. It has its own
restrictions -- in many ways it's less free than if we were to just
release our code to the public domain, or under
On Sat, 2004-06-26 at 15:02 +0100, Alan Cox wrote:
> There are a lot of drivers that assume 0 means no IRQ, including some
> big x86 non-PC systems. Remember however that dev->irq is an OS private
> cookie. In the x86 case for example we add 16 to APIC directed
> interrupts both to split IRQs out a
On Fri, 2004-03-05 at 18:11 +, Paulo Marques wrote:
> Anyway, this time I tested it using blocking and non-blocking I/O and it works
> for both cases. Even better, this patch only changes the behaviour for
> non-blocking I/O, and keeps the same behaviour for the more usual blocking I/O
> (at
On Sat, 2004-03-27 at 18:47 -0800, don wrote:
> These are applications, not file system interfaces like USB Mass Storage.
> I want to mount the camera or gadget file system and access it from any
> program, not run a separate app to fetch files like Mass Stor. mounts
> a memory device.
>
> Why cre
On Thu, 2004-03-25 at 14:52 -0800, David Brownell wrote:
> (Although I personally would prefer that Microsoft adopt vendor-neutral
> protocols, instead of pushing the rest of the industry to adopt things
> that are MSFT-biased ... for some reason, they haven't listened to almost
> anyone on such to
On Thu, 2004-03-04 at 12:33 +, Paulo Marques wrote:
> Yes, unfortunately it did went into 2.6.4-rc1. However it is already corrected
> in 2.6.4-rc2. Luckily it didn't went into any "non-rc" official release.
>
> Please try 2.6.4-rc2, and check to see if the bug went away...
Seems to work; th
On Mon, 2004-02-16 at 15:16 +, Paulo Marques wrote:
> This patch corrected a problem for me, that happened when a printer presents an
> out-of-paper status while printing a document. The driver would send endless
> garbage to the printer.
This patch went in to 2.6.4-rc1, didn't it? It seems
[EMAIL PROTECTED] said:
> This is very good news. Thanks a lot for doing this, I for one will
> be switching to this as soon as I get the chance (lack of isoc packets
> doesn't bother me at this time :).
Roll on SMP support in UML then :)
--
dwmw2
_
38 matches
Mail list logo
