Hi KyongHo,
On 09.03.2014 14:54, KyongHo Cho wrote:
On Thu, Mar 6, 2014 at 8:48 AM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> wrote:
On Fri, Feb 14, 2014 at 9:17 AM, Cho KyongHo <pullip.cho@xxxxxxxxxxx> wrote:
-----Original Message-----
From: Olof Johansson [mailto:olof@xxxxxxxxx]
Sent: Friday, February 14, 2014 4:34 AM
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim <kgene.kim@xxxxxxxxx> wrote:
Just adding KyongHo Cho.
If he can fixup for this time, it would be best solution because he knows
well than others, I think.
It's not so much a matter of "fixup for this time", it's a about
having ownership of the driver, making sure it works (and keeps
working if there is related development). The posted patches have not
been followed through on and the result is a broken driver. :(
I definitely appreciate his expertise, and we should make sure that he
gets to review the code, but if someone else is able to spend time on
reworking the driver (or rewriting a newer one) and maintaining it
longer-term, then we should not stop them from doing so. And there is
no reason to keep broken stale code in the kernel meanwhile.
Thank you for your concerning.
I also definitely agree with you that the driver must work.
I am always concerning about it but it was not easy to make some time
for the patches.
I will continue to post the next version of patches, of course.
I think it is not far from now to show it.
Lots of time is going from last reply. there are two options.
1. just waiting more
2. remove it as patch and start it again by someone.
what's the opinions?
Please be patient until the patches are OK enough to post.
The patches have lots of improvements and workarounds.
Sorry for delaying the patches.
One thing is certain, starting from scratch is not a good idea.
Why not discuss with me to make exynos-iommu driver better?
It is not a matter of starting from scratch or not, but rather of
getting a reasonable IOMMU driver for Exynos in mainline in reasonable
period of time. Usually it is much easier to just remove a stale driver
and quickly refactor all the code at once and then add a "new" driver,
than wasting time on submitting heaps of patches for a driver that is
not used and does not work anyway.
In fact, we already have a working driver, based on heavily refactored
original one in our internal tree anyway and we are just wasting time on
waiting for next version of the original refactor series to come, while
we could simply drop current version from the kernel, squash all of any
changes to it into a one patch adding the new driver and submit it
instead. Of course care would be taken to preserve any authorship
information.
Do you have some time frame in which you may post next version of the
series (and guaranteed time to work on it)?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
