On 2 February 2017 at 16:37, Logan Gunthorpe wrote:
>
>
> On 01/02/17 05:10 AM, Emil Velikov wrote:
>> You can keep it roughly as-is if you're ~reasonably certain one won't
>> change it in the future.
>
> I've made the change anyway. I think it's better now.
>
>> Some teams
On 2 February 2017 at 16:37, Logan Gunthorpe wrote:
>
>
> On 01/02/17 05:10 AM, Emil Velikov wrote:
>> You can keep it roughly as-is if you're ~reasonably certain one won't
>> change it in the future.
>
> I've made the change anyway. I think it's better now.
>
>> Some teams frown upon adding new
On 01/02/17 05:10 AM, Emil Velikov wrote:
> You can keep it roughly as-is if you're ~reasonably certain one won't
> change it in the future.
I've made the change anyway. I think it's better now.
> Some teams frown upon adding new IOCTL(s) where existing ones can be
> made backward/forward
On 01/02/17 05:10 AM, Emil Velikov wrote:
> You can keep it roughly as-is if you're ~reasonably certain one won't
> change it in the future.
I've made the change anyway. I think it's better now.
> Some teams frown upon adding new IOCTL(s) where existing ones can be
> made backward/forward
On 31 January 2017 at 23:13, Logan Gunthorpe wrote:
> Hi Emil,
>
> Thanks for the feedback.
>
> On 31/01/17 01:48 PM, Emil Velikov wrote:
>>> +struct switchtec_ioctl_fw_info {
>>> + __u32 flash_length;
>>> +
>>> + struct {
>>> + __u32 address;
>>> +
On 31 January 2017 at 23:13, Logan Gunthorpe wrote:
> Hi Emil,
>
> Thanks for the feedback.
>
> On 31/01/17 01:48 PM, Emil Velikov wrote:
>>> +struct switchtec_ioctl_fw_info {
>>> + __u32 flash_length;
>>> +
>>> + struct {
>>> + __u32 address;
>>> + __u32
Hi Emil,
Thanks for the feedback.
On 31/01/17 01:48 PM, Emil Velikov wrote:
>> +struct switchtec_ioctl_fw_info {
>> + __u32 flash_length;
>> +
>> + struct {
>> + __u32 address;
>> + __u32 length;
>> + __u32 active;
> Something to keep in
Hi Emil,
Thanks for the feedback.
On 31/01/17 01:48 PM, Emil Velikov wrote:
>> +struct switchtec_ioctl_fw_info {
>> + __u32 flash_length;
>> +
>> + struct {
>> + __u32 address;
>> + __u32 length;
>> + __u32 active;
> Something to keep in
Hi Logan,
NOTE: Please take my comments with a healthy pinch of salt.
I'd imagine that core/more experienced developers have more thorough
feedback, so I'll mention a few things on the less common part -
robust/compat UABI.
Above all, please read through the in-tree documentation on the topic
Hi Logan,
NOTE: Please take my comments with a healthy pinch of salt.
I'd imagine that core/more experienced developers have more thorough
feedback, so I'll mention a few things on the less common part -
robust/compat UABI.
Above all, please read through the in-tree documentation on the topic
On 31/01/17 11:57 AM, Greg Kroah-Hartman wrote:
> Sorry, it was probably me :)
Nope, it was Christoph Hellwig. I don't mind changing it. It's just hard
to know what's expected all the time.
> Why do you need this? Wherever you put it, it should be built as part
> of the online kernel
On 31/01/17 11:57 AM, Greg Kroah-Hartman wrote:
> Sorry, it was probably me :)
Nope, it was Christoph Hellwig. I don't mind changing it. It's just hard
to know what's expected all the time.
> Why do you need this? Wherever you put it, it should be built as part
> of the online kernel
On Tue, Jan 31, 2017 at 10:35:44AM -0700, Logan Gunthorpe wrote:
>
>
> On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> > That's one big patch to review, would you want to do that?
>
> Sorry, will do.
>
> > Can you break it up into smaller parts? At least put the documentation
> >
On Tue, Jan 31, 2017 at 10:35:44AM -0700, Logan Gunthorpe wrote:
>
>
> On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> > That's one big patch to review, would you want to do that?
>
> Sorry, will do.
>
> > Can you break it up into smaller parts? At least put the documentation
> >
On 31/01/17 10:49 AM, Jonathan Corbet wrote:
> The good news is that your switchtec.txt file is already 99% in the RST
> format, so there is little or nothing to do there.
>
> The bad news is that we don't quite have a place for it yet. This is
> really user-space developer documentation, and
On 31/01/17 10:49 AM, Jonathan Corbet wrote:
> The good news is that your switchtec.txt file is already 99% in the RST
> format, so there is little or nothing to do there.
>
> The bad news is that we don't quite have a place for it yet. This is
> really user-space developer documentation, and
Hi Logan,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.10-rc6 next-20170130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Logan,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.10-rc6 next-20170130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Tue, 31 Jan 2017 10:35:44 -0700
Logan Gunthorpe wrote:
> > And don't dump a .txt file into Documentation/ anymore, people are
> > working to move to the newer format.
>
> Fair. I wasn't sure where a good place to put it was. Any suggestions?
We're working toward a
On Tue, 31 Jan 2017 10:35:44 -0700
Logan Gunthorpe wrote:
> > And don't dump a .txt file into Documentation/ anymore, people are
> > working to move to the newer format.
>
> Fair. I wasn't sure where a good place to put it was. Any suggestions?
We're working toward a rational document
On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> That's one big patch to review, would you want to do that?
Sorry, will do.
> Can you break it up into smaller parts? At least put the documentation
> separately, right?
Ha, funny. Last time I sent a patch someone asked for the documentation
On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> That's one big patch to review, would you want to do that?
Sorry, will do.
> Can you break it up into smaller parts? At least put the documentation
> separately, right?
Ha, funny. Last time I sent a patch someone asked for the documentation
On Tue, Jan 31, 2017 at 10:03:24AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function
On Tue, Jan 31, 2017 at 10:03:24AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function
On Tue, Jan 31, 2017 at 10:03:24AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function
On Tue, Jan 31, 2017 at 10:03:24AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function
26 matches
Mail list logo