On 02/01/2023 14:44, Shenhar, Talel wrote:
On 1/2/2023 2:47 PM, Krzysztof Kozlowski wrote:I explained - using same IO address suggests you used Linux driver
Can you elaborate on this inaccurate hardware description?
On 02/01/2023 13:17, Shenhar, Talel wrote:
Things we had in mind:None of these address the core problem - possibly inaccurate hardware
1) map more specific region to avoid conflict (we don't need the same
registers on both entity so if we do very specific multiple mapping this
shall be resolved)
2) use other kernel API for mapping that doesn't do request_mem_region
(or use the reserve only for one of them)
3) have single driver (edac mc) handle also the refresh rate
4) export edac_mc.h and have the drivers/memory have all the needed code
to do both edac and refresh rate under drivers/memory
description...
structure in your hardware description. I assume we talk here about
Devicetree. If not, that's quite different case... then I guess ACPI,
which I do not care - I am not it's maintainer.
Also, I'd like to write down my understanding of your response from above:No. Sorry, we probably talk about two different things.
it seems you see as possible solution both using different API that
allow overlapping (solution 2) and also for splitting the IO address
space to finer pieces to achieve full HW description (solution 1)
You started writing that you have a hardware described as one IO address
space and now have a problem developing drivers for it.
The driver model for this is entirely different problem than problem of
accurate hardware description. Whether you described HW correct or not,
I don't know. You did not provide any details here, like DTS or bindings
(if we talk about Devicetree).
Having multiple drivers using similar resources is already solved many
times (MFD, syscon).
Whether the solution is correct or not is one more (third) topic: poking
to same IO address space from two different drivers is error-prone. This
one is solvable with splitting IO address space.
Best regards,
Krzysztof