From: alex@digriz.org.uk (Alexander Clouter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] add devicetree bindings for rtc-m48t86
Date: Mon, 1 Apr 2013 23:02:04 +0100 [thread overview]
Message-ID: <20130401220204.GJ1953@edkhil> (raw)
In-Reply-To: <5159FFAA.5030205@gmail.com>
On Tue, Apr 02, 2013 at 08:44:10AM +1100, Ryan Mallon wrote:
>On 01/04/13 08:56, Alexander Clouter wrote:
>> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
>> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
>> a memory mapped region. As I am devicetree'ing the TS-7800, this
>> driver needs converting and thats what this patchset does.
>>
>> The patch does the following:
>> * remove platform specific ops hooks, moving ioremap'ing and
>> everything into the driver
>> * utilises named resources to indicate index/data ranges
>> * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
>> * and, of course, enable devicetree hooks and include documentation
>>
>> Awkward step, the first patch breaks both boards, the two following
>> patches fix them. Happy to re-work this if folks give me a pointer
>> on how to do this in an acceptable way.
>
>Sorry, that's no good. It breaks things like git bisect.
Bah :)
>> My vote is to break fast, fix fast, spend the time writing other code :)
>
>The patch series will need to be reworked so that there is no
>build/runtime breakage between any of the patches. I'll have a read
>through and see if I can suggest something.
I am currently working through a new patchset now. It maintains the original {write,read}byte
ops but if not defined, and the required named resources are present, it moves to using driver
side mem mapped regions and what not...
'watch this space'
Cheers
--
Alexander Clouter
.sigmonster says: Deflector shields just came on, Captain.
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Clouter <alex-L4GPcECwBoDe9xe1eoZjHA@public.gmane.org>
To: Ryan Mallon <rmallon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo
<a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Hartley Sweeten
<hsweeten-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 0/3] add devicetree bindings for rtc-m48t86
Date: Mon, 1 Apr 2013 23:02:04 +0100 [thread overview]
Message-ID: <20130401220204.GJ1953@edkhil> (raw)
In-Reply-To: <5159FFAA.5030205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Apr 02, 2013 at 08:44:10AM +1100, Ryan Mallon wrote:
>On 01/04/13 08:56, Alexander Clouter wrote:
>> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
>> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
>> a memory mapped region. As I am devicetree'ing the TS-7800, this
>> driver needs converting and thats what this patchset does.
>>
>> The patch does the following:
>> * remove platform specific ops hooks, moving ioremap'ing and
>> everything into the driver
>> * utilises named resources to indicate index/data ranges
>> * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
>> * and, of course, enable devicetree hooks and include documentation
>>
>> Awkward step, the first patch breaks both boards, the two following
>> patches fix them. Happy to re-work this if folks give me a pointer
>> on how to do this in an acceptable way.
>
>Sorry, that's no good. It breaks things like git bisect.
Bah :)
>> My vote is to break fast, fix fast, spend the time writing other code :)
>
>The patch series will need to be reworked so that there is no
>build/runtime breakage between any of the patches. I'll have a read
>through and see if I can suggest something.
I am currently working through a new patchset now. It maintains the original {write,read}byte
ops but if not defined, and the required named resources are present, it moves to using driver
side mem mapped regions and what not...
'watch this space'
Cheers
--
Alexander Clouter
.sigmonster says: Deflector shields just came on, Captain.
next prev parent reply other threads:[~2013-04-01 22:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-31 21:56 [PATCH 0/3] add devicetree bindings for rtc-m48t86 Alexander Clouter
2013-03-31 21:56 ` Alexander Clouter
2013-03-31 21:56 ` [PATCH 1/3] rtc: rtc-m48t86: add devicetree bindings Alexander Clouter
2013-03-31 21:56 ` Alexander Clouter
2013-04-01 22:06 ` Ryan Mallon
2013-04-01 22:06 ` Ryan Mallon
2013-03-31 21:56 ` [PATCH 2/3] arm: orion5x: fixup ts78xx to be able to use the rtc-m48t86 again Alexander Clouter
2013-03-31 21:56 ` Alexander Clouter
2013-03-31 21:56 ` [PATCH 3/3] arm: ep93xx: fixup ts72xx " Alexander Clouter
2013-03-31 21:56 ` Alexander Clouter
2013-04-01 21:44 ` [PATCH 0/3] add devicetree bindings for rtc-m48t86 Ryan Mallon
2013-04-01 21:44 ` Ryan Mallon
2013-04-01 22:02 ` Alexander Clouter [this message]
2013-04-01 22:02 ` Alexander Clouter
2013-04-01 22:12 ` Ryan Mallon
2013-04-01 22:12 ` Ryan Mallon
2013-04-01 22:32 ` Jason Cooper
2013-04-01 22:32 ` Jason Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130401220204.GJ1953@edkhil \
--to=alex@digriz.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.