Hi!
> >Well, in 2.6.73.1 we add 'trivial' one line to add new
> >pci id, and in
> >2.6.73.2 we have data corruption, because that driver
> >needed some
> >quirk we did not know about...?
>
> False argument. -stable should only be merging patches
> that are already upstream, and known.
Well,
David Hollis wrote:
With the asix.c driver, you can't just add the USB IDs and have it work.
Each ID also needs to be told which driver structure to use, since the
driver itself supports three similar, but distinct chips. Adding the
IDs to the driver itself is naturally trivial, but adding via s
On Tue, 2007-05-22 at 15:17 -0700, Greg KH wrote:
> >
> > Theres more to this than just PCI IDs though.
> > ac97 ID updates, usb id updates, etc, etc.
>
> USB ids also can be added through sysfs :)
>
FWIW,
With the asix.c driver, you can't just add the USB IDs and have it work.
Each ID also n
Pavel Machek wrote:
Well, in 2.6.73.1 we add 'trivial' one line to add new pci id, and in
2.6.73.2 we have data corruption, because that driver needed some
quirk we did not know about...?
False argument. -stable should only be merging patches that are already
upstream, and known.
Je
Hi!
> >So, because of that, I don't really see a need to be
> >adding new device
> >ids to the -stable tree.
>
> Maybe you are just not seeing all the developers that
> keep bringing this up??
>
> Really, it is just silly to think that one-line PCI IDs
> patches will cause any harm at all, an
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> >2) In theory new hardware can seem to work with a simple PCI ID
> >update, and later we find it needs extra quirk handling or specific
> >driver support. This could mean adding buggy support for new hardware
> >to -stable. In pract
On Tue, May 22, 2007 at 06:56:40PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 03:17:18PM -0700, Greg Kroah-Hartman wrote:
>
> > > > > I haven't found a single distro that (a) makes it trivial to add
> PCI IDs at
> > > > > install time, and then (b) ensures those PCI IDs remain pers
On Tue, May 22, 2007 at 03:17:18PM -0700, Greg Kroah-Hartman wrote:
> > > > I haven't found a single distro that (a) makes it trivial to add PCI
> > IDs at
> > > > install time, and then (b) ensures those PCI IDs remain persistent
> > for each
> > > > boot. We are not at all to the
Chris Wright wrote:
2) In theory new hardware can seem to work with a simple PCI ID
update, and later we find it needs extra quirk handling or specific
driver support. This could mean adding buggy support for new hardware
to -stable. In practice, hopefully this isn't a real issue.
No need to
On Tue, May 22, 2007 at 03:00:44PM -0700, Chris Wright wrote:
> * Greg KH ([EMAIL PROTECTED]) wrote:
> > On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > > Really, it is just silly to think that one-line PCI IDs patches will
> > > cause
> > > any harm at all, and it should be se
On Tue, May 22, 2007 at 04:24:04PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> > Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> > the new_id stuff entirely, so I can see why you might get this
> > impression :)
>
> I looked at distros other than those produced by my e
On Tue, May 22, 2007 at 03:51:35PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 12:35:38PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > > Greg KH wrote:
> > > > What's wrong with the current sysfs way of adding new device ids
> wit
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > Really, it is just silly to think that one-line PCI IDs patches will cause
> > any harm at all, and it should be self-evident that there is clear
> > potential
> > to HELP Linux users. Tha
Greg KH wrote:
Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
the new_id stuff entirely, so I can see why you might get this
impression :)
I looked at distros other than those produced by my employer.
Apparently you did not.
This is not how we best serve Linux users.
On Tue, May 22, 2007 at 12:35:38PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > Greg KH wrote:
> > > What's wrong with the current sysfs way of adding new device ids without
> > > touching the kernel? Devices described above was the very
On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> > What's wrong with the current sysfs way of adding new device ids without
> > touching the kernel? Devices described above was the very reason we
> > added that functionality, so users would not have to constantly up
On Tue, May 22, 2007 at 02:53:53PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 11:47:33AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> > > I'd like to propose we allow adding new device IDs as part
> > > of the -stable process, but o
Greg KH wrote:
What's wrong with the current sysfs way of adding new device ids without
touching the kernel? Devices described above was the very reason we
added that functionality, so users would not have to constantly update
their kernel. The distros provide userspace tools that enable these
On Tue, May 22, 2007 at 11:47:33AM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> > I'd like to propose we allow adding new device IDs as part
> > of the -stable process, but only under certain conditions:
>
> Who would be the primary benifa
On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> I'd like to propose we allow adding new device IDs as part
> of the -stable process, but only under certain conditions:
Who would be the primary benifactor of this?
The very large majority of users out there use a distro kernel, and
20 matches
Mail list logo
