On Mon, Jun 19, 2017 at 4:27 PM, Logan Gunthorpe wrote:
>
>
> On 19/06/17 02:07 PM, Jon Mason wrote:
>> I think this code is of quality enough to go from an RFC to a standard
>> patch, and we can nit pick it to death there ;-)
>
> Thanks!
>
>> Please rebase on ntb-next (which
On Mon, Jun 19, 2017 at 4:27 PM, Logan Gunthorpe wrote:
>
>
> On 19/06/17 02:07 PM, Jon Mason wrote:
>> I think this code is of quality enough to go from an RFC to a standard
>> patch, and we can nit pick it to death there ;-)
>
> Thanks!
>
>> Please rebase on ntb-next (which I believe you are
On 19/06/17 02:07 PM, Jon Mason wrote:
> I think this code is of quality enough to go from an RFC to a standard
> patch, and we can nit pick it to death there ;-)
Thanks!
> Please rebase on ntb-next (which I believe you are already doing), and
> resbutmit.
I'll try to get the rebase done and
On 19/06/17 02:07 PM, Jon Mason wrote:
> I think this code is of quality enough to go from an RFC to a standard
> patch, and we can nit pick it to death there ;-)
Thanks!
> Please rebase on ntb-next (which I believe you are already doing), and
> resbutmit.
I'll try to get the rebase done and
On Thu, Jun 15, 2017 at 02:37:16PM -0600, Logan Gunthorpe wrote:
> Hi,
>
> This patchset implements Non-Transparent Bridge (NTB) support for the
> Microsemi Switchtec series of switches. We're looking for some
> review from the community at this point but hope to get it upstreamed
> for v4.14.
>
On Thu, Jun 15, 2017 at 02:37:16PM -0600, Logan Gunthorpe wrote:
> Hi,
>
> This patchset implements Non-Transparent Bridge (NTB) support for the
> Microsemi Switchtec series of switches. We're looking for some
> review from the community at this point but hope to get it upstreamed
> for v4.14.
>
On Sat, Jun 17, 2017 at 07:09:59AM +0200, 'Greg Kroah-Hartman' wrote:
> On Fri, Jun 16, 2017 at 11:21:00PM +0300, Serge Semin wrote:
> > On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
> > wrote:
> > > Now, if you'd like to actually review the code I'd be happy to
On Sat, Jun 17, 2017 at 07:09:59AM +0200, 'Greg Kroah-Hartman' wrote:
> On Fri, Jun 16, 2017 at 11:21:00PM +0300, Serge Semin wrote:
> > On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
> > wrote:
> > > Now, if you'd like to actually review the code I'd be happy to address
> > > any
On 16/06/17 11:09 PM, 'Greg Kroah-Hartman' wrote:
> Ah, but the patchset does seem to properly formatted. At least it's
> easy for me to review as-published, while a much smaller number of
> patches, making much larger individual patches, would be much much
> harder to review.
>
> But what do
On 16/06/17 11:09 PM, 'Greg Kroah-Hartman' wrote:
> Ah, but the patchset does seem to properly formatted. At least it's
> easy for me to review as-published, while a much smaller number of
> patches, making much larger individual patches, would be much much
> harder to review.
>
> But what do
On 16/06/17 11:09 PM, 'Greg Kroah-Hartman' wrote:
> Ah, but the patchset does seem to properly formatted. At least it's
> easy for me to review as-published, while a much smaller number of
> patches, making much larger individual patches, would be much much
> harder to review.
>
> But what do
On 16/06/17 11:09 PM, 'Greg Kroah-Hartman' wrote:
> Ah, but the patchset does seem to properly formatted. At least it's
> easy for me to review as-published, while a much smaller number of
> patches, making much larger individual patches, would be much much
> harder to review.
>
> But what do
On Fri, Jun 16, 2017 at 11:21:00PM +0300, Serge Semin wrote:
> On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
> wrote:
> > Now, if you'd like to actually review the code I'd be happy to address
> > any concerns you find. I won't be responding to any more
On Fri, Jun 16, 2017 at 11:21:00PM +0300, Serge Semin wrote:
> On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
> wrote:
> > Now, if you'd like to actually review the code I'd be happy to address
> > any concerns you find. I won't be responding to any more philosophical
> > arguments or
On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 12:38 PM, Serge Semin wrote:
> > On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
> > wrote:
> > It's the way the NTB API was created for, to have set of
On Fri, Jun 16, 2017 at 01:34:59PM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 12:38 PM, Serge Semin wrote:
> > On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
> > wrote:
> > It's the way the NTB API was created for, to have set of functions to access
> > NTB devices in the
On 16/06/17 12:38 PM, Serge Semin wrote:
> On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
> wrote:
> It's the way the NTB API was created for, to have set of functions to access
> NTB devices in the similar way. These aren't my beliefs, it's the way it was
>
On 16/06/17 12:38 PM, Serge Semin wrote:
> On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
> wrote:
> It's the way the NTB API was created for, to have set of functions to access
> NTB devices in the similar way. These aren't my beliefs, it's the way it was
> created. I agree it can
On 16/06/17 12:08 PM, Allen Hubbe wrote:
> Alright. I'll leave it to you to find and reconcile common functionalities
> of the drivers. What about making spad emulation optional?
Ok.
I don't see the point of making spad emulation optional. Who would want
to disable it and what would be the
On 16/06/17 12:08 PM, Allen Hubbe wrote:
> Alright. I'll leave it to you to find and reconcile common functionalities
> of the drivers. What about making spad emulation optional?
Ok.
I don't see the point of making spad emulation optional. Who would want
to disable it and what would be the
On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 10:33 AM, Serge Semin wrote:
> > New NTB API is going to be merged to mainline kernel within next features
> > merge window, so it's really recommended to use that API for new hardware.
> >
On Fri, Jun 16, 2017 at 11:08:52AM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 10:33 AM, Serge Semin wrote:
> > New NTB API is going to be merged to mainline kernel within next features
> > merge window, so it's really recommended to use that API for new hardware.
> > Could you please
From: Logan Gunthorpe
> On 16/06/17 09:34 AM, Allen Hubbe wrote:
> > In code review, I really only have found minor nits. Overall, the driver
> > looks good.
>
> Great, thanks for such a quick review!
>
> > In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms).
> > This looks
From: Logan Gunthorpe
> On 16/06/17 09:34 AM, Allen Hubbe wrote:
> > In code review, I really only have found minor nits. Overall, the driver
> > looks good.
>
> Great, thanks for such a quick review!
>
> > In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms).
> > This looks
On Fri, Jun 16, 2017 at 10:47:21AM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 09:34 AM, Allen Hubbe wrote:
> > In code review, I really only have found minor nits. Overall, the driver
> > looks good.
>
> Great, thanks for such a quick review!
>
> > In
On Fri, Jun 16, 2017 at 10:47:21AM -0600, Logan Gunthorpe
wrote:
>
>
> On 16/06/17 09:34 AM, Allen Hubbe wrote:
> > In code review, I really only have found minor nits. Overall, the driver
> > looks good.
>
> Great, thanks for such a quick review!
>
> > In switchtec_ntb_part_op, there is a
On 16/06/17 10:33 AM, Serge Semin wrote:
> New NTB API is going to be merged to mainline kernel within next features
> merge window, so it's really recommended to use that API for new hardware.
> Could you please rabase your driver on top of the tree?
> https://github.com/jonmason/ntb.git
Yes,
On 16/06/17 10:33 AM, Serge Semin wrote:
> New NTB API is going to be merged to mainline kernel within next features
> merge window, so it's really recommended to use that API for new hardware.
> Could you please rabase your driver on top of the tree?
> https://github.com/jonmason/ntb.git
Yes,
On 16/06/17 09:34 AM, Allen Hubbe wrote:
> In code review, I really only have found minor nits. Overall, the driver
> looks good.
Great, thanks for such a quick review!
> In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms). This
> looks like a thread context, so it could
On 16/06/17 09:34 AM, Allen Hubbe wrote:
> In code review, I really only have found minor nits. Overall, the driver
> looks good.
Great, thanks for such a quick review!
> In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms). This
> looks like a thread context, so it could
Hello Logan.
Thanks for the new hardware driver. It's really great to see NTB subsystem
being developed.
New NTB API is going to be merged to mainline kernel within next features
merge window, so it's really recommended to use that API for new hardware.
Could you please rabase your driver on top
Hello Logan.
Thanks for the new hardware driver. It's really great to see NTB subsystem
being developed.
New NTB API is going to be merged to mainline kernel within next features
merge window, so it's really recommended to use that API for new hardware.
Could you please rabase your driver on top
From: Logan Gunthorpe
> On 16/06/17 07:53 AM, Allen Hubbe wrote:
> > See what is staged in https://github.com/jonmason/ntb.git ntb-next, with
> > the addition of multi-peer
> support by Serge. It would be good at this stage to understand whether the
> api changes there would
> also support the
From: Logan Gunthorpe
> On 16/06/17 07:53 AM, Allen Hubbe wrote:
> > See what is staged in https://github.com/jonmason/ntb.git ntb-next, with
> > the addition of multi-peer
> support by Serge. It would be good at this stage to understand whether the
> api changes there would
> also support the
On 16/06/17 07:53 AM, Allen Hubbe wrote:
> See what is staged in https://github.com/jonmason/ntb.git ntb-next, with the
> addition of multi-peer support by Serge. It would be good at this stage to
> understand whether the api changes there would also support the Switchtec
> driver, and what
On 16/06/17 07:53 AM, Allen Hubbe wrote:
> See what is staged in https://github.com/jonmason/ntb.git ntb-next, with the
> addition of multi-peer support by Serge. It would be good at this stage to
> understand whether the api changes there would also support the Switchtec
> driver, and what
From: Logan Gunthorpe
> Hi,
>
> This patchset implements Non-Transparent Bridge (NTB) support for the
> Microsemi Switchtec series of switches. We're looking for some
> review from the community at this point but hope to get it upstreamed
> for v4.14.
>
> Switchtec NTB support is configured over
From: Logan Gunthorpe
> Hi,
>
> This patchset implements Non-Transparent Bridge (NTB) support for the
> Microsemi Switchtec series of switches. We're looking for some
> review from the community at this point but hope to get it upstreamed
> for v4.14.
>
> Switchtec NTB support is configured over
Hi,
This patchset implements Non-Transparent Bridge (NTB) support for the
Microsemi Switchtec series of switches. We're looking for some
review from the community at this point but hope to get it upstreamed
for v4.14.
Switchtec NTB support is configured over the same function and bar
as the
Hi,
This patchset implements Non-Transparent Bridge (NTB) support for the
Microsemi Switchtec series of switches. We're looking for some
review from the community at this point but hope to get it upstreamed
for v4.14.
Switchtec NTB support is configured over the same function and bar
as the
40 matches
Mail list logo