From: Bjorn Helgaas <helgaas@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: kelvin.cao@microchip.com, kurt.schwemmer@microsemi.com,
bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kelvincao@outlook.com
Subject: Re: [PATCH 0/5] Switchtec Fixes and Improvements
Date: Fri, 8 Oct 2021 13:25:24 -0500 [thread overview]
Message-ID: <20211008182524.GA1361129@bhelgaas> (raw)
In-Reply-To: <e60010f3-f803-e60b-3412-346ccc11a0fb@deltatee.com>
On Fri, Oct 08, 2021 at 11:23:46AM -0600, Logan Gunthorpe wrote:
> On 2021-10-08 11:05 a.m., Bjorn Helgaas wrote:
> > On Fri, Sep 24, 2021 at 11:08:37AM +0000, kelvin.cao@microchip.com wrote:
> >> From: Kelvin Cao <kelvin.cao@microchip.com>
> >>
> >> Hi,
> >>
> >> Please find a bunch of patches for the switchtec driver collected over the
> >> last few months.
> >
> > Question: Is there a reason this driver should be in drivers/pci/?
> >
> > It doesn't use any internal PCI core interfaces, e.g., it doesn't
> > include drivers/pci/pci.h, and AFAICT it's really just a driver for a
> > PCI device that happens to be a switch.
> >
> > I don't really *care* that it's in drivers/pci; I rely on Kurt and
> > Logan to review changes. The only problem it presents for me is that
> > I have to write merge commit logs for the changes. You'd think that
> > would be trivial, but since I don't know much about the driver, it
> > does end up being work for me.
>
> We did discuss this when it was originally merged.
Thanks, I thought I remembered talking about it, but didn't bother to
dig it up.
> The main reason we want it in the PCI tree is so that it's in a sensible
> spot in the Kconfig hierarchy (under PCI support). Seeing it is still
> PCI hardware. Dropping it into the miscellaneous devices mess (or
> similar) is less than desirable. Moreover, it's not like the maintainers
> for misc have any additional knowledge that would make them better
> qualified to merge these changes. In fact, I'm sure they'd have less
> knowledge and we wouldn't have gotten to the bottom of this last issue
> if it had been a different maintainer.
>
> In the future I'll try to be more careful in my reviews to ensure we
> have a better understanding and clearer commit messages. If there's
> anything else we can do to make your job easier, please let us know.
Oh, please don't take this as me complaining about anybody's reviews!
I honestly just look for your or Kurt's ack. I think I just need to
be a little less fixated on writing the merge commit logs :)
Bjorn
prev parent reply other threads:[~2021-10-08 18:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 11:08 [PATCH 0/5] Switchtec Fixes and Improvements kelvin.cao
2021-09-24 11:08 ` [PATCH 1/5] PCI/switchtec: Error out MRPC execution when no GAS access kelvin.cao
2021-10-01 20:18 ` Bjorn Helgaas
2021-10-01 20:29 ` Logan Gunthorpe
2021-10-01 23:49 ` Kelvin.Cao
2021-10-02 15:11 ` Bjorn Helgaas
2021-10-04 20:51 ` Kelvin.Cao
2021-10-05 20:11 ` Bjorn Helgaas
2021-10-06 0:37 ` Kelvin.Cao
2021-10-06 2:33 ` Bjorn Helgaas
2021-10-06 5:49 ` Kelvin.Cao
2021-10-06 14:19 ` Bjorn Helgaas
2021-10-06 19:00 ` Kelvin.Cao
2021-10-06 20:20 ` Bjorn Helgaas
2021-10-06 21:27 ` Kelvin.Cao
2021-10-07 21:23 ` Bjorn Helgaas
2021-10-08 0:06 ` Kelvin.Cao
2021-10-08 11:03 ` Bjorn Helgaas
2021-10-01 22:58 ` Kelvin.Cao
2021-10-01 23:52 ` Logan Gunthorpe
2021-10-02 0:05 ` Kelvin.Cao
2021-09-24 11:08 ` [PATCH 2/5] PCI/switchtec: Fix a MRPC error status handling issue kelvin.cao
2021-09-24 11:08 ` [PATCH 3/5] PCI/switchtec: Update the way of getting management VEP instance ID kelvin.cao
2021-09-24 11:08 ` [PATCH 4/5] PCI/switchtec: Replace ENOTSUPP with EOPNOTSUPP kelvin.cao
2021-09-24 11:08 ` [PATCH 5/5] PCI/switchtec: Add check of event support kelvin.cao
2021-09-24 15:53 ` [PATCH 0/5] Switchtec Fixes and Improvements Logan Gunthorpe
2021-09-25 5:27 ` Kelvin.Cao
2021-09-27 16:39 ` Bjorn Helgaas
2021-09-27 18:25 ` Kelvin.Cao
2021-10-08 17:05 ` Bjorn Helgaas
2021-10-08 17:23 ` Logan Gunthorpe
2021-10-08 18:25 ` Bjorn Helgaas [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=20211008182524.GA1361129@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=kelvin.cao@microchip.com \
--cc=kelvincao@outlook.com \
--cc=kurt.schwemmer@microsemi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.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).