This patch was generated against 2.6.20-rc5; it fixes a bug that
cropped up in a late 2.6.19-mm kernel.
When ALSA's sysfs device creation was converted from using
class_device_create() to device_create(), the fourth param from
class_device_create() [dev] was simply plugged into arg 2 of
device_cr
On Wed, Jan 24, 2007 at 08:50:06PM -0500, Christopher Monty Montgomery wrote:
> This patch was generated against 2.6.20-rc5; it fixes a bug that
> cropped up in a late 2.6.19-mm kernel.
>
> When ALSA's sysfs device creation was converted from using
> class_device_create() to device_create(), the f
Christopher "Monty" Montgomery wrote:
> This patch was generated against 2.6.20-rc5; it fixes a bug that
> cropped up in a late 2.6.19-mm kernel.
>
> When ALSA's sysfs device creation was converted from using
> class_device_create() to device_create(), the fourth param from
> class_device_create()
On 1/24/07, Greg KH <[EMAIL PROTECTED]> wrote:
I don't understand, where does the symlink currently point to? It looks
correct to me on my machines:
My machines and the fedora rawhide machines using the 2.6.20-rcX
releases look nothing like what you pasted. If they did, hald would
be working.
Christopher "Monty" Montgomery wrote:
>
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted. If they did, hald would
> be working... (I'll note that bugs have also been logged against
> Pulse and HAL by users having trouble, so it's not
On 1/25/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
Christopher "Monty" Montgomery wrote:
>
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted. If they did, hald would
> be working... (I'll note that bugs have also been logged agains
Christopher "Monty" Montgomery wrote:
>
> Interesting to know. Looking more closely, it looks like machines
> here are split between the messed up output I forwarded previously and
> the output that is expected. All of my personal boxes are messed up.
>
There is some option about deprecated sy
On 1/25/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
There is some option about deprecated sysfs stuff. Perhaps this is the
cause of your twisted tree. It's off here:
# CONFIG_SYSFS_DEPRECATED is not set
It is set. It is also set in the default config, so plently of people
are running with a
At Thu, 25 Jan 2007 10:57:25 -0500,
Christopher "Monty" Montgomery wrote:
>
> On 1/25/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> > There is some option about deprecated sysfs stuff. Perhaps this is the
> > cause of your twisted tree. It's off here:
> >
> > # CONFIG_SYSFS_DEPRECATED is not s
> What was there (plugging the old 'dev' arg into the new call's
> 'parent' makes no sense) is clearly wrong.
It makes sense because the meaning of card->dev was changed, too.
Now it points the "card*" object that is the root of all belonging
devices. The former card->dev is stored in card->pare
I'm working on this now and will doublecheck just in case my test was
flawed first time.
Doublechecking indicates my initial test was wrong somehow; both
card->dev->parent and card->parent passed as arg 2 to the
device_create call in snd_register_device result in correct device
symlinks. Are the
At Thu, 25 Jan 2007 12:30:44 -0500,
[EMAIL PROTECTED] wrote:
>
> > I'm working on this now and will doublecheck just in case my test was
> > flawed first time.
>
> Doublechecking indicates my initial test was wrong somehow; both
> card->dev->parent and card->parent passed as arg 2 to the
> device
Updated version of patch also taking into account feedback from
Takashi is attached.
I'm going to look at hald now.
Monty
diff -uprN -X linux-2.6.20-rc5/Documentation/dontdiff
linux-2.6.20-rc5/sound/core/sound.c linux-2.6.20-rc5-monty/sound/core/sound.c
--- linux-2.6.20-rc5/sound/core/sound.c 2
On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
At Thu, 25 Jan 2007 12:30:44 -0500,
[EMAIL PROTECTED] wrote:
>
> > I'm working on this now and will doublecheck just in case my test was
> > flawed first time.
>
> Doublechecking indicates my initial test was wrong somehow; both
> card->dev->par
At Thu, 25 Jan 2007 13:07:04 -0500,
[EMAIL PROTECTED] wrote:
>
> On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
> > At Thu, 25 Jan 2007 12:30:44 -0500,
> > [EMAIL PROTECTED] wrote:
> > >
> > > > I'm working on this now and will doublecheck just in case my test was
> > > > flawed first time.
>
On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
The problem with your patch is that it breaks the structure newly
introduced. In the new tree, card* contains the whole belonging
devices, and each device points to the one in the card object.
Passing dev->parent there cuts the relation betwee
At Thu, 25 Jan 2007 13:34:19 -0500,
[EMAIL PROTECTED] wrote:
>
> On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> > The problem with your patch is that it breaks the structure newly
> > introduced. In the new tree, card* contains the whole belonging
> > devices, and each device points to
On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
> [This does beg the question: Does the benefit of this complete
> restructuring in a subminor release of an allegedly stable kernel
> outweigh the fact that it breaks all audio for any user running a
> gnome desktop?]
Well, that's not me who
On Thu, Jan 25, 2007 at 01:51:42PM -0500, [EMAIL PROTECTED] wrote:
> On 1/25/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> >> [This does beg the question: Does the benefit of this complete
> >> restructuring in a subminor release of an allegedly stable kernel
> >> outweigh the fact that it break
Basically, new distros can disable that option if their userspace can
handle the new structure of sysfs with the symlinks. Users of older
distros with newer kernels can enable the option and (hopefully) not
break anything.
I would like to register a general objection to a change of this size
'h
On Thu, Jan 25, 2007 at 03:40:06PM -0500, [EMAIL PROTECTED] wrote:
> >Basically, new distros can disable that option if their userspace can
> >handle the new structure of sysfs with the symlinks. Users of older
> >distros with newer kernels can enable the option and (hopefully) not
> >break anythi
On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
I want to do just a little more testing here (Takashi reminded me I
have a bit more testing of my own to do).
Can you give me the 'tree /sys/class/sound' output?
Once I verify it's 'all good' (actually, I'm stalling; not in front of
the machine wi
At Fri, 26 Jan 2007 05:53:36 -0500,
[EMAIL PROTECTED] wrote:
>
> On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > Is there anything else left to fix?
>
> Once that testing is done, no. But don't trust the two patches I sent
> yet, I'll resumbit the patch resulting from more thorough testing
Before I get to the less focused rant below, I wanted to mention that
the HELP text for 'Create deprecated sysfs files' does not make it
clear that one is opting for old in exclusion of new.
On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
There is no such thing as a "stable release update" serie
On Fri, Jan 26, 2007 at 12:40:31PM +0100, Takashi Iwai wrote:
> At Fri, 26 Jan 2007 05:53:36 -0500,
> [EMAIL PROTECTED] wrote:
> >
> > On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > Is there anything else left to fix?
> >
> > Once that testing is done, no. But don't trust the two patc
At Fri, 26 Jan 2007 10:04:57 -0800,
Greg KH wrote:
>
> On Fri, Jan 26, 2007 at 12:40:31PM +0100, Takashi Iwai wrote:
> > At Fri, 26 Jan 2007 05:53:36 -0500,
> > [EMAIL PROTECTED] wrote:
> > >
> > > On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > > Is there anything else left to fix?
>
Yes, working on testing all cases here, takes a while, kernel builds
are hella long on this machine.
Monty
-
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
Ple
On Fri, Jan 26, 2007 at 01:03:41PM -0500, [EMAIL PROTECTED] wrote:
> Before I get to the less focused rant below, I wanted to mention that
> the HELP text for 'Create deprecated sysfs files' does not make it
> clear that one is opting for old in exclusion of new.
Hm, can you think of some better w
On Fri, Jan 26, 2007 at 07:25:34PM +0100, Takashi Iwai wrote:
> Greg, feel free to pick it up to your tree for pushing. Since this
> patch conflicts with the development tree of ALSA mm branch, it'd be
> even harder to push from ALSA tree, unfortuantely...
>
> Of course, it'd be safer after conf
On 1/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
Ok, I'll do it through my trees, but I'll wait for Monty to finish
building and testing.
/me hands Monty a copy of distcc and ccache :)
More like a disk that isn't strangely crippled.
(This kernel isn't getting anywhere near the studly machines :
30 matches
Mail list logo
