From: Chen G. <gan...@as...> - 2013-06-26 06:32:23
|
For "User Mode Linux", it may enable 'MMU', but not need implement ioremap and iounmap, so "include/asm-generic/io.h" need notice this case to keep itself 'generic'. 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 <gan...@as...> --- arch/um/include/asm/Kbuild | 1 + include/asm-generic/io.h | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index b30f34a..a34ea5d 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -3,3 +3,4 @@ generic-y += hw_irq.h irq_regs.h kdebug.h percpu.h sections.h topology.h xor.h generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h generic-y += switch_to.h clkdev.h generic-y += trace_clock.h +generic-y += io.h diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index d5afe96..e80331d 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) /* * Change "struct page" to physical address. * - * This implementation is for the no-MMU case only... if you have an MMU + * This implementation is for the no-MMU or UML case only... if you have an MMU * you'll need to provide your own definitions. */ -#ifndef CONFIG_MMU +#if !CONFIG_MMU || CONFIG_UML static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) { return (void __iomem*) (unsigned long)offset; @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) static inline void iounmap(void __iomem *addr) { } -#endif /* CONFIG_MMU */ +#endif /* !CONFIG_MMU || CONFIG_UML */ #ifdef CONFIG_HAS_IOPORT #ifndef CONFIG_GENERIC_IOMAP -- 1.7.7.6 |
From: Richard W. <ri...@no...> - 2013-06-26 06:54:50
|
Hi! Am 26.06.2013 08:31, schrieb Chen Gang: > For "User Mode Linux", it may enable 'MMU', but not need implement > ioremap and iounmap, so "include/asm-generic/io.h" need notice this > case to keep itself 'generic'. > > 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 <gan...@as...> > --- > arch/um/include/asm/Kbuild | 1 + > include/asm-generic/io.h | 6 +++--- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild > index b30f34a..a34ea5d 100644 > --- a/arch/um/include/asm/Kbuild > +++ b/arch/um/include/asm/Kbuild > @@ -3,3 +3,4 @@ generic-y += hw_irq.h irq_regs.h kdebug.h percpu.h sections.h topology.h xor.h > generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h > generic-y += switch_to.h clkdev.h > generic-y += trace_clock.h > +generic-y += io.h We include that file already. See three lines above. > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h > index d5afe96..e80331d 100644 > --- a/include/asm-generic/io.h > +++ b/include/asm-generic/io.h > @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) > /* > * Change "struct page" to physical address. > * > - * This implementation is for the no-MMU case only... if you have an MMU > + * This implementation is for the no-MMU or UML case only... if you have an MMU > * you'll need to provide your own definitions. > */ > -#ifndef CONFIG_MMU > +#if !CONFIG_MMU || CONFIG_UML > static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) > { > return (void __iomem*) (unsigned long)offset; > @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) > static inline void iounmap(void __iomem *addr) > { > } > -#endif /* CONFIG_MMU */ > +#endif /* !CONFIG_MMU || CONFIG_UML */ > > #ifdef CONFIG_HAS_IOPORT > #ifndef CONFIG_GENERIC_IOMAP > UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] to make nandsim work on UML. Maybe this helps. Thanks, //richard [1] http://lists.infradead.org/pipermail/linux-mtd/2012-February/039701.html |
From: Geert U. <ge...@li...> - 2013-06-26 07:38:57
|
On Wed, Jun 26, 2013 at 8:54 AM, Richard Weinberger <ri...@no...> wrote: >> -#ifndef CONFIG_MMU >> +#if !CONFIG_MMU || CONFIG_UML FWIW, the above syntax is not correct, it should be #if !defined(CONFIG_MMU) || defined(CONFIG_UML) > UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. > _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] > to make nandsim work on UML. Maybe this helps. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
From: Chen G. <gan...@as...> - 2013-06-26 07:57:37
|
On 06/26/2013 03:38 PM, Geert Uytterhoeven wrote: > On Wed, Jun 26, 2013 at 8:54 AM, Richard Weinberger <ri...@no...> wrote: >>> >> -#ifndef CONFIG_MMU >>> >> +#if !CONFIG_MMU || CONFIG_UML > FWIW, the above syntax is not correct, it should be > > #if !defined(CONFIG_MMU) || defined(CONFIG_UML) > Oh, really it is. :-) Thanks. -- Chen Gang Asianux Corporation |
From: Richard W. <ri...@no...> - 2013-06-26 08:05:40
|
Hi! Am 26.06.2013 09:56, schrieb Chen Gang: > On 06/26/2013 02:54 PM, Richard Weinberger wrote: >> Hi! >> >> Am 26.06.2013 08:31, schrieb Chen Gang: >>> For "User Mode Linux", it may enable 'MMU', but not need implement >>> ioremap and iounmap, so "include/asm-generic/io.h" need notice this >>> case to keep itself 'generic'. >>> >>> 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 <gan...@as...> >>> --- >>> arch/um/include/asm/Kbuild | 1 + >>> include/asm-generic/io.h | 6 +++--- >>> 2 files changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild >>> index b30f34a..a34ea5d 100644 >>> --- a/arch/um/include/asm/Kbuild >>> +++ b/arch/um/include/asm/Kbuild >>> @@ -3,3 +3,4 @@ generic-y += hw_irq.h irq_regs.h kdebug.h percpu.h sections.h topology.h xor.h >>> generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h >>> generic-y += switch_to.h clkdev.h >>> generic-y += trace_clock.h >>> +generic-y += io.h >> >> We include that file already. See three lines above. >> > > Oh, really it is, thanks. > >>> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h >>> index d5afe96..e80331d 100644 >>> --- a/include/asm-generic/io.h >>> +++ b/include/asm-generic/io.h >>> @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) >>> /* >>> * Change "struct page" to physical address. >>> * >>> - * This implementation is for the no-MMU case only... if you have an MMU >>> + * This implementation is for the no-MMU or UML case only... if you have an MMU >>> * you'll need to provide your own definitions. >>> */ >>> -#ifndef CONFIG_MMU >>> +#if !CONFIG_MMU || CONFIG_UML >>> static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>> { >>> return (void __iomem*) (unsigned long)offset; >>> @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>> static inline void iounmap(void __iomem *addr) >>> { >>> } >>> -#endif /* CONFIG_MMU */ >>> +#endif /* !CONFIG_MMU || CONFIG_UML */ >>> >>> #ifdef CONFIG_HAS_IOPORT >>> #ifndef CONFIG_GENERIC_IOMAP >>> >> >> UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. >> _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] >> to make nandsim work on UML. Maybe this helps. >> > > But "no io memory" is not the excuse to not define the related dummy > function. UML has no io memory, period. Same applies for s390, it also includes asm-generic/io.h in the !CONFIG_PCI case. UML and s390 are very special here. > The drivers internal code has already check the related return value, > so it is the architecture's duty to 'tell' the driver whether support > io memory (e.g. define ioremap, but return NULL). It does so already by setting CONFIG_HAS_IOMEM=n Thanks, //richard |
From: Chen G. <gan...@as...> - 2013-06-26 07:57:05
|
On 06/26/2013 02:54 PM, Richard Weinberger wrote: > Hi! > > Am 26.06.2013 08:31, schrieb Chen Gang: >> For "User Mode Linux", it may enable 'MMU', but not need implement >> ioremap and iounmap, so "include/asm-generic/io.h" need notice this >> case to keep itself 'generic'. >> >> 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 <gan...@as...> >> --- >> arch/um/include/asm/Kbuild | 1 + >> include/asm-generic/io.h | 6 +++--- >> 2 files changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild >> index b30f34a..a34ea5d 100644 >> --- a/arch/um/include/asm/Kbuild >> +++ b/arch/um/include/asm/Kbuild >> @@ -3,3 +3,4 @@ generic-y += hw_irq.h irq_regs.h kdebug.h percpu.h sections.h topology.h xor.h >> generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h >> generic-y += switch_to.h clkdev.h >> generic-y += trace_clock.h >> +generic-y += io.h > > We include that file already. See three lines above. > Oh, really it is, thanks. >> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h >> index d5afe96..e80331d 100644 >> --- a/include/asm-generic/io.h >> +++ b/include/asm-generic/io.h >> @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) >> /* >> * Change "struct page" to physical address. >> * >> - * This implementation is for the no-MMU case only... if you have an MMU >> + * This implementation is for the no-MMU or UML case only... if you have an MMU >> * you'll need to provide your own definitions. >> */ >> -#ifndef CONFIG_MMU >> +#if !CONFIG_MMU || CONFIG_UML >> static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >> { >> return (void __iomem*) (unsigned long)offset; >> @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >> static inline void iounmap(void __iomem *addr) >> { >> } >> -#endif /* CONFIG_MMU */ >> +#endif /* !CONFIG_MMU || CONFIG_UML */ >> >> #ifdef CONFIG_HAS_IOPORT >> #ifndef CONFIG_GENERIC_IOMAP >> > > UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. > _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] > to make nandsim work on UML. Maybe this helps. > But "no io memory" is not the excuse to not define the related dummy function. The drivers internal code has already check the related return value, so it is the architecture's duty to 'tell' the driver whether support io memory (e.g. define ioremap, but return NULL). So all together, I recommend the fix like below --------------------------diff begin------------------------------------ diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index b30f34a..b282042 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -1,5 +1,5 @@ generic-y += bug.h cputime.h device.h emergency-restart.h futex.h hardirq.h generic-y += hw_irq.h irq_regs.h kdebug.h percpu.h sections.h topology.h xor.h -generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h +generic-y += ftrace.h pci.h param.h delay.h mutex.h current.h exec.h generic-y += switch_to.h clkdev.h generic-y += trace_clock.h diff --git a/arch/um/include/asm/io.h b/arch/um/include/asm/io.h new file mode 100644 index 0000000..00f3cd8 --- /dev/null +++ b/arch/um/include/asm/io.h @@ -0,0 +1,21 @@ +#ifndef UML_IO_H +#define UML_IO_H + +#include <asm-generic/io.h> + +/* + * UML does not support io memory, so return NULL. + */ +static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) +{ + return NULL; +} + +#define ioremap_nocache ioremap +#define ioremap_wc ioremap_nocache + +static inline void iounmap(void __iomem *addr) +{ +} + +#endif /* UML_IO_H */ --------------------------diff end------------------------------------ Thanks. -- Chen Gang Asianux Corporation |
From: Chen G. <gan...@as...> - 2013-06-26 08:35:21
|
On 06/26/2013 04:05 PM, Richard Weinberger wrote: >>>> >>> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h >>>> >>> index d5afe96..e80331d 100644 >>>> >>> --- a/include/asm-generic/io.h >>>> >>> +++ b/include/asm-generic/io.h >>>> >>> @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) >>>> >>> /* >>>> >>> * Change "struct page" to physical address. >>>> >>> * >>>> >>> - * This implementation is for the no-MMU case only... if you have an MMU >>>> >>> + * This implementation is for the no-MMU or UML case only... if you have an MMU >>>> >>> * you'll need to provide your own definitions. >>>> >>> */ >>>> >>> -#ifndef CONFIG_MMU >>>> >>> +#if !CONFIG_MMU || CONFIG_UML >>>> >>> static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>>> >>> { >>>> >>> return (void __iomem*) (unsigned long)offset; >>>> >>> @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>>> >>> static inline void iounmap(void __iomem *addr) >>>> >>> { >>>> >>> } >>>> >>> -#endif /* CONFIG_MMU */ >>>> >>> +#endif /* !CONFIG_MMU || CONFIG_UML */ >>>> >>> >>>> >>> #ifdef CONFIG_HAS_IOPORT >>>> >>> #ifndef CONFIG_GENERIC_IOMAP >>>> >>> >>> >> >>> >> UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. >>> >> _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] >>> >> to make nandsim work on UML. Maybe this helps. >>> >> >> > >> > But "no io memory" is not the excuse to not define the related dummy >> > function. > UML has no io memory, period. > Same applies for s390, it also includes asm-generic/io.h in the !CONFIG_PCI > case. > UML and s390 are very special here. > Oh, yes, really the same. >> > The drivers internal code has already check the related return value, >> > so it is the architecture's duty to 'tell' the driver whether support >> > io memory (e.g. define ioremap, but return NULL). > It does so already by setting CONFIG_HAS_IOMEM=n Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" directory, but can not find the related definition for 'ioremap'. Is there another declaration or definition way which I don't know ? (maybe it is). For our case, the ".config" file does not define 'CONFIG_HAS_IOMEM', can I assume it means "CONFIG_HAS_IOMEM=n" ? Thanks -- Chen Gang Asianux Corporation |
From: Richard W. <ri...@no...> - 2013-06-26 08:40:02
|
Am 26.06.2013 10:34, schrieb Chen Gang: > On 06/26/2013 04:05 PM, Richard Weinberger wrote: >>>>>>>> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h >>>>>>>> index d5afe96..e80331d 100644 >>>>>>>> --- a/include/asm-generic/io.h >>>>>>>> +++ b/include/asm-generic/io.h >>>>>>>> @@ -303,10 +303,10 @@ static inline void *phys_to_virt(unsigned long address) >>>>>>>> /* >>>>>>>> * Change "struct page" to physical address. >>>>>>>> * >>>>>>>> - * This implementation is for the no-MMU case only... if you have an MMU >>>>>>>> + * This implementation is for the no-MMU or UML case only... if you have an MMU >>>>>>>> * you'll need to provide your own definitions. >>>>>>>> */ >>>>>>>> -#ifndef CONFIG_MMU >>>>>>>> +#if !CONFIG_MMU || CONFIG_UML >>>>>>>> static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>>>>>>> { >>>>>>>> return (void __iomem*) (unsigned long)offset; >>>>>>>> @@ -325,7 +325,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) >>>>>>>> static inline void iounmap(void __iomem *addr) >>>>>>>> { >>>>>>>> } >>>>>>>> -#endif /* CONFIG_MMU */ >>>>>>>> +#endif /* !CONFIG_MMU || CONFIG_UML */ >>>>>>>> >>>>>>>> #ifdef CONFIG_HAS_IOPORT >>>>>>>> #ifndef CONFIG_GENERIC_IOMAP >>>>>>>> >>>>>> >>>>>> UML has no io memory but a MMU, so I'd argue that you better fix drivers/ptp/ptp_pch.c dependencies. >>>>>> _If_ ptp_pch.c really works without real io memory, you can look what I did in my GENERIC_IO series[1] >>>>>> to make nandsim work on UML. Maybe this helps. >>>>>> >>>> >>>> But "no io memory" is not the excuse to not define the related dummy >>>> function. >> UML has no io memory, period. >> Same applies for s390, it also includes asm-generic/io.h in the !CONFIG_PCI >> case. >> UML and s390 are very special here. >> > > Oh, yes, really the same. > >>>> The drivers internal code has already check the related return value, >>>> so it is the architecture's duty to 'tell' the driver whether support >>>> io memory (e.g. define ioremap, but return NULL). >> It does so already by setting CONFIG_HAS_IOMEM=n > > Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" > directory, but can not find the related definition for 'ioremap'. > > Is there another declaration or definition way which I don't know ? > (maybe it is). Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because without io memory you cannot have a ioremap(). > For our case, the ".config" file does not define 'CONFIG_HAS_IOMEM', can > I assume it means "CONFIG_HAS_IOMEM=n" ? If I'm not mistaken it works the other way around. All archs except UML and s390 set CONFIG_HAS_IOMEM=y. Thanks, //richard |
From: Chen G. <gan...@as...> - 2013-06-26 08:59:07
|
On 06/26/2013 04:39 PM, Richard Weinberger wrote: >>>>> >>>> The drivers internal code has already check the related return value, >>>>> >>>> so it is the architecture's duty to 'tell' the driver whether support >>>>> >>>> io memory (e.g. define ioremap, but return NULL). >>> >> It does so already by setting CONFIG_HAS_IOMEM=n >> > >> > Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" >> > directory, but can not find the related definition for 'ioremap'. >> > >> > Is there another declaration or definition way which I don't know ? >> > (maybe it is). > Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because > without io memory you cannot have a ioremap(). > I assume if ioremap() return NULL, it means "without io memory", is it correct ? If it is correct, "define a dummy ioremap(), and return NULL" is just the meaning that you mentioned above. If so, for UML, it is not requirement, but recommend to define a dummy ioremap() which return NULL, so can be generic enough to mach all cases. >> > For our case, the ".config" file does not define 'CONFIG_HAS_IOMEM', can >> > I assume it means "CONFIG_HAS_IOMEM=n" ? > If I'm not mistaken it works the other way around. > All archs except UML and s390 set CONFIG_HAS_IOMEM=y. I guess so, too. Thanks. -- Chen Gang Asianux Corporation |
From: Richard W. <ri...@no...> - 2013-06-26 09:04:09
|
Am 26.06.2013 10:58, schrieb Chen Gang: > On 06/26/2013 04:39 PM, Richard Weinberger wrote: >>>>>>>>>> The drivers internal code has already check the related return value, >>>>>>>>>> so it is the architecture's duty to 'tell' the driver whether support >>>>>>>>>> io memory (e.g. define ioremap, but return NULL). >>>>>> It does so already by setting CONFIG_HAS_IOMEM=n >>>> >>>> Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" >>>> directory, but can not find the related definition for 'ioremap'. >>>> >>>> Is there another declaration or definition way which I don't know ? >>>> (maybe it is). >> Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because >> without io memory you cannot have a ioremap(). >> > > I assume if ioremap() return NULL, it means "without io memory", is it > correct ? > > If it is correct, "define a dummy ioremap(), and return NULL" is just > the meaning that you mentioned above. > > If so, for UML, it is not requirement, but recommend to define a dummy > ioremap() which return NULL, so can be generic enough to mach all cases. No. Not setting CONFIG_HAS_IOMEM=y means "This arch has no io memory and therefore no functions to mess with it". Let's get back to the real problem, drivers/ptp/ptp_pch.c does not build on UML (and I'm very sure also not on S390). Fix the issue by making it depend on HAS_IOMEM. Btw: Did you actually look at this driver? There is *zero* reason to have it on UML. ...like 99.9% of all other drivers which use io memory. Thanks, //richard |
From: Chen G. <gan...@as...> - 2013-06-26 09:34:12
|
On 06/26/2013 05:03 PM, Richard Weinberger wrote: > Am 26.06.2013 10:58, schrieb Chen Gang: >> > On 06/26/2013 04:39 PM, Richard Weinberger wrote: >>>>>>>>>>> >>>>>>>>>> The drivers internal code has already check the related return value, >>>>>>>>>>> >>>>>>>>>> so it is the architecture's duty to 'tell' the driver whether support >>>>>>>>>>> >>>>>>>>>> io memory (e.g. define ioremap, but return NULL). >>>>>>> >>>>>> It does so already by setting CONFIG_HAS_IOMEM=n >>>>> >>>> >>>>> >>>> Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" >>>>> >>>> directory, but can not find the related definition for 'ioremap'. >>>>> >>>> >>>>> >>>> Is there another declaration or definition way which I don't know ? >>>>> >>>> (maybe it is). >>> >> Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because >>> >> without io memory you cannot have a ioremap(). >>> >> >> > >> > I assume if ioremap() return NULL, it means "without io memory", is it >> > correct ? >> > >> > If it is correct, "define a dummy ioremap(), and return NULL" is just >> > the meaning that you mentioned above. >> > >> > If so, for UML, it is not requirement, but recommend to define a dummy >> > ioremap() which return NULL, so can be generic enough to mach all cases. > No. > Not setting CONFIG_HAS_IOMEM=y means "This arch has no io memory and therefore no > functions to mess with it". > Since the API itself already contents the meaning: "return NULL means the arch has no related io memory", Why not define a generic dummy one in "include/asm-generic/io.h" instead of "HAS_IOMEM" (which has already spread many various places, and also, most of new drivers have to know about it). e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a dummy ioremap() which return NULL ... (also need consider more details). All together, I think: it is the duty of "asm-generic/io.h" to process this issue, not the duty of many drivers and some architectures. > Let's get back to the real problem, > drivers/ptp/ptp_pch.c does not build on UML (and I'm very sure also not on S390). > Fix the issue by making it depend on HAS_IOMEM. > At least now, it seems it is the only suitable way to fix this issue. :-( > Btw: Did you actually look at this driver? There is *zero* reason to have it on UML. > ..like 99.9% of all other drivers which use io memory. Excuse me, I did not look at the details of this driver. Maybe it just like you said above. Thanks. -- Chen Gang Asianux Corporation |
From: Richard W. <ri...@no...> - 2013-06-26 09:38:32
|
Am 26.06.2013 11:33, schrieb Chen Gang: > On 06/26/2013 05:03 PM, Richard Weinberger wrote: >> Am 26.06.2013 10:58, schrieb Chen Gang: >>>> On 06/26/2013 04:39 PM, Richard Weinberger wrote: >>>>>>>>>>>>>>>>>>>>>> The drivers internal code has already check the related return value, >>>>>>>>>>>>>>>>>>>>>> so it is the architecture's duty to 'tell' the driver whether support >>>>>>>>>>>>>>>>>>>>>> io memory (e.g. define ioremap, but return NULL). >>>>>>>>>>>>>> It does so already by setting CONFIG_HAS_IOMEM=n >>>>>>>>>> >>>>>>>>>> Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" >>>>>>>>>> directory, but can not find the related definition for 'ioremap'. >>>>>>>>>> >>>>>>>>>> Is there another declaration or definition way which I don't know ? >>>>>>>>>> (maybe it is). >>>>>> Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because >>>>>> without io memory you cannot have a ioremap(). >>>>>> >>>> >>>> I assume if ioremap() return NULL, it means "without io memory", is it >>>> correct ? >>>> >>>> If it is correct, "define a dummy ioremap(), and return NULL" is just >>>> the meaning that you mentioned above. >>>> >>>> If so, for UML, it is not requirement, but recommend to define a dummy >>>> ioremap() which return NULL, so can be generic enough to mach all cases. >> No. >> Not setting CONFIG_HAS_IOMEM=y means "This arch has no io memory and therefore no >> functions to mess with it". >> > > Since the API itself already contents the meaning: "return NULL means > the arch has no related io memory", > > Why not define a generic dummy one in "include/asm-generic/io.h" instead > of "HAS_IOMEM" (which has already spread many various places, and also, > most of new drivers have to know about it). > > e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a > dummy ioremap() which return NULL ... (also need consider more details). Because we don't even want to build these drivers and not make them fail while executing io memory related functions. > > All together, I think: it is the duty of "asm-generic/io.h" to process > this issue, not the duty of many drivers and some architectures. > > >> Let's get back to the real problem, >> drivers/ptp/ptp_pch.c does not build on UML (and I'm very sure also not on S390). >> Fix the issue by making it depend on HAS_IOMEM. >> > > At least now, it seems it is the only suitable way to fix this issue. :-( > > >> Btw: Did you actually look at this driver? There is *zero* reason to have it on UML. >> ..like 99.9% of all other drivers which use io memory. > > Excuse me, I did not look at the details of this driver. Maybe it just > like you said above. It is. Thanks, //richard |
From: Chen G. <gan...@as...> - 2013-06-26 09:56:01
|
On 06/26/2013 05:38 PM, Richard Weinberger wrote: > Am 26.06.2013 11:33, schrieb Chen Gang: >> > On 06/26/2013 05:03 PM, Richard Weinberger wrote: >>> >> Am 26.06.2013 10:58, schrieb Chen Gang: >>>>> >>>> On 06/26/2013 04:39 PM, Richard Weinberger wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The drivers internal code has already check the related return value, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> so it is the architecture's duty to 'tell' the driver whether support >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> io memory (e.g. define ioremap, but return NULL). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> It does so already by setting CONFIG_HAS_IOMEM=n >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/" >>>>>>>>>>> >>>>>>>>>> directory, but can not find the related definition for 'ioremap'. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Is there another declaration or definition way which I don't know ? >>>>>>>>>>> >>>>>>>>>> (maybe it is). >>>>>>> >>>>>> Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because >>>>>>> >>>>>> without io memory you cannot have a ioremap(). >>>>>>> >>>>>> >>>>> >>>> >>>>> >>>> I assume if ioremap() return NULL, it means "without io memory", is it >>>>> >>>> correct ? >>>>> >>>> >>>>> >>>> If it is correct, "define a dummy ioremap(), and return NULL" is just >>>>> >>>> the meaning that you mentioned above. >>>>> >>>> >>>>> >>>> If so, for UML, it is not requirement, but recommend to define a dummy >>>>> >>>> ioremap() which return NULL, so can be generic enough to mach all cases. >>> >> No. >>> >> Not setting CONFIG_HAS_IOMEM=y means "This arch has no io memory and therefore no >>> >> functions to mess with it". >>> >> >> > >> > Since the API itself already contents the meaning: "return NULL means >> > the arch has no related io memory", >> > >> > Why not define a generic dummy one in "include/asm-generic/io.h" instead >> > of "HAS_IOMEM" (which has already spread many various places, and also, >> > most of new drivers have to know about it). >> > >> > e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >> > dummy ioremap() which return NULL ... (also need consider more details). > Because we don't even want to build these drivers and not make them fail while > executing io memory related functions. > It is one reason, but it seems not quite enough for it, it depends on our requirements. If we are also the 'platform' of all kernel modules (not only for user mode), and "include/asm-generic/*" plays an important role for it. It is the modules their own choice to determine which architectures they want to support, and which architecture they won't, not need be directed or forced by 'platform'. Also better to let kernel modules free to determine whether build in or not, when actually do not support the specific features of architecture currently, not need be directed or forced by 'platform'. Thanks. -- Chen Gang Asianux Corporation |
From: Geert U. <ge...@li...> - 2013-06-26 09:48:29
|
On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >> Since the API itself already contents the meaning: "return NULL means >> the arch has no related io memory", No, NULL means it could not map the I/O memory. >> Why not define a generic dummy one in "include/asm-generic/io.h" instead >> of "HAS_IOMEM" (which has already spread many various places, and also, >> most of new drivers have to know about it). >> >> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >> dummy ioremap() which return NULL ... (also need consider more details). > > Because we don't even want to build these drivers and not make them fail while > executing io memory related functions. Indeed, it doesn't make sense to build drivers that cannot work. And they may fail in a very bad way. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
From: Chen G. <gan...@as...> - 2013-06-26 10:02:02
|
On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote: > On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >>> >> Since the API itself already contents the meaning: "return NULL means >>> >> the arch has no related io memory", > No, NULL means it could not map the I/O memory. > "it could not map the I/O memory" includes "has no related io memory". So it is enough for our case. >>> >> Why not define a generic dummy one in "include/asm-generic/io.h" instead >>> >> of "HAS_IOMEM" (which has already spread many various places, and also, >>> >> most of new drivers have to know about it). >>> >> >>> >> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >>> >> dummy ioremap() which return NULL ... (also need consider more details). >> > >> > Because we don't even want to build these drivers and not make them fail while >> > executing io memory related functions. > Indeed, it doesn't make sense to build drivers that cannot work. > And they may fail in a very bad way. That is our 'platform' guys feeling, not the 'module' guys, as 'platform' guys, it is better to provide the choice to 'module' guys, and let them decide by themselves, not forced by us. Thanks. -- Chen Gang Asianux Corporation |
From: Richard W. <ri...@no...> - 2013-06-26 10:17:30
|
Am 26.06.2013 12:01, schrieb Chen Gang: > On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote: >> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >>>>>> Since the API itself already contents the meaning: "return NULL means >>>>>> the arch has no related io memory", >> No, NULL means it could not map the I/O memory. >> > > "it could not map the I/O memory" includes "has no related io memory". > So it is enough for our case. > >>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead >>>>>> of "HAS_IOMEM" (which has already spread many various places, and also, >>>>>> most of new drivers have to know about it). >>>>>> >>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >>>>>> dummy ioremap() which return NULL ... (also need consider more details). >>>> >>>> Because we don't even want to build these drivers and not make them fail while >>>> executing io memory related functions. >> Indeed, it doesn't make sense to build drivers that cannot work. >> And they may fail in a very bad way. > > That is our 'platform' guys feeling, not the 'module' guys, as > 'platform' guys, it is better to provide the choice to 'module' guys, > and let them decide by themselves, not forced by us. FYI, this is my last reply to this thread. As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y. If an arch does not have io memory these drivers cannot work and therefore we don't want them built. Over and out, //richard |
From: Chen G. <gan...@as...> - 2013-06-26 10:23:11
|
On 06/26/2013 06:17 PM, Richard Weinberger wrote: > Am 26.06.2013 12:01, schrieb Chen Gang: >> > On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote: >>> >> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >>>>>>> >>>>>> Since the API itself already contents the meaning: "return NULL means >>>>>>> >>>>>> the arch has no related io memory", >>> >> No, NULL means it could not map the I/O memory. >>> >> >> > >> > "it could not map the I/O memory" includes "has no related io memory". >> > So it is enough for our case. >> > >>>>>>> >>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead >>>>>>> >>>>>> of "HAS_IOMEM" (which has already spread many various places, and also, >>>>>>> >>>>>> most of new drivers have to know about it). >>>>>>> >>>>>> >>>>>>> >>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >>>>>>> >>>>>> dummy ioremap() which return NULL ... (also need consider more details). >>>>> >>>> >>>>> >>>> Because we don't even want to build these drivers and not make them fail while >>>>> >>>> executing io memory related functions. >>> >> Indeed, it doesn't make sense to build drivers that cannot work. >>> >> And they may fail in a very bad way. >> > >> > That is our 'platform' guys feeling, not the 'module' guys, as >> > 'platform' guys, it is better to provide the choice to 'module' guys, >> > and let them decide by themselves, not forced by us. > FYI, this is my last reply to this thread. > > As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y. > If an arch does not have io memory these drivers cannot work and therefore we don't > want them built. It is really the time for stopping discussion, and thank you all for spending your time resources on this discussion. Next, I will send related patch for it (also cc to you all). Thanks. -- Chen Gang Asianux Corporation |
From: Chen G. <gan...@as...> - 2013-07-01 01:41:28
|
On 06/26/2013 06:22 PM, Chen Gang wrote: > On 06/26/2013 06:17 PM, Richard Weinberger wrote: >> Am 26.06.2013 12:01, schrieb Chen Gang: >>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote: >>>>>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >>>>>>>>>>>>>> Since the API itself already contents the meaning: "return NULL means >>>>>>>>>>>>>> the arch has no related io memory", >>>>>> No, NULL means it could not map the I/O memory. >>>>>> >>>> >>>> "it could not map the I/O memory" includes "has no related io memory". >>>> So it is enough for our case. >>>> >>>>>>>>>>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead >>>>>>>>>>>>>> of "HAS_IOMEM" (which has already spread many various places, and also, >>>>>>>>>>>>>> most of new drivers have to know about it). >>>>>>>>>>>>>> >>>>>>>>>>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >>>>>>>>>>>>>> dummy ioremap() which return NULL ... (also need consider more details). >>>>>>>>>> >>>>>>>>>> Because we don't even want to build these drivers and not make them fail while >>>>>>>>>> executing io memory related functions. >>>>>> Indeed, it doesn't make sense to build drivers that cannot work. >>>>>> And they may fail in a very bad way. >>>> >>>> That is our 'platform' guys feeling, not the 'module' guys, as >>>> 'platform' guys, it is better to provide the choice to 'module' guys, >>>> and let them decide by themselves, not forced by us. >> FYI, this is my last reply to this thread. >> >> As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y. >> If an arch does not have io memory these drivers cannot work and therefore we don't >> want them built. > Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic support this features (at least, not forbid it) So how about the diff below ? ;-) ---------------------------diff begin----------------------------------- diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index d5afe96..ede3775 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address) /* * Change "struct page" to physical address. * - * This implementation is for the no-MMU case only... if you have an MMU - * you'll need to provide your own definitions. + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases. + * if you have an MMU and IOMEM, you'll need to provide your own definitions. */ -#ifndef CONFIG_MMU +#if !defined(CONFIG_MMU) || \ + (!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST)) static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) { +#if !defined(CONFIG_MMU) return (void __iomem*) (unsigned long)offset; +#else + return NULL; } #define __ioremap(offset, size, flags) ioremap(offset, size) @@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) static inline void iounmap(void __iomem *addr) { } -#endif /* CONFIG_MMU */ +#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */ #ifdef CONFIG_HAS_IOPORT #ifndef CONFIG_GENERIC_IOMAP ---------------------------diff end------------------------------------- > It is really the time for stopping discussion, and thank you all for > spending your time resources on this discussion. > > Next, I will send related patch for it (also cc to you all). > > > Thanks. > -- Chen Gang |
From: Chen G. <gan...@as...> - 2013-07-01 03:45:01
|
On 07/01/2013 09:40 AM, Chen Gang wrote: > On 06/26/2013 06:22 PM, Chen Gang wrote: >> > On 06/26/2013 06:17 PM, Richard Weinberger wrote: >>> >> Am 26.06.2013 12:01, schrieb Chen Gang: >>>>> >>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote: >>>>>>> >>>>>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Since the API itself already contents the meaning: "return NULL means >>>>>>>>>>>>>>> >>>>>>>>>>>>>> the arch has no related io memory", >>>>>>> >>>>>> No, NULL means it could not map the I/O memory. >>>>>>> >>>>>> >>>>> >>>> >>>>> >>>> "it could not map the I/O memory" includes "has no related io memory". >>>>> >>>> So it is enough for our case. >>>>> >>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead >>>>>>>>>>>>>>> >>>>>>>>>>>>>> of "HAS_IOMEM" (which has already spread many various places, and also, >>>>>>>>>>>>>>> >>>>>>>>>>>>>> most of new drivers have to know about it). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a >>>>>>>>>>>>>>> >>>>>>>>>>>>>> dummy ioremap() which return NULL ... (also need consider more details). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Because we don't even want to build these drivers and not make them fail while >>>>>>>>>>> >>>>>>>>>> executing io memory related functions. >>>>>>> >>>>>> Indeed, it doesn't make sense to build drivers that cannot work. >>>>>>> >>>>>> And they may fail in a very bad way. >>>>> >>>> >>>>> >>>> That is our 'platform' guys feeling, not the 'module' guys, as >>>>> >>>> 'platform' guys, it is better to provide the choice to 'module' guys, >>>>> >>>> and let them decide by themselves, not forced by us. >>> >> FYI, this is my last reply to this thread. >>> >> >>> >> As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y. >>> >> If an arch does not have io memory these drivers cannot work and therefore we don't >>> >> want them built. >> > > Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic > support this features (at least, not forbid it) > > So how about the diff below ? ;-) > > ---------------------------diff begin----------------------------------- > > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h > index d5afe96..ede3775 100644 > --- a/include/asm-generic/io.h > +++ b/include/asm-generic/io.h > @@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address) > /* > * Change "struct page" to physical address. > * > - * This implementation is for the no-MMU case only... if you have an MMU > - * you'll need to provide your own definitions. > + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases. > + * if you have an MMU and IOMEM, you'll need to provide your own definitions. > */ > -#ifndef CONFIG_MMU > +#if !defined(CONFIG_MMU) || \ > + (!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST)) Need use 'CONFIG_COMPILE_TEST' instead of 'COMPILE_TEST'. > static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) > { > +#if !defined(CONFIG_MMU) > return (void __iomem*) (unsigned long)offset; > +#else > + return NULL; > } > > #define __ioremap(offset, size, flags) ioremap(offset, size) > @@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) > static inline void iounmap(void __iomem *addr) > { > } > -#endif /* CONFIG_MMU */ > +#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */ > > #ifdef CONFIG_HAS_IOPORT > #ifndef CONFIG_GENERIC_IOMAP > > ---------------------------diff end------------------------------------- > >> > It is really the time for stopping discussion, and thank you all for >> > spending your time resources on this discussion. >> > >> > Next, I will send related patch for it (also cc to you all). >> > >> > >> > Thanks. >> > > > -- Chen Gang > -- Chen Gang |
From: Chen G. <gan...@as...> - 2013-07-02 02:15:01
|
'asm-generic' need provide necessary configuration checking, if can't pass checking, 'asm-generic' shouldn't implement it. For 'COMPILE_TEST', according to its help contents, 'asm-generic' need let it pass configuration checking, and provide related dummy contents for it. Part of 'COMPLE_TEST' help contents in "init/Kconfig": "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." Signed-off-by: Chen Gang <gan...@as...> --- include/asm-generic/io.h | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index d5afe96..301ce80 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address) /* * Change "struct page" to physical address. * - * This implementation is for the no-MMU case only... if you have an MMU - * you'll need to provide your own definitions. + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases. + * if you have an MMU and IOMEM, you'll need to provide your own definitions. */ -#ifndef CONFIG_MMU +#if !defined(CONFIG_MMU) || \ + (!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST)) static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) { +#if !defined(CONFIG_MMU) return (void __iomem*) (unsigned long)offset; +#else + return NULL; +#endif } #define __ioremap(offset, size, flags) ioremap(offset, size) @@ -325,7 +330,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) static inline void iounmap(void __iomem *addr) { } -#endif /* CONFIG_MMU */ +#endif /* !CONFIG_MMU || (!CONFIG_HAS_IOMEM && CONFIG_COMPILE_TEST) */ #ifdef CONFIG_HAS_IOPORT #ifndef CONFIG_GENERIC_IOMAP @@ -341,6 +346,15 @@ static inline void ioport_unmap(void __iomem *p) extern void __iomem *ioport_map(unsigned long port, unsigned int nr); extern void ioport_unmap(void __iomem *p); #endif /* CONFIG_GENERIC_IOMAP */ +#elif defined(CONFIG_COMPILE_TEST) /* CONFIG_HAS_IOPORT */ +static inline void __iomem *ioport_map(unsigned long port, unsigned int nr) +{ + return NULL; +} + +static inline void ioport_unmap(void __iomem *p) +{ +} #endif /* CONFIG_HAS_IOPORT */ #ifndef xlate_dev_kmem_ptr -- 1.7.7.6 |
From: Geert U. <ge...@li...> - 2013-07-02 07:20:02
|
On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: > 'asm-generic' need provide necessary configuration checking, if can't > pass checking, 'asm-generic' shouldn't implement it. > > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need > let it pass configuration checking, and provide related dummy contents > for it. > > Part of 'COMPLE_TEST' help contents in "init/Kconfig": > > "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." > > > Signed-off-by: Chen Gang <gan...@as...> NAKed-by: Geert Uytterhoeven <ge...@li...> Please don't clutter the code with checks for CONFIG_COMPILE_TEST. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
From: Chen G. <gan...@as...> - 2013-07-02 08:01:16
|
On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: > On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: >> > 'asm-generic' need provide necessary configuration checking, if can't >> > pass checking, 'asm-generic' shouldn't implement it. >> > >> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need >> > let it pass configuration checking, and provide related dummy contents >> > for it. >> > >> > Part of 'COMPLE_TEST' help contents in "init/Kconfig": >> > >> > "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." >> > >> > >> > Signed-off-by: Chen Gang <gan...@as...> > NAKed-by: Geert Uytterhoeven <ge...@li...> > > Please don't clutter the code with checks for CONFIG_COMPILE_TEST. Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the platform should not support 'COMPILE_TEST") ? Or you mean: 'COMPILE_TEST' should not exist in kernel ? Can we use 'asm-default' instead of 'asm-generic', since "if HW support, it will provide default value, or it will provide nothing" ? Thanks. -- Chen Gang |
From: Geert U. <ge...@li...> - 2013-07-02 10:57:25
|
On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote: > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: >>> > 'asm-generic' need provide necessary configuration checking, if can't >>> > pass checking, 'asm-generic' shouldn't implement it. >>> > >>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need >>> > let it pass configuration checking, and provide related dummy contents >>> > for it. >>> > >>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig": >>> > >>> > "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." >>> > >>> > >>> > Signed-off-by: Chen Gang <gan...@as...> >> NAKed-by: Geert Uytterhoeven <ge...@li...> >> >> Please don't clutter the code with checks for CONFIG_COMPILE_TEST. > > Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the > platform should not support 'COMPILE_TEST") ? > > Or you mean: 'COMPILE_TEST' should not exist in kernel ? I mean that COMPILE_TEST should exist in Kconfig files only. It's only meant to have more compile coverage, not to "fix" (through #ifdef) more code to make it compile. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
From: Chen G. <gan...@as...> - 2013-07-03 00:52:57
|
On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote: > On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote: >> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: >>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: >>>>> >>> > 'asm-generic' need provide necessary configuration checking, if can't >>>>> >>> > pass checking, 'asm-generic' shouldn't implement it. >>>>> >>> > >>>>> >>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need >>>>> >>> > let it pass configuration checking, and provide related dummy contents >>>>> >>> > for it. >>>>> >>> > >>>>> >>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig": >>>>> >>> > >>>>> >>> > "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." >>>>> >>> > >>>>> >>> > >>>>> >>> > Signed-off-by: Chen Gang <gan...@as...> >>> >> NAKed-by: Geert Uytterhoeven <ge...@li...> >>> >> >>> >> Please don't clutter the code with checks for CONFIG_COMPILE_TEST. >> > >> > Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the >> > platform should not support 'COMPILE_TEST") ? >> > >> > Or you mean: 'COMPILE_TEST' should not exist in kernel ? > I mean that COMPILE_TEST should exist in Kconfig files only. > It's only meant to have more compile coverage, not to "fix" (through #ifdef) > more code to make it compile. If so, can we allow the module to 'COMPILE_TEST' under one platform which not support the related HW ? e.g. "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)...". 'asm-generic' need provide generic layer to users (both architecture guys and module guys). So for 'default', it can depend on some conditions (e.g. HW support); but for 'generic', it need try to be independent from any conditions. And it is also necessary for 'generic' to provide the configuration checking features, but this checking must be no negative effect (or consistent) with its 'generic' services. So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it also necessary to consider about 'COMPILE_TEST' to be consistent with its 'generic' services. BTW: 20% code are for 80% features, but the left 20% features, need 80% code, if we have to make it complete, we have to face this 'rule'. Thanks. -- Chen Gang |
From: Chen G. <gan...@as...> - 2013-07-03 01:27:49
|
On 07/03/2013 08:51 AM, Chen Gang wrote: > On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote: >> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote: >>>> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: >>>>>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: >>>>>>>>>> 'asm-generic' need provide necessary configuration checking, if can't >>>>>>>>>> pass checking, 'asm-generic' shouldn't implement it. >>>>>>>>>> >>>>>>>>>> For 'COMPILE_TEST', according to its help contents, 'asm-generic' need >>>>>>>>>> let it pass configuration checking, and provide related dummy contents >>>>>>>>>> for it. >>>>>>>>>> >>>>>>>>>> Part of 'COMPLE_TEST' help contents in "init/Kconfig": >>>>>>>>>> >>>>>>>>>> "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Signed-off-by: Chen Gang <gan...@as...> >>>>>> NAKed-by: Geert Uytterhoeven <ge...@li...> >>>>>> >>>>>> Please don't clutter the code with checks for CONFIG_COMPILE_TEST. >>>> >>>> Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the >>>> platform should not support 'COMPILE_TEST") ? >>>> >>>> Or you mean: 'COMPILE_TEST' should not exist in kernel ? >> I mean that COMPILE_TEST should exist in Kconfig files only. >> It's only meant to have more compile coverage, not to "fix" (through #ifdef) >> more code to make it compile. > > If so, can we allow the module to 'COMPILE_TEST' under one platform > which not support the related HW ? > > e.g. "...Despite they cannot be loaded there (or even when they load > they cannot be used due to missing HW support)...". > > > 'asm-generic' need provide generic layer to users (both architecture > guys and module guys). > > So for 'default', it can depend on some conditions (e.g. HW support); > but for 'generic', it need try to be independent from any conditions. > > And it is also necessary for 'generic' to provide the configuration > checking features, but this checking must be no negative effect (or > consistent) with its 'generic' services. > > So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it > also necessary to consider about 'COMPILE_TEST' to be consistent with > its 'generic' services. > > > BTW: 20% code are for 80% features, but the left 20% features, need 80% > code, if we have to make it complete, we have to face this 'rule'. > > It is necessary to let the 'COMPILE_TEST' related members to know about it (better to provide their own opinions), it may be helpful for our discussion, so I list the details below. -------------------------------commit begin---------------------------------- commit 4bb1667255a86360721291fe59991d033bbc2f2a Author: Jiri Slaby <js...@su...> Date: Wed May 22 10:56:24 2013 +0200 build some drivers only when compile-testing Some drivers can be built on more platforms than they run on. This is a burden for users and distributors who package a kernel. They have to manually deselect some (for them useless) drivers when updating their configs via oldconfig. And yet, sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. Now the drivers where we use this new option: * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom processors so it should depend on x86. * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc systems -- which do not actually support the hardware via that method. * INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom device. [v2] * remove EXPERT dependency [gregkh - remove chipidea portion, as it's incorrect, and also doesn't apply to my driver-core tree] Signed-off-by: Jiri Slaby <js...@su...> Cc: Andrew Morton <ak...@li...> Cc: Linus Torvalds <tor...@li...> Cc: Jeff Mahoney <je...@su...> Cc: Alexander Shishkin <ale...@li...> Cc: lin...@vg... Cc: Florian Tobias Schandinat <Flo...@gm...> Cc: lin...@li... Cc: lin...@vg... Cc: Richard Cochran <ric...@gm...> Cc: ne...@vg... Cc: Ben Hutchings <be...@de...> Cc: "Keller, Jacob E" <jac...@in...> Signed-off-by: Greg Kroah-Hartman <gr...@li...> diff --git a/init/Kconfig b/init/Kconfig index 55ccdf6..1e825c2 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -53,6 +53,20 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +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. + -------------------------------commit end------------------------------------ Thanks. -- Chen Gang |