linux-kernel - Re: [EXT] Re: [PATCH v5 2/2] misc: nxp-sr1xx: UWB driver support for sr1xx series chip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <047ed933-9e13-804c-52cf-0815661f0f5d@nxp.com>
Date:   Tue, 20 Dec 2022 20:13:12 +0530
From:   Manjunatha Venkatesh <manjunatha.venkatesh@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, will@...nel.org, axboe@...nel.dk,
        robh+dt@...nel.org, mb@...htnvm.io, ckeepax@...nsource.cirrus.com,
        arnd@...db.d, mst@...hat.com, javier@...igon.com,
        mikelley@...rosoft.com, jasowang@...hat.com,
        sunilmut@...rosoft.com, bjorn.andersson@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, devicetree@...r.kernel.org,
        ashish.deshpande@....com, rvmanjumce@...il.com
Subject: Re: [EXT] Re: [PATCH v5 2/2] misc: nxp-sr1xx: UWB driver support for
 sr1xx series chip


On 12/20/2022 8:00 PM, Greg KH wrote:
> Caution: EXT Email
>
> On Tue, Dec 20, 2022 at 07:39:52PM +0530, Manjunatha Venkatesh wrote:
>> On 11/30/2022 12:57 PM, Greg KH wrote:
>>> Caution: EXT Email
>>>
>>> On Wed, Nov 30, 2022 at 09:10:08AM +0530, Manjunatha Venkatesh wrote:
>>>> On 9/14/2022 8:23 PM, Greg KH wrote:
>>> Note, originally you all were "rushed" to get this accepted, and now
>>> this took 2 1/2 months to respond back to a code review?  Something is
>>> wrong here, when responding so late, almost all context is lost :(
>> Sorry for the delayed response,further we will make sure address the review
>> comments ASAP.
>>
>>>>> Caution: EXT Email
>>>>>
>>>>> On Wed, Sep 14, 2022 at 07:59:44PM +0530, Manjunatha Venkatesh wrote:
>>>>>> +++ b/drivers/misc/nxp-sr1xx.c
>>>>>> @@ -0,0 +1,794 @@
>>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>>>>> Please no.  If you really want to dual-license your Linux kernel code,
>>>>> that's fine, but I will insist that you get a signed-off-by from your
>>>>> corporate lawyer so that I know that they agree with this and are
>>>>> willing to handle all of the complex issues that this entails as it will
>>>>> require work on their side over time.
>>>>>
>>>>> If that's not worth bothering your lawyers over, please just stick with
>>>>> GPL as the only license.
>>>> Dual-license is signed-off by NXP corporate lawyer.
>>> We need a signed-off-by on the patch itself.
>> As part of Version6 patch submission signed-off by NXP corporate lawyer
>> updated
>>>> Though, we would like to understand what complex issues which require
>>>> work over the time?
>>> I am not a lawyer and can not advise you of this, please work with yours
>>> to set into place the requirements you will have to keep this working
>>> properly.  Note, it is not trivial, and will require work on your end.
>>>
>>> I will push back again, and ask "Why?"  Why do you want this dual
>>> licensed?  What is driving that requirement and what will having it
>>> licensed like this enable you to do that having it just under GPL-2.0
>>> will not?
>> Our corporate lawyer suggested to use this dual license for NXP UWB product.
> And I need a tangable _reason_ why a dual license is needed here.
> Remember, dual licensing takes from the community and does not give
> back, so justifications for why this is required is essencial if you
> wish for people to at the very least, review your code...

Sure, will get the actual reason from our corporate lawyer,meanwhile can 
we submit

next driver patch version where we have addressed previous code review 
comments.

>>>>>> +#define SR1XX_SET_PWR _IOW(SR1XX_MAGIC, 0x01, long)
>>>>>> +#define SR1XX_SET_FWD _IOW(SR1XX_MAGIC, 0x02, long)
>>>>> You can't stick ioctl command definitions in a .c file that userspace
>>>>> never sees.  How are your userspace tools supposed to know what the
>>>>> ioctl is and how it is defined?
>>>> We will move ioctl command definitions into user space header file as part
>>>> of our next patch submission.
>>>>> How was this ever tested and where is your userspace code that interacts
>>>>> with this code?
>>>> We will share the corresponding user space code soon,meanwhile can you
>>>> please suggest how to share this user space code?
>>> You all have ways of posting code publicly :)
>> NXP UWB user space code available at below shared path.
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fuwb-driver-testapp&data=05%7C01%7Cmanjunatha.venkatesh%40nxp.com%7C999fcbfc998c42d4ae5708dae296be78%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638071434311303825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Z4h8OUd%2BM%2Fy5dnVoiBioS1%2FbR4Rqul8tW7OB%2FPCRqI%3D&reserved=0
> And the code there shows that you did not write the kernel side
> correctly :(
>
> Please fix it all up for your next submission.
>
> thanks,
>
> greg k-h