linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Denis Efremov <efremov@linux.com>,
	sathyanarayanan kuppuswamy 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/4] Simplify PCIe hotplug indicator control
Date: Wed, 28 Aug 2019 05:33:09 +0200	[thread overview]
Message-ID: <20190828033309.e65mmunihlyrzzgz@wunner.de> (raw)
In-Reply-To: <20190827225319.GE9987@google.com>

On Tue, Aug 27, 2019 at 05:53:19PM -0500, Bjorn Helgaas wrote:
> Unrelated, but if anybody is looking at pciehp, is there value in
> having pciehp split across five files?
> 
>   drivers/pci/hotplug/pciehp.h
>   drivers/pci/hotplug/pciehp_core.c
>   drivers/pci/hotplug/pciehp_ctrl.c
>   drivers/pci/hotplug/pciehp_hpc.c
>   drivers/pci/hotplug/pciehp_pci.c
> 
> To me, it just makes things harder because when I'm browsing for
> something in pciehp and I don't know the exact name of it, I have to
> guess which file it's in, and I'm invariably wrong.
> 
> It seems like it would be much simpler if everything were in a single
> pciehp.c file.  Then we could also get rid of the header and make
> several more things static.

I wouldn't go so far as to say there's *value* in the split.

It's a historic artefact, it's been like that since pciehp was
introduced back in 2004:
https://git.kernel.org/tglx/history/c/c16b4b14d980

I was hesitant to change it so far, in particular because it makes
it harder to backport stable patches.

That said, I did think about rearranging things to reduce the number
of files and non-static declarations or to give the files better names.
I wasn't thinking of squashing everything into one file, it would
probably be quite large and not make things simpler.

The general logic is that everything touching the registers is in
pciehp_hpc.c.  You won't (or shouldn't) find register access in any
of the other files.

pciehp_ctrl.c is the control logic, reaction to events, etc.
Though portions of the control logic are also in pciehp_hpc.c,
in particular the interrupt servicing.

pciehp_core.c contains the interface to the PCI hotplug core and
the probe/remove/PM routines.

pciehp_pci.c contains bringup/teardown of the slot.

One thing that I think deserves changing is this comment at the
top of each file:

"Send feedback to <greg@kroah.com>, <kristen.c.accardi@intel.com>"

We now use MAINTAINERS to do this.  Kristen took over maintainership
in 2005 with commit 8cf4c19523b7 but by 2009 she had stepped down per
commit be3652b8a253.  So providing her address is no longer accurate.
And I imagine Greg is no longer as familiar with the driver as it has
changed considerably since 2004.  He'd probably have to defer to others
who have done work on it recently (such as me).

Thanks,

Lukas

      reply	other threads:[~2019-08-28  3:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 16:06 [PATCH v3 0/4] Simplify PCIe hotplug indicator control Denis Efremov
2019-08-19 16:06 ` [PATCH v3 1/4] PCI: pciehp: Add pciehp_set_indicators() to jointly set LED indicators Denis Efremov
2019-08-19 16:16   ` Denis Efremov
2019-08-27 23:24     ` Oliver O'Halloran
2019-08-21 23:58   ` Kuppuswamy Sathyanarayanan
2019-08-27 23:41   ` Oliver O'Halloran
2019-08-19 16:06 ` [PATCH v3 2/4] PCI: pciehp: Switch LED indicators with a single write Denis Efremov
2019-08-27 22:36   ` Kuppuswamy Sathyanarayanan
2019-08-19 16:06 ` [PATCH v3 3/4] PCI: pciehp: Remove pciehp_set_attention_status() Denis Efremov
2019-08-27 22:47   ` Kuppuswamy Sathyanarayanan
2019-08-19 16:06 ` [PATCH v3 4/4] PCI: pciehp: Remove pciehp_green_led_{on,off,blink}() Denis Efremov
2019-08-27 22:49   ` Kuppuswamy Sathyanarayanan
2019-08-27 23:49   ` Oliver O'Halloran
2019-08-20 12:16 ` [PATCH v3 0/4] Simplify PCIe hotplug indicator control Denis Efremov
2019-08-27 22:32   ` Bjorn Helgaas
2019-08-27 22:50     ` Kuppuswamy Sathyanarayanan
2019-08-27 22:53     ` Bjorn Helgaas
2019-08-28  3:33       ` Lukas Wunner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190828033309.e65mmunihlyrzzgz@wunner.de \
    --to=lukas@wunner.de \
    --cc=efremov@linux.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).