[PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

The related driver need depend on HAS_IOMEM, or may be built under UML
architecture.

The related error (with allmodconfig, without pcap):

    CC [M]  drivers/ptp/ptp_pch.o
  drivers/ptp/ptp_pch.c: In function ‘pch_remove’:
  drivers/ptp/ptp_pch.c:571:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration]
  drivers/ptp/ptp_pch.c: In function ‘pch_probe’:
  drivers/ptp/ptp_pch.c:621:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration]
  drivers/ptp/ptp_pch.c:621:13: warning: assignment makes pointer from integer without a cast [enabled by default]
  cc1: some warnings being treated as errors

Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 drivers/ptp/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 5be73ba..5a7910e 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -73,6 +73,7 @@ config DP83640_PHY
 config PTP_1588_CLOCK_PCH
 	tristate "Intel PCH EG20T as PTP clock"
 	depends on X86 || COMPILE_TEST
+	depends on HAS_IOMEM
 	select PTP_1588_CLOCK
 	help
 	  This driver adds support for using the PCH EG20T as a PTP
-- 
1.7.7.6

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Geert Uytterhoeven]

On Thu, Jun 27, 2013 at 2:52 AM, Chen Gang <gang.chen@asianux.com> wrote:
> The related driver need depend on HAS_IOMEM, or may be built under UML
> architecture.
>
> The related error (with allmodconfig, without pcap):
>
>     CC [M]  drivers/ptp/ptp_pch.o
>   drivers/ptp/ptp_pch.c: In function ‘pch_remove’:
>   drivers/ptp/ptp_pch.c:571:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration]
>   drivers/ptp/ptp_pch.c: In function ‘pch_probe’:
>   drivers/ptp/ptp_pch.c:621:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration]
>   drivers/ptp/ptp_pch.c:621:13: warning: assignment makes pointer from integer without a cast [enabled by default]
>   cc1: some warnings being treated as errors
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 06/27/2013 02:48 PM, Geert Uytterhoeven wrote:
> On Thu, Jun 27, 2013 at 2:52 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > The related driver need depend on HAS_IOMEM, or may be built under UML
>> > architecture.
>> >
>> > The related error (with allmodconfig, without pcap):
>> >
>> >     CC [M]  drivers/ptp/ptp_pch.o
>> >   drivers/ptp/ptp_pch.c: In function ‘pch_remove’:
>> >   drivers/ptp/ptp_pch.c:571:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration]
>> >   drivers/ptp/ptp_pch.c: In function ‘pch_probe’:
>> >   drivers/ptp/ptp_pch.c:621:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration]
>> >   drivers/ptp/ptp_pch.c:621:13: warning: assignment makes pointer from integer without a cast [enabled by default]
>> >   cc1: some warnings being treated as errors
>> >
>> > Signed-off-by: Chen Gang <gang.chen@asianux.com>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks.

-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[David Miller]

From: Chen Gang <gang.chen@asianux.com>
Date: Thu, 27 Jun 2013 08:52:07 +0800

> @@ -73,6 +73,7 @@ config DP83640_PHY
>  config PTP_1588_CLOCK_PCH
>  	tristate "Intel PCH EG20T as PTP clock"
>  	depends on X86 || COMPILE_TEST

This "depends on X86 || COMPILE_TEST" does not exist in either 'net' or 'net-next'.
Please submit your patches against a clean checkout of the networking GIT tree,
rather than something else such as linux-next.

Thanks.

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 06/29/2013 12:23 PM, David Miller wrote:
> From: Chen Gang <gang.chen@asianux.com>
> Date: Thu, 27 Jun 2013 08:52:07 +0800
> 
>> > @@ -73,6 +73,7 @@ config DP83640_PHY
>> >  config PTP_1588_CLOCK_PCH
>> >  	tristate "Intel PCH EG20T as PTP clock"
>> >  	depends on X86 || COMPILE_TEST
> This "depends on X86 || COMPILE_TEST" does not exist in either 'net' or 'net-next'.
> Please submit your patches against a clean checkout of the networking GIT tree,
> rather than something else such as linux-next.

Oh, really it is, It is my fault (originally I get mail address from
"./scripts/get_maintainers.pl", but not give additional check on it).

For your information (or implicit suggestion), if one module wants to
request 'COMPILE_TEST', the platforms (or asm-generic) is recommended to
try to support it.

It seems I still have the chance to continue discuss about it with
platform guys. ;-)

Thanks.
-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Richard Weinberger]

Am 01.07.2013 03:34, schrieb Chen Gang:
> On 06/29/2013 12:23 PM, David Miller wrote:
>> From: Chen Gang <gang.chen@asianux.com>
>> Date: Thu, 27 Jun 2013 08:52:07 +0800
>>
>>>> @@ -73,6 +73,7 @@ config DP83640_PHY
>>>>  config PTP_1588_CLOCK_PCH
>>>>  	tristate "Intel PCH EG20T as PTP clock"
>>>>  	depends on X86 || COMPILE_TEST
>> This "depends on X86 || COMPILE_TEST" does not exist in either 'net' or 'net-next'.
>> Please submit your patches against a clean checkout of the networking GIT tree,
>> rather than something else such as linux-next.
> 
> Oh, really it is, It is my fault (originally I get mail address from
> "./scripts/get_maintainers.pl", but not give additional check on it).
> 
> For your information (or implicit suggestion), if one module wants to
> request 'COMPILE_TEST', the platforms (or asm-generic) is recommended to
> try to support it.
> 
> It seems I still have the chance to continue discuss about it with
> platform guys. ;-)

David told you that your patch does not apply.
Not even Linus' tree has "depends on X86 || COMPILE_TEST".
Please adjust your patch.

Thanks,
//richard

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 07/01/2013 01:40 PM, Richard Weinberger wrote:
> Am 01.07.2013 03:34, schrieb Chen Gang:
>> > On 06/29/2013 12:23 PM, David Miller wrote:
>>> >> From: Chen Gang <gang.chen@asianux.com>
>>> >> Date: Thu, 27 Jun 2013 08:52:07 +0800
>>> >>
>>>>> >>>> @@ -73,6 +73,7 @@ config DP83640_PHY
>>>>> >>>>  config PTP_1588_CLOCK_PCH
>>>>> >>>>  	tristate "Intel PCH EG20T as PTP clock"
>>>>> >>>>  	depends on X86 || COMPILE_TEST
>>> >> This "depends on X86 || COMPILE_TEST" does not exist in either 'net' or 'net-next'.
>>> >> Please submit your patches against a clean checkout of the networking GIT tree,
>>> >> rather than something else such as linux-next.
>> > 
>> > Oh, really it is, It is my fault (originally I get mail address from
>> > "./scripts/get_maintainers.pl", but not give additional check on it).
>> > 
>> > For your information (or implicit suggestion), if one module wants to
>> > request 'COMPILE_TEST', the platforms (or asm-generic) is recommended to
>> > try to support it.
>> > 
>> > It seems I still have the chance to continue discuss about it with
>> > platform guys. ;-)
> David told you that your patch does not apply.
> Not even Linus' tree has "depends on X86 || COMPILE_TEST".
> Please adjust your patch.


Before send the patch, it is better to discuss the "asm-generic"
whether need consider 'COMPILE_TEST'.

config COMPILE_TEST
        bool "Compile also drivers which will not load"
        default n
        help
          Some drivers can be compiled on a different platform than they are
          intended to be run on. Despite they cannot be loaded there (or even
          when they load they cannot be used due to missing HW support),
          developers still, opposing to distributors, might want to build such
          drivers to compile-test them.

          If you are a developer and want to build everything available, say Y
          here. If you are a user/distributor, say N here to exclude useless
          drivers to be distributed.

I guess, 'COMPILE_TEST' is really useful for UML.

Thanks.
-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Richard Weinberger]

Am 01.07.2013 08:09, schrieb Chen Gang:
> On 07/01/2013 01:40 PM, Richard Weinberger wrote:
>> Am 01.07.2013 03:34, schrieb Chen Gang:
>>>> On 06/29/2013 12:23 PM, David Miller wrote:
>>>>>> From: Chen Gang <gang.chen@asianux.com>
>>>>>> Date: Thu, 27 Jun 2013 08:52:07 +0800
>>>>>>
>>>>>>>>>> @@ -73,6 +73,7 @@ config DP83640_PHY
>>>>>>>>>>  config PTP_1588_CLOCK_PCH
>>>>>>>>>>  	tristate "Intel PCH EG20T as PTP clock"
>>>>>>>>>>  	depends on X86 || COMPILE_TEST
>>>>>> This "depends on X86 || COMPILE_TEST" does not exist in either 'net' or 'net-next'.
>>>>>> Please submit your patches against a clean checkout of the networking GIT tree,
>>>>>> rather than something else such as linux-next.
>>>>
>>>> Oh, really it is, It is my fault (originally I get mail address from
>>>> "./scripts/get_maintainers.pl", but not give additional check on it).
>>>>
>>>> For your information (or implicit suggestion), if one module wants to
>>>> request 'COMPILE_TEST', the platforms (or asm-generic) is recommended to
>>>> try to support it.
>>>>
>>>> It seems I still have the chance to continue discuss about it with
>>>> platform guys. ;-)
>> David told you that your patch does not apply.
>> Not even Linus' tree has "depends on X86 || COMPILE_TEST".
>> Please adjust your patch.
> 
> 
> Before send the patch, it is better to discuss the "asm-generic"
> whether need consider 'COMPILE_TEST'.

No.

> config COMPILE_TEST
>         bool "Compile also drivers which will not load"
>         default n
>         help
>           Some drivers can be compiled on a different platform than they are
>           intended to be run on. Despite they cannot be loaded there (or even
>           when they load they cannot be used due to missing HW support),
>           developers still, opposing to distributors, might want to build such
>           drivers to compile-test them.
> 
>           If you are a developer and want to build everything available, say Y
>           here. If you are a user/distributor, say N here to exclude useless
>           drivers to be distributed.
> 
> I guess, 'COMPILE_TEST' is really useful for UML.

No.

We have explained you more than once what the deal and why UML does not
have ioremap() and friends.

Thanks,
//richard

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 07/01/2013 02:34 PM, Richard Weinberger wrote:
>> config COMPILE_TEST
>> >         bool "Compile also drivers which will not load"
>> >         default n
>> >         help
>> >           Some drivers can be compiled on a different platform than they are
>> >           intended to be run on. Despite they cannot be loaded there (or even
>> >           when they load they cannot be used due to missing HW support),
>> >           developers still, opposing to distributors, might want to build such
>> >           drivers to compile-test them.
>> > 
>> >           If you are a developer and want to build everything available, say Y
>> >           here. If you are a user/distributor, say N here to exclude useless
>> >           drivers to be distributed.
>> > 
>> > I guess, 'COMPILE_TEST' is really useful for UML.
> No.
> 
> We have explained you more than once what the deal and why UML does not
> have ioremap() and friends.

This time, it is not for UML, it is for 'COMPILE_TEST': the
'asm-generic' whether need consider it.


Thanks.
-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Geert Uytterhoeven]

On Mon, Jul 1, 2013 at 8:44 AM, Chen Gang <gang.chen@asianux.com> wrote:
> On 07/01/2013 02:34 PM, Richard Weinberger wrote:
>>> config COMPILE_TEST
>>> >         bool "Compile also drivers which will not load"
>>> >         default n
>>> >         help
>>> >           Some drivers can be compiled on a different platform than they are
>>> >           intended to be run on. Despite they cannot be loaded there (or even
>>> >           when they load they cannot be used due to missing HW support),
>>> >           developers still, opposing to distributors, might want to build such
>>> >           drivers to compile-test them.
>>> >
>>> >           If you are a developer and want to build everything available, say Y
>>> >           here. If you are a user/distributor, say N here to exclude useless
>>> >           drivers to be distributed.
>>> >
>>> > I guess, 'COMPILE_TEST' is really useful for UML.
>> No.
>>
>> We have explained you more than once what the deal and why UML does not
>> have ioremap() and friends.
>
> This time, it is not for UML, it is for 'COMPILE_TEST': the
> 'asm-generic' whether need consider it.

COMPILE_TEST is only meant to be used as a dependency in Kconfig files,
to make drivers that cannot work due to missing hardware invisible when
configuring your kernel.

There should be no #ifdefs in actual code that check for (the lack of)
CONFIG_COMPILE_TEST.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 07/01/2013 03:32 PM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 8:44 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > On 07/01/2013 02:34 PM, Richard Weinberger wrote:
>>>> >>> config COMPILE_TEST
>>>>> >>> >         bool "Compile also drivers which will not load"
>>>>> >>> >         default n
>>>>> >>> >         help
>>>>> >>> >           Some drivers can be compiled on a different platform than they are
>>>>> >>> >           intended to be run on. Despite they cannot be loaded there (or even
>>>>> >>> >           when they load they cannot be used due to missing HW support),
>>>>> >>> >           developers still, opposing to distributors, might want to build such
>>>>> >>> >           drivers to compile-test them.
>>>>> >>> >
>>>>> >>> >           If you are a developer and want to build everything available, say Y
>>>>> >>> >           here. If you are a user/distributor, say N here to exclude useless
>>>>> >>> >           drivers to be distributed.
>>>>> >>> >
>>>>> >>> > I guess, 'COMPILE_TEST' is really useful for UML.
>>> >> No.
>>> >>
>>> >> We have explained you more than once what the deal and why UML does not
>>> >> have ioremap() and friends.
>> >
>> > This time, it is not for UML, it is for 'COMPILE_TEST': the
>> > 'asm-generic' whether need consider it.
> COMPILE_TEST is only meant to be used as a dependency in Kconfig files,
> to make drivers that cannot work due to missing hardware invisible when
> configuring your kernel.
> 

Why "Despite they cannot be loaded there (or even when they load they
cannot be used due to missing HW support)" ?

> There should be no #ifdefs in actual code that check for (the lack of)
> CONFIG_COMPILE_TEST.

In ideal world, it should be no #ifdefs for all "CONFIG_*" in 'normal code'.

But "asm-generic" are not belong to 'normal code', it is one of the main
place to process "CONFIG_*".

If the platforms need support 'COMPILE_TEST', the asm-generic is the
main place for implementing it.


So I think our focus is on "whether the platforms guys need support
'COMPILE_TEST" for modules guys".


Thanks
-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Geert Uytterhoeven]

On Mon, Jul 1, 2013 at 9:47 AM, Chen Gang <gang.chen@asianux.com> wrote:
> On 07/01/2013 03:32 PM, Geert Uytterhoeven wrote:
>> On Mon, Jul 1, 2013 at 8:44 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>> > On 07/01/2013 02:34 PM, Richard Weinberger wrote:
>>>>> >>> config COMPILE_TEST
>>>>>> >>> >         bool "Compile also drivers which will not load"
>>>>>> >>> >         default n
>>>>>> >>> >         help
>>>>>> >>> >           Some drivers can be compiled on a different platform than they are
>>>>>> >>> >           intended to be run on. Despite they cannot be loaded there (or even
>>>>>> >>> >           when they load they cannot be used due to missing HW support),
>>>>>> >>> >           developers still, opposing to distributors, might want to build such
>>>>>> >>> >           drivers to compile-test them.
>>>>>> >>> >
>>>>>> >>> >           If you are a developer and want to build everything available, say Y
>>>>>> >>> >           here. If you are a user/distributor, say N here to exclude useless
>>>>>> >>> >           drivers to be distributed.
>>>>>> >>> >
>>>>>> >>> > I guess, 'COMPILE_TEST' is really useful for UML.
>>>> >> No.
>>>> >>
>>>> >> We have explained you more than once what the deal and why UML does not
>>>> >> have ioremap() and friends.
>>> >
>>> > This time, it is not for UML, it is for 'COMPILE_TEST': the
>>> > 'asm-generic' whether need consider it.
>> COMPILE_TEST is only meant to be used as a dependency in Kconfig files,
>> to make drivers that cannot work due to missing hardware invisible when
>> configuring your kernel.
>
> Why "Despite they cannot be loaded there (or even when they load they
> cannot be used due to missing HW support)" ?
>
>> There should be no #ifdefs in actual code that check for (the lack of)
>> CONFIG_COMPILE_TEST.
>
> In ideal world, it should be no #ifdefs for all "CONFIG_*" in 'normal code'.
>
> But "asm-generic" are not belong to 'normal code', it is one of the main
> place to process "CONFIG_*".
>
> If the platforms need support 'COMPILE_TEST', the asm-generic is the
> main place for implementing it.
>
> So I think our focus is on "whether the platforms guys need support
> 'COMPILE_TEST" for modules guys".

COMPILE_TEST is to be used as a dependency if the code would compile,
but would not run. Adding fixes in the code to make more code compile is not
the job of COMPILE_TEST.

If we follow your reasoning, we can add dummy variants of all hardware support
that lives in arch/*/include/asm to asm-generic, so everything would compile
for all platforms. But that's now what we want.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 07/01/2013 03:56 PM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:47 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > On 07/01/2013 03:32 PM, Geert Uytterhoeven wrote:
>>> >> On Mon, Jul 1, 2013 at 8:44 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>>>> >>> > On 07/01/2013 02:34 PM, Richard Weinberger wrote:
>>>>>>>>> >>>>> >>> config COMPILE_TEST
>>>>>>>>>>> >>>>>> >>> >         bool "Compile also drivers which will not load"
>>>>>>>>>>> >>>>>> >>> >         default n
>>>>>>>>>>> >>>>>> >>> >         help
>>>>>>>>>>> >>>>>> >>> >           Some drivers can be compiled on a different platform than they are
>>>>>>>>>>> >>>>>> >>> >           intended to be run on. Despite they cannot be loaded there (or even
>>>>>>>>>>> >>>>>> >>> >           when they load they cannot be used due to missing HW support),
>>>>>>>>>>> >>>>>> >>> >           developers still, opposing to distributors, might want to build such
>>>>>>>>>>> >>>>>> >>> >           drivers to compile-test them.
>>>>>>>>>>> >>>>>> >>> >
>>>>>>>>>>> >>>>>> >>> >           If you are a developer and want to build everything available, say Y
>>>>>>>>>>> >>>>>> >>> >           here. If you are a user/distributor, say N here to exclude useless
>>>>>>>>>>> >>>>>> >>> >           drivers to be distributed.
>>>>>>>>>>> >>>>>> >>> >
>>>>>>>>>>> >>>>>> >>> > I guess, 'COMPILE_TEST' is really useful for UML.
>>>>>>> >>>> >> No.
>>>>>>> >>>> >>
>>>>>>> >>>> >> We have explained you more than once what the deal and why UML does not
>>>>>>> >>>> >> have ioremap() and friends.
>>>>> >>> >
>>>>> >>> > This time, it is not for UML, it is for 'COMPILE_TEST': the
>>>>> >>> > 'asm-generic' whether need consider it.
>>> >> COMPILE_TEST is only meant to be used as a dependency in Kconfig files,
>>> >> to make drivers that cannot work due to missing hardware invisible when
>>> >> configuring your kernel.
>> >
>> > Why "Despite they cannot be loaded there (or even when they load they
>> > cannot be used due to missing HW support)" ?
>> >
>>> >> There should be no #ifdefs in actual code that check for (the lack of)
>>> >> CONFIG_COMPILE_TEST.
>> >
>> > In ideal world, it should be no #ifdefs for all "CONFIG_*" in 'normal code'.
>> >
>> > But "asm-generic" are not belong to 'normal code', it is one of the main
>> > place to process "CONFIG_*".
>> >
>> > If the platforms need support 'COMPILE_TEST', the asm-generic is the
>> > main place for implementing it.
>> >
>> > So I think our focus is on "whether the platforms guys need support
>> > 'COMPILE_TEST" for modules guys".
> COMPILE_TEST is to be used as a dependency if the code would compile,
> but would not run. Adding fixes in the code to make more code compile is not
> the job of COMPILE_TEST.
> 

But from the explanation of 'COMPILE_TEST' in its Kconig, it seems not
like what you said.

e.g."Despite they cannot be loaded there (or even when they load they
cannot be used due to missing HW support)"

Can we allow the module to 'COMPILE_TEST' under one platform which not
support the related HW.


> If we follow your reasoning, we can add dummy variants of all hardware support
> that lives in arch/*/include/asm to asm-generic, so everything would compile
> for all platforms. But that's now what we want.

"If HW support, implement default one, else do nothing" is more like
"default work", not "generic work".

"asm-generic" has already added default implementation for all
platforms, it also checked whether the HW support or not, that means at
least more than 80% works has done.

So if we still call it "asm-generic", I recommend to implement dummy one.

Thanks.
-- 
Chen Gang

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Richard Weinberger]

Am 01.07.2013 09:56, schrieb Geert Uytterhoeven:
> If we follow your reasoning, we can add dummy variants of all hardware support
> that lives in arch/*/include/asm to asm-generic, so everything would compile
> for all platforms. But that's now what we want.

I hope you meant *not* want?

Thanks,
//richard

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Geert Uytterhoeven]

On Mon, Jul 1, 2013 at 1:12 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 01.07.2013 09:56, schrieb Geert Uytterhoeven:
>> If we follow your reasoning, we can add dummy variants of all hardware support
>> that lives in arch/*/include/asm to asm-generic, so everything would compile
>> for all platforms. But that's now what we want.
>
> I hope you meant *not* want?

Sorry, s/now/not/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] drivers/ptp/Kconfig: add "depends on HAS_IOMEM" for 'PTP_1588_CLOCK_PCH'

[Chen Gang]

On 07/01/2013 07:19 PM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 1:12 PM, Richard Weinberger <richard@nod.at> wrote:
>> > Am 01.07.2013 09:56, schrieb Geert Uytterhoeven:
>>> >> If we follow your reasoning, we can add dummy variants of all hardware support
>>> >> that lives in arch/*/include/asm to asm-generic, so everything would compile
>>> >> for all platforms. But that's now what we want.
>> >
>> > I hope you meant *not* want?
> Sorry, s/now/not/

I can understand your feelings, I also can understand if none of my
patches for 'asm-generic' will be applied.

Most of patches for 'asm-generic' should be for 'important' (e.g. duty
definition: whether should support 'COMPILE_TEST', what's the meaning of
'generic').

But this kind of patches are not 'emergent', they need be given more
considerations (they are not for applying, the are for thinking).

For duty definition, it is not for what we want to do, it is for what we
should do (or what we have to do).


At last, I will send related patches for 'COMPILE_TEST' (I can
understand if not applied, or no response). And also should send another
patch for HAS_IOMEM about ptp driver (also cc to you all).

Thanks.
-- 
Chen Gang