> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> Tested-by: Duncan Sands <[EMAIL PROTECTED]>
Signed-off-by: Duncan Sands <[EMAIL PROTECTED]>
Thanks again for doing this!
Best wishes,
Duncan.
--
To unsubscribe from this list: send the line "unsubscribe l
Hi,
> The problem is that I couldn't find the maintainer for the code
> in drivers/usb/atm/.
that would be me (though since I haven't used this modem in years I would
be more than happy to hand it off to someone else).
> Besides, I don't have a proper hardware to test this.
I will try to find
Hi Pavel,
> >> @@ -1014,11 +1015,7 @@ static int usbatm_do_heavy_init(void *arg)
> >>struct usbatm_data *instance = arg;
> >>int ret;
> >>
> >> - daemonize(instance->driver->driver_name);
> >>allow_signal(SIGTERM);
> >> - instance->thread_pid = current->pid;
> >> -
> >> - complete
Hi Pavel,
> Oh, I see. You're right - this race is possible... I'll fix that up
> if this patch works.
it seems to work fine. Thanks again for doing this!
Best wishes,
Duncan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
On Monday 11 February 2008 12:22:27 Pavel Emelyanov wrote:
> Duncan Sands wrote:
> > Hi Pavel,
> >
> >> Oh, I see. You're right - this race is possible... I'll fix that up
> >> if this patch works.
> >
> > it seems to work fine. Thanks
> I still don't think they would lose out by much.. I've just being
> trying to RE the ATI Mpeg2 IDCT/MC hardware, ATI know this, I know
> this, they are only wasting my time and my employers money (we still
> are going to buy their chips... no choice..) will they give out specs
> .. no .. why? cau
> I wonder why the invocations of kmalloc are needed in these functions.
Because some architectures can't do DMA to/from the stack.
All the best,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> > > I wonder why the invocations of kmalloc are needed in these functions.
> >
> > Because some architectures can't do DMA to/from the stack.
>
> doing dma to/from kmalloc also isn't too nice... should be using
> dma_alloc_*() API I guess
The USB core applies dma_map_single to the buffer, so i
> I've seen similar hehaviour (machine halts) with a BT848 on a VT82C686
> board while displaying the picture on a radeon card under X.org 6.8.1.
I have the same problem with a Bt878 on a VT82C686 board with a Radeon 7500
card. The problem predates X.org.
> Heavy HDD IO almost certainly caused s
> Jeremy do you use overlay or gradisplay ?
Dunno about Jeremy, but I'm using overlay and getting hard
hangs.
Ciao,
D.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
Hi Alistair,
> Just out of curiosity, is there ANY reason why this has to be done in the
> kernel? The PPPoATM module for pppd implements (via linux-atm) a completely
> userspace ATM decoder.. if anything, now redundant ATM stack code should be
> REMOVED from Linux!
the main advantage of the k
Hi Alistair,
> > The instalation is currently (with firmware loader instead of modem_run)
> > very simple: USE="atm" emerge ppp, download firmware and place it in
> > /lib/firmware, compile the kernel with speedtch support.
>
> Compared to "place the firmware in /lib/firmware" on many other distr
On Thu, 2005-02-10 at 16:11 -0800, Pete Zaitcev wrote:
> I entered a patch which adds "exclusive_access" lock into 2.4.29, to fix
> devices which cannot handle simultaneous accesses. This caused a regression
> with European ADSL modems. An ioctl USBDEVFS_REAPURB allows a process to enter
> the kern
> > - /* if not yet claimed, claim it for the driver */
> > - dev_warn(&ps->dev->dev, "usbfs: process %d (%s) did not claim interface
> > %u before use\n",
> > - current->pid, current->comm, ifnum);
> > - return claimintf(ps, ifnum);
> > + return -EINVAL;
> > }
> >
> > static
Hi,
> When entered, the menu point "USB DSL modem support" in menuconfig, path
> [Device Drivers->USB
> Support] shows no entries but "^@" instead. The following fixes it.
is the problem that there are no entries, or that "^@" is displayed? If there
are no
entries then presumably you didn't tu
Hi Mikie,
> Do you have any news regarding my case of slow transfers via
> Speedtouch USB modem on linux ?
I found my old speedtouch modem and tested here. I got 2.1 Mbaud
bulk downspeed, and 3 Mbaud isoc downspeed. This last is half the
speed my line supports, so something is wrong [*]. Unfor
On Wednesday 21 February 2007 22:36:14 Simon Arlott wrote:
> Increment usbatm driver module refcount when atm device is opened,
> this prevents the driver for the device being removed if it's in use.
> (I continue to allow removing the driver without unplugging the device
> if it's not being used).
> + /* the module/device has probably been removed */
> + if (urb->status == -ESHUTDOWN)
> + return;
> +
> if (printk_ratelimit())
> atm_warn(channel->usbatm, "%s: urb 0x%p failed (%d)!\n",
>
asprzak
> M: [EMAIL PROTECTED]
> --
> 1.4.3.1
>
>
You may want to put something in the cxacru driver too.
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Pete,
On Friday 23 February 2007 00:53:18 Pete Zaitcev wrote:
> On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > + /* the module/device has probably been removed */
> > > + if (urb->status == -ESHUTDOWN)
On Friday 23 February 2007 17:16:24 Alan Stern wrote:
> On Fri, 23 Feb 2007, Duncan Sands wrote:
>
> > if you get ESHUTDOWN, does that mean that you are about to be disconnected,
> > i.e. the disconnect method is about to be called? Or is it possible for the
> > device to
> Gee, thanks. I sat and wrote code side-by-side, and it looks like, even
> barriers
> won't fix anything, because they don't affect other CPUs.
?! The whole point of memory barriers is that they affect other CPUs.
Maybe you are thinking of compiler barriers?
> ->proc_fops is valid
Can read_proc still be executing when remove_proc_entry returns?
In my driver [*] I allocate some data and create a proc entry using
create_proc_entry. My read method reads from my allocated data. When
shutting down, I call remove_proc_entry and immediately free the data.
If some call to read_pr
Hi Simon,
> +static int cxacru_proc_read(struct usbatm_data *usbatm_instance,
> + struct atm_dev *atm_dev, loff_t * pos, char *page)
> +{
> + struct cxacru_data *instance = usbatm_instance->driver_data;
> + u32 *cxinf = instance->cxinf_status;
> + int left = *pos;
if there was no
> The device is only polled for status every 5 seconds yet status updates
> occur as often as every second - when the line is down the status changes
> between "down" and "attempting to activate" every 2 seconds.
How much overhead does polling involve? [A particularly problematic case
is when p
> usbatm only outputs basic information via the per-device /proc/net/atm/ file,
> this patch allows the device specific USB ATM drivers to replace the
> atm_proc_read function with their own.
I'm still meditating on this. The reason I didn't do this originally is
because of potential problems w
> Couldn't the cxacru instance pointer to the proc_read function be set to NULL
> before unloading?
The problem is reads that started (on some other CPU) before you started
shutting things down
(eg: but setting this to null or whatever other method you like) and only
finish after you have
finis
> I've had it polling every 200ms on a dual ppro200 since november,
> and it has never failed to poll the status.
Great, that's certainly better than the speedtouch ;)
I can't help feeling that polling twice a second is overkill.
How about changing it to poll every 5 seconds if the line is
up, an
On Wednesday 31 January 2007 19:42:51 Alexey Dobriyan wrote:
> On Wed, Jan 31, 2007 at 11:54:35AM +0100, Duncan Sands wrote:
> > Can read_proc still be executing when remove_proc_entry returns?
> >
> > In my driver [*] I allocate some data and create a proc entry using
>
On Thursday 1 February 2007 00:39:14 you wrote:
> On Tue, 30 Jan 2007 21:30:29 +
> Simon Arlott <[EMAIL PROTECTED]> wrote:
>
> > +static int cxacru_proc_read(struct usbatm_data *usbatm_instance,
> > + struct atm_dev *atm_dev, loff_t * pos, char *page)
> > +{
> > + struct cxacru_data *insta
> I don't understand how this is supposed to work. Consider
>
> CPU1 CPU2
>
> atomic_inc(&dp->pde_users);
> if (dp->proc_fops)
> de->proc_fops = NULL;
> use_proc_fops <= BOOM
> if (
Hi Alexey,
> I believe, barriers not needed, not now.
>
> This scheme relies on the fact that remove_proc_entry() will be the only
> place that will clear ->proc_fops and, once cleared, ->proc_fops will
> never be resurrected. Clearing of ->proc_fops will eventually propagate
> to CPU doing first
> I'm really not convinced about the user-mode thing unless somebody can
> show me a good reason for it. Not just some "wouldn't it be nice" kind of
> thing. A real, honest-to-goodness reason that we actually _want_ to see
> used.
Qemu? It would be nice if emulators could directly drive hardwa
On Tuesday 2 January 2007 12:11, Leonard Norrgard wrote:
> This seems a bit odd. As the bt878 module loads, I get the following
> error messages, despite definitions in the bttv module that bt878
> depends on:
>
> # egrep '(bttv_read_gpio|bttv_write_gpio|bttv_gpio_enable)' /var/log/dmesg
> bt878:
Hi Ilyes, you won't be able to allocate that much *contiguous* memory,
but you should be able to allocate enough non-contiguous memory (e.g.
by calling __get_free_page 256 times; not the same as calling
__get_free_pages(8) !). To use that memory, you can try using the usb
scatter/gather support (s
On Friday 6 July 2007 14:54:18 mikie wrote:
> Hi,
>
> I experience some problems with the speedtch.c module, especially in
> regards to its firmware loader.
> I am not quite sure if this module is going to load the firmware
> itself or does it use some external software to do that ?
It loads it i
Hi,
> On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug.
> I copied your script to /sbin/hotplug and also added simple logging,
> so I can see whenever the script is being started. It turns out that
> the script is not started at all by the kernel...
did you turn hotplug on in you
Hi,
> > Is it actually running in isochronous mode? (It prints some messages
> > about this).
>
> This is what I get:
> [EMAIL PROTECTED]:/# cat /sys/module/speedtch/parameters/enable_isoc
> Y
>
> I think it means it confirms the isochronous mode is working.
> Especially that I modified the so
> I also tried a couple of other firmwares available on the net, and
> also the one from Windows XP install (which works and achieves speeds
> of up to 720kbyte/sec downlink). Some of the firmwares did not work
> either, and some worked the same way - it means not more than 3mbit/s
> (around 400kby
On Tuesday 10 July 2007 11:13:09 mikie wrote:
> 2007/7/10, Duncan Sands <[EMAIL PROTECTED]>:
> > > I also tried a couple of other firmwares available on the net, and
> > > also the one from Windows XP install (which works and achieves speeds
> > > of up to
Hi Mikie,
> I begin to think that the isochronous mode is not working. I tried the
> speedtch module with disabled and enabled isoc and there is no
> difference in transfer speeds at all.
>
> All I checked was :
> [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc
> Y
>
> which
Hi,
> Actually I had to mount it (I hope that not having it mounted does
> not change a lot in this matter).
probably not. Not having sysfs mounted can cause hotplug to fail,
but I think not having /proc/bus/usb mounted shouldn't cause any
trouble nowadays.
> I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(v
On Thursday 10 May 2007 14:12:47 Indan Zupancic wrote:
> Hello,
>
> On Thu, May 10, 2007 03:38, Jeff Garzik wrote:
> >
> > This was ACK'd by Greg, as you see in the sign-offs. See the commit
> > below for rationale.
> >
> > USB is now treated like other buses, for network drivers:
> > * USB netwo
Hi,
> > Just look at the tasklet_disable() logic.
>
> Do not count this.
>
> Done this way because nobody needed that thing, except for _one_ place
> in keyboard/console driver, which was very difficult to fix that time,
> when vt code was utterly messy and not smp safe at all.
>
> start_bh_ato
> Old days that was acceptable, you had not gazillion of attempts
> but just a few, but since some time (also old already) it became
> disasterous.
What changed? And can it be fixed?
Thanks,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Friday 13 April 2007 01:56:31 Oleg Nesterov wrote:
> usbatm_do_heavy_init() calls allow_signal() which plays with parent process's
> ->sighand.
>
> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
> --- 2.6.21-
On Sunday 15 April 2007 02:18:39 Simon Arlott wrote:
> Detect usb device shutdown and ignore failed urbs.
> This happens when the driver is unloaded or the device is unplugged.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
> Cc: Duncan Sands <[EMAIL PROTECTED]&
Hi Simon,
> +static ssize_t cxacru_sysfs_show_adsl_state(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct usb_interface *intf = to_usb_interface(dev);
> + struct usbatm_data *usbatm_instance = usb_get_intfdata(intf);
> + struct cxacru_data *instance
Hi Simon,
> +named device points to the USB interface device's directory which contains
> +several sysfs attribute files for retriving device statistics:
retrieving
Ciao,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
Hi,
> Instead of changing existign probe functionality to be asynchronous, we
> could *add* a new and asynchronous part to it. For example, we could make
> the rule for PCI - or other bus - devices be:
>
> - the bus will *first* call the "probe()" function synchronously.
>
> - after that one
Hi Cornelia,
> > the usbatm USB ADSL modem drivers have this functionality. These drivers
> > need to load firmware before they become useful. The natural place to do
> > this is in the probe() method, but because firmware loading can take quite
> > some time (10 seconds, or even an infinite amo
Hi Simon,
> static ssize_t cxacru_sysfs_showattr_dB(s16 value, char *buf)
> {
> - if (unlikely(value < 0)) {
> - return snprintf(buf, PAGE_SIZE, "%d.%02u\n",
> - value / 100, -value % 100);
> - } else {
> - return snprin
abs() for dB values instead of two almost identical return lines.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
> Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> Cc: Duncan Sands <[EMAIL PROTECTED]>
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
> Cc: Andr
t; date right now.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
> Cc: Duncan Sands <[EMAIL PROTECTED]>
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
> ---
> I will email Roman Kagan once I think my cxacru-info utility is ready to
> be released and to
Hi Simon, don't these error messages (except the first) risk spamming
the log if something goes wrong (like the modem being unplugged)? How
about rate-limiting them, like usbatm does?
Ciao,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Sunday 23 September 2007 17:36:08 Simon Arlott wrote:
> Cleanup code by removing "ret = ret;" assignments.
>
> Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubs
Hi Simon,
> + usb_info(usbatm, "started firmware\n");
...
> + usb_info(usbatm, "loaded config data\n");
maybe these should be debug messages. When are they useful?
Ciao,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
> - dbg("too big transfer requested");
> + if (printk_ratelimit())
> + usb_err(instance->usbatm, "requested transfer size too
> large (%d, %d)\n",
> + wbuflen, rbuflen);
etc
Acked-by:
So, given the fact that the userspace RCU library does now see
some real-world use, is it now time for Mathieu to resubmit his
sys_membarrier() patch?
I'm using userspace RCU with success in financial software, so the LTTng project
isn't the only user. It works well, but it's not as fast as I'
On 12/8/20 10:32 AM, Enrico Weigelt, metux IT consult wrote:
Since we have the nice helpers pr_err() and pr_warn(), use them instead
of raw printk().
Signed-off-by: Enrico Weigelt, metux IT consult
Acked-by: Duncan Sands
---
drivers/usb/atm/usbatm.c | 2 +-
drivers/usb/atm/xusbatm.c
On 06/12/13 04:59, learc83 wrote:
Fixed a pointer variable format issue.
This is obviously OK.
Ciao, Duncan.
Signed-off-by: Seth Archer Brown
---
drivers/usb/atm/usbatm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/us
Hi Seth,
On 06/12/13 15:24, Seth Archer wrote:
Sorry, but do you mean the patch is OK, or the original is OK and no patch
necessary?
I meant that the patch is obviously OK.
Ciao, Duncan.
-Seth
On Fri, Dec 6, 2013 at 3:24 AM, Duncan Sands mailto:duncan.sa...@gmail.com>> wrote:
. Darwish
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Duncan Sands
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
---
drivers/usb/atm/usbatm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm
63 matches
Mail list logo
