| Message ID | cover.1665568707.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: ioremap: Convert architectures to take GENERIC_IOREMAP way (Alternative) | expand |
Hi Christophe, On 10/12/22 at 12:09pm, Christophe Leroy wrote: > From: > > As proposed in the discussion related to your series, here comes an > exemple of how it could be. > > I have taken it into ARC and IA64 architectures as an exemple. This is > untested, even not compiled, it is just to illustrated my meaning in the > discussion. > > I also added a patch for powerpc architecture, that one in tested with > both pmac32_defconfig and ppc64_le_defconfig. > > From my point of view, this different approach provide less churn and > less intellectual disturbance than the way you do it. Yes, I agree, and admire your insistence on the thing you think right or better. Learn from you. When you suggested this in my v2 post, I made a draft patch at below link according to your suggestion to request people to review. What worried me is that I am not sure it's ignored or disliked after one week of waiting. https://lore.kernel.org/all/YwtND%2FL8xD+ViN3r@MiWiFi-R3L-srv/#related Up to now, seems people don't oppose this generic_ioremap_prot() way, we can take it. So what's your plan? You want me to continue with your patches wrapped in, or I can leave it to you if you want to take over? Thanks Baoquan > > Baoquan He (5): > hexagon: mm: Convert to GENERIC_IOREMAP > openrisc: mm: remove unneeded early ioremap code > mm: ioremap: allow ARCH to have its own ioremap definition > arc: mm: Convert to GENERIC_IOREMAP > ia64: mm: Convert to GENERIC_IOREMAP > > Christophe Leroy (3): > mm/ioremap: Define generic_ioremap_prot() and generic_iounmap() > mm/ioremap: Consider IOREMAP space in generic ioremap > powerpc: mm: Convert to GENERIC_IOREMAP > > arch/arc/Kconfig | 1 + > arch/arc/include/asm/io.h | 7 +++--- > arch/arc/mm/ioremap.c | 46 +++-------------------------------- > arch/hexagon/Kconfig | 1 + > arch/hexagon/include/asm/io.h | 9 +++++-- > arch/hexagon/mm/ioremap.c | 44 --------------------------------- > arch/ia64/Kconfig | 1 + > arch/ia64/include/asm/io.h | 11 ++++++--- > arch/ia64/mm/ioremap.c | 45 ++++++---------------------------- > arch/openrisc/mm/ioremap.c | 22 ++++------------- > arch/powerpc/Kconfig | 1 + > arch/powerpc/include/asm/io.h | 11 ++++++--- > arch/powerpc/mm/ioremap.c | 26 +------------------- > arch/powerpc/mm/ioremap_32.c | 25 ++++++++----------- > arch/powerpc/mm/ioremap_64.c | 22 +++++++---------- > include/asm-generic/io.h | 7 ++++++ > mm/ioremap.c | 33 +++++++++++++++++++------ > 17 files changed, 98 insertions(+), 214 deletions(-) > delete mode 100644 arch/hexagon/mm/ioremap.c > > -- > 2.37.1 >
Hi Baoquan, Le 17/10/2022 à 02:37, Baoquan He a écrit : > Hi Christophe, > > On 10/12/22 at 12:09pm, Christophe Leroy wrote: >> From: >> >> As proposed in the discussion related to your series, here comes an >> exemple of how it could be. >> >> I have taken it into ARC and IA64 architectures as an exemple. This is >> untested, even not compiled, it is just to illustrated my meaning in the >> discussion. >> >> I also added a patch for powerpc architecture, that one in tested with >> both pmac32_defconfig and ppc64_le_defconfig. >> >> From my point of view, this different approach provide less churn and >> less intellectual disturbance than the way you do it. > > Yes, I agree, and admire your insistence on the thing you think right or > better. Learn from you. > > When you suggested this in my v2 post, I made a draft patch at below link > according to your suggestion to request people to review. What worried > me is that I am not sure it's ignored or disliked after one week of > waiting. > > https://lore.kernel.org/all/YwtND%2FL8xD+ViN3r@MiWiFi-R3L-srv/#related > > Up to now, seems people don't oppose this generic_ioremap_prot() way, we > can take it. So what's your plan? You want me to continue with your > patches wrapped in, or I can leave it to you if you want to take over? I don't plan to steal your work. If you feel confortable with my proposal, feel free to continue with it and amplify it. You have done most of the job, you have a clear view of all subtilities in the different architectures, so please continue, I don't plan to take over the good work you've done until now. The only purpose of my series was to illustrate my comments and convince myself it was a possible way, nothing more. Thanks Christophe > > Thanks > Baoquan > >> >> Baoquan He (5): >> hexagon: mm: Convert to GENERIC_IOREMAP >> openrisc: mm: remove unneeded early ioremap code >> mm: ioremap: allow ARCH to have its own ioremap definition >> arc: mm: Convert to GENERIC_IOREMAP >> ia64: mm: Convert to GENERIC_IOREMAP >> >> Christophe Leroy (3): >> mm/ioremap: Define generic_ioremap_prot() and generic_iounmap() >> mm/ioremap: Consider IOREMAP space in generic ioremap >> powerpc: mm: Convert to GENERIC_IOREMAP >> >> arch/arc/Kconfig | 1 + >> arch/arc/include/asm/io.h | 7 +++--- >> arch/arc/mm/ioremap.c | 46 +++-------------------------------- >> arch/hexagon/Kconfig | 1 + >> arch/hexagon/include/asm/io.h | 9 +++++-- >> arch/hexagon/mm/ioremap.c | 44 --------------------------------- >> arch/ia64/Kconfig | 1 + >> arch/ia64/include/asm/io.h | 11 ++++++--- >> arch/ia64/mm/ioremap.c | 45 ++++++---------------------------- >> arch/openrisc/mm/ioremap.c | 22 ++++------------- >> arch/powerpc/Kconfig | 1 + >> arch/powerpc/include/asm/io.h | 11 ++++++--- >> arch/powerpc/mm/ioremap.c | 26 +------------------- >> arch/powerpc/mm/ioremap_32.c | 25 ++++++++----------- >> arch/powerpc/mm/ioremap_64.c | 22 +++++++---------- >> include/asm-generic/io.h | 7 ++++++ >> mm/ioremap.c | 33 +++++++++++++++++++------ >> 17 files changed, 98 insertions(+), 214 deletions(-) >> delete mode 100644 arch/hexagon/mm/ioremap.c >> >> -- >> 2.37.1 >> >
On 10/17/22 at 05:06pm, Christophe Leroy wrote: > Hi Baoquan, > > Le 17/10/2022 à 02:37, Baoquan He a écrit : > > Hi Christophe, > > > > On 10/12/22 at 12:09pm, Christophe Leroy wrote: > >> From: > >> > >> As proposed in the discussion related to your series, here comes an > >> exemple of how it could be. > >> > >> I have taken it into ARC and IA64 architectures as an exemple. This is > >> untested, even not compiled, it is just to illustrated my meaning in the > >> discussion. > >> > >> I also added a patch for powerpc architecture, that one in tested with > >> both pmac32_defconfig and ppc64_le_defconfig. > >> > >> From my point of view, this different approach provide less churn and > >> less intellectual disturbance than the way you do it. > > > > Yes, I agree, and admire your insistence on the thing you think right or > > better. Learn from you. > > > > When you suggested this in my v2 post, I made a draft patch at below link > > according to your suggestion to request people to review. What worried > > me is that I am not sure it's ignored or disliked after one week of > > waiting. > > > > https://lore.kernel.org/all/YwtND%2FL8xD+ViN3r@MiWiFi-R3L-srv/#related > > > > Up to now, seems people don't oppose this generic_ioremap_prot() way, we > > can take it. So what's your plan? You want me to continue with your > > patches wrapped in, or I can leave it to you if you want to take over? > > I don't plan to steal your work. If you feel confortable with my > proposal, feel free to continue with it and amplify it. You have done > most of the job, you have a clear view of all subtilities in the > different architectures, so please continue, I don't plan to take over > the good work you've done until now. > > The only purpose of my series was to illustrate my comments and convince > myself it was a possible way, nothing more. Thanks a lot for all these you have done, I will post another version with the introducing generic_ioremap_prot() way you suggesed.
From: As proposed in the discussion related to your series, here comes an exemple of how it could be. I have taken it into ARC and IA64 architectures as an exemple. This is untested, even not compiled, it is just to illustrated my meaning in the discussion. I also added a patch for powerpc architecture, that one in tested with both pmac32_defconfig and ppc64_le_defconfig. From my point of view, this different approach provide less churn and less intellectual disturbance than the way you do it. Open for discussion. Baoquan He (5): hexagon: mm: Convert to GENERIC_IOREMAP openrisc: mm: remove unneeded early ioremap code mm: ioremap: allow ARCH to have its own ioremap definition arc: mm: Convert to GENERIC_IOREMAP ia64: mm: Convert to GENERIC_IOREMAP Christophe Leroy (3): mm/ioremap: Define generic_ioremap_prot() and generic_iounmap() mm/ioremap: Consider IOREMAP space in generic ioremap powerpc: mm: Convert to GENERIC_IOREMAP arch/arc/Kconfig | 1 + arch/arc/include/asm/io.h | 7 +++--- arch/arc/mm/ioremap.c | 46 +++-------------------------------- arch/hexagon/Kconfig | 1 + arch/hexagon/include/asm/io.h | 9 +++++-- arch/hexagon/mm/ioremap.c | 44 --------------------------------- arch/ia64/Kconfig | 1 + arch/ia64/include/asm/io.h | 11 ++++++--- arch/ia64/mm/ioremap.c | 45 ++++++---------------------------- arch/openrisc/mm/ioremap.c | 22 ++++------------- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/io.h | 11 ++++++--- arch/powerpc/mm/ioremap.c | 26 +------------------- arch/powerpc/mm/ioremap_32.c | 25 ++++++++----------- arch/powerpc/mm/ioremap_64.c | 22 +++++++---------- include/asm-generic/io.h | 7 ++++++ mm/ioremap.c | 33 +++++++++++++++++++------ 17 files changed, 98 insertions(+), 214 deletions(-) delete mode 100644 arch/hexagon/mm/ioremap.c