On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote: > > > On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote: > >On Wed, Aug 05, 2015 at 09:21:05PM +0530, Keerthy wrote: > >>Felipe, > >> > >>On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote: > >>>On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote: > >>>>Compared to da830-rtc compatibility am3352-rtc is more compatible to > >>>>the one in am437x. Hence adding the am3352-rtc compatible to cover the > >>>>entire feature set. > >>>> > >>>>The ti,am4372-rtc has no Documentation and not used even in the driver > >>>>hence removing it. > >>> > >>>why don't you do the inverse ? Document am4372-rtc and make driver use > >>>it ? > >> > >>am3352-rtc suffices for am4372 too. No need to add additional one for > >>am4372. > > > >Until we end up needing it, right ? :-) > > > >Besides, it's already used in a DTS. What happens if someone branched > >from that DTS and ships that in a product. RTC will just stop working > >for them. Sure, it wasn't documented, but that's a problem of commit > >73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few > >nodes) which, essentially, added that compatible flag without > >documenting it. > > > >BTW, this compatible has been in tree since August 2013, IMO it's unfar > >to drop it just like that. Documenting it would be a better approach. > > Okay. Can you point me to a file which is already accessing it in dts? Accessing what ? Also, once DTS reaches a major kernel release, it's deemed stable and should be supported. Are we dropping that ? -- balbi
Attachment:
signature.asc
Description: Digital signature
