From: Arnd Bergmann <arnd@arndb.de> To: Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org>, Dong Aisheng <aisheng.dong@freescale.com>, Huang Shijie <b32955@freescale.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 1/3] lib: add support for stmp-style devices Date: Sat, 21 Apr 2012 11:09:42 +0000 [thread overview] Message-ID: <201204211109.42732.arnd@arndb.de> (raw) In-Reply-To: <20120420211108.GC12691@pengutronix.de> On Friday 20 April 2012, Wolfram Sang wrote: > On Fri, Apr 20, 2012 at 01:30:17PM +0800, Shawn Guo wrote: > > On Wed, Apr 18, 2012 at 11:20:19AM +0200, Wolfram Sang wrote: > > > > If not, i guess include/linux/fsl which already exists may be the > > > > right place. > > > > > > Which is a bad choice in my book. linux/dma would have been the proper > > > thing for mxs-dma.h, I'd think. > > > > > If it already exists, it will be the proper place. We do not want to > > be too invasive to create folders in include/linux for every subsystem > > for only the need of fsl drivers. > > I think linux/dma would have made sense: > > $:~/Kernel/linux/include/linux$ ll *dma* > -rw-r--r-- 1 ninja ninja 1809 Apr 15 23:32 dma-attrs.h > ... > -rw-r--r-- 1 ninja ninja 2631 Apr 15 23:32 sh_dma.h > -rw-r--r-- 1 ninja ninja 123 Mar 30 22:12 sirfsoc_dma.h > -rw-r--r-- 1 ninja ninja 1784 Aug 20 2011 timb_dma.h +1 > > On the other hand, I have seen a clear need for include/linux/fsl. > > The following files are all good candidates to be moved there. > > > > include/linux/fsl_devices.h > > I stumbled over this file some time ago. It is an arbitrary collection of stuff > which should better be seperate. See 'fsl_spi_platform_data'? That should be > cpm_spi_platform_data. It doesn't even fit to MPC5200 (which SPI driver > unnecessarily includes this file), let alone i.MX, so calling it 'fsl' doesn't > make sense at all. I fear similar confusion with a fsl-directory. Agreed. I would much prefer to avoid any such vendor specific silos for where to dump random code. A file for a company that makes both powerpc and arm SoCs that have a few components in common but also share other components with other SoCs of the respective architectures does not seem very useful to me. > > include/linux/fsl-diu-fb.h > > Sadly, another bad choice. It should have gone to include/video like all other > fb-drivers. > > > include/linux/fsl_hypervisor.h > > And that could simply stay in include/linux then, like kvm does. Well, we could also have a linux/virt/ directory. Unfortunately in both these cases we have no choice any more because they contain ioctl data structures that are exported to user space, so we cannot move these files without breaking user space programs and we don't do that. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V2 1/3] lib: add support for stmp-style devices Date: Sat, 21 Apr 2012 11:09:42 +0000 [thread overview] Message-ID: <201204211109.42732.arnd@arndb.de> (raw) In-Reply-To: <20120420211108.GC12691@pengutronix.de> On Friday 20 April 2012, Wolfram Sang wrote: > On Fri, Apr 20, 2012 at 01:30:17PM +0800, Shawn Guo wrote: > > On Wed, Apr 18, 2012 at 11:20:19AM +0200, Wolfram Sang wrote: > > > > If not, i guess include/linux/fsl which already exists may be the > > > > right place. > > > > > > Which is a bad choice in my book. linux/dma would have been the proper > > > thing for mxs-dma.h, I'd think. > > > > > If it already exists, it will be the proper place. We do not want to > > be too invasive to create folders in include/linux for every subsystem > > for only the need of fsl drivers. > > I think linux/dma would have made sense: > > $:~/Kernel/linux/include/linux$ ll *dma* > -rw-r--r-- 1 ninja ninja 1809 Apr 15 23:32 dma-attrs.h > ... > -rw-r--r-- 1 ninja ninja 2631 Apr 15 23:32 sh_dma.h > -rw-r--r-- 1 ninja ninja 123 Mar 30 22:12 sirfsoc_dma.h > -rw-r--r-- 1 ninja ninja 1784 Aug 20 2011 timb_dma.h +1 > > On the other hand, I have seen a clear need for include/linux/fsl. > > The following files are all good candidates to be moved there. > > > > include/linux/fsl_devices.h > > I stumbled over this file some time ago. It is an arbitrary collection of stuff > which should better be seperate. See 'fsl_spi_platform_data'? That should be > cpm_spi_platform_data. It doesn't even fit to MPC5200 (which SPI driver > unnecessarily includes this file), let alone i.MX, so calling it 'fsl' doesn't > make sense at all. I fear similar confusion with a fsl-directory. Agreed. I would much prefer to avoid any such vendor specific silos for where to dump random code. A file for a company that makes both powerpc and arm SoCs that have a few components in common but also share other components with other SoCs of the respective architectures does not seem very useful to me. > > include/linux/fsl-diu-fb.h > > Sadly, another bad choice. It should have gone to include/video like all other > fb-drivers. > > > include/linux/fsl_hypervisor.h > > And that could simply stay in include/linux then, like kvm does. Well, we could also have a linux/virt/ directory. Unfortunately in both these cases we have no choice any more because they contain ioctl data structures that are exported to user space, so we cannot move these files without breaking user space programs and we don't do that. Arnd
next prev parent reply other threads:[~2012-04-21 11:19 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-21 22:21 [PATCH V2 0/3] introduce stmp-style devices Wolfram Sang 2012-03-21 22:21 ` Wolfram Sang 2012-03-21 22:21 ` [PATCH V2 1/3] lib: add support for " Wolfram Sang 2012-03-21 22:21 ` Wolfram Sang 2012-03-29 2:45 ` Huang Shijie 2012-03-29 2:45 ` Huang Shijie 2012-03-29 6:43 ` Wolfram Sang 2012-03-29 6:43 ` Wolfram Sang 2012-04-18 9:05 ` Dong Aisheng 2012-04-18 9:05 ` Dong Aisheng 2012-04-18 9:20 ` Wolfram Sang 2012-04-18 9:20 ` Wolfram Sang 2012-04-19 16:24 ` Arnd Bergmann 2012-04-19 16:24 ` Arnd Bergmann 2012-04-20 5:30 ` Shawn Guo 2012-04-20 5:30 ` Shawn Guo 2012-04-20 21:11 ` Wolfram Sang 2012-04-20 21:11 ` Wolfram Sang 2012-04-21 11:09 ` Arnd Bergmann [this message] 2012-04-21 11:09 ` Arnd Bergmann 2012-04-04 11:21 ` Huang Shijie 2012-04-04 11:21 ` Huang Shijie 2012-04-04 12:23 ` Wolfram Sang 2012-04-04 12:23 ` Wolfram Sang 2012-04-06 7:40 ` Huang Shijie 2012-04-06 7:40 ` Huang Shijie 2012-04-06 18:21 ` Wolfram Sang 2012-04-06 18:21 ` Wolfram Sang 2012-04-07 2:30 ` Huang Shijie 2012-04-07 2:30 ` Huang Shijie 2012-04-07 8:00 ` Wolfram Sang 2012-04-07 8:00 ` Wolfram Sang 2012-04-07 13:45 ` Huang Shijie 2012-04-07 13:45 ` Huang Shijie 2012-04-23 6:55 ` Andrew Morton 2012-04-23 6:55 ` Andrew Morton 2012-04-23 7:28 ` Wolfram Sang 2012-04-23 7:28 ` Wolfram Sang 2012-04-23 11:06 ` Arnd Bergmann 2012-04-23 11:06 ` Arnd Bergmann 2012-03-21 22:21 ` [PATCH 2/3] i2c: mxs: use global reset function Wolfram Sang 2012-03-21 22:21 ` Wolfram Sang 2012-03-21 22:21 ` [PATCH 3/3] rtc: stmp3xxx: use global stmp_device functionality Wolfram Sang 2012-03-21 22:21 ` Wolfram Sang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201204211109.42732.arnd@arndb.de \ --to=arnd@arndb.de \ --cc=aisheng.dong@freescale.com \ --cc=b32955@freescale.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=shawn.guo@linaro.org \ --cc=w.sang@pengutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.