Date:	Wed, 19 Mar 2014 19:51:21 +0100
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Grant Grundler <grundler@...omium.org>,
	Tomasz Figa <t.figa@...sung.com>
CC:	Linux DeviceTree <devicetree@...r.kernel.org>,
	Linux Samsung SOC <linux-samsung-soc@...r.kernel.org>,
	Prathyush <prathyush.k@...sung.com>,
	Joerg Roedel <joro@...tes.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Sachin Kamat <sachin.kamat@...aro.org>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Varun Sethi <Varun.Sethi@...escale.com>,
	Antonios Motakis <a.motakis@...tualopensystems.com>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>,
	Rahul Sharma <rahul.sharma@...sung.com>
Subject: Re: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API
 functions

On 19.03.2014 19:37, Grant Grundler wrote:
> On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa <t.figa@...sung.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists