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
. 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
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
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
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:
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
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 lear...@gmail.com
---
drivers/usb/atm/usbatm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
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 duncan.sa...@gmail.com
mailto:duncan.sa
> 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 "unsubscr
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 again for
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 again for doing this!
Oh, thanks for testing. What should I do next
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 linux-kernel in
the body of a message
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
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 PROTECTED]
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;
> >> -
> >> -
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(instance-thread_started);
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,
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
> - dbg("too big transfer requested");
> + if (printk_ratelimit())
> + usb_err(instance->usbatm, "requested transfer size too
> large (%d, %d)\n",
> + wbuflen, rbuflen);
etc
Ac
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
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 "u
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
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 unsubscribe linux-kernel in
the body of a message
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 to
- 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: Duncan Sands [EMAIL PROTECTED]
-
To unsubscribe
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 [*].
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
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 turn on ATM
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 [*].
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
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
>
>
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 as I
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
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
> > > o
> 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
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
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 720kbyte/sec downlink). Some of the firmwares did
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
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
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 your
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 source of
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
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
> 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
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.
>
>
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_atomic() was
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 message
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
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 network driver
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
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
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 has
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 amount of
te 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 t
.
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 point out that the driver's been in the kernel for a
while and doesn't
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
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
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 snprintf(buf,
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: Andrew Morton [EMAIL PROTECTED]
-
To unsubscribe from this list: send
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
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 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
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]&
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]
Acked-by: Duncan Sands [EMAIL
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 =
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-rc5/d
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-rc5/drivers/usb/atm/usbatm.c~usbatm2006
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
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)
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)
+ return
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 just sit there disabled
Kasprzak
> 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/
> + /* 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",
>
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
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). No
+ /* 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,
/computone.html
S: Maintained
+CONEXANT ACCESSRUNNER USB DRIVER
+P: Simon Arlott
+M: [EMAIL PROTECTED]
+S: Maintained
+
COSA/SRP SYNC SERIAL DRIVER
P: Jan Yenya Kasprzak
M: [EMAIL PROTECTED]
--
1.4.3.1
You may want to put something in the cxacru driver too.
Acked-by: Duncan
> 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
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
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
> I don't understand how this is supposed to work. Consider
>
> CPU1 CPU2
>
> atomic_inc(>pde_users);
> if (dp->proc_fops)
> de->proc_fops = NULL;
> use_proc_fops <= BOOM
> if
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
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 *instance =
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 check,
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
>
> 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,
> 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
> 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
> 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
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
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
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
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 polling
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
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
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, and
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
create_proc_entry. My read
1 - 100 of 124 matches
Mail list logo
