linux-kernel - Re: [PATCH] tmio_mmc: Optionally support using platform clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc64b4640908010710w1a0d6344s3e810433c28aadd5@mail.gmail.com>
Date:	Sat, 1 Aug 2009 18:10:52 +0400
From:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
To:	Ian Molton <ian@...menth.co.uk>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	linux-kernel@...r.kernel.org, Magnus Damm <damm@...nsource.se>,
	akpm@...ux-foundation.org, Matt Fleming <matt@...sole-pimps.org>,
	Philip Langdale <philipl@...rt.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: [PATCH] tmio_mmc: Optionally support using platform clock

Hi!

Sorry for the delay,

2009/7/28 Ian Molton <ian@...menth.co.uk>:
> Guennadi Liakhovetski wrote:
>
>> Hi Ian
>
> Hi!
>
>> Thanks for the review.
>
> No problem - I hope you dont feel that I am picking on you in particular
> here, this problem is not isolated to your patches.
>
>> I understand your concerns. Of course, the _proper_ solution would be to
>> implement an architecture-independent clock API, something like what
>> clocklib was trying to do. So, yes, if clocklib were in place now, I
>> certainly would have used it.
>
> Which is of course a chicken/egg situation. I dealt with this a number of
> times during the e-series development, and every time, integration with
> mainline has gone more swiftly and with better quality, when the job was
> done properly to begin with.
>
>> I searched for those clocklib submission attempts (Dmitry added to CC).
>
> Also adding RMK to the CC:
>
>> Last one I can find (maybe I missed some) is from July 2008 - more than a
>> year ago. So, looks like our options currently are:
>>
>> 1. wait for new submissions of clocklib - if any are planned
>
> Dmitry: whats the current status of your clocklib work?

It wasn't refreshed since last submission or so, since for ARM we do have
rmk's clocks implementations and I other maintainers (except AVR32 IIRC)
didn't care at all.

>> 3. take over patches from Dmitry and bring them to a state acceptable for
>> mainline
>
> Take over / collaborate with. I'll happily help people push these patches.
>
>> I personally don't have free (as in beer) time to work on 2 or 3. Anyone?
>
> If I can find out what the current state of this stuff is, I'll help get it
> working - I can test / update all the TC6x and T7x MFD devices (and probably
> asic3 too)

I don't think I'll have time to work on/refresh clocklib patches. Feel
free to continue
where I've left them.


-- 
With best wishes
Dmitry
--
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/