On 19.03.2014 19:37, Grant Grundler wrote:
On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa <t.figa@xxxxxxxxxxx> wrote:
...
As I said, AFAIK the trend is to get rid of ordering by initcalls and make
sure that drivers can handle missing dependencies properly, even for
"services" such as DMA, GPIO, clocks and so on, which after all are provided
by normal drivers like other.
Ok - I'm not following the general kernel dev trends. initcall()
levels are easy to understand and implement. So I would not be in a
hurry to replace them.
Well, initcall level is still a way to satisfy most of dependencies,
i.e. all client devices with higher initcall levels will probe
successfully. However the other case needs to be handled as well - in
this case the IOMMU binding code needs to defer probe of client driver
if respective IOMMU is not yet available.
ps. I've written IOMMU support for four different IOMMUs on three
operating systems (See drivers/parisc for two linux examples). But I
still feel like I at best have 80% understanding of how this one is
organized/works. Abstract descriptions and convoluted code have been
handicapping me (and lack of time to dig further).
Well, this is one of my concerns with this driver. It isn't easy to read
(and so review, maintain, extend and debug found issues).
My postscript comment was more to explain why I'm not confident in my
opinion - not a reason to reject the patch series. I still consider
the whole series as a step forward. But I'm not the expert here.
I fully agree with you. Other than the issues mentioned in review, the
patches are definitely a step forward. I'd even say that all the patches
that have nothing to do with device tree could be merged in their
current form and the code refined later. It doesn't mean that patches
shouldn't be reviewed now and issues spotted reported, even if they
could be fixed later - this is for the IOMMU subsystem maintainer to decide.
As for patches related to DT support, more care needs to be taken, as
bindings should be designed with stability in mind, so the refining
process should happen at review stage.
Right now, with ~30 patches posted by the exynos iommu (official?)
maintainer, no one else who has a clue will attempt to fix or clean up
those kinds of problems. i.e. it's useful to enable others to fix
what are essentially unspecified "design pattern" issues.
Agreed.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
