Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1433943 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver fu.wei@linaro.org - 2016-06-29 20:20 +0200
      Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in  GTDT driver "Rafael J. Wysocki" <rafael@kernel.org> - 2016-06-29 23:30 +0200
        Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in  GTDT driver Fu Wei <fu.wei@linaro.org> - 2016-06-30 03:20 +0200
          Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-30 03:30 +0200
            Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in  GTDT driver Fu Wei <fu.wei@linaro.org> - 2016-06-30 03:40 +0200
            Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in  GTDT driver Timur Tabi <timur@codeaurora.org> - 2016-06-30 06:20 +0200
    [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 07/10] clocksource/drivers/arm_arch_timer: Simplify ACPI support code. fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei@linaro.org - 2016-06-29 20:20 +0200
      Re: [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve  printk relevant code Hanjun Guo <hanjun.guo@linaro.org> - 2016-06-30 05:00 +0200
        Re: [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve  printk relevant code Fu Wei <fu.wei@linaro.org> - 2016-07-07 18:20 +0200
    [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei@linaro.org - 2016-06-29 20:20 +0200
    [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver fu.wei@linaro.org - 2016-06-29 20:30 +0200
    Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer "Rafael J. Wysocki" <rafael@kernel.org> - 2016-06-29 23:40 +0200
      Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Fu Wei <fu.wei@linaro.org> - 2016-06-30 03:40 +0200
        Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-30 03:40 +0200
          Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Hanjun Guo <hanjun.guo@linaro.org> - 2016-06-30 04:20 +0200
            Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-30 15:30 +0200
              Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Hanjun Guo <hanjun.guo@linaro.org> - 2016-06-30 16:10 +0200
                Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Will Deacon <will.deacon@arm.com> - 2016-07-01 17:30 +0200
                  Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-01 23:00 +0200
                    Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer "Rafael J. Wysocki" <rafael@kernel.org> - 2016-07-04 15:00 +0200
                      Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Graeme Gregory <gg@slimlogic.co.uk> - 2016-07-05 16:20 +0200
                        Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer "Rafael J. Wysocki" <rafael@kernel.org> - 2016-07-06 02:10 +0200
                          Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Hanjun Guo <hanjun.guo@linaro.org> - 2016-07-07 13:20 +0200
                            Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-07 14:00 +0200
                              Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-07-07 15:40 +0200
                                Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-07 16:00 +0200
                                  Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Fu Wei <fu.wei@linaro.org> - 2016-07-07 17:30 +0200
                                  Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-07-08 15:30 +0200
                                    Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Sudeep Holla <sudeep.holla@arm.com> - 2016-07-08 16:00 +0200
                                    Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Hanjun Guo <hanjun.guo@linaro.org> - 2016-07-09 05:50 +0200
                                  Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Hanjun Guo <hanjun.guo@linaro.org> - 2016-07-09 05:10 +0200
              Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-07-01 16:10 +0200
                Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-01 23:00 +0200
                  Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-07-04 15:50 +0200
                    Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT  support in arm_arch_timer "Rafael J. Wysocki" <rafael@kernel.org> - 2016-07-04 16:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1434151

On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
> Hi Rafael,
> 
> On 30 June 2016 at 05:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Wed, Jun 29, 2016 at 8:15 PM,  <fu.wei@linaro.org> wrote:
> >> From: Fu Wei <fu.wei@linaro.org>
> >>
> >> 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

[toc] | [prev] | [next] | [standalone]

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

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 <rafael@kernel.org> wrote:
>>> On Wed, Jun 29, 2016 at 8:15 PM,  <fu.wei@linaro.org> wrote:
>>>> From: Fu Wei <fu.wei@linaro.org>
>>>>
>>>> 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

[toc] | [prev] | [next] | [standalone]

#1434551

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 <rafael@kernel.org> wrote:
> >>> On Wed, Jun 29, 2016 at 8:15 PM,  <fu.wei@linaro.org> wrote:
> >>>> From: Fu Wei <fu.wei@linaro.org>
> >>>>
> >>>> 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

[toc] | [prev] | [next] | [standalone]

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

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 <rafael@kernel.org> wrote:
>>>>> On Wed, Jun 29, 2016 at 8:15 PM,  <fu.wei@linaro.org> wrote:
>>>>>> From: Fu Wei <fu.wei@linaro.org>
>>>>>>
>>>>>> 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1435624

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

[toc] | [prev] | [next] | [standalone]

#1436474 — 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 <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

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

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 <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory <gg@slimlogic.co.uk> 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 <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

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

On 2016/7/6 8:00, Rafael J. Wysocki wrote:
> On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory <gg@slimlogic.co.uk> 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 <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

#1438543

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 <gg@slimlogic.co.uk> 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 <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

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

[+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

[toc] | [prev] | [next] | [standalone]

#1438639

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

[toc] | [prev] | [next] | [standalone]

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

Hi Rafael,

On 7 July 2016 at 21:58, Rafael J. Wysocki <rjw@rjwysocki.net> 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1439889 — 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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#1439880 — 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

[toc] | [prev] | [next] | [standalone]

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

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.



-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [prev] | [next] | [standalone]

#1435622

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web