linux-kernel - Re: [PATCH v4 10/15] mtd: nand: move Micron specific init logic in nand

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]

Message-ID: <954a69d8-b62e-4250-79a5-68e5062aeda1@gmail.com>
Date:   Wed, 4 Jan 2017 22:20:40 +0100
From:   Marek Vasut <marek.vasut@...il.com>
To:     Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:     Richard Weinberger <richard@....at>, linux-mtd@...ts.infradead.org,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        Icenowy Zheng <icenowy@...c.xyz>, Valdis.Kletnieks@...edu,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/15] mtd: nand: move Micron specific init logic in
 nand_micron.c

On 01/04/2017 06:58 PM, Boris Brezillon wrote:
> On Wed, 4 Jan 2017 18:22:31 +0100
> Marek Vasut <marek.vasut@...il.com> wrote:
> 
>> On 01/04/2017 06:13 PM, Boris Brezillon wrote:
>>> On Wed, 4 Jan 2017 16:15:46 +0100
>>> Marek Vasut <marek.vasut@...il.com> wrote:
>>>   
>>>> On 01/03/2017 02:01 PM, Boris Brezillon wrote:  
>>>>> Move Micron specific initialization logic into nand_micron.c. This is
>>>>> part of the "separate vendor specific code from core" cleanup process.
>>>>>
>>>>> Signed-off-by: Boris Brezillon <boris.brezillon@...e-electrons.com>    
>>>>
>>>> [...]
>>>>  
>>>>> diff --git a/drivers/mtd/nand/nand_micron.c b/drivers/mtd/nand/nand_micron.c
>>>>> new file mode 100644
>>>>> index 000000000000..ddb9adf12c21
>>>>> --- /dev/null
>>>>> +++ b/drivers/mtd/nand/nand_micron.c
>>>>> @@ -0,0 +1,83 @@
>>>>> +/*
>>>>> + * Copyright (C) 2013 Boris Brezillon <boris.brezillon@...e-electrons.com>    
>>>>
>>>> 2013-2017 ?  
>>>
>>> 2017, indeed.
>>>   
>>>>  
>>>>> + * This program is free software; you can redistribute it and/or modify
>>>>> + * it under the terms of the GNU General Public License as published by
>>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>>> + * (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>> + * GNU General Public License for more details.
>>>>> + */
>>>>> +
>>>>> +#include <linux/mtd/nand.h>
>>>>> +
>>>>> +struct nand_onfi_vendor_micron {
>>>>> +	u8 two_plane_read;
>>>>> +	u8 read_cache;
>>>>> +	u8 read_unique_id;
>>>>> +	u8 dq_imped;
>>>>> +	u8 dq_imped_num_settings;
>>>>> +	u8 dq_imped_feat_addr;
>>>>> +	u8 rb_pulldown_strength;
>>>>> +	u8 rb_pulldown_strength_feat_addr;
>>>>> +	u8 rb_pulldown_strength_num_settings;
>>>>> +	u8 otp_mode;
>>>>> +	u8 otp_page_start;
>>>>> +	u8 otp_data_prot_addr;
>>>>> +	u8 otp_num_pages;
>>>>> +	u8 otp_feat_addr;
>>>>> +	u8 read_retry_options;
>>>>> +	u8 reserved[72];
>>>>> +	u8 param_revision;
>>>>> +} __packed;    
>>>>
>>>> Is this __packed really needed?
>>>>  
>>>
>>> I'm just copying an existing structure. And yes, it's probably unneeded
>>> since all fields are u8, and the struct size in a multiple of 8 bytes,
>>> but it shouldn't hurt either. 
>>>   
>> Could you send a patch to drop it, please ? :)
>>
> 
> Is there a strong reason to drop this attribute? All ONFI related
> structs are using it to make sure the layout is not changed by the
> compiler, and be able to cast a buffer container the ONFI param page
> content to one of the nand_onfi_xxx struct.
> 
> Yes, this is currently not needed (at least for this struct), but I'd
> prefer to keep nand_onfi_xxx definitions consistent if you don't mind,
> unless you see a good reason to avoid using this __packed attribute.

OK, fine. No, there's no strong reason to remove it.

-- 
Best regards,
Marek Vasut