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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 Aug 2018 09:43:30 +0100 From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org> To: Brian Norris <briannorris@...omium.org>, Rob Herring <robh@...nel.org> Cc: Brian Norris <computersforpeace@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Andrew Lunn <andrew@...n.ch>, Dmitry Torokhov <dmitry.torokhov@...il.com>, Guenter Roeck <linux@...ck-us.net>, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Julius Werner <jwerner@...omium.org>, Stephen Boyd <swboyd@...omium.org> Subject: Re: [RFC PATCH v1 0/3] device property: Support MAC address in VPD Sorry for the delay!! For some reason I missed this email thread totally! On 31/08/18 02:26, Brian Norris wrote: >> Seems to me that nvmem needs to be extended to allow providers to >> retrieve and interpret data. Not everything is at some fixed offset and >> size. Something like this is valid dts: >> >> nvmem = <&phandle> "a-string"; >> There has been some discussion on extending nvmem support to MTD and non-DT users in https://patchwork.kernel.org/cover/10562365/ One of the thing which we discussed in this thread is adding compatible strings to cells mainly to 1> Differentiate between actual cells and partitions for MTD case. 2> Allow provider specific bindings for each cell, in VPD instance key string & value length could be one them. This means that we would endup adding xlate callback support to the nvmem_config. AFAIU, From consumer side old bindings should still work! From non-dt or ACPI side these cells can be parsed by the provider driver and add it to the nvmem_config. Does this make sense? Or Did I miss anything obvious ? >> But that's pretty uncommon (I can't think of a binding that actually >> uses that). Perhaps the provider has an array of keys defined and the >> consumer just provides the index. > In the case of VPD, all keys are 0-terminated strings (there's also a > length field, but the key is still 0-terminated), so that scheme could > work. (I'm not sure an indexed provider is extremely relevant right now, > although it probably could be supported if I expand the of_nvmem > retrieval to support a generic of_xlate() override anyway.) The > information represented is almost the same as in my proposal, except that: > (a) now I have to give the VPD a phandle -- so far, I've avoided that, > as it's just an auto-enumerated device underneath the > /firmware/coreboot device (see drivers/firmware/google/vpd.c) > (b) this is no longer directly useful to ACPI systems -- I'm not > actually sure how (if at all) nvmem provider/consumer is supposed to > work there > > But maybe this isn't really that useful to ACPI, and it's sufficient to > just have fwnode_get_mac_address() call of_get_nvmem_mac_address() when > we're using DT. > >> Or we could do '<key>-nvmem = <&phandle>', but parsing that is a bit >> more complicated. > That doesn't seem to have much advantage to me.
Powered by blists - more mailing lists