All of lore.kernel.org
 help / color / mirror / Atom feed
From: a.zummo@towertech.it (Alessandro Zummo)
To: linux-arm-kernel@lists.infradead.org
Subject: Can someone Ack and queue a patch for RTC subsytem?
Date: Thu, 19 Dec 2013 18:40:24 +0100	[thread overview]
Message-ID: <20131219184024.2a649328@linux.lan.towertech.it> (raw)
In-Reply-To: <87d2kslphr.fsf@natisbad.org>

On Thu, 19 Dec 2013 18:28:16 +0100
arno at natisbad.org (Arnaud Ebalard) wrote:

> >  Yes, Andrew usually pick those.   
>
> I guess he should be put in the MAINTAINERS file then. Otherwise,
> get_maintainer.pl script can not do its job correctly and people
> end up thinking you should be the one handling those.

 That makes sense, I'll leave the decision add his email to Andrew. 


> > I do not maintain a separate tree due to most RTCs being specifit to a
> > subsytem.   
> 
> I do not understand: the chip is generic, i.e. this is not a RTC chip
> specific to a given SoC (like rtc-mv.c is for instance). Can you be
> more specific?

 Yes, this chip is generic, but most aren't. Some of those who
 are generic, are strictly connected to a particular system/board, 
 and they end up in that system's tree. Most of the drivers
 are pretty small.
 

> >  Regarding your patch, please do not add entries to /proc.
> >  Use sysfs if you need.  
> 
> Well, this is what is currently described in the documentation
> (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
> many drivers do (AFAICT, 22/125).

 This needs to be fixed as well. Documentation.txt does not suggest
 to add arbitrary values to the procfs. "many do" does not apply.


> Additionally, I only provide some additional info for an existing
> file: the /proc entry is created by the drivers/rtc/class.c as
> soon as someone selects CONFIG_RTC_INTF_PROC.

 I know, but that makes the procfs entry a mess. sysfs is the way,


> Do you want me to send a v7 w/ the .proc helper removed or leave
> things as they are and Ack the patch as is?

 Unless absolutely needed, I'd prefer if you can remove them
 or move to sysfs.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

WARNING: multiple messages have this Message-ID (diff)
From: Alessandro Zummo <a.zummo@towertech.it>
To: arno@natisbad.org (Arnaud Ebalard)
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Jason Cooper <jason@lakedaemon.net>,
	linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Peter Huewe <peter.huewe@infineon.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Thierry Reding <treding@nvidia.com>,
	Mark Brown <broonie@kernel.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Landley <rob@landley.net>,
	rtc-linux@googlegroups.com, Guenter Roeck <linux@roeck-us.net>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Kumar Gala <galak@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Can someone Ack and queue a patch for RTC subsytem?
Date: Thu, 19 Dec 2013 18:40:24 +0100	[thread overview]
Message-ID: <20131219184024.2a649328@linux.lan.towertech.it> (raw)
In-Reply-To: <87d2kslphr.fsf@natisbad.org>

On Thu, 19 Dec 2013 18:28:16 +0100
arno@natisbad.org (Arnaud Ebalard) wrote:

> >  Yes, Andrew usually pick those.   
>
> I guess he should be put in the MAINTAINERS file then. Otherwise,
> get_maintainer.pl script can not do its job correctly and people
> end up thinking you should be the one handling those.

 That makes sense, I'll leave the decision add his email to Andrew. 


> > I do not maintain a separate tree due to most RTCs being specifit to a
> > subsytem.   
> 
> I do not understand: the chip is generic, i.e. this is not a RTC chip
> specific to a given SoC (like rtc-mv.c is for instance). Can you be
> more specific?

 Yes, this chip is generic, but most aren't. Some of those who
 are generic, are strictly connected to a particular system/board, 
 and they end up in that system's tree. Most of the drivers
 are pretty small.
 

> >  Regarding your patch, please do not add entries to /proc.
> >  Use sysfs if you need.  
> 
> Well, this is what is currently described in the documentation
> (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
> many drivers do (AFAICT, 22/125).

 This needs to be fixed as well. Documentation.txt does not suggest
 to add arbitrary values to the procfs. "many do" does not apply.


> Additionally, I only provide some additional info for an existing
> file: the /proc entry is created by the drivers/rtc/class.c as
> soon as someone selects CONFIG_RTC_INTF_PROC.

 I know, but that makes the procfs entry a mess. sysfs is the way,


> Do you want me to send a v7 w/ the .proc helper removed or leave
> things as they are and Ack the patch as is?

 Unless absolutely needed, I'd prefer if you can remove them
 or move to sysfs.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


  reply	other threads:[~2013-12-19 17:40 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-19 16:34 Can someone Ack and queue a patch for RTC subsytem? Arnaud Ebalard
2013-12-19 16:34 ` Arnaud Ebalard
2013-12-19 16:38 ` Alessandro Zummo
2013-12-19 16:38   ` Alessandro Zummo
2013-12-19 17:28   ` Arnaud Ebalard
2013-12-19 17:28     ` Arnaud Ebalard
2013-12-19 17:40     ` Alessandro Zummo [this message]
2013-12-19 17:40       ` Alessandro Zummo
2013-12-19 18:01       ` Jason Cooper
2013-12-19 18:01         ` Jason Cooper
2013-12-19 18:03         ` Alessandro Zummo
2013-12-19 18:03           ` Alessandro Zummo
2013-12-19 18:05       ` Arnaud Ebalard
2013-12-19 18:05         ` Arnaud Ebalard
2013-12-19 18:09         ` Jason Cooper
2013-12-19 18:09           ` Jason Cooper
2013-12-19 19:48           ` Guenter Roeck
2013-12-19 19:48             ` Guenter Roeck
2013-12-19 19:52             ` Jason Cooper
2013-12-19 19:52               ` Jason Cooper
2013-12-19 16:46 ` Jason Cooper
2013-12-19 16:46   ` Jason Cooper
2013-12-19 16:57   ` [rtc-linux] " Alessandro Zummo
2013-12-19 16:57     ` Alessandro Zummo
2013-12-19 22:17     ` Arnaud Ebalard
2013-12-19 22:17       ` Arnaud Ebalard
2013-12-20 18:30       ` Mark Brown
2013-12-20 18:30         ` Mark Brown
2013-12-20 20:23         ` Arnaud Ebalard
2013-12-20 20:23           ` Arnaud Ebalard
2013-12-21 14:16           ` Mark Brown
2013-12-21 14:16             ` Mark Brown
2013-12-19 17:46   ` Arnaud Ebalard
2013-12-19 17:46     ` Arnaud Ebalard
2013-12-19 17:49     ` Alessandro Zummo
2013-12-19 17:49       ` Alessandro Zummo
2013-12-20  9:03       ` Maxime Ripard
2013-12-20  9:03         ` Maxime Ripard
2013-12-20 11:00         ` Alessandro Zummo
2013-12-19 17:50     ` Jason Cooper
2013-12-19 17:50       ` Jason Cooper
2013-12-20  0:57     ` Jason Cooper
2013-12-20  0:57       ` 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=20131219184024.2a649328@linux.lan.towertech.it \
    --to=a.zummo@towertech.it \
    --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.