Re: dell_rbtn - kernel panic at boot...

[Darren Hart]

On Wed, May 27, 2015 at 09:28:23AM +0200, Pali Rohár wrote:
> On Tuesday 26 May 2015 21:16:58 Darren Hart wrote:
> > On Mon, May 25, 2015 at 08:03:42AM +0200, Pali Rohár wrote:
> > > On Monday 25 May 2015 07:01:21 Matthew Garrett wrote:
> > > > On Sun, May 24, 2015 at 09:44:32PM -0700, Darren Hart wrote:
> > > > > Greg, Matthew, I'm tempted to recommend this 434 line driver be
> > > > > rolled into dell-laptop.c. Any strong opinions?
> > > > 
> > > > Mrm. It's slightly conceptually nasty in that one's an ACPI driver
> > > > and one's calling a Dell custom interface, but I think merging them
> > > > is probably the last bad answer.
> > > 
> > > I think merging does not fix our problem. dell laptop rfkill driver 
> > > needs to be initialized after dell-rbtn acpi driver register itself.
> > 
> > If they were the same driver, you could control this ordering.
> > 
> 
> Yes, I see, you are right. I can call acpi driver register function and
> after that initializing dell laptop rfkill code.
> 
> > > 
> > > And dell-laptop and dell-rbtn are two different devices (one dell smbios 
> > > and one acpi) and it for me it sounds like bad idea too...
> > 
> > We all agree it's a bad idea - the point Mathew and I made was it may be the
> > "least bad" idea (all the others may be worse).
> > 
> > I'm looking into this, but I don't have an easy answer for you. This one is
> > going to take some research on your part to get to the right answer.
> > 
> 
> I still think that changing module_init() could work... Do you know who
> can help us with those _ini*() macros (and ideally answer how to do that)?

You sent the patches implementing that, I'd suggest providing complete details
on what you tested to add confidence to this working.

Greg, on Cc, is likely the best one to say if this is a reasonable approach, or
an abuse of the *_init APIs. I suspect he'll say it's the a hack to workaround a
fundamentally flawed design.

I'd suggest spending some time thinking about how this could be written such
that the individual drivers do not talk back and forth to eachother, but instead
talk to a subsystem (rfkill?) in a way that can tolerate the ordering issue.

If you simply cannot reasonably avoid the ordering issue, then I suspect the
least bad approach is to merge the drivers.

Greg - from a general driver development best practices perspective, would you
disagree with anything I've said here?

Quick summary to save Greg the search: dell-laptop calls a function in
dell-rbtn. If both are built-in, if dell-rbtn hasn't completed init yet, the
dell-laptop init will crash.

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/