linux-kernel - Re: [PATCH] staging: comedi: Fix incorrect type assignment

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Feb 2017 21:00:50 +0530
From:   Karthik Nayak <karthik.188@...il.com>
To:     Ian Abbott <abbotti@....co.uk>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        devel@...verdev.osuosl.org, hsweeten@...ionengravers.com,
        Nikita Eshkeev <kastolom@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] staging: comedi: Fix incorrect type assignment

Hi,

On Wed, Feb 8, 2017 at 7:18 PM, Ian Abbott <abbotti@....co.uk> wrote:
> On 08/02/17 13:26, Karthik Nayak wrote:
>>
>> Hello,
>>
>> On Wed, Feb 8, 2017 at 6:43 PM, Ian Abbott <abbotti@....co.uk> wrote:
>>>
>>> On 07/02/17 19:06, Karthik Nayak wrote:
>>>>
>>>>
>>>> This patch fixes the following sparse error:
>>>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32: warning: incorrect
>>>> type in assignment (different base types)
>>>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:    expected
>>>> restricted __be32 [usertype] serial_number
>>>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:    got unsigned int
>>>>
>>>> This is done by introducing a temporary variable which is of type
>>>> '__be32' and converting the existing variable to type 'unsigned int'.
>>>>
>>>> Signed-off-by: Karthik Nayak <Karthik.188@...il.com>
>>>> ---
>>>>  drivers/staging/comedi/drivers/ni_pcimio.c | 5 +++--
>>>>  drivers/staging/comedi/drivers/ni_stc.h    | 2 +-
>>>>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> [snip]
>
>>> (On a side note, nothing actually uses serial number, so the code that
>>> reads
>>> it from the EEPROM could just be ripped out.)
>>>
>>> Reviewed-by: Ian Abbott <abbotti@....co.uk>
>>>
>>
>> Yea, I saw that, was assuming there might be a purposed use case scenario.
>
>
> AFAICT it's never been used - not even to print a kernel log message or
> anything.
>
>> Do you want me to send another patch?
>
>
> If you want.  If you plan to do so, could you indicate whether you are going
> to base the patch on top of this one, or whether this patch should be
> discarded.  Thanks!
>

Sure, I'll base it on top of the existing patch. I'll reply to the
first patch with the second one.

-- 
Regards,
Karthik Nayak