Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1583726 > unrolled thread

Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver

Started byLogan Gunthorpe <logang@deltatee.com>
First post2017-02-17 21:50 +0100
Last post2017-02-23 23:20 +0100
Articles 7 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Logan Gunthorpe <logang@deltatee.com> - 2017-02-17 21:50 +0100
    Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Logan Gunthorpe <logang@deltatee.com> - 2017-02-23 21:40 +0100
      Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-23 22:00 +0100
      Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Sinan Kaya <okaya@codeaurora.org> - 2017-02-23 22:00 +0100
        Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Logan Gunthorpe <logang@deltatee.com> - 2017-02-23 22:50 +0100
      Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Bjorn Helgaas <helgaas@kernel.org> - 2017-02-23 23:20 +0100
        Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver Logan Gunthorpe <logang@deltatee.com> - 2017-02-23 23:20 +0100

#1583726 — Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver

FromLogan Gunthorpe <logang@deltatee.com>
Date2017-02-17 21:50 +0100
SubjectRe: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver
Message-ID<tbXDA-DC-7@gated-at.bofh.it>
Hi Bjorn,

Can you give us an idea of when you might be able to comment on our
patchset? We've addressed all the outstanding issues and have a couple
of reviewed and tested tags. So we'd like to see this move forward as
soon as possible.

I can do a respin with the tags collected or address any concerns you
may have, just please let us know.

Thanks,

Logan

On 02/02/17 11:05 AM, Logan Gunthorpe wrote:
> Changes since v1:
> 
> * Rebased onto 4.10-rc6 (cleanly)
> * Split the patch into a few more easily digestible patches (as
>   suggested by Greg Kroah-Hartman)
> * Folded switchtec.c into switchtec.h (per Greg)
> * Fixed a bunch of 32bit build warnings caught by the kbuild test robot
> * Fixed some issues in the documentation so it has a proper
>   reStructredText format (as noted by Jonathan Corbet)
> * Fixed padding and sizes in the IOCTL structures as noticed by Emil
>   Velikov and used pahole to verify their consistency across 32 and 64
>   bit builds
> * Reworked one of the IOCTL interfaces to be more future proof (per
>   Emil).
> 
> Changes since RFC:
> 
> * Fixed incorrect use of the drive model as pointed out by Greg
>   Kroah-Hartman
> * Used devm functions as suggested by Keith Busch
> * Added a handful of sysfs attributes to the switchtec class
> * Added a handful of IOCTLs to the switchtec device
> * A number of miscellaneous bug fixes
> 
> --
> 
> Hi,
> 
> This is a continuation of the RFC we posted lasted month [1] which
> proposes a management driver for Microsemi's Switchtec line of PCI
> switches. This hardware is still looking to be used in the Open
> Compute Platform
> 
> To make this entirely clear: the Switchtec products are compliant
> with the PCI specifications and are supported today with the standard
> in-kernel driver. However, these devices also expose a management endpoint
> on a separate PCI function address which can be used to perform some
> advanced operations. This is a driver for that function. See the patch
> for more information.
> 
> Since the RFC, we've made the changes requested by Greg Kroah-Hartman
> and Keith Busch, and we've also fleshed out a number of features. We've
> added a couple of IOCTLs and sysfs attributes which are documented in
> the patch. Significant work has also been done on the userspace tool
> which is available under a GPL license at [2]. We've also had testing
> done by some of the interested parties.
> 
> We hope to see this work included in either 4.11 or 4.12 assuming a
> smooth review process.
> 
> The patch is based off of the v4.10-rc6 release.
> 
> Thanks for your review,
> 
> Logan
> 
> [1] https://www.spinics.net/lists/linux-pci/msg56897.html
> [2] https://github.com/sbates130272/switchtec-user
> 
> --
> 
> Logan Gunthorpe (4):
>   MicroSemi Switchtec management interface driver
>   switchtec: Add user interface documentation
>   switchtec: Add sysfs attributes to the Switchtec driver
>   switchtec: Add IOCTLs to the Switchtec driver
> 
>  Documentation/ABI/testing/sysfs-class-switchtec |   96 ++
>  Documentation/ioctl/ioctl-number.txt            |    1 +
>  Documentation/switchtec.txt                     |   80 ++
>  MAINTAINERS                                     |   11 +
>  drivers/pci/Kconfig                             |    1 +
>  drivers/pci/Makefile                            |    1 +
>  drivers/pci/switch/Kconfig                      |   13 +
>  drivers/pci/switch/Makefile                     |    1 +
>  drivers/pci/switch/switchtec.c                  | 1608 +++++++++++++++++++++++
>  include/uapi/linux/switchtec_ioctl.h            |  132 ++
>  10 files changed, 1944 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec
>  create mode 100644 Documentation/switchtec.txt
>  create mode 100644 drivers/pci/switch/Kconfig
>  create mode 100644 drivers/pci/switch/Makefile
>  create mode 100644 drivers/pci/switch/switchtec.c
>  create mode 100644 include/uapi/linux/switchtec_ioctl.h
> 
> --
> 2.1.4
> 

[toc] | [next] | [standalone]


#1587115

FromLogan Gunthorpe <logang@deltatee.com>
Date2017-02-23 21:40 +0100
Message-ID<te8lc-6kY-9@gated-at.bofh.it>
In reply to#1583726
Hello,

We're still waiting on any kind of response from Bjorn. (If you're
listening please say something!)

Does anyone have any suggestions for dealing with an unresponsive
maintainer? Or a way for us to move forward with this quickly and get it
merged?

ie. Can anyone else pick this up through another route? In the end, it's
just a fairly basic driver and doesn't touch any core PCI functionality
and we've had a fair amount of review from other kernel contributors,
all of which we've addressed.

Thanks,

Logan




On 17/02/17 01:36 PM, Logan Gunthorpe wrote:
> Hi Bjorn,
> 
> Can you give us an idea of when you might be able to comment on our
> patchset? We've addressed all the outstanding issues and have a couple
> of reviewed and tested tags. So we'd like to see this move forward as
> soon as possible.
> 
> I can do a respin with the tags collected or address any concerns you
> may have, just please let us know.
> 
> Thanks,
> 
> Logan
> 
> On 02/02/17 11:05 AM, Logan Gunthorpe wrote:
>> Changes since v1:
>>
>> * Rebased onto 4.10-rc6 (cleanly)
>> * Split the patch into a few more easily digestible patches (as
>>   suggested by Greg Kroah-Hartman)
>> * Folded switchtec.c into switchtec.h (per Greg)
>> * Fixed a bunch of 32bit build warnings caught by the kbuild test robot
>> * Fixed some issues in the documentation so it has a proper
>>   reStructredText format (as noted by Jonathan Corbet)
>> * Fixed padding and sizes in the IOCTL structures as noticed by Emil
>>   Velikov and used pahole to verify their consistency across 32 and 64
>>   bit builds
>> * Reworked one of the IOCTL interfaces to be more future proof (per
>>   Emil).
>>
>> Changes since RFC:
>>
>> * Fixed incorrect use of the drive model as pointed out by Greg
>>   Kroah-Hartman
>> * Used devm functions as suggested by Keith Busch
>> * Added a handful of sysfs attributes to the switchtec class
>> * Added a handful of IOCTLs to the switchtec device
>> * A number of miscellaneous bug fixes
>>
>> --
>>
>> Hi,
>>
>> This is a continuation of the RFC we posted lasted month [1] which
>> proposes a management driver for Microsemi's Switchtec line of PCI
>> switches. This hardware is still looking to be used in the Open
>> Compute Platform
>>
>> To make this entirely clear: the Switchtec products are compliant
>> with the PCI specifications and are supported today with the standard
>> in-kernel driver. However, these devices also expose a management endpoint
>> on a separate PCI function address which can be used to perform some
>> advanced operations. This is a driver for that function. See the patch
>> for more information.
>>
>> Since the RFC, we've made the changes requested by Greg Kroah-Hartman
>> and Keith Busch, and we've also fleshed out a number of features. We've
>> added a couple of IOCTLs and sysfs attributes which are documented in
>> the patch. Significant work has also been done on the userspace tool
>> which is available under a GPL license at [2]. We've also had testing
>> done by some of the interested parties.
>>
>> We hope to see this work included in either 4.11 or 4.12 assuming a
>> smooth review process.
>>
>> The patch is based off of the v4.10-rc6 release.
>>
>> Thanks for your review,
>>
>> Logan
>>
>> [1] https://www.spinics.net/lists/linux-pci/msg56897.html
>> [2] https://github.com/sbates130272/switchtec-user
>>
>> --
>>
>> Logan Gunthorpe (4):
>>   MicroSemi Switchtec management interface driver
>>   switchtec: Add user interface documentation
>>   switchtec: Add sysfs attributes to the Switchtec driver
>>   switchtec: Add IOCTLs to the Switchtec driver
>>
>>  Documentation/ABI/testing/sysfs-class-switchtec |   96 ++
>>  Documentation/ioctl/ioctl-number.txt            |    1 +
>>  Documentation/switchtec.txt                     |   80 ++
>>  MAINTAINERS                                     |   11 +
>>  drivers/pci/Kconfig                             |    1 +
>>  drivers/pci/Makefile                            |    1 +
>>  drivers/pci/switch/Kconfig                      |   13 +
>>  drivers/pci/switch/Makefile                     |    1 +
>>  drivers/pci/switch/switchtec.c                  | 1608 +++++++++++++++++++++++
>>  include/uapi/linux/switchtec_ioctl.h            |  132 ++
>>  10 files changed, 1944 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec
>>  create mode 100644 Documentation/switchtec.txt
>>  create mode 100644 drivers/pci/switch/Kconfig
>>  create mode 100644 drivers/pci/switch/Makefile
>>  create mode 100644 drivers/pci/switch/switchtec.c
>>  create mode 100644 include/uapi/linux/switchtec_ioctl.h
>>
>> --
>> 2.1.4
>>

[toc] | [prev] | [next] | [standalone]


#1587120

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-02-23 22:00 +0100
Message-ID<te8Ey-6rD-21@gated-at.bofh.it>
In reply to#1587115
On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote:
> Hello,
> 
> We're still waiting on any kind of response from Bjorn. (If you're
> listening please say something!)
> 
> Does anyone have any suggestions for dealing with an unresponsive
> maintainer? Or a way for us to move forward with this quickly and get it
> merged?

It's the middle of the merge window, nothing new can go in right now.
Wait until after 4.11-rc1 comes out before expecting for maintainers to
be able to start reviewing and discussing new things like this.

patience please,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1587122

FromSinan Kaya <okaya@codeaurora.org>
Date2017-02-23 22:00 +0100
Message-ID<te8Ey-6rD-19@gated-at.bofh.it>
In reply to#1587115
On 2/23/2017 3:36 PM, Logan Gunthorpe wrote:
> We're still waiting on any kind of response from Bjorn. (If you're
> listening please say something!)
> 
> Does anyone have any suggestions for dealing with an unresponsive
> maintainer? Or a way for us to move forward with this quickly and get it
> merged?

You'll want to be careful during the merge window (these days) as the
maintainer is usually busy with code delivery. You can't rush your code in at
the last minute.

[GIT PULL] PCI changes for v4.11]

Here is a list of all the patches waiting to be reviewed. 

https://patchwork.ozlabs.org/project/linux-pci/list/

You'll just have to wait your turn.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[toc] | [prev] | [next] | [standalone]


#1587131

FromLogan Gunthorpe <logang@deltatee.com>
Date2017-02-23 22:50 +0100
Message-ID<te9qW-6Yl-13@gated-at.bofh.it>
In reply to#1587122

On 23/02/17 01:51 PM, Sinan Kaya wrote:
> You'll want to be careful during the merge window (these days) as the
> maintainer is usually busy with code delivery. You can't rush your code in at
> the last minute.

Thanks for the advice, we will continue to wait.

However, I would say we've been very patient. It's been three weeks
since we posted the latest revision, a month since the first version and
almost 3 months since our RFC. I don't think it's too much to expect at
least a response saying that it's in the works or something. That long
with dead silence from the maintainer is a bit much.

Logan

[toc] | [prev] | [next] | [standalone]


#1587140

FromBjorn Helgaas <helgaas@kernel.org>
Date2017-02-23 23:20 +0100
Message-ID<te9TX-7sz-11@gated-at.bofh.it>
In reply to#1587115
On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote:
> Hello,
> 
> We're still waiting on any kind of response from Bjorn. (If you're
> listening please say something!)
> 
> Does anyone have any suggestions for dealing with an unresponsive
> maintainer? Or a way for us to move forward with this quickly and get it
> merged?

I try to deal with regressions first and other bug fixes second.
After that, I look at things that add new functionality.  I try to
look at the new stuff in roughly chronological order, as you would see
here:

https://patchwork.ozlabs.org/project/linux-pci/list/?order=date&page=1

If other folks have feedback, as they did on your 12/17, 1/31, and
even the 2/2 posting, I generally let that get sorted out before I
look at it.  I apologize that I haven't responded to your queries
about posting a v3 vs updating v2.

To answer that question, it's much simpler for me to deal with a
fresh, clean new series than it is to tweak things in an
already-posted series, partly because a series with discussion other
than simple acks and reviewed-bys looks more like work-in-progress.

Bjorn

[toc] | [prev] | [next] | [standalone]


#1587141

FromLogan Gunthorpe <logang@deltatee.com>
Date2017-02-23 23:20 +0100
Message-ID<te9TY-7sz-29@gated-at.bofh.it>
In reply to#1587140
Thanks Bjorn! I understand your busy and we appreciate your time in this
matter.

I'll prepare a v3 with a collected set of tags shortly. We're more than
happy to clean this up to make your job as easy as possible. We were
just looking for direction in how to move this forward.

Logan

On 23/02/17 03:14 PM, Bjorn Helgaas wrote:
> On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote:
>> Hello,
>>
>> We're still waiting on any kind of response from Bjorn. (If you're
>> listening please say something!)
>>
>> Does anyone have any suggestions for dealing with an unresponsive
>> maintainer? Or a way for us to move forward with this quickly and get it
>> merged?
> 
> I try to deal with regressions first and other bug fixes second.
> After that, I look at things that add new functionality.  I try to
> look at the new stuff in roughly chronological order, as you would see
> here:
> 
> https://patchwork.ozlabs.org/project/linux-pci/list/?order=date&page=1
> 
> If other folks have feedback, as they did on your 12/17, 1/31, and
> even the 2/2 posting, I generally let that get sorted out before I
> look at it.  I apologize that I haven't responded to your queries
> about posting a v3 vs updating v2.
> 
> To answer that question, it's much simpler for me to deal with a
> fresh, clean new series than it is to tweak things in an
> already-posted series, partly because a series with discussion other
> than simple acks and reviewed-bys looks more like work-in-progress.
> 
> Bjorn
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web