On 04/21/15 12:16, Rafał Miłecki wrote:
On 20 April 2015 at 22:16, Arend van Spriel<ar...@broadcom.com> wrote:
On 04/20/15 20:49, Rafał Miłecki wrote:
On 20 April 2015 at 19:12, Arend van Spriel<ar...@broadcom.com> wrote:
On 04/20/15 13:26, Rafał Miłecki wrote:
On 17 April 2015 at 10:50, Arend van Spriel<ar...@broadcom.com> wrote:
Another option is to add the parsing stuff in that nvram code and have
an
api to get the appropriate portion based on pcie domain and bus number
as
used in brcmf_fw_get_firmwares_pcie(). However, I would prefer to have
this
in the driver and not in arch specific code as there may be other
platforms
like our set-top boxes needing this.
This is some plan for the future I was lacking from the beginning. It
makes things more clear now, thanks.
You're welcome. Do you want to see this clarification in the commit
message?
I don't really need that, I'm leaving it up to you :)
The last remaining question from me is if about this NVRAM validation
function (if it exists).
Ok. I can try to answer that one. The nvram parsing code in firmware.c
intends to do just that. So apart from stripping comments and whitespace it
validates each line and gives off a warning if a wrongly formatted entry is
found.
OK, thanks. So I guess this patch is OK after all?
Until proven otherwise. I tested it with a number of format violations,
but there could be more creative people out there coming up with a
pattern uncovering some issue.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
