subject:"\[PATCH v6 00\/10\] acpi, clocksource\: add GTDT driver and GTDT support in arm_arch

On 2016/7/8 21:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.

I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Fine to me.

Having a maintainer per file would be farcical, I really do not

Agree, but having three of us in maintainer entries in MAINTAINERS
file will help the patches be reviewed correctly with more eyes.

expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Fair enough. What I'm concern most is land ACPI on ARM64 soundly,
let's do that :)

OK, let's back to this patch set, Fuwei already prepared a new version
of patches [1] (moving acpi_gtdt.c to drivers/acpi/arm64/ and add a
maintainer entries patch), shall we review and comment on this patch
set for now, or just let Fuwei send out the new version?

[1]:
https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/topic-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On 2016/7/8 21:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.

Fine to me.

Having a maintainer per file would be farcical, I really do not

Agree, but having three of us in maintainer entries in MAINTAINERS
file will help the patches be reviewed correctly with more eyes.

expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Fair enough. What I'm concern most is land ACPI on ARM64 soundly,
let's do that :)

[1]:
https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/topic-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer


On 2016/7/7 21:58, Rafael J. Wysocki wrote:

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]


So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.


OK


I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.


OK


Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?


I'm fine with it as it helps for maintain.

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer


On 2016/7/7 21:58, Rafael J. Wysocki wrote:

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]


So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.


OK


I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.


OK


Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?


I'm fine with it as it helps for maintain.

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-08 Thread Sudeep Holla




On 08/07/16 14:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]


Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.


To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.


I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Having a maintainer per file would be farcical, I really do not
expect that amount of traffic for drivers/acpi/arm64 therefore


I agree.


I really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.



Yes sounds good to me.

--
Regards,
Sudeep

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-08 Thread Sudeep Holla




On 08/07/16 14:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]


Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.


To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.


I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Having a maintainer per file would be farcical, I really do not
expect that amount of traffic for drivers/acpi/arm64 therefore


I agree.


I really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.



Yes sounds good to me.

--
Regards,
Sudeep

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-08 Thread Lorenzo Pieralisi

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

> > Anyway let's avoid these petty arguments, I agree there must be some
> > sort of ARM64 ACPI maintainership for the reasons you mentioned above.
> 
> To avoid confusion on who's going to push stuff to Linus, I can do
> that, but it must be clear whose ACKs are needed for that to happen.
> That may be one person or all of you, whatever you decide.

I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Having a maintainer per file would be farcical, I really do not
expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Thanks,
Lorenzo

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-08 Thread Lorenzo Pieralisi

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

> > Anyway let's avoid these petty arguments, I agree there must be some
> > sort of ARM64 ACPI maintainership for the reasons you mentioned above.
> 
> To avoid confusion on who's going to push stuff to Linus, I can do
> that, but it must be clear whose ACKs are needed for that to happen.
> That may be one person or all of you, whatever you decide.

I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Having a maintainer per file would be farcical, I really do not
expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Thanks,
Lorenzo

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Fu Wei

Hi Rafael,

On 7 July 2016 at 21:58, Rafael J. Wysocki  wrote:
> On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
>> [+Sudeep]
>>
>> On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
>>
>> [...]
>>
>> > > >> So is this a documentation issue in which case Fu Wei can add that to
>> > > >> the file to explain its limited to ARM64. Or we could even rename the
>> > > >> file acpi_arm64_gtdt.c
>> > > >>
>> > > >> It seems a pity as the comment on this series were minors to block
>> > > >> things on a filename/location.
>> > > >
>> > > > Let me repeat what I said above:
>> > > >
>> > > > I'm mostly concerned about how (and by whom) that code is going to be
>> > > > maintained going forward.
>> > > >
>> > > > This is not about documentation, it is about responsibility.
>> > > >
>> > > > Honestly, I don't think I'm the right maintainer to apply the patch
>> > > > introducing this code and then handle bug reports regarding it and so
>> > > > on.  That has to be done by somebody else.
>> > >
>> > > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
>> > > support (with lots of people's help), I'm willing to maintain the ARM64
>> > > ACPI code under drivers/acpi/ if no objections.
>> >
>> > OK
>>
>> I would ask you please to add Sudeep and myself for the ARM64 specific
>> ACPI code maintainership too.
>
> OK

For this, it seems we have a decision now, so I will post  v7 tomorrow
following this decision:
drivers/acpi/arm64/acpi_gtdt.c

I think that is a very good idea, I also believe Hanjun can maintain it well.

>
>> > Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
>>
>> It can, but I do not understand why x86 should not have a separate
>> directory for all x86 specific stuff too then.
>
> It should. :-)
>
> It doesn't have it ATM, but that doesn't mean it's all OK.
>
> Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it
> has something at least.
>
> In any case, IMO, if some code is only used by one architecture, it should be
> clear that this is the case, and moving that code into a separate directory
> helps to achieve that.
>
>> Anyway let's avoid these petty arguments, I agree there must be some
>> sort of ARM64 ACPI maintainership for the reasons you mentioned above.
>
> To avoid confusion on who's going to push stuff to Linus, I can do that,
> but it must be clear whose ACKs are needed for that to happen.  That may be
> one person or all of you, whatever you decide.
>
> I can take pull requests too if that's more convenient.
>
> Thanks,
> Rafael
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Fu Wei

Hi Rafael,

On 7 July 2016 at 21:58, Rafael J. Wysocki  wrote:
> On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
>> [+Sudeep]
>>
>> On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
>>
>> [...]
>>
>> > > >> So is this a documentation issue in which case Fu Wei can add that to
>> > > >> the file to explain its limited to ARM64. Or we could even rename the
>> > > >> file acpi_arm64_gtdt.c
>> > > >>
>> > > >> It seems a pity as the comment on this series were minors to block
>> > > >> things on a filename/location.
>> > > >
>> > > > Let me repeat what I said above:
>> > > >
>> > > > I'm mostly concerned about how (and by whom) that code is going to be
>> > > > maintained going forward.
>> > > >
>> > > > This is not about documentation, it is about responsibility.
>> > > >
>> > > > Honestly, I don't think I'm the right maintainer to apply the patch
>> > > > introducing this code and then handle bug reports regarding it and so
>> > > > on.  That has to be done by somebody else.
>> > >
>> > > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
>> > > support (with lots of people's help), I'm willing to maintain the ARM64
>> > > ACPI code under drivers/acpi/ if no objections.
>> >
>> > OK
>>
>> I would ask you please to add Sudeep and myself for the ARM64 specific
>> ACPI code maintainership too.
>
> OK

For this, it seems we have a decision now, so I will post  v7 tomorrow
following this decision:
drivers/acpi/arm64/acpi_gtdt.c

I think that is a very good idea, I also believe Hanjun can maintain it well.

>
>> > Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
>>
>> It can, but I do not understand why x86 should not have a separate
>> directory for all x86 specific stuff too then.
>
> It should. :-)
>
> It doesn't have it ATM, but that doesn't mean it's all OK.
>
> Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it
> has something at least.
>
> In any case, IMO, if some code is only used by one architecture, it should be
> clear that this is the case, and moving that code into a separate directory
> helps to achieve that.
>
>> Anyway let's avoid these petty arguments, I agree there must be some
>> sort of ARM64 ACPI maintainership for the reasons you mentioned above.
>
> To avoid confusion on who's going to push stuff to Linus, I can do that,
> but it must be clear whose ACKs are needed for that to happen.  That may be
> one person or all of you, whatever you decide.
>
> I can take pull requests too if that's more convenient.
>
> Thanks,
> Rafael
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
> [+Sudeep]
> 
> On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
> 
> [...]
> 
> > > >> So is this a documentation issue in which case Fu Wei can add that to
> > > >> the file to explain its limited to ARM64. Or we could even rename the
> > > >> file acpi_arm64_gtdt.c
> > > >>
> > > >> It seems a pity as the comment on this series were minors to block
> > > >> things on a filename/location.
> > > >
> > > > Let me repeat what I said above:
> > > >
> > > > I'm mostly concerned about how (and by whom) that code is going to be
> > > > maintained going forward.
> > > >
> > > > This is not about documentation, it is about responsibility.
> > > >
> > > > Honestly, I don't think I'm the right maintainer to apply the patch
> > > > introducing this code and then handle bug reports regarding it and so
> > > > on.  That has to be done by somebody else.
> > > 
> > > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> > > support (with lots of people's help), I'm willing to maintain the ARM64
> > > ACPI code under drivers/acpi/ if no objections.
> > 
> > OK
> 
> I would ask you please to add Sudeep and myself for the ARM64 specific
> ACPI code maintainership too.

OK

> > Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
> 
> It can, but I do not understand why x86 should not have a separate
> directory for all x86 specific stuff too then.

It should. :-)

It doesn't have it ATM, but that doesn't mean it's all OK.

Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it
has something at least.

In any case, IMO, if some code is only used by one architecture, it should be
clear that this is the case, and moving that code into a separate directory
helps to achieve that.

> Anyway let's avoid these petty arguments, I agree there must be some
> sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do that,
but it must be clear whose ACKs are needed for that to happen.  That may be
one person or all of you, whatever you decide.

I can take pull requests too if that's more convenient.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
> [+Sudeep]
> 
> On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
> 
> [...]
> 
> > > >> So is this a documentation issue in which case Fu Wei can add that to
> > > >> the file to explain its limited to ARM64. Or we could even rename the
> > > >> file acpi_arm64_gtdt.c
> > > >>
> > > >> It seems a pity as the comment on this series were minors to block
> > > >> things on a filename/location.
> > > >
> > > > Let me repeat what I said above:
> > > >
> > > > I'm mostly concerned about how (and by whom) that code is going to be
> > > > maintained going forward.
> > > >
> > > > This is not about documentation, it is about responsibility.
> > > >
> > > > Honestly, I don't think I'm the right maintainer to apply the patch
> > > > introducing this code and then handle bug reports regarding it and so
> > > > on.  That has to be done by somebody else.
> > > 
> > > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> > > support (with lots of people's help), I'm willing to maintain the ARM64
> > > ACPI code under drivers/acpi/ if no objections.
> > 
> > OK
> 
> I would ask you please to add Sudeep and myself for the ARM64 specific
> ACPI code maintainership too.

OK

> > Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
> 
> It can, but I do not understand why x86 should not have a separate
> directory for all x86 specific stuff too then.

It should. :-)

It doesn't have it ATM, but that doesn't mean it's all OK.

Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it
has something at least.

In any case, IMO, if some code is only used by one architecture, it should be
clear that this is the case, and moving that code into a separate directory
helps to achieve that.

> Anyway let's avoid these petty arguments, I agree there must be some
> sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do that,
but it must be clear whose ACKs are needed for that to happen.  That may be
one person or all of you, whatever you decide.

I can take pull requests too if that's more convenient.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Lorenzo Pieralisi

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]

> > >> So is this a documentation issue in which case Fu Wei can add that to
> > >> the file to explain its limited to ARM64. Or we could even rename the
> > >> file acpi_arm64_gtdt.c
> > >>
> > >> It seems a pity as the comment on this series were minors to block
> > >> things on a filename/location.
> > >
> > > Let me repeat what I said above:
> > >
> > > I'm mostly concerned about how (and by whom) that code is going to be
> > > maintained going forward.
> > >
> > > This is not about documentation, it is about responsibility.
> > >
> > > Honestly, I don't think I'm the right maintainer to apply the patch
> > > introducing this code and then handle bug reports regarding it and so
> > > on.  That has to be done by somebody else.
> > 
> > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> > support (with lots of people's help), I'm willing to maintain the ARM64
> > ACPI code under drivers/acpi/ if no objections.
> 
> OK

I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.

> Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?

It can, but I do not understand why x86 should not have a separate
directory for all x86 specific stuff too then.

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

> > > That's one thing.
> > >
> > > Another one is the question I asked a few messages ago: Why having the
> > > GTDT code in drivers/acpi/ is actually useful to anyone?  It
> > > definitely would not be useful to me as the maintainer of
> > > drivers/acpi/, but maybe it would be useful to somebody for a specific
> > > practical reason.  Or is it just "let's put this into drivers/acpi/
> > > for the lack of a better place"?

The same logic applies to eg ioapic.c but anyway, see above, if it
can help having a separate subdirectory let's do it.

> > Having GTDT code in drivers/acpi/ is useful as it is code that is used
> > by two different subsystems, clocksource and watchdog,and where people
> > look by default for utility ACPI code.
> > 
> > If the mostly concerned thing (maintainer ship) is settled down, the
> > second question would be easily solved.

See above.

Thanks,
Lorenzo

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Lorenzo Pieralisi

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]

> > >> So is this a documentation issue in which case Fu Wei can add that to
> > >> the file to explain its limited to ARM64. Or we could even rename the
> > >> file acpi_arm64_gtdt.c
> > >>
> > >> It seems a pity as the comment on this series were minors to block
> > >> things on a filename/location.
> > >
> > > Let me repeat what I said above:
> > >
> > > I'm mostly concerned about how (and by whom) that code is going to be
> > > maintained going forward.
> > >
> > > This is not about documentation, it is about responsibility.
> > >
> > > Honestly, I don't think I'm the right maintainer to apply the patch
> > > introducing this code and then handle bug reports regarding it and so
> > > on.  That has to be done by somebody else.
> > 
> > I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> > support (with lots of people's help), I'm willing to maintain the ARM64
> > ACPI code under drivers/acpi/ if no objections.
> 
> OK

I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.

> Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?

It can, but I do not understand why x86 should not have a separate
directory for all x86 specific stuff too then.

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

> > > That's one thing.
> > >
> > > Another one is the question I asked a few messages ago: Why having the
> > > GTDT code in drivers/acpi/ is actually useful to anyone?  It
> > > definitely would not be useful to me as the maintainer of
> > > drivers/acpi/, but maybe it would be useful to somebody for a specific
> > > practical reason.  Or is it just "let's put this into drivers/acpi/
> > > for the lack of a better place"?

The same logic applies to eg ioapic.c but anyway, see above, if it
can help having a separate subdirectory let's do it.

> > Having GTDT code in drivers/acpi/ is useful as it is code that is used
> > by two different subsystems, clocksource and watchdog,and where people
> > look by default for utility ACPI code.
> > 
> > If the mostly concerned thing (maintainer ship) is settled down, the
> > second question would be easily solved.

See above.

Thanks,
Lorenzo

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, July 07, 2016 07:12:38 PM Hanjun Guo wrote:
> On 2016/7/6 8:00, Rafael J. Wysocki wrote:
> > On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:
> >> On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> >>> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  
> >>> wrote:
>  On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> > On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >>> On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>  GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>  ACPI spec, I think it can stay in drivers/acpi/ from this point
>  of view, am I right?
> >>>
> >>> The question is not "Can it?", but "Does it need to?".
> >>>
> >>> It is in the spec, but still there's only one architecture needing it.
> >>>
> >>> There is no way to test it on any other architecture and no reason to 
> >>> build it
> >>> for any other architecture, so why does it need to be located in 
> >>> drivers/acpi/ ?
> >>
> >> I'm fine to move it to other places such as arch/arm64/kernel/, but I
> >> would like to ask ARM64 maintainer's suggestion for this.
> >>
> >> Will, Catalin, what's your opinion on this?
> >
> > We don't have any device-tree code for the architected timer under
> > arch/arm64, so I don't see why we should need anything for ACPI either.
> 
>  And I don't see a reason for the GTDT code to be there in drivers/acpi/.
> 
>  What gives?
> >>>
> >>> Well, since there are things like acpi_lpss in there, my position here
> >>> is kind of weak. :-)
> >>>
> >>> That said I'm not particularly happy with having them in
> >>> drivers/acpi/, so I definitely won't object against attempts to moving
> >>> them somewhere else.
> >>>
>  Maybe it should go to the same place as the analogus DT code, then?
> >>>
> >>> I'm mostly concerned about how (and by whom) that code is going to be
> >>> maintained going forward, though.  I also think it should be made
> >>> clear that it is ARM64-only.
> >>>
> >>
> >> So is this a documentation issue in which case Fu Wei can add that to
> >> the file to explain its limited to ARM64. Or we could even rename the
> >> file acpi_arm64_gtdt.c
> >>
> >> It seems a pity as the comment on this series were minors to block
> >> things on a filename/location.
> >
> > Let me repeat what I said above:
> >
> > I'm mostly concerned about how (and by whom) that code is going to be
> > maintained going forward.
> >
> > This is not about documentation, it is about responsibility.
> >
> > Honestly, I don't think I'm the right maintainer to apply the patch
> > introducing this code and then handle bug reports regarding it and so
> > on.  That has to be done by somebody else.
> 
> I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> support (with lots of people's help), I'm willing to maintain the ARM64
> ACPI code under drivers/acpi/ if no objections.

OK

Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?

> >
> > That's one thing.
> >
> > Another one is the question I asked a few messages ago: Why having the
> > GTDT code in drivers/acpi/ is actually useful to anyone?  It
> > definitely would not be useful to me as the maintainer of
> > drivers/acpi/, but maybe it would be useful to somebody for a specific
> > practical reason.  Or is it just "let's put this into drivers/acpi/
> > for the lack of a better place"?
> 
> Having GTDT code in drivers/acpi/ is useful as it is code that is used
> by two different subsystems, clocksource and watchdog,and where people
> look by default for utility ACPI code.
> 
> If the mostly concerned thing (maintainer ship) is settled down, the
> second question would be easily solved.

Fair enough.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, July 07, 2016 07:12:38 PM Hanjun Guo wrote:
> On 2016/7/6 8:00, Rafael J. Wysocki wrote:
> > On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:
> >> On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> >>> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  
> >>> wrote:
>  On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> > On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >>> On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>  GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>  ACPI spec, I think it can stay in drivers/acpi/ from this point
>  of view, am I right?
> >>>
> >>> The question is not "Can it?", but "Does it need to?".
> >>>
> >>> It is in the spec, but still there's only one architecture needing it.
> >>>
> >>> There is no way to test it on any other architecture and no reason to 
> >>> build it
> >>> for any other architecture, so why does it need to be located in 
> >>> drivers/acpi/ ?
> >>
> >> I'm fine to move it to other places such as arch/arm64/kernel/, but I
> >> would like to ask ARM64 maintainer's suggestion for this.
> >>
> >> Will, Catalin, what's your opinion on this?
> >
> > We don't have any device-tree code for the architected timer under
> > arch/arm64, so I don't see why we should need anything for ACPI either.
> 
>  And I don't see a reason for the GTDT code to be there in drivers/acpi/.
> 
>  What gives?
> >>>
> >>> Well, since there are things like acpi_lpss in there, my position here
> >>> is kind of weak. :-)
> >>>
> >>> That said I'm not particularly happy with having them in
> >>> drivers/acpi/, so I definitely won't object against attempts to moving
> >>> them somewhere else.
> >>>
>  Maybe it should go to the same place as the analogus DT code, then?
> >>>
> >>> I'm mostly concerned about how (and by whom) that code is going to be
> >>> maintained going forward, though.  I also think it should be made
> >>> clear that it is ARM64-only.
> >>>
> >>
> >> So is this a documentation issue in which case Fu Wei can add that to
> >> the file to explain its limited to ARM64. Or we could even rename the
> >> file acpi_arm64_gtdt.c
> >>
> >> It seems a pity as the comment on this series were minors to block
> >> things on a filename/location.
> >
> > Let me repeat what I said above:
> >
> > I'm mostly concerned about how (and by whom) that code is going to be
> > maintained going forward.
> >
> > This is not about documentation, it is about responsibility.
> >
> > Honestly, I don't think I'm the right maintainer to apply the patch
> > introducing this code and then handle bug reports regarding it and so
> > on.  That has to be done by somebody else.
> 
> I'm working on ACPI for years and upstreamed the ARM64 ACPI core
> support (with lots of people's help), I'm willing to maintain the ARM64
> ACPI code under drivers/acpi/ if no objections.

OK

Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?

> >
> > That's one thing.
> >
> > Another one is the question I asked a few messages ago: Why having the
> > GTDT code in drivers/acpi/ is actually useful to anyone?  It
> > definitely would not be useful to me as the maintainer of
> > drivers/acpi/, but maybe it would be useful to somebody for a specific
> > practical reason.  Or is it just "let's put this into drivers/acpi/
> > for the lack of a better place"?
> 
> Having GTDT code in drivers/acpi/ is useful as it is code that is used
> by two different subsystems, clocksource and watchdog,and where people
> look by default for utility ACPI code.
> 
> If the mostly concerned thing (maintainer ship) is settled down, the
> second question would be easily solved.

Fair enough.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Hanjun Guo


On 2016/7/6 8:00, Rafael J. Wysocki wrote:

On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:

On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:

On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:

On 2016/6/30 21:27, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:

GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


I'm fine to move it to other places such as arch/arm64/kernel/, but I
would like to ask ARM64 maintainer's suggestion for this.

Will, Catalin, what's your opinion on this?


We don't have any device-tree code for the architected timer under
arch/arm64, so I don't see why we should need anything for ACPI either.


And I don't see a reason for the GTDT code to be there in drivers/acpi/.

What gives?


Well, since there are things like acpi_lpss in there, my position here
is kind of weak. :-)

That said I'm not particularly happy with having them in
drivers/acpi/, so I definitely won't object against attempts to moving
them somewhere else.


Maybe it should go to the same place as the analogus DT code, then?


I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward, though.  I also think it should be made
clear that it is ARM64-only.



So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.



That's one thing.

Another one is the question I asked a few messages ago: Why having the
GTDT code in drivers/acpi/ is actually useful to anyone?  It
definitely would not be useful to me as the maintainer of
drivers/acpi/, but maybe it would be useful to somebody for a specific
practical reason.  Or is it just "let's put this into drivers/acpi/
for the lack of a better place"?


Having GTDT code in drivers/acpi/ is useful as it is code that is used
by two different subsystems, clocksource and watchdog,and where people
look by default for utility ACPI code.

If the mostly concerned thing (maintainer ship) is settled down, the
second question would be easily solved.

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-07 Thread Hanjun Guo


On 2016/7/6 8:00, Rafael J. Wysocki wrote:

On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:

On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:

On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:

On 2016/6/30 21:27, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:

GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


I'm fine to move it to other places such as arch/arm64/kernel/, but I
would like to ask ARM64 maintainer's suggestion for this.

Will, Catalin, what's your opinion on this?


We don't have any device-tree code for the architected timer under
arch/arm64, so I don't see why we should need anything for ACPI either.


And I don't see a reason for the GTDT code to be there in drivers/acpi/.

What gives?


Well, since there are things like acpi_lpss in there, my position here
is kind of weak. :-)

That said I'm not particularly happy with having them in
drivers/acpi/, so I definitely won't object against attempts to moving
them somewhere else.


Maybe it should go to the same place as the analogus DT code, then?


I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward, though.  I also think it should be made
clear that it is ARM64-only.



So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.



That's one thing.

Another one is the question I asked a few messages ago: Why having the
GTDT code in drivers/acpi/ is actually useful to anyone?  It
definitely would not be useful to me as the maintainer of
drivers/acpi/, but maybe it would be useful to somebody for a specific
practical reason.  Or is it just "let's put this into drivers/acpi/
for the lack of a better place"?


Having GTDT code in drivers/acpi/ is useful as it is code that is used
by two different subsystems, clocksource and watchdog,and where people
look by default for utility ACPI code.

If the mostly concerned thing (maintainer ship) is settled down, the
second question would be easily solved.

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-05 Thread Rafael J. Wysocki

On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:
> On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
>> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  
>> wrote:
>> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
>> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
>> >> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
>> >> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>> >> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>> >> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
>> >> > >>of view, am I right?
>> >> > >
>> >> > >The question is not "Can it?", but "Does it need to?".
>> >> > >
>> >> > >It is in the spec, but still there's only one architecture needing it.
>> >> > >
>> >> > >There is no way to test it on any other architecture and no reason to 
>> >> > >build it
>> >> > >for any other architecture, so why does it need to be located in 
>> >> > >drivers/acpi/ ?
>> >> >
>> >> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
>> >> > would like to ask ARM64 maintainer's suggestion for this.
>> >> >
>> >> > Will, Catalin, what's your opinion on this?
>> >>
>> >> We don't have any device-tree code for the architected timer under
>> >> arch/arm64, so I don't see why we should need anything for ACPI either.
>> >
>> > And I don't see a reason for the GTDT code to be there in drivers/acpi/.
>> >
>> > What gives?
>>
>> Well, since there are things like acpi_lpss in there, my position here
>> is kind of weak. :-)
>>
>> That said I'm not particularly happy with having them in
>> drivers/acpi/, so I definitely won't object against attempts to moving
>> them somewhere else.
>>
>> > Maybe it should go to the same place as the analogus DT code, then?
>>
>> I'm mostly concerned about how (and by whom) that code is going to be
>> maintained going forward, though.  I also think it should be made
>> clear that it is ARM64-only.
>>
>
> So is this a documentation issue in which case Fu Wei can add that to
> the file to explain its limited to ARM64. Or we could even rename the
> file acpi_arm64_gtdt.c
>
> It seems a pity as the comment on this series were minors to block
> things on a filename/location.

Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.

That's one thing.

Another one is the question I asked a few messages ago: Why having the
GTDT code in drivers/acpi/ is actually useful to anyone?  It
definitely would not be useful to me as the maintainer of
drivers/acpi/, but maybe it would be useful to somebody for a specific
practical reason.  Or is it just "let's put this into drivers/acpi/
for the lack of a better place"?

I have not received a good answer to this one yet.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-05 Thread Rafael J. Wysocki

On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory  wrote:
> On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
>> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  
>> wrote:
>> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
>> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
>> >> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
>> >> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>> >> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>> >> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
>> >> > >>of view, am I right?
>> >> > >
>> >> > >The question is not "Can it?", but "Does it need to?".
>> >> > >
>> >> > >It is in the spec, but still there's only one architecture needing it.
>> >> > >
>> >> > >There is no way to test it on any other architecture and no reason to 
>> >> > >build it
>> >> > >for any other architecture, so why does it need to be located in 
>> >> > >drivers/acpi/ ?
>> >> >
>> >> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
>> >> > would like to ask ARM64 maintainer's suggestion for this.
>> >> >
>> >> > Will, Catalin, what's your opinion on this?
>> >>
>> >> We don't have any device-tree code for the architected timer under
>> >> arch/arm64, so I don't see why we should need anything for ACPI either.
>> >
>> > And I don't see a reason for the GTDT code to be there in drivers/acpi/.
>> >
>> > What gives?
>>
>> Well, since there are things like acpi_lpss in there, my position here
>> is kind of weak. :-)
>>
>> That said I'm not particularly happy with having them in
>> drivers/acpi/, so I definitely won't object against attempts to moving
>> them somewhere else.
>>
>> > Maybe it should go to the same place as the analogus DT code, then?
>>
>> I'm mostly concerned about how (and by whom) that code is going to be
>> maintained going forward, though.  I also think it should be made
>> clear that it is ARM64-only.
>>
>
> So is this a documentation issue in which case Fu Wei can add that to
> the file to explain its limited to ARM64. Or we could even rename the
> file acpi_arm64_gtdt.c
>
> It seems a pity as the comment on this series were minors to block
> things on a filename/location.

Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.

That's one thing.

Another one is the question I asked a few messages ago: Why having the
GTDT code in drivers/acpi/ is actually useful to anyone?  It
definitely would not be useful to me as the maintainer of
drivers/acpi/, but maybe it would be useful to somebody for a specific
practical reason.  Or is it just "let's put this into drivers/acpi/
for the lack of a better place"?

I have not received a good answer to this one yet.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-05 Thread Graeme Gregory

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:
> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> >> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> >> > >>of view, am I right?
> >> > >
> >> > >The question is not "Can it?", but "Does it need to?".
> >> > >
> >> > >It is in the spec, but still there's only one architecture needing it.
> >> > >
> >> > >There is no way to test it on any other architecture and no reason to 
> >> > >build it
> >> > >for any other architecture, so why does it need to be located in 
> >> > >drivers/acpi/ ?
> >> >
> >> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
> >> > would like to ask ARM64 maintainer's suggestion for this.
> >> >
> >> > Will, Catalin, what's your opinion on this?
> >>
> >> We don't have any device-tree code for the architected timer under
> >> arch/arm64, so I don't see why we should need anything for ACPI either.
> >
> > And I don't see a reason for the GTDT code to be there in drivers/acpi/.
> >
> > What gives?
> 
> Well, since there are things like acpi_lpss in there, my position here
> is kind of weak. :-)
> 
> That said I'm not particularly happy with having them in
> drivers/acpi/, so I definitely won't object against attempts to moving
> them somewhere else.
> 
> > Maybe it should go to the same place as the analogus DT code, then?
> 
> I'm mostly concerned about how (and by whom) that code is going to be
> maintained going forward, though.  I also think it should be made
> clear that it is ARM64-only.
> 

So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.

Graeme

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-05 Thread Graeme Gregory

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:
> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> >> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> >> > >>of view, am I right?
> >> > >
> >> > >The question is not "Can it?", but "Does it need to?".
> >> > >
> >> > >It is in the spec, but still there's only one architecture needing it.
> >> > >
> >> > >There is no way to test it on any other architecture and no reason to 
> >> > >build it
> >> > >for any other architecture, so why does it need to be located in 
> >> > >drivers/acpi/ ?
> >> >
> >> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
> >> > would like to ask ARM64 maintainer's suggestion for this.
> >> >
> >> > Will, Catalin, what's your opinion on this?
> >>
> >> We don't have any device-tree code for the architected timer under
> >> arch/arm64, so I don't see why we should need anything for ACPI either.
> >
> > And I don't see a reason for the GTDT code to be there in drivers/acpi/.
> >
> > What gives?
> 
> Well, since there are things like acpi_lpss in there, my position here
> is kind of weak. :-)
> 
> That said I'm not particularly happy with having them in
> drivers/acpi/, so I definitely won't object against attempts to moving
> them somewhere else.
> 
> > Maybe it should go to the same place as the analogus DT code, then?
> 
> I'm mostly concerned about how (and by whom) that code is going to be
> maintained going forward, though.  I also think it should be made
> clear that it is ARM64-only.
> 

So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.

Graeme

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Mon, Jul 4, 2016 at 3:43 PM, Daniel Lezcano
 wrote:
> On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
>> On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
>>> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
>>>
>
> [ ... ]
>
>>> clocksource-probe which is DT based with different drivers using it in
>>> drivers/clocksource with a pletore of different archs.
>>
>> So maybe the GTDT code should be there too?
>
> *maybe*
>
>>> Cstate code which is only used by x86 is in drivers/acpi, it is only
>>> used by x86/ia64 and it isn't a problem.
>>
>> It is a problem.
>
> Can you explain why it is a problem ?
>
>> drivers/acpi/ is not the right place for arch-specific code.
>
> I do not understand this assertion regarding what happened during the
> last years with different subsystems where the drivers were moved from
> their arch specific directories to the drivers directory (cpufreq,
> cpuidle, clockevent, clk, etc ...) and resulted at the end to a code
> refactoring and consolidation.
>
> Why ACPI should follow the opposite rule ?

Because drivers/acpi/ is for common and generic ACPI code.  Maybe it
should not be located under drivers/, but that's a different matter.

>>> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
>>> comprehension of the code.
>>>
>>> IMHO, having all ACPI code in the same directory will encourage the
>>> consolidation.
>>
>> The consolidation of what exactly?
>
> The consolidation of the ACPI code in general which is the
> counter-example of self-contained code.

Do you actually realize how much ACPI code is there in the kernel and
that moving it all into one directory would be totally
counter-productive?

You seem to be thinking that ACPI is something like cpufreq, where you
have the core and the drivers and nothing but the drivers uses the
core, but that's not the case.

>> In particular, how does the GTDT code in drivers/acpi/ help to consolidate
>> anything?
>
> If I imagine we group all ACPI code under a common directory, the first
> example coming in my mind is the sharing of private headers, reducing
> the scope of exported functions and global variables (eg. acpi_disabled).
>
> That say, I can understand grouping all the ACPI into a single directory
> will make it fall under a single umbrella's maintainer and that could be
> a nightmare to maintain as it covers a lot of different features.
> However, I believe that could be solved by clearly identifying who takes
> care of what.

And one way of doing that is to put things in different places in the
kernel source tree.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Mon, Jul 4, 2016 at 3:43 PM, Daniel Lezcano
 wrote:
> On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
>> On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
>>> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
>>>
>
> [ ... ]
>
>>> clocksource-probe which is DT based with different drivers using it in
>>> drivers/clocksource with a pletore of different archs.
>>
>> So maybe the GTDT code should be there too?
>
> *maybe*
>
>>> Cstate code which is only used by x86 is in drivers/acpi, it is only
>>> used by x86/ia64 and it isn't a problem.
>>
>> It is a problem.
>
> Can you explain why it is a problem ?
>
>> drivers/acpi/ is not the right place for arch-specific code.
>
> I do not understand this assertion regarding what happened during the
> last years with different subsystems where the drivers were moved from
> their arch specific directories to the drivers directory (cpufreq,
> cpuidle, clockevent, clk, etc ...) and resulted at the end to a code
> refactoring and consolidation.
>
> Why ACPI should follow the opposite rule ?

Because drivers/acpi/ is for common and generic ACPI code.  Maybe it
should not be located under drivers/, but that's a different matter.

>>> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
>>> comprehension of the code.
>>>
>>> IMHO, having all ACPI code in the same directory will encourage the
>>> consolidation.
>>
>> The consolidation of what exactly?
>
> The consolidation of the ACPI code in general which is the
> counter-example of self-contained code.

Do you actually realize how much ACPI code is there in the kernel and
that moving it all into one directory would be totally
counter-productive?

You seem to be thinking that ACPI is something like cpufreq, where you
have the core and the drivers and nothing but the drivers uses the
core, but that's not the case.

>> In particular, how does the GTDT code in drivers/acpi/ help to consolidate
>> anything?
>
> If I imagine we group all ACPI code under a common directory, the first
> example coming in my mind is the sharing of private headers, reducing
> the scope of exported functions and global variables (eg. acpi_disabled).
>
> That say, I can understand grouping all the ACPI into a single directory
> will make it fall under a single umbrella's maintainer and that could be
> a nightmare to maintain as it covers a lot of different features.
> However, I believe that could be solved by clearly identifying who takes
> care of what.

And one way of doing that is to put things in different places in the
kernel source tree.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-04 Thread Daniel Lezcano

On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
> On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
>> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
>>

[ ... ]

>> clocksource-probe which is DT based with different drivers using it in 
>> drivers/clocksource with a pletore of different archs.
> 
> So maybe the GTDT code should be there too?

*maybe*

>> Cstate code which is only used by x86 is in drivers/acpi, it is only 
>> used by x86/ia64 and it isn't a problem.
> 
> It is a problem.  

Can you explain why it is a problem ?

> drivers/acpi/ is not the right place for arch-specific code.

I do not understand this assertion regarding what happened during the
last years with different subsystems where the drivers were moved from
their arch specific directories to the drivers directory (cpufreq,
cpuidle, clockevent, clk, etc ...) and resulted at the end to a code
refactoring and consolidation.

Why ACPI should follow the opposite rule ?

>> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
>> comprehension of the code.
>>
>> IMHO, having all ACPI code in the same directory will encourage the 
>> consolidation.
> 
> The consolidation of what exactly?

The consolidation of the ACPI code in general which is the
counter-example of self-contained code.

> In particular, how does the GTDT code in drivers/acpi/ help to consolidate
> anything?

If I imagine we group all ACPI code under a common directory, the first
example coming in my mind is the sharing of private headers, reducing
the scope of exported functions and global variables (eg. acpi_disabled).

That say, I can understand grouping all the ACPI into a single directory
will make it fall under a single umbrella's maintainer and that could be
a nightmare to maintain as it covers a lot of different features.
However, I believe that could be solved by clearly identifying who takes
care of what.

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-04 Thread Daniel Lezcano

On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
> On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
>> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
>>

[ ... ]

>> clocksource-probe which is DT based with different drivers using it in 
>> drivers/clocksource with a pletore of different archs.
> 
> So maybe the GTDT code should be there too?

*maybe*

>> Cstate code which is only used by x86 is in drivers/acpi, it is only 
>> used by x86/ia64 and it isn't a problem.
> 
> It is a problem.  

Can you explain why it is a problem ?

> drivers/acpi/ is not the right place for arch-specific code.

I do not understand this assertion regarding what happened during the
last years with different subsystems where the drivers were moved from
their arch specific directories to the drivers directory (cpufreq,
cpuidle, clockevent, clk, etc ...) and resulted at the end to a code
refactoring and consolidation.

Why ACPI should follow the opposite rule ?

>> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
>> comprehension of the code.
>>
>> IMHO, having all ACPI code in the same directory will encourage the 
>> consolidation.
> 
> The consolidation of what exactly?

The consolidation of the ACPI code in general which is the
counter-example of self-contained code.

> In particular, how does the GTDT code in drivers/acpi/ help to consolidate
> anything?

If I imagine we group all ACPI code under a common directory, the first
example coming in my mind is the sharing of private headers, reducing
the scope of exported functions and global variables (eg. acpi_disabled).

That say, I can understand grouping all the ACPI into a single directory
will make it fall under a single umbrella's maintainer and that could be
a nightmare to maintain as it covers a lot of different features.
However, I believe that could be solved by clearly identifying who takes
care of what.

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:
> On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
>> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
>> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
>> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
>> > >>of view, am I right?
>> > >
>> > >The question is not "Can it?", but "Does it need to?".
>> > >
>> > >It is in the spec, but still there's only one architecture needing it.
>> > >
>> > >There is no way to test it on any other architecture and no reason to 
>> > >build it
>> > >for any other architecture, so why does it need to be located in 
>> > >drivers/acpi/ ?
>> >
>> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
>> > would like to ask ARM64 maintainer's suggestion for this.
>> >
>> > Will, Catalin, what's your opinion on this?
>>
>> We don't have any device-tree code for the architected timer under
>> arch/arm64, so I don't see why we should need anything for ACPI either.
>
> And I don't see a reason for the GTDT code to be there in drivers/acpi/.
>
> What gives?

Well, since there are things like acpi_lpss in there, my position here
is kind of weak. :-)

That said I'm not particularly happy with having them in
drivers/acpi/, so I definitely won't object against attempts to moving
them somewhere else.

> Maybe it should go to the same place as the analogus DT code, then?

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward, though.  I also think it should be made
clear that it is ARM64-only.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki  wrote:
> On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
>> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
>> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
>> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
>> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
>> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
>> > >>of view, am I right?
>> > >
>> > >The question is not "Can it?", but "Does it need to?".
>> > >
>> > >It is in the spec, but still there's only one architecture needing it.
>> > >
>> > >There is no way to test it on any other architecture and no reason to 
>> > >build it
>> > >for any other architecture, so why does it need to be located in 
>> > >drivers/acpi/ ?
>> >
>> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
>> > would like to ask ARM64 maintainer's suggestion for this.
>> >
>> > Will, Catalin, what's your opinion on this?
>>
>> We don't have any device-tree code for the architected timer under
>> arch/arm64, so I don't see why we should need anything for ACPI either.
>
> And I don't see a reason for the GTDT code to be there in drivers/acpi/.
>
> What gives?

Well, since there are things like acpi_lpss in there, my position here
is kind of weak. :-)

That said I'm not particularly happy with having them in
drivers/acpi/, so I definitely won't object against attempts to moving
them somewhere else.

> Maybe it should go to the same place as the analogus DT code, then?

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward, though.  I also think it should be made
clear that it is ARM64-only.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> > >>of view, am I right?
> > >
> > >The question is not "Can it?", but "Does it need to?".
> > >
> > >It is in the spec, but still there's only one architecture needing it.
> > >
> > >There is no way to test it on any other architecture and no reason to 
> > >build it
> > >for any other architecture, so why does it need to be located in 
> > >drivers/acpi/ ?
> > 
> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
> > would like to ask ARM64 maintainer's suggestion for this.
> > 
> > Will, Catalin, what's your opinion on this?
> 
> We don't have any device-tree code for the architected timer under
> arch/arm64, so I don't see why we should need anything for ACPI either.

And I don't see a reason for the GTDT code to be there in drivers/acpi/.

What gives?

Maybe it should go to the same place as the analogus DT code, then?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> > On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> > >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> > >>of view, am I right?
> > >
> > >The question is not "Can it?", but "Does it need to?".
> > >
> > >It is in the spec, but still there's only one architecture needing it.
> > >
> > >There is no way to test it on any other architecture and no reason to 
> > >build it
> > >for any other architecture, so why does it need to be located in 
> > >drivers/acpi/ ?
> > 
> > I'm fine to move it to other places such as arch/arm64/kernel/, but I
> > would like to ask ARM64 maintainer's suggestion for this.
> > 
> > Will, Catalin, what's your opinion on this?
> 
> We don't have any device-tree code for the architected timer under
> arch/arm64, so I don't see why we should need anything for ACPI either.

And I don't see a reason for the GTDT code to be there in drivers/acpi/.

What gives?

Maybe it should go to the same place as the analogus DT code, then?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
> 
> [ ... ]
> 
> >> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >> ACPI spec, I think it can stay in drivers/acpi/ from this point
> >> of view, am I right?
> >
> > The question is not "Can it?", but "Does it need to?".
> >
> > It is in the spec, but still there's only one architecture needing it.
> >
> > There is no way to test it on any other architecture and no reason to build 
> > it
> > for any other architecture, so why does it need to be located in 
> > drivers/acpi/ ?
> 
> Hi Rafael,
> 
> what is the problem of having it in drivers/acpi ?

There's no reason for it to be there.

> There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.

Yes, they are, but for a reason.  Having them in there makes it easier to
rework and clean up the core.

> clocksource-probe which is DT based with different drivers using it in 
> drivers/clocksource with a pletore of different archs.

So maybe the GTDT code should be there too?

> Cstate code which is only used by x86 is in drivers/acpi, it is only 
> used by x86/ia64 and it isn't a problem.

It is a problem.  drivers/acpi/ is not the right place for arch-specific code.

> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
> comprehension of the code.
> 
> IMHO, having all ACPI code in the same directory will encourage the 
> consolidation.

The consolidation of what exactly?

In particular, how does the GTDT code in drivers/acpi/ help to consolidate
anything?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
> 
> [ ... ]
> 
> >> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >> ACPI spec, I think it can stay in drivers/acpi/ from this point
> >> of view, am I right?
> >
> > The question is not "Can it?", but "Does it need to?".
> >
> > It is in the spec, but still there's only one architecture needing it.
> >
> > There is no way to test it on any other architecture and no reason to build 
> > it
> > for any other architecture, so why does it need to be located in 
> > drivers/acpi/ ?
> 
> Hi Rafael,
> 
> what is the problem of having it in drivers/acpi ?

There's no reason for it to be there.

> There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.

Yes, they are, but for a reason.  Having them in there makes it easier to
rework and clean up the core.

> clocksource-probe which is DT based with different drivers using it in 
> drivers/clocksource with a pletore of different archs.

So maybe the GTDT code should be there too?

> Cstate code which is only used by x86 is in drivers/acpi, it is only 
> used by x86/ia64 and it isn't a problem.

It is a problem.  drivers/acpi/ is not the right place for arch-specific code.

> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
> comprehension of the code.
> 
> IMHO, having all ACPI code in the same directory will encourage the 
> consolidation.

The consolidation of what exactly?

In particular, how does the GTDT code in drivers/acpi/ help to consolidate
anything?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-01 Thread Will Deacon

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> >>of view, am I right?
> >
> >The question is not "Can it?", but "Does it need to?".
> >
> >It is in the spec, but still there's only one architecture needing it.
> >
> >There is no way to test it on any other architecture and no reason to build 
> >it
> >for any other architecture, so why does it need to be located in 
> >drivers/acpi/ ?
> 
> I'm fine to move it to other places such as arch/arm64/kernel/, but I
> would like to ask ARM64 maintainer's suggestion for this.
> 
> Will, Catalin, what's your opinion on this?

We don't have any device-tree code for the architected timer under
arch/arm64, so I don't see why we should need anything for ACPI either.

Will

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-01 Thread Will Deacon

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> On 2016/6/30 21:27, Rafael J. Wysocki wrote:
> >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> >>ACPI spec, I think it can stay in drivers/acpi/ from this point
> >>of view, am I right?
> >
> >The question is not "Can it?", but "Does it need to?".
> >
> >It is in the spec, but still there's only one architecture needing it.
> >
> >There is no way to test it on any other architecture and no reason to build 
> >it
> >for any other architecture, so why does it need to be located in 
> >drivers/acpi/ ?
> 
> I'm fine to move it to other places such as arch/arm64/kernel/, but I
> would like to ask ARM64 maintainer's suggestion for this.
> 
> Will, Catalin, what's your opinion on this?

We don't have any device-tree code for the architected timer under
arch/arm64, so I don't see why we should need anything for ACPI either.

Will

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-01 Thread Daniel Lezcano


On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:

[ ... ]


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


Hi Rafael,

what is the problem of having it in drivers/acpi ?

There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.

clocksource-probe which is DT based with different drivers using it in 
drivers/clocksource with a pletore of different archs.


Cstate code which is only used by x86 is in drivers/acpi, it is only 
used by x86/ia64 and it isn't a problem. There is a small chunk in 
arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the 
code.


IMHO, having all ACPI code in the same directory will encourage the 
consolidation.




--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-07-01 Thread Daniel Lezcano


On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:

[ ... ]


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


Hi Rafael,

what is the problem of having it in drivers/acpi ?

There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.

clocksource-probe which is DT based with different drivers using it in 
drivers/clocksource with a pletore of different archs.


Cstate code which is only used by x86 is in drivers/acpi, it is only 
used by x86/ia64 and it isn't a problem. There is a small chunk in 
arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the 
code.


IMHO, having all ACPI code in the same directory will encourage the 
consolidation.




--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-30 Thread Hanjun Guo


On 2016/6/30 21:27, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:

Hi Rafael,

On 2016/6/30 9:37, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:

On Wed, Jun 29, 2016 at 8:15 PM,   wrote:

From: Fu Wei 

This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer
1. Move some enums and marcos to header file
2. Add a new enum for spi type.
3. Improve printk relevant code

(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
Parse all kinds of timer in GTDT table of ACPI:arch timer,
memory-mapped timer and SBSA Generic Watchdog timer.
This driver can help to simplify all the relevant timer drivers,
and separate all the ACPI GTDT knowledge from them.

(3)Simplify ACPI code for arm_arch_timer

(4)Add GTDT support for ARM memory-mapped timer


GTDT is ARM-specific AFAICS.


yes, you are right, it is.



If so, why do we need that code to reside in drivers/acpi/ ?


Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)


Yes, you are.  Nobody except for ARM64 will ever need it.


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


I'm fine to move it to other places such as arch/arm64/kernel/, but I
would like to ask ARM64 maintainer's suggestion for this.

Will, Catalin, what's your opinion on this?

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-30 Thread Hanjun Guo


On 2016/6/30 21:27, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:

Hi Rafael,

On 2016/6/30 9:37, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:

On Wed, Jun 29, 2016 at 8:15 PM,   wrote:

From: Fu Wei 

This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer
1. Move some enums and marcos to header file
2. Add a new enum for spi type.
3. Improve printk relevant code

(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
Parse all kinds of timer in GTDT table of ACPI:arch timer,
memory-mapped timer and SBSA Generic Watchdog timer.
This driver can help to simplify all the relevant timer drivers,
and separate all the ACPI GTDT knowledge from them.

(3)Simplify ACPI code for arm_arch_timer

(4)Add GTDT support for ARM memory-mapped timer


GTDT is ARM-specific AFAICS.


yes, you are right, it is.



If so, why do we need that code to reside in drivers/acpi/ ?


Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)


Yes, you are.  Nobody except for ARM64 will ever need it.


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?


The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?


I'm fine to move it to other places such as arch/arm64/kernel/, but I
would like to ask ARM64 maintainer's suggestion for this.

Will, Catalin, what's your opinion on this?

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-30 Thread Rafael J. Wysocki

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> Hi Rafael,
> 
> On 2016/6/30 9:37, Rafael J. Wysocki wrote:
> > On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
> >> Hi Rafael,
> >>
> >> On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> >>> On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
>  From: Fu Wei 
> 
>  This patchset:
>  (1)Preparation for adding GTDT support in arm_arch_timer
>  1. Move some enums and marcos to header file
>  2. Add a new enum for spi type.
>  3. Improve printk relevant code
> 
>  (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
>  Parse all kinds of timer in GTDT table of ACPI:arch timer,
>  memory-mapped timer and SBSA Generic Watchdog timer.
>  This driver can help to simplify all the relevant timer drivers,
>  and separate all the ACPI GTDT knowledge from them.
> 
>  (3)Simplify ACPI code for arm_arch_timer
> 
>  (4)Add GTDT support for ARM memory-mapped timer
> >>>
> >>> GTDT is ARM-specific AFAICS.
> >>
> >> yes, you are right, it is.
> >>
> >>>
> >>> If so, why do we need that code to reside in drivers/acpi/ ?
> >>
> >> Although  the GTDT is just for ARM64, but this driver is parsing one
> >> of ACPI table,
> >> I think that could be treated as ACPI driver.  Do I miss something? :-)
> >
> > Yes, you are.  Nobody except for ARM64 will ever need it.
> 
> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> ACPI spec, I think it can stay in drivers/acpi/ from this point
> of view, am I right?

The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-30 Thread Rafael J. Wysocki

On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
> Hi Rafael,
> 
> On 2016/6/30 9:37, Rafael J. Wysocki wrote:
> > On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
> >> Hi Rafael,
> >>
> >> On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> >>> On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
>  From: Fu Wei 
> 
>  This patchset:
>  (1)Preparation for adding GTDT support in arm_arch_timer
>  1. Move some enums and marcos to header file
>  2. Add a new enum for spi type.
>  3. Improve printk relevant code
> 
>  (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
>  Parse all kinds of timer in GTDT table of ACPI:arch timer,
>  memory-mapped timer and SBSA Generic Watchdog timer.
>  This driver can help to simplify all the relevant timer drivers,
>  and separate all the ACPI GTDT knowledge from them.
> 
>  (3)Simplify ACPI code for arm_arch_timer
> 
>  (4)Add GTDT support for ARM memory-mapped timer
> >>>
> >>> GTDT is ARM-specific AFAICS.
> >>
> >> yes, you are right, it is.
> >>
> >>>
> >>> If so, why do we need that code to reside in drivers/acpi/ ?
> >>
> >> Although  the GTDT is just for ARM64, but this driver is parsing one
> >> of ACPI table,
> >> I think that could be treated as ACPI driver.  Do I miss something? :-)
> >
> > Yes, you are.  Nobody except for ARM64 will ever need it.
> 
> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
> ACPI spec, I think it can stay in drivers/acpi/ from this point
> of view, am I right?

The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-29 Thread Hanjun Guo


Hi Rafael,

On 2016/6/30 9:37, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:

On Wed, Jun 29, 2016 at 8:15 PM,   wrote:

From: Fu Wei 

This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer
1. Move some enums and marcos to header file
2. Add a new enum for spi type.
3. Improve printk relevant code

(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
Parse all kinds of timer in GTDT table of ACPI:arch timer,
memory-mapped timer and SBSA Generic Watchdog timer.
This driver can help to simplify all the relevant timer drivers,
and separate all the ACPI GTDT knowledge from them.

(3)Simplify ACPI code for arm_arch_timer

(4)Add GTDT support for ARM memory-mapped timer


GTDT is ARM-specific AFAICS.


yes, you are right, it is.



If so, why do we need that code to reside in drivers/acpi/ ?


Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)


Yes, you are.  Nobody except for ARM64 will ever need it.


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-29 Thread Hanjun Guo


Hi Rafael,

On 2016/6/30 9:37, Rafael J. Wysocki wrote:

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:

On Wed, Jun 29, 2016 at 8:15 PM,   wrote:

From: Fu Wei 

This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer
1. Move some enums and marcos to header file
2. Add a new enum for spi type.
3. Improve printk relevant code

(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
Parse all kinds of timer in GTDT table of ACPI:arch timer,
memory-mapped timer and SBSA Generic Watchdog timer.
This driver can help to simplify all the relevant timer drivers,
and separate all the ACPI GTDT knowledge from them.

(3)Simplify ACPI code for arm_arch_timer

(4)Add GTDT support for ARM memory-mapped timer


GTDT is ARM-specific AFAICS.


yes, you are right, it is.



If so, why do we need that code to reside in drivers/acpi/ ?


Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)


Yes, you are.  Nobody except for ARM64 will ever need it.


GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
> Hi Rafael,
> 
> On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> > On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
> >> From: Fu Wei 
> >>
> >> This patchset:
> >> (1)Preparation for adding GTDT support in arm_arch_timer
> >> 1. Move some enums and marcos to header file
> >> 2. Add a new enum for spi type.
> >> 3. Improve printk relevant code
> >>
> >> (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
> >> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> >> memory-mapped timer and SBSA Generic Watchdog timer.
> >> This driver can help to simplify all the relevant timer drivers,
> >> and separate all the ACPI GTDT knowledge from them.
> >>
> >> (3)Simplify ACPI code for arm_arch_timer
> >>
> >> (4)Add GTDT support for ARM memory-mapped timer
> >
> > GTDT is ARM-specific AFAICS.
> 
> yes, you are right, it is.
> 
> >
> > If so, why do we need that code to reside in drivers/acpi/ ?
> 
> Although  the GTDT is just for ARM64, but this driver is parsing one
> of ACPI table,
> I think that could be treated as ACPI driver.  Do I miss something? :-)

Yes, you are.  Nobody except for ARM64 will ever need it.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
> Hi Rafael,
> 
> On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> > On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
> >> From: Fu Wei 
> >>
> >> This patchset:
> >> (1)Preparation for adding GTDT support in arm_arch_timer
> >> 1. Move some enums and marcos to header file
> >> 2. Add a new enum for spi type.
> >> 3. Improve printk relevant code
> >>
> >> (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
> >> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> >> memory-mapped timer and SBSA Generic Watchdog timer.
> >> This driver can help to simplify all the relevant timer drivers,
> >> and separate all the ACPI GTDT knowledge from them.
> >>
> >> (3)Simplify ACPI code for arm_arch_timer
> >>
> >> (4)Add GTDT support for ARM memory-mapped timer
> >
> > GTDT is ARM-specific AFAICS.
> 
> yes, you are right, it is.
> 
> >
> > If so, why do we need that code to reside in drivers/acpi/ ?
> 
> Although  the GTDT is just for ARM64, but this driver is parsing one
> of ACPI table,
> I think that could be treated as ACPI driver.  Do I miss something? :-)

Yes, you are.  Nobody except for ARM64 will ever need it.

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-29 Thread Fu Wei

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
>> From: Fu Wei 
>>
>> This patchset:
>> (1)Preparation for adding GTDT support in arm_arch_timer
>> 1. Move some enums and marcos to header file
>> 2. Add a new enum for spi type.
>> 3. Improve printk relevant code
>>
>> (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>> memory-mapped timer and SBSA Generic Watchdog timer.
>> This driver can help to simplify all the relevant timer drivers,
>> and separate all the ACPI GTDT knowledge from them.
>>
>> (3)Simplify ACPI code for arm_arch_timer
>>
>> (4)Add GTDT support for ARM memory-mapped timer
>
> GTDT is ARM-specific AFAICS.

yes, you are right, it is.

>
> If so, why do we need that code to reside in drivers/acpi/ ?

Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)

>
> Thanks,
> Rafael



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

2016-06-29 Thread Fu Wei

Hi Rafael,

On 30 June 2016 at 05:32, Rafael J. Wysocki  wrote:
> On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
>> From: Fu Wei 
>>
>> This patchset:
>> (1)Preparation for adding GTDT support in arm_arch_timer
>> 1. Move some enums and marcos to header file
>> 2. Add a new enum for spi type.
>> 3. Improve printk relevant code
>>
>> (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>> memory-mapped timer and SBSA Generic Watchdog timer.
>> This driver can help to simplify all the relevant timer drivers,
>> and separate all the ACPI GTDT knowledge from them.
>>
>> (3)Simplify ACPI code for arm_arch_timer
>>
>> (4)Add GTDT support for ARM memory-mapped timer
>
> GTDT is ARM-specific AFAICS.

yes, you are right, it is.

>
> If so, why do we need that code to reside in drivers/acpi/ ?

Although  the GTDT is just for ARM64, but this driver is parsing one
of ACPI table,
I think that could be treated as ACPI driver.  Do I miss something? :-)

>
> Thanks,
> Rafael



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Wed, Jun 29, 2016 at 8:15 PM,   wrote:
> From: Fu Wei 
>
> This patchset:
> (1)Preparation for adding GTDT support in arm_arch_timer
> 1. Move some enums and marcos to header file
> 2. Add a new enum for spi type.
> 3. Improve printk relevant code
>
> (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> memory-mapped timer and SBSA Generic Watchdog timer.
> This driver can help to simplify all the relevant timer drivers,
> and separate all the ACPI GTDT knowledge from them.
>
> (3)Simplify ACPI code for arm_arch_timer
>
> (4)Add GTDT support for ARM memory-mapped timer

GTDT is ARM-specific AFAICS.

If so, why do we need that code to reside in drivers/acpi/ ?

Thanks,
Rafael

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer