Hi,
Following this message (on the RTC list) are six patches:
- Remove the /sys/class/rtc-dev class_device, and a class_interface
- Use "struct rtc_device" in the external interface, not class_device
- Simplify the sysfs attribute handling, removing a class_interface
- Simplify the /proc/driver/rtc handling, removing the last class_interface
- Remove the class_device in "struct rtc_device"; now suspend()/resume() work
- Implement class suspend()/resume() so the system clock is updated on resume
The main point of this series of patches is that last one, which I'll
circulate just a bit more widely. (Although I think the first four are
also nice cleanups!) It might be the first example of a framework that
uses the "new" class level suspend()/resume() calls to offload drivers.
Other than actually using that new PM infrastructure, this series should
be interesting since it addresses one of the few remaining obstacles to
having the "Generic Time-Of-Day" (GTOD) framework be fully generic, in
the sense of working with whatever RTC is available on the platform (which
includes ones accessed through I2C or SPI, so that spinlocked access is
insufficient) and removing arch-specific RTC hooks.
This has been lightly tested on one of the ARMs that doesn't yet have
new-style dynamic tick working. I'm sure fault paths need tweaking yet.
- Dave
On Wed, Feb 21, 2007 at 07:45:14PM -0800, David Brownell wrote:
> Hi,
>
> Following this message (on the RTC list) are six patches:
>
> - Remove the /sys/class/rtc-dev class_device, and a class_interface
> - Use "struct rtc_device" in the external interface, not class_device
> - Simplify the sysfs attribute handling, removing a class_interface
> - Simplify the /proc/driver/rtc handling, removing the last class_interface
> - Remove the class_device in "struct rtc_device"; now suspend()/resume() work
> - Implement class suspend()/resume() so the system clock is updated on resume
>
> The main point of this series of patches is that last one, which I'll
> circulate just a bit more widely. (Although I think the first four are
> also nice cleanups!) It might be the first example of a framework that
> uses the "new" class level suspend()/resume() calls to offload drivers.
>
> Other than actually using that new PM infrastructure, this series should
> be interesting since it addresses one of the few remaining obstacles to
> having the "Generic Time-Of-Day" (GTOD) framework be fully generic, in
> the sense of working with whatever RTC is available on the platform (which
> includes ones accessed through I2C or SPI, so that spinlocked access is
> insufficient) and removing arch-specific RTC hooks.
>
> This has been lightly tested on one of the ARMs that doesn't yet have
> new-style dynamic tick working. I'm sure fault paths need tweaking yet.
All of these looks good to me, feel free to add an:
Acked-by: Greg Kroah-Hartman <[email protected]>
to them if you want.
thanks for doing the class_device removal work, I appreciate it.
greg k-h
On Thursday 22 February 2007 10:09 am, Greg KH wrote:
> On Wed, Feb 21, 2007 at 07:45:14PM -0800, David Brownell wrote:
> >
> > The main point of this series of patches is that last one, which I'll
> > circulate just a bit more widely. (Although I think the first four are
> > also nice cleanups!) It might be the first example of a framework that
> > uses the "new" class level suspend()/resume() calls to offload drivers.
> >
> > ..
>
> All of these looks good to me, feel free to add an:
> Acked-by: Greg Kroah-Hartman <[email protected]>
> to them if you want.
Thanks ...
> thanks for doing the class_device removal work, I appreciate it.
Actually the class_device removal work was because that was the
only way to clean the RTC suspend()/remove() patch out of my
queue, where it's been sitting since not log after those class
suspend/resume methods started to circulate, early last summer.
It'll be good to have that finally gone!
- Dave
On Thu, 22 Feb 2007 12:44:31 -0800
David Brownell <[email protected]> wrote:
> > All of these looks good to me, feel free to add an:
> > Acked-by: Greg Kroah-Hartman <[email protected]>
> > to them if you want.
>
> Thanks ...
>
>
> > thanks for doing the class_device removal work, I appreciate it.
>
> Actually the class_device removal work was because that was the
> only way to clean the RTC suspend()/remove() patch out of my
> queue, where it's been sitting since not log after those class
> suspend/resume methods started to circulate, early last summer.
>
> It'll be good to have that finally gone!
Hi David,
thanks for your work. The interface system was originally
in place because it seemed the right-thing-to-do. if it isn't,
better to remove it ;)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On Thursday 22 February 2007 1:37 pm, Alessandro Zummo wro
> Hi David,
>
> thanks for your work. The interface system was originally
> in place because it seemed the right-thing-to-do. if it isn't,
> better to remove it ;)
The Right Thing may also have changed a bit over time!
- Dave
On Thu, 22 Feb 2007 14:21:36 -0800
David Brownell <[email protected]> wrote:
> >
> > thanks for your work. The interface system was originally
> > in place because it seemed the right-thing-to-do. if it isn't,
> > better to remove it ;)
>
> The Right Thing may also have changed a bit over time!
eheh :)
given that Greg also agreed, you have my
Acked-By: Alessandro Zummo <[email protected]>
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On Friday 23 February 2007 4:09 am, Alessandro Zummo wrote:
>
> given that Greg also agreed, you have my
> Acked-By: Alessandro Zummo <[email protected]>
Thanks. I'll re-issue this series in a bit with those signoffs,
after after the oops fix. Then I expect it should sit in MM for
a while.
- Dave