could the [x86] Kconfig content for PCI be cleaned up at all?

could the [x86] Kconfig content for PCI be cleaned up at all?

[Robert P. J. Day]

  digging through the current PCI code and Kconfig files and it seems
like some of that could be made simpler, but i'm willing to be
convinced otherwise.

  first, from arch/x86/Kconfig, rather than simply sourcing the file
"drivers/pci/Kconfig" (as is done with many other drivers
directories), that Kconfig file defines:

  menu "Bus options (PCI etc.)"

  config PCI
        bool "PCI support"
        default y
  ... snip ...

and later on, sources the Kconfig files for PCI and PCIe individually:

  source "drivers/pci/pcie/Kconfig"

  source "drivers/pci/Kconfig"

and even further down, finally sources the file for PCI hotplug after
PCMCIA:

  source "drivers/pcmcia/Kconfig"

  source "drivers/pci/hotplug/Kconfig"

given the dependencies, could all of this not be encapsulated in the
top-level Kconfig files under drivers/pci?

  next, in drivers/Makefile, pci code is pulled in with the single
statement:

  obj-$(CONFIG_PCI)               += pci/

given that, can't one drop all the "depends on PCI" directives from
the file drivers/pci/Kconfig? or just wrap the whole file in a "if
PCI" test? (unless there's something i'm missing here.)

  and could the same thing not be said for the pcie/ subdirectory?
drivers/pci/Makefile contains the line:

  obj-$(CONFIG_PCIEPORTBUS) += pcie/

with the dependency in drivers/pci/pcie/Kconfig:

  config PCIEPORTBUS
        bool "PCI Express Port Bus support"
        depends on PCI

suggesting that drivers/pci/pcie/Kconfig could also be simplified
quite a bit by dropping redundant dependency directives.

  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: could the [x86] Kconfig content for PCI be cleaned up at all?

[Bjorn Helgaas]

On Sat, May 17, 2014 at 5:29 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   digging through the current PCI code and Kconfig files and it seems
> like some of that could be made simpler, but i'm willing to be
> convinced otherwise.

I'm sure it could be cleaned up, and it would be great if you did!

I don't know the reason why all the arches source
drivers/pci/pcie/Kconfig directly; it seems like that should be done
from drivers/pci/Kconfig.

>   first, from arch/x86/Kconfig, rather than simply sourcing the file
> "drivers/pci/Kconfig" (as is done with many other drivers
> directories), that Kconfig file defines:
>
>   menu "Bus options (PCI etc.)"
>
>   config PCI
>         bool "PCI support"
>         default y
>   ... snip ...
>
> and later on, sources the Kconfig files for PCI and PCIe individually:
>
>   source "drivers/pci/pcie/Kconfig"
>
>   source "drivers/pci/Kconfig"
>
> and even further down, finally sources the file for PCI hotplug after
> PCMCIA:
>
>   source "drivers/pcmcia/Kconfig"
>
>   source "drivers/pci/hotplug/Kconfig"
>
> given the dependencies, could all of this not be encapsulated in the
> top-level Kconfig files under drivers/pci?
>
>   next, in drivers/Makefile, pci code is pulled in with the single
> statement:
>
>   obj-$(CONFIG_PCI)               += pci/
>
> given that, can't one drop all the "depends on PCI" directives from
> the file drivers/pci/Kconfig? or just wrap the whole file in a "if
> PCI" test? (unless there's something i'm missing here.)
>
>   and could the same thing not be said for the pcie/ subdirectory?
> drivers/pci/Makefile contains the line:
>
>   obj-$(CONFIG_PCIEPORTBUS) += pcie/
>
> with the dependency in drivers/pci/pcie/Kconfig:
>
>   config PCIEPORTBUS
>         bool "PCI Express Port Bus support"
>         depends on PCI
>
> suggesting that drivers/pci/pcie/Kconfig could also be simplified
> quite a bit by dropping redundant dependency directives.
>
>   thoughts?

I don't know all the history behind what we have now, so I can't give
you much advice.  I think you just have to work through the process of
simplifying things and see whether it turns out to be feasible.

Bjorn

Re: could the [x86] Kconfig content for PCI be cleaned up at all?

[Robert P. J. Day]

On Sat, 17 May 2014, Bjorn Helgaas wrote:

> On Sat, May 17, 2014 at 5:29 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >   digging through the current PCI code and Kconfig files and it
> > seems like some of that could be made simpler, but i'm willing to
> > be convinced otherwise.
>
> I'm sure it could be cleaned up, and it would be great if you did!
>
> I don't know the reason why all the arches source
> drivers/pci/pcie/Kconfig directly; it seems like that should be done
> from drivers/pci/Kconfig.

  that's what i thought, but i'll look more closely to see if there's
some subtlety there.

  at the very least, i can submit a patch for both:

  * .../pci/Kconfig
  * .../pci/pcie/Kconfig

that removes all the extraneous dependencies on PCI and PCIEPORTBUS,
respectively, and just wraps the files in a single "if" condition,
unless someone has a reason why that wouldn't work.  you know, along
the lines of acpi/Kconfig and many others:

  menuconfig ACPI
        bool "ACPI (Advanced Configuration and Power Interface) Support"
        ... snip ...

  if ACPI
        ... big snip, entire rest of file ...
  endif # ACPI

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: could the [x86] Kconfig content for PCI be cleaned up at all?

[Robert P. J. Day]

On Sat, 17 May 2014, Bjorn Helgaas wrote:

> On Sat, May 17, 2014 at 5:29 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >   digging through the current PCI code and Kconfig files and it seems
> > like some of that could be made simpler, but i'm willing to be
> > convinced otherwise.
>
> I'm sure it could be cleaned up, and it would be great if you did!
>
> I don't know the reason why all the arches source
> drivers/pci/pcie/Kconfig directly; it seems like that should be done
> from drivers/pci/Kconfig.
>
> >   first, from arch/x86/Kconfig, rather than simply sourcing the file
> > "drivers/pci/Kconfig" (as is done with many other drivers
> > directories), that Kconfig file defines:
> >
> >   menu "Bus options (PCI etc.)"
> >
> >   config PCI
> >         bool "PCI support"
> >         default y
> >   ... snip ...
> >
> > and later on, sources the Kconfig files for PCI and PCIe individually:
> >
> >   source "drivers/pci/pcie/Kconfig"
> >
> >   source "drivers/pci/Kconfig"
> >
> > and even further down, finally sources the file for PCI hotplug after
> > PCMCIA:
> >
> >   source "drivers/pcmcia/Kconfig"
> >
> >   source "drivers/pci/hotplug/Kconfig"

   ... snip ...

> I don't know all the history behind what we have now, so I can't
> give you much advice.  I think you just have to work through the
> process of simplifying things and see whether it turns out to be
> feasible.

  one of the quirky features of the current Kconfig layout is that, in
some arch Kconfig files, the main PCI content is included, then
pcmcia, *then* PCI hotplug, which means that when you pop into
something like "make menuconfig" and wander over to the PCI menu, you
see the majority of PCI selections, then the selection for PCCard, and
*then* the choice for PCI hotplug, which strikes me as just, well, odd
and confusing since, if you deselect PCI entirely, almost everything
goes away except for (you guessed it) PCCard. (and that framebuffer
selection as well.)

  as you say, there may be some historical inertia as to why things
were done this way, but is there any *technical* reason why everything
PCI-related can't just hang off of the drivers/pci/ directory via a
single "source" directive?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: could the [x86] Kconfig content for PCI be cleaned up at all?

[Bjorn Helgaas]

On Mon, May 19, 2014 at 12:59 AM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
> On Sat, 17 May 2014, Bjorn Helgaas wrote:
>
>> On Sat, May 17, 2014 at 5:29 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> >
>> >   digging through the current PCI code and Kconfig files and it seems
>> > like some of that could be made simpler, but i'm willing to be
>> > convinced otherwise.
>>
>> I'm sure it could be cleaned up, and it would be great if you did!
>>
>> I don't know the reason why all the arches source
>> drivers/pci/pcie/Kconfig directly; it seems like that should be done
>> from drivers/pci/Kconfig.
>>
>> >   first, from arch/x86/Kconfig, rather than simply sourcing the file
>> > "drivers/pci/Kconfig" (as is done with many other drivers
>> > directories), that Kconfig file defines:
>> >
>> >   menu "Bus options (PCI etc.)"
>> >
>> >   config PCI
>> >         bool "PCI support"
>> >         default y
>> >   ... snip ...
>> >
>> > and later on, sources the Kconfig files for PCI and PCIe individually:
>> >
>> >   source "drivers/pci/pcie/Kconfig"
>> >
>> >   source "drivers/pci/Kconfig"
>> >
>> > and even further down, finally sources the file for PCI hotplug after
>> > PCMCIA:
>> >
>> >   source "drivers/pcmcia/Kconfig"
>> >
>> >   source "drivers/pci/hotplug/Kconfig"
>
>    ... snip ...
>
>> I don't know all the history behind what we have now, so I can't
>> give you much advice.  I think you just have to work through the
>> process of simplifying things and see whether it turns out to be
>> feasible.
>
>   one of the quirky features of the current Kconfig layout is that, in
> some arch Kconfig files, the main PCI content is included, then
> pcmcia, *then* PCI hotplug, which means that when you pop into
> something like "make menuconfig" and wander over to the PCI menu, you
> see the majority of PCI selections, then the selection for PCCard, and
> *then* the choice for PCI hotplug, which strikes me as just, well, odd
> and confusing since, if you deselect PCI entirely, almost everything
> goes away except for (you guessed it) PCCard. (and that framebuffer
> selection as well.)
>
>   as you say, there may be some historical inertia as to why things
> were done this way, but is there any *technical* reason why everything
> PCI-related can't just hang off of the drivers/pci/ directory via a
> single "source" directive?

Not that I'm aware of.  Give it a try and we'll see what happens.

Bjorn