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:   Tue, 18 Feb 2020 09:29:39 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Mac Lu (盧孟德) <mac.lu@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>
Cc:     Andrew-CT Chen (陳智迪) 
        <Andrew-CT.Chen@...iatek.com>
Subject: Re: NVMEM usage consult for device information



On 18/02/2020 09:26, Mac Lu (盧孟德) wrote:
> Hi Srini:
>>Is this data stored in a non volatile memory on the SoC?
>>if yes, then we should have a proper nvmem provider driver.
> 
> Yes. This data is stored in non volatile memory on the SoC.
It makes sense to have  nvmem driver in that case. which can then be 
used by Device Tree to retrieve the required configurations from NVMEM.

--srini
> It would be read at bootloader and delivered to kernel by DTB.

> 
> 
> Thanks
> Mac
> 
> -----Original Message-----
> From: Srinivas Kandagatla [mailto:srinivas.kandagatla@...aro.org]
> Sent: Tuesday, February 18, 2020 5:19 PM
> To: Mac Lu (盧孟德) <mac.lu@...iatek.com>; linux-kernel@...r.kernel.org; linux-mediatek@...ts.infradead.org
> Cc: Andrew-CT Chen (陳智迪) <Andrew-CT.Chen@...iatek.com>
> Subject: Re: NVMEM usage consult for device information
> 
> 
> 
> On 18/02/2020 05:16, Mac Lu (盧孟德) wrote:
>> Hello,
>> 
>> Mediatek chip have some SOC configurations and specific data which 
>> would be delivered to kernel by DTB.
>> 
> Is this data stored in a non volatile memory on the SoC?
> if yes, then we should have a proper nvmem provider driver.
> 
> --srini
> 
>> So we want to implement a new NVMEM driver to retrieve these data for 
>> use by the NVMEM Framework.
>> 
>> Do you agree with the usage for our application?
>> 
>> Thanks
>> 
>> Mac
>> 
>> ************* MEDIATEK Confidentiality Notice ******************** The 
>> information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or 
>> otherwise exempt from disclosure under applicable laws. It is intended 
>> to be conveyed only to the designated recipient(s). Any use, 
>> dissemination, distribution, printing, retaining or copying of this 
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and may 
>> be unlawful. If you are not an intended recipient of this e-mail, or 
>> believe that you have received this e-mail in error, please notify the 
>> sender immediately (by replying to this e-mail), delete any and all 
>> copies of this e-mail (including any attachments) from your system, 
>> and do not disclose the content of this e-mail to any other person. Thank you!
>> 
> 
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ