[WIP] wifi: mt76: add support for providing precal in nvmem cells - #765
[WIP] wifi: mt76: add support for providing precal in nvmem cells#765Ansuel wants to merge 2 commits into
Conversation
| if (IS_ERR(data)) | ||
| return PTR_ERR(data); | ||
|
|
||
| if (retlen < len) { |
There was a problem hiding this comment.
I think you should also fail for retlen > len. If NVMEM cell is bigger than expected EEPROM I'd say sth it just wrong there. I wouldn't advise copying just first N bytes of NVMEM cell as you do below.
There was a problem hiding this comment.
Eh this is almost a pattern... In theory this should never happen... Should we enforce and match always the requested len?
And use != ?
|
I fixed compilation errors and verified NVMEM access works (provides the same data as MTD one). |
In preparation for NVMEM support, split get_of_eeprom() in subfunction to tidy the code and facilitate the addition of alternative method to get eeprom data. No behaviour change intended. While at it also drop OF ifdef checks as OF have stubs and calling of_get_property would result in the same error returned. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
@rmilecki can you review another time? Think only the retlen is to understand aside from that that is ready... And we need to understand for the name and the offset thing |
Add support for providing eeprom in nvmem cells by adding nvmem cell as an alternative source for mt76_get_of_eeprom(). Nvmem cells will follow standard nvmem cell definition and needs to be called eeprom' to be correctly identified. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
In case someone wants to test this on devices having the EEPROM stored inside a UBI volume or on a partition on the eMMC, I've written two simple read-only NVMEM providers for that: |
|
@dangowrt btw I sent upstream a variant of this patch that has less patch delta, don't know if you notice it. |
|
@Ansuel this was merged. |
|
Merged? Can you give a link? I didn't receive a confirm.
Il Mer 26 Lug 2023, 15:24 Rosen Penev ***@***.***> ha scritto:
… @Ansuel <https://github.com/Ansuel> this was merged.
—
Reply to this email directly, view it on GitHub
<#765 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQRZBREANLIJTDQ3S6LXSELA7ANCNFSM6AAAAAAWH2NCTI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Oh ok I thought it was merged upstream. Then this can be closed. The
upstream version is a bit different to this.
Il Mer 26 Lug 2023, 15:28 Rosen Penev ***@***.***> ha scritto:
… cd3dfe3
<cd3dfe3>
—
Reply to this email directly, view it on GitHub
<#765 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQVMHMAXR7YZHBMBNHDXSELRBANCNFSM6AAAAAAWH2NCTI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
See torvalds/linux@5fdaeca |
|
shall this pr be closed? or is anything missing still? |
5 participants
Add support for providing precal in nvmem cells by adding nvmem cell as
an alternative source for mt76_get_of_eeprom().
Nvmem cells will follow standard nvmem cell definition and needs to be
called 'precal' to be correctly identified.
@nbd168 Hi, i need to be quite honest... this is not tested as i lack any device currently...
But anyway I notice upstream we have
mediatek,mtd-eeprombut i really can't see why we need it instead of using the standard way of using nvmem cells.On openwrt we are widely using them for ath10k precal and mac-address for pretty much everything and even this driver use them to set the mac address... So why not add support for eeprom?
I reordered the function and added support for it. What do you think? Also I decided to use precal for the cell name but this is totally arbritrary and comes from
offs = is_mt7915(&dev->mt76) ? MT_EE_PRECAL : MT_EE_PRECAL_V2;Also maybe on second look the load precal should be a secondary cell so name should be cal?
If this is accepted the final idea is to migrate everyone to nvmem implementation and flag the custom binding as deprecated.