David Brownell wrote:
Right now, there is nothing in the standard hotplug userspace that makes
this easy for anyone. It encourages applications to do the hideous thing
and do whatever they think is best.
We should provide some sort of standard support where an application can
install a configura
On Sat, Oct 12, 2002 at 12:21:29AM +0200, Oliver Neukum wrote:
> Am Freitag, 11. Oktober 2002 23:43 schrieb Alan Cox:
> > On Fri, 2002-10-11 at 21:30, Oliver Neukum wrote:
> > > That is not true. Hotplugging changes it. By assigning new devices
> > > to existing device nodes, the kernel _does_ hand
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>And like I said, being part of the system, its job is to
> >>*FOLLOW* policies. The _only_ policy it has any business
> >>defining is "default-secure". Just look at all the trouble
> >>MSFT causes by choosing "default-unprotected
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>But Randy did provide usb_calc_bus_time() ... it was exactly the
> >>right primitive, once it learned something about high speed! :)
> >>
> >>Not using those other calls because they were specific to URBs (not
> >>endpoints),
>
On Thu, Oct 10, 2002 at 11:38:26PM -0700, Randy.Dunlap wrote:
> Hi,
>
> Here's the updated "nousb" patch for vanilla 2.5.41.
> It applies with 2 small offsets to 2.5.41-bk3.
Looks good, thanks for doing this.
applied,
greg k-h
---
This sf.ne
On Fri, Oct 11, 2002 at 05:08:43PM -0400, Dan Streetman wrote:
>
> Hi, this patch fixes usbfs. You can't use a single mount_count for 2
> different mounts.
It looks like you are using a buggy version of pine that strips the
whitespace off of the ends of lines, so this patch didn't apply. But I
And like I said, being part of the system, its job is to
*FOLLOW* policies. The _only_ policy it has any business
defining is "default-secure". Just look at all the trouble
MSFT causes by choosing "default-unprotected"!!
...
Perhaps one missing piece here is the observation that security
poli
But Randy did provide usb_calc_bus_time() ... it was exactly the
right primitive, once it learned something about high speed! :)
Not using those other calls because they were specific to URBs (not
endpoints),
I don't see how your code is different in this respect.
Think about how it works
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Like I said before, gphoto, sane, etc, don't have security policies.
> > That's the systems job, not the applications.
> >
> > /sbin/hotplug, being part of the system, should solve this.
>
> And like I said, being part of the
Sorry, I should have said packet. I have UHCI on the brain :)
I wonder why ... :)
So it does a maximum of one packet per endpoint per frame for low speed
devices? Or does it only do one packet and then move on, but if there's
still time left in the frame, there's the chance of doing another
Like I said before, gphoto, sane, etc, don't have security policies.
That's the systems job, not the applications.
/sbin/hotplug, being part of the system, should solve this.
And like I said, being part of the system, its job is to
*FOLLOW* policies. The _only_ policy it has any business
defi
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>So was I. Both "enforcing" and "not oversubscribing" are decisions.
> >
> > Uhh, looking at the OHCI code, why is it doing that stuff itself?
> >
> > Why isn't it using the code that Randy developed?
>
> But Randy did provide u
The question now is where should we do that? The current API is specific
to URB's so it won't be as easy as just moving the calls to
urb_submit_urb or something.
What OHCI does is just update the bandwidth utilization fields directly.
Those fields are exported only for viewing in "usbfs", and a
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>All the other HCs apply a certain degree of round-robin logic to
> >>promote fairness in silicon. UHCI has to do that in software.
> >>I'd leave this part in.
> >
> > OHCI only does one TD per frame per transfer?
>
> No, but
All the other HCs apply a certain degree of round-robin logic to
promote fairness in silicon. UHCI has to do that in software.
I'd leave this part in.
OHCI only does one TD per frame per transfer?
No, but it only tries one transfer before going to the
next endpoint. Normally that won't mea
I believe that this driver has been sufficiently beaten into submission that
it can now be considered for being added to the tree.
Patch is against 2.5.41.
I have a 2.4 version as well that is essentially the same as this version
with the necessary backport changes if we want to add it to the 2.4
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> The tricky bit is that the usb_{claim,release}_bandwidth() calls work
> on urbs, not endpoints. So I think those calls need to vanish, and
> HCDs need to switch to more precise math.
> >>>
> >>>Exactly.
> >>>
> >>>The qu
The tricky bit is that the usb_{claim,release}_bandwidth() calls work
on urbs, not endpoints. So I think those calls need to vanish, and
HCDs need to switch to more precise math.
Exactly.
The question now is where should we do that? The current API is specific
to URB's so it won't be as easy as
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>>-changed lowspeed control TDs from depth to breadth.
> >>
> >>Why for? This will guarantee that it will take (# of TD's * 1 ms) time
> >>to complete.
> >
> >
> > Well, mainly to make the code common...but also, making it dept
-changed lowspeed control TDs from depth to breadth.
Why for? This will guarantee that it will take (# of TD's * 1 ms) time
to complete.
Well, mainly to make the code common...but also, making it depth opens the
possibility (for a large transfer) of hogging the bus, and, will most
lowspeed d
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>Reservation should be on a per-endpoint basis, for both ISO and INTR
> >>transfer modes, if we try to follow the USB spec. Dan's change makes
> >>interrupt transfers work that way ... ISO should too.
> >>
> >>The tricky bit is
Reservation should be on a per-endpoint basis, for both ISO and INTR
transfer modes, if we try to follow the USB spec. Dan's change makes
interrupt transfers work that way ... ISO should too.
The tricky bit is that the usb_{claim,release}_bandwidth() calls work
on urbs, not endpoints. So I thi
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> >>-move bandwidth reservation into submit_interrupt and submit_isochronous.
> >>Reserve bandwidth at start of submit_iso, and release on error. Reserve
> >>at end of submit_common (for int only, not bulk).
yep, that's the major problem with removing interrupt queueing...but it
should happen at some point...
removing "automagic resubmit", not "removing interrupt queuing" ... ;)
If noone's looked yet, I can look through the current drivers for any that
use interrupt URBs and try to create a patc
Johannes Erdfelt wrote:
-move bandwidth reservation into submit_interrupt and submit_isochronous.
Reserve bandwidth at start of submit_iso, and release on error. Reserve
at end of submit_common (for int only, not bulk). For interrupt, only
reserve if the URB is the first (i.e. not queued). Only
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>Yes. But at that point it's not a hotplug problem, hotplug is
> >>just a tool used to solve the problem ... :)
> >
> > I disagree. The hotplug support in the kernel is the tool. The hotplug
> > support in userspace (/sbin/hotplug
The "devmode=0666" option works in trusted environments, where
you have some reason to trust all your users.
Which is of limited usefulness.
Limited to "personal" computers, sure ... ;-)
Yes. But at that point it's not a hotplug problem, hotplug is
just a tool used to solve the problem ...
On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
> >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> >> -for places where a td->link was written, added check to make sure HC
> >> hadn't already wrote that td->link back to
On Fri, 11 Oct 2002, David Brownell wrote:
>Actually in principle I see several groups of changes that could
>be delivered in more than one order ... not "all at once":
well, it is possible, but it creates more work to do it seperately than at
once. the couple of bugfixes could have been sepera
On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
>On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>> Hi all. Finally got time to work on this...so, this patch is rather
>> large, but it (almost) all needs to happen at once. So, I'll list
>> essentially what all the changes are, not n
Glad to see this!
Dan Streetman wrote:
Hi all. Finally got time to work on this...so, this patch is rather
large, but it (almost) all needs to happen at once. So, I'll list
essentially what all the changes are, not necessarily in order. I have
tested control and interrupt queueing, but not bul
On Fri, Oct 11, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 11, 2002 at 05:42:58PM -0400, Johannes Erdfelt wrote:
> > On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > For usbfs nodes. It doesn't work for /dev/usb/scannerX
> >
> > I think the point is that we don't ne
On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> Hi all. Finally got time to work on this...so, this patch is rather
> large, but it (almost) all needs to happen at once. So, I'll list
> essentially what all the changes are, not necessarily in order. I have
> tested control and i
Am Freitag, 11. Oktober 2002 23:43 schrieb Alan Cox:
> On Fri, 2002-10-11 at 21:30, Oliver Neukum wrote:
> > That is not true. Hotplugging changes it. By assigning new devices
> > to existing device nodes, the kernel _does_ hand out permissions.
>
> Only if you got the design wrong. The kernel shou
Hi,
On Fri, Oct 11, 2002 at 02:51:17PM -0700, Greg KH wrote:
> So the userspace SANE tools don't need the scanner driver anymore? If
> so, I'd be glad to remove the driver, like the others that we dropped a
> while ago for this same reason.
SANE 1.0.9 will have support for both the scanner drive
Hi all. Finally got time to work on this...so, this patch is rather
large, but it (almost) all needs to happen at once. So, I'll list
essentially what all the changes are, not necessarily in order. I have
tested control and interrupt queueing, but not bulk (no bulk devices on
hand...), so if pe
On Fri, Oct 11, 2002 at 05:42:58PM -0400, Johannes Erdfelt wrote:
> On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Freitag, 11. Oktober 2002 22:56 schrieb Johannes Erdfelt:
> > > On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > > > However, the kernel only
On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 11. Oktober 2002 22:56 schrieb Johannes Erdfelt:
> > On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > > However, the kernel only enforces the privileges. It doesn't set them.
> > >
> > > That is not tru
On Fri, 2002-10-11 at 21:30, Oliver Neukum wrote:
> That is not true. Hotplugging changes it. By assigning new devices
> to existing device nodes, the kernel _does_ hand out permissions.
Only if you got the design wrong. The kernel should pass hotplug the
info to create the device nodes.
If you a
On Fri, 2002-10-11 at 20:41, Oliver Neukum wrote:
>
> > > and even more painfully, what do you do if there's an IO error
> > > during execution of the script. The only safe reaction would be a kernel
> > > panic.
> >
> > A kernel panic should only be the result of a catastrophic system
> > failure
Am Freitag, 11. Oktober 2002 22:56 schrieb Johannes Erdfelt:
> On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > However, the kernel only enforces the privileges. It doesn't set them.
> >
> > That is not true. Hotplugging changes it. By assigning new devices
> > to existing devic
Hi, this patch fixes usbfs. You can't use a single mount_count for 2
different mounts.
--- usb-2.5/drivers/usb/core/inode.cFri Oct 11 16:52:49 2002
+++ linux/drivers/usb/core/inode.c Fri Oct 11 15:54:47 2002
@@ -45,7 +45,8 @@
static struct vfsmount *usbdevfs_mount;
static struct vfs
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>>The problem with permissions isn't libusb's problem, it's hotplug's
> >>>problem.
> >>
> >>I agree, is there a mount option that libusb users prefer to use to get
> >>usbfs devices with the needed permissions?
>
> It's not a h
On Fri, Oct 11, 2002 at 09:44:23PM +0200, Oliver Neukum wrote:
> > * Quite a lot of scanners are still unsupported by the driver because of
> > the "only 2 or 3 endpoints" issue. I.e. for some unknown reason the
> > driver refuses to work with scanners that only have one bulk endpoint.
> > Is
On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > However, the kernel only enforces the privileges. It doesn't set them.
>
> That is not true. Hotplugging changes it. By assigning new devices
> to existing device nodes, the kernel _does_ hand out permissions.
It assigns the pe
The problem with permissions isn't libusb's problem, it's hotplug's
problem.
I agree, is there a mount option that libusb users prefer to use to get
usbfs devices with the needed permissions?
It's not a hotplug problem, since the standard package doesn't
know about application-specific securi
> > > A kernel panic should only be the result of a catastrophic system
> > > failure that the kernel cannot continue from.
> >
> > Unauthorised access _is_ a catastrophe.
>
> I agree.
>
> However, the kernel only enforces the privileges. It doesn't set them.
That is not true. Hotplugging change
On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > and even more painfully, what do you do if there's an IO error
> > > during execution of the script. The only safe reaction would be a kernel
> > > panic.
> >
> > A kernel panic should only be the result of a catastrophic syst
Hi,
this incorporates Greg's suggestions. I am still working at understanding
the driverfs code. So that is not cleaned up.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usu
> * Quite a lot of scanners are still unsupported by the driver because of
> the "only 2 or 3 endpoints" issue. I.e. for some unknown reason the
> driver refuses to work with scanners that only have one bulk endpoint.
> Is there already a plan on how to fix that? There is a patch at
> htt
> > and even more painfully, what do you do if there's an IO error
> > during execution of the script. The only safe reaction would be a kernel
> > panic.
>
> A kernel panic should only be the result of a catastrophic system
> failure that the kernel cannot continue from.
Unauthorised access _is
ChangeSet 1.741, 2002/10/11 11:02:51-07:00, [EMAIL PROTECTED]
[PATCH] USB: fix ctsrts handling in pl2303 driver.
Thanks to the prolific engineers for pointing this out to me.
diff -Nru a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
--- a/drivers/usb/serial/pl2303.c Fri Oct 1
ChangeSet 1.740, 2002/10/11 11:02:23-07:00, [EMAIL PROTECTED]
[PATCH] Configure.help entry for CONFIG_USB_MIDI
diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help
--- a/Documentation/Configure.help Fri Oct 11 12:32:57 2002
+++ b/Documentation/Configure.help Fri Oc
ChangeSet 1.738, 2002/10/11 11:02:02-07:00, [EMAIL PROTECTED]
[PATCH] usbfs race while mounting/umounting
I use usbfs, but normally have only a single USB device connected, a
generic mouse. When usbfs is unmounted on shutdown, I see "BUG at
inode.c:1034" in between 5% and 50% of all cases, the
Hi,
Here are some small USB bug fixes for 2.4.20-pre10.
Pull from: bk://linuxusb.bkbits.net/marcelo-2.4
The individual patches will be sent in follow up messages to this email.
thanks,
greg k-h
Documentation/Configure.help | 21 +
drivers/usb/hid-input.c |2 +
ChangeSet 1.739, 2002/10/11 11:02:13-07:00, [EMAIL PROTECTED]
[PATCH] hid-input: fix find_next_zero_bit usage
It was swapping the parameters, using the bitfield size for the
offset and the offset for the bitfield size. With this the mouse
buttons in my wireless USB keyboard finally works 8
On Fri, Oct 11, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > I'd rather not go that route.
> >
> > I'd much rather prefer that applications add some a configuration to
> > hotplug with the devices they support and hotplug dynamically adjust the
> > permissions to the console user.
> >
> >
> I'd rather not go that route.
>
> I'd much rather prefer that applications add some a configuration to
> hotplug with the devices they support and hotplug dynamically adjust the
> permissions to the console user.
>
> This should be doable.
Not entirely and securely.
To be precise, you can hand
On Fri, Oct 11, 2002 at 04:00:09PM +0200, Matthias Bruestle wrote:
> Mahlzeit
>
>
> I'm currently testing multiple readers with SuSE 8.1 (linux 2.4.19).
> The computer does freeze often at the end of tests in the middle of
> testruns. The nun lock and caps lock LEDs did then blink. The text
> c
Am Freitag, 11. Oktober 2002 17:45 schrieb John Tyner:
> > Sorry, my humor got the better of me. You should add a few comment
> > regarding the locking through v4l open. YOur relienance on it makes
> > it very subtle and impossible to understand without comments.
> > The code itself is very well.
On Fri, Oct 11, 2002 at 01:42:53PM -0400, Johannes Erdfelt wrote:
> On Fri, Oct 11, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Fri, Oct 11, 2002 at 01:16:21PM -0400, Johannes Erdfelt wrote:
> > > On Fri, Oct 11, 2002, Henning Meier-Geinitz <[EMAIL PROTECTED]> wrote:
> > > > * "Overall plan":
On Fri, Oct 11, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 11, 2002 at 01:16:21PM -0400, Johannes Erdfelt wrote:
> > On Fri, Oct 11, 2002, Henning Meier-Geinitz <[EMAIL PROTECTED]> wrote:
> > > * "Overall plan": Will the kernel USB scanner driver stay and be kept
> > > current? I'm a
On Fri, Oct 11, 2002 at 01:16:21PM -0400, Johannes Erdfelt wrote:
> On Fri, Oct 11, 2002, Henning Meier-Geinitz <[EMAIL PROTECTED]> wrote:
> > * "Overall plan": Will the kernel USB scanner driver stay and be kept
> > current? I'm asking because SANE has now support for libusb. While
> > libusb
On Fri, Oct 11, 2002, Henning Meier-Geinitz <[EMAIL PROTECTED]> wrote:
> * "Overall plan": Will the kernel USB scanner driver stay and be kept
> current? I'm asking because SANE has now support for libusb. While
> libusb has its problems (especially regarding permissions), it can
> support a
Hello all,
Sorry if this was answered recently, I couldn't find much in the
archives.
My question is about the USB scanner driver and its maintainance. If I
understood correctly, the maintainer is now Brian Beattie. Should
patches and bug reports be send to him only, this list or both?
I'm tal
anton wilson wrote:
>
> Is there a guarantee that USB core and the HC will report timing problems?
It's more of an issue of whether the HC does. The HCD may not treat
some things as a timing issue (retry for a non-ISO transaction, etc),
and if it's not precise about scheduling periodic transac
> Sorry, my humor got the better of me. You should add a few comment
> regarding the locking through v4l open. YOur relienance on it makes
> it very subtle and impossible to understand without comments.
> The code itself is very well.
Absolutely. Once there are no more problems with the code, I'l
On Fri, 11 Oct 2002, anton wilson wrote:
| Is there a guarantee that USB core and the HC will report timing problems?
| For instance, if I'm "chaining" ISO transfers to run every millisecond, do
| USB core and the HC always know if we miss that 1 millisecond transfer for
| some reason? If so, how
Is there a guarantee that USB core and the HC will report timing problems?
For instance, if I'm "chaining" ISO transfers to run every millisecond, do
USB core and the HC always know if we miss that 1 millisecond transfer for
some reason? If so, how does it communicate this failure with the up
Mahlzeit
I'm currently testing multiple readers with SuSE 8.1 (linux 2.4.19).
The computer does freeze often at the end of tests in the middle of
testruns. The nun lock and caps lock LEDs did then blink. The text
console did just freeze, but this text console was not in text mode,
but in fbdev
Am Freitag, 11. Oktober 2002 02:50 schrieb John Tyner:
> > To be frank, your disconnection handling is the most outrageous abuse
> > of semaphores I've seen in months. But it is correct :-)
>
> Well, I'd like it to be correct in the "it's actually decent code"
> department as well. The "in months"
71 matches
Mail list logo
