| Message ID | 1438771792-12604-2-git-send-email-j-keerthy@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 ?
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. > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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? > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ?
On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote: > 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 ? I meant getting used in any other dts files than the one i just dropped it. I checked the driver for rtc-omap and the compatibles are ti,am3352-rtc, ti,da830-rtc. So instead of appending it i dropped it as it was unused before. Tony i guess has already pulled in this patch. So i will let Tony comment on this. If the am4372-rtc compatible needs to be there i can add more documentation and append am3352-rtc. Regards, Keerthy > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Wed, Aug 05, 2015 at 11:14:45AM -0500, Felipe Balbi wrote: > 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. It was required to be done that way that time, probably author didn't want to be loyal to the king than the king himself ;), see, 1. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/191206.html 2. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89473.html Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote: > > > On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote: > >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 ? > > I meant getting used in any other dts files than the one i just dropped it. how can you ever know that for sure ? There are already quite a few third party platforms based on AM437x, how can you be sure those companies don't have their own DTS ?
On Thursday 06 August 2015 07:46 PM, Felipe Balbi wrote: > On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote: >> >> >> On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote: >>> 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 ? >> >> I meant getting used in any other dts files than the one i just dropped it. > > how can you ever know that for sure ? There are already quite a few > third party platforms based on AM437x, how can you be sure those > companies don't have their own DTS ? Felipe, If that is a concern i can re-do this. Tony, Shall i re-do this patch without removing am4372-rtc? If you can drop this i can re-do without removing the original am4372 compatible. Regards, Keerthy > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Keerthy <a0393675@ti.com> [150806 09:51]: > > Shall i re-do this patch without removing am4372-rtc? If you can drop this i > can re-do without removing the original am4372 compatible. OK please send a patch reverting the compatible change against the current omap-for-v4.3/dt-v2 branch. Please also describe why that's needed :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index ade28c79..40c01c4 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -308,7 +308,7 @@ }; rtc: rtc@44e3e000 { - compatible = "ti,am4372-rtc","ti,da830-rtc"; + compatible = "ti,am3352-rtc", "ti,da830-rtc"; reg = <0x44e3e000 0x1000>; interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
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. Signed-off-by: Keerthy <j-keerthy@ti.com> --- arch/arm/boot/dts/am4372.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)