Re: [RFC] About ARM expansion boards and others things
On 05/04/11 15:28, Enric Balletbò i Serra wrote: > 2011/5/4 Igor Grinberg : >> On 05/03/11 20:25, Enric Balletbò i Serra wrote: [...] >>> I'll explain a little more, the real problem is I don't know how to >>> add support for an expansion board for IGEP v2 board. I see most of >>> boards adds the support inside the board-x.c file, for example if >>> the expansion board has a Touchscreen interface using ADS7846/TSC2046 >>> they register ads7846 platform data in board-.c file. This is ok >>> beacause the ads7846 can be detected and if expansion board is not >>> present the detection fails, but maybe other devices in expansion >>> board can't be detected (for example an I/O expansion). So which is >>> the best form to do this ? >>> >>> I'm thinking in create a kernel module for the expansion board that >>> add all the new features, the expansion board should come with a I2C >>> E2PROM for board ID storage, so the idea is create an i2c driver that >>> reads the E2PROM and if found the Board ID inits all the expansion >>> board devices. >> Why do you need to create a new driver? Why don't you use the existing one? >> at24 works nice with most i2c EEPROMs. >> >> Let me generalize: >> 1) Lets call each board that actually has SoC, like IGEP, a System On Module >> (SoM) >> 2) SoM has on-board and on-SoC devices >> 3) expansion has additional on-board devices >> 4) We are talking about X SoMs and Y extensions >> 5) Each SoM can be connected to each extension and communicate with its >> devices. >> 6) We are looking for a solution to be able to detect the expansion and >> register >> the devices it has assembled. > Great generalitzation ! Thanks, please, consider "extension" = "expansion". >>> I have done a few experiments, I've created a kernel module (driver) >>> for a custom expansion board for IGEP v2, the expansion board has : >>>- I2C E2PROM >>>- ADS7846 touch controller (spi) >>>- Seiko 7.0inch LCD >>>- General purpose I/O >>> >>> The driver is capable to register correctly i2c and spi devices and >>> seems is working but I have problems with the Seiko 7.0inch LCD and >>> configuring the MUX from driver. >> Like Tony already said the generic MUX API should solve the problem of MUX. >> But, you will still have a problem with devices that have to be initialized >> very early, like IO chips. > Right, about the MUX, there is any patch or specification for the MUX API ? You can read here: http://www.spinics.net/lists/arm-kernel/msg123703.html and here: http://www.spinics.net/lists/arm-kernel/msg123702.html I still haven't had a chance to look into it. [...] >>> All of this is a crazy idea ? What's the best form to solve the problem ? >> This is not crazy at all. >> We already use this concept in our BSP, we detect the expansion >> by reading data from EEPROM, and register the devices accordingly. >> We solve the MUX problem by initializing the pins to some default state >> and once the expansion detection is done, we reconfigure the pins >> to their right state as required by connected devices. >> >> And yes the above is done from board file. > So its possilbe read the EEPROM in board file ? How ? I was thinking > wasn't possible read the EEPROM in board initialitzation because was > in a early state. You should take a look at the at24 driver (drivers/misc/at24.c) While registering the EEPROM device structure, you can provide the setup() callback inside the at24_platform_data, which will be called once the at24 driver is initialized. Though, this will not happen early, but there are still plenty of things you can do. You can see the usage example in davinci code, if I'm not mistaken, they setup the MAC address this way. This will not solve you the dynamic DSS device registration problem. >> I don't see any reason to create a driver for the expansion, >> unless it can be removed/attached "on the fly" while the SoM is up and >> running. > Completely agree, normally expansion board can't be connected "on the fly" > >> Nevertheless, some framework or at least an agreement on how we should >> separate the SoM code from the expansion code. >> >> I thought of some convention like board-*.c will stay the code for the SoM >> and exp-*.c will be used for the expansion code. >> Now, the code in board-*.c will do the detection of the expansion and >> run the appropriate exp_*_init() function, which will do the initialization >> steps >> for the detected expansion. >> A bit more complicated solution will be needed if there are several >> expansions >> connected all together. >> > Looks good for me if this is the accepted solution. > >> I have had this in my mind for very long time, but did not want to bother, >> because there were discussions about a totally different approach which uses >> device trees (DT), where the detection of expansion is moved away >> from the kernel code. >> >> With the DT approach, the kernel (should) get(s) all the information >> regarding >> the devices
Re: [RFC] About ARM expansion boards and others things
2011/5/4 Igor Grinberg : > On 05/03/11 20:25, Enric Balletbò i Serra wrote: > >> Hi guys, >> I'm thinking probably in a crazy idea, I hope someone can help me or >> kill definitely this idea from my mind. > > This is not that crazy as you think it is... > >> I'll explain a little more, the real problem is I don't know how to >> add support for an expansion board for IGEP v2 board. I see most of >> boards adds the support inside the board-x.c file, for example if >> the expansion board has a Touchscreen interface using ADS7846/TSC2046 >> they register ads7846 platform data in board-.c file. This is ok >> beacause the ads7846 can be detected and if expansion board is not >> present the detection fails, but maybe other devices in expansion >> board can't be detected (for example an I/O expansion). So which is >> the best form to do this ? >> >> I'm thinking in create a kernel module for the expansion board that >> add all the new features, the expansion board should come with a I2C >> E2PROM for board ID storage, so the idea is create an i2c driver that >> reads the E2PROM and if found the Board ID inits all the expansion >> board devices. > > Why do you need to create a new driver? Why don't you use the existing one? > at24 works nice with most i2c EEPROMs. > > Let me generalize: > 1) Lets call each board that actually has SoC, like IGEP, a System On Module > (SoM) > 2) SoM has on-board and on-SoC devices > 3) expansion has additional on-board devices > 4) We are talking about X SoMs and Y extensions > 5) Each SoM can be connected to each extension and communicate with its > devices. > 6) We are looking for a solution to be able to detect the expansion and > register > the devices it has assembled. Great generalitzation ! >> I have done a few experiments, I've created a kernel module (driver) >> for a custom expansion board for IGEP v2, the expansion board has : >> - I2C E2PROM >> - ADS7846 touch controller (spi) >> - Seiko 7.0inch LCD >> - General purpose I/O >> >> The driver is capable to register correctly i2c and spi devices and >> seems is working but I have problems with the Seiko 7.0inch LCD and >> configuring the MUX from driver. > > Like Tony already said the generic MUX API should solve the problem of MUX. > But, you will still have a problem with devices that have to be initialized > very early, like IO chips. Right, about the MUX, there is any patch or specification for the MUX API ? > >> Basically I wonder if it's possible add another omap_dss_device from >> kernel module to the omap DSS driver (something like >> omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any >> reason to not export the MUX functionality to be used for other >> drivers ? > > ... > >> All of this is a crazy idea ? What's the best form to solve the problem ? > > This is not crazy at all. > We already use this concept in our BSP, we detect the expansion > by reading data from EEPROM, and register the devices accordingly. > We solve the MUX problem by initializing the pins to some default state > and once the expansion detection is done, we reconfigure the pins > to their right state as required by connected devices. > > And yes the above is done from board file. So its possilbe read the EEPROM in board file ? How ? I was thinking wasn't possible read the EEPROM in board initialitzation because was in a early state. > I don't see any reason to create a driver for the expansion, > unless it can be removed/attached "on the fly" while the SoM is up and > running. Completely agree, normally expansion board can't be connected "on the fly" > > Nevertheless, some framework or at least an agreement on how we should > separate the SoM code from the expansion code. > > I thought of some convention like board-*.c will stay the code for the SoM > and exp-*.c will be used for the expansion code. > Now, the code in board-*.c will do the detection of the expansion and > run the appropriate exp_*_init() function, which will do the initialization > steps > for the detected expansion. > A bit more complicated solution will be needed if there are several expansions > connected all together. > Looks good for me if this is the accepted solution. > I have had this in my mind for very long time, but did not want to bother, > because there were discussions about a totally different approach which uses > device trees (DT), where the detection of expansion is moved away > from the kernel code. > > With the DT approach, the kernel (should) get(s) all the information regarding > the devices and how they are wired for free (no detection). > If I understand correctly, the information about devices > (whether on SoM or expansion) could be either statically added to the DT > structures or dynamically detected by the bootloader and passed to the > kernel (like ATAGS work now). Really interesting, I'll look that, do you think is the future to solve this problem ? Have you tested ? > > I still doubt what a
Re: [RFC] About ARM expansion boards and others things
On Tue, 2011-05-03 at 19:25 +0200, Enric Balletbò i Serra wrote: > Hi guys, > I'm thinking probably in a crazy idea, I hope someone can help me or > kill definitely this idea from my mind. > > I'll explain a little more, the real problem is I don't know how to > add support for an expansion board for IGEP v2 board. I see most of > boards adds the support inside the board-x.c file, for example if > the expansion board has a Touchscreen interface using ADS7846/TSC2046 > they register ads7846 platform data in board-.c file. This is ok > beacause the ads7846 can be detected and if expansion board is not > present the detection fails, but maybe other devices in expansion > board can't be detected (for example an I/O expansion). So which is > the best form to do this ? > > I'm thinking in create a kernel module for the expansion board that > add all the new features, the expansion board should come with a I2C > E2PROM for board ID storage, so the idea is create an i2c driver that > reads the E2PROM and if found the Board ID inits all the expansion > board devices. > > I have done a few experiments, I've created a kernel module (driver) > for a custom expansion board for IGEP v2, the expansion board has : >- I2C E2PROM >- ADS7846 touch controller (spi) >- Seiko 7.0inch LCD >- General purpose I/O > > The driver is capable to register correctly i2c and spi devices and > seems is working but I have problems with the Seiko 7.0inch LCD and > configuring the MUX from driver. > > Basically I wonder if it's possible add another omap_dss_device from > kernel module to the omap DSS driver (something like > omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any > reason to not export the MUX functionality to be used for other > drivers ? Currently omapdss doesn't let you add dss devices dynamically, they all need to be there when omapdss is loaded. There shouldn't be any bigger reason why this couldn't be implemented, but there just has never been need for it and it will make the code more complex, so it has just never been done. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
Op 4 mei 2011, om 12:46 heeft Enric Balletbò i Serra het volgende geschreven: > 2011/5/4 Vladimir Pantelic : >> Enric Balletbò i Serra wrote: >>> >>> Hi guys, >>> I'm thinking probably in a crazy idea, I hope someone can help me or >>> kill definitely this idea from my mind. >>> >>> I'll explain a little more, the real problem is I don't know how to >>> add support for an expansion board for IGEP v2 board. I see most of >>> boards adds the support inside the board-x.c file, for example if >>> the expansion board has a Touchscreen interface using ADS7846/TSC2046 >>> they register ads7846 platform data in board-.c file. This is ok >>> beacause the ads7846 can be detected and if expansion board is not >>> present the detection fails, but maybe other devices in expansion >>> board can't be detected (for example an I/O expansion). So which is >>> the best form to do this ? >>> >>> I'm thinking in create a kernel module for the expansion board that >>> add all the new features, the expansion board should come with a I2C >>> E2PROM for board ID storage, so the idea is create an i2c driver that >>> reads the E2PROM and if found the Board ID inits all the expansion >>> board devices. >> >> don't know if you are aware of that: >> >> http://elinux.org/BeagleBoardPinMux#Expansion_boards >> > > Yes I know it. > >> also beagle.c board file has support for some expansion boards >> already, maybe there is some code to be shared. >> >> > > But I don't see any support for expansion board in board-omap3beagle.c > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=33007fd4a0835fd298129c9fda30b844707cc08b;hb=HEAD > > i see some patches (not published in mainline) that are reading a > kernel cmdline. I mean, the bootloader (u-boot) detects if an > expansion board is present (mostly via i2c) and then add to the kernel > cmdline a parameter with the name of the expansion board. The kernel > reads this parameter and initializes the expansion board devices. > > But not sure if this is a good solution. What solution do you think is > better ? Using kernel cmdline or create a separate kernel module for > every expansion board ? We went the uboot way with beagle because the I2C subsystem in linux sucks for things like this. When we were implementing it there was no sane way to do: 1) register eeprom with i2c 2) read eeprom 3) register additional i2c devices on the expansion board And of course in-kernel muxing didn't work back then. To illustrate the problem a bit more, all camera sensor boards use the same I2C id for the sensor, so you can't register them all at once, you need to know which one is attached. So for the beagleboard xM we'd need the following: a) being able to read the eeprom from linux and (re)initialize extra i2c devices, SPI, mmc, uart, etc b) being able to read the ID register from the camera sensor and (re)setup the i2c data and v4l2 stuff Personally, I don't care where the logic resides, it just needs to work and be expandable. regards, Koen-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
Sorry for the second send attempt, the first one was accidentally sent to wrong addresses. On 05/04/11 13:53, Igor Grinberg wrote: > On 05/03/11 20:25, Enric Balletbò i Serra wrote: > >> Hi guys, >> I'm thinking probably in a crazy idea, I hope someone can help me or >> kill definitely this idea from my mind. > This is not that crazy as you think it is... > >> I'll explain a little more, the real problem is I don't know how to >> add support for an expansion board for IGEP v2 board. I see most of >> boards adds the support inside the board-x.c file, for example if >> the expansion board has a Touchscreen interface using ADS7846/TSC2046 >> they register ads7846 platform data in board-.c file. This is ok >> beacause the ads7846 can be detected and if expansion board is not >> present the detection fails, but maybe other devices in expansion >> board can't be detected (for example an I/O expansion). So which is >> the best form to do this ? >> >> I'm thinking in create a kernel module for the expansion board that >> add all the new features, the expansion board should come with a I2C >> E2PROM for board ID storage, so the idea is create an i2c driver that >> reads the E2PROM and if found the Board ID inits all the expansion >> board devices. > Why do you need to create a new driver? Why don't you use the existing one? > at24 works nice with most i2c EEPROMs. > > Let me generalize: > 1) Lets call each board that actually has SoC, like IGEP, a System On Module > (SoM) > 2) SoM has on-board and on-SoC devices > 3) expansion has additional on-board devices > 4) We are talking about X SoMs and Y extensions > 5) Each SoM can be connected to each extension and communicate with its > devices. > 6) We are looking for a solution to be able to detect the expansion and > register >the devices it has assembled. > >> I have done a few experiments, I've created a kernel module (driver) >> for a custom expansion board for IGEP v2, the expansion board has : >>- I2C E2PROM >>- ADS7846 touch controller (spi) >>- Seiko 7.0inch LCD >>- General purpose I/O >> >> The driver is capable to register correctly i2c and spi devices and >> seems is working but I have problems with the Seiko 7.0inch LCD and >> configuring the MUX from driver. > Like Tony already said the generic MUX API should solve the problem of MUX. > But, you will still have a problem with devices that have to be initialized > very early, like IO chips. > >> Basically I wonder if it's possible add another omap_dss_device from >> kernel module to the omap DSS driver (something like >> omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any >> reason to not export the MUX functionality to be used for other >> drivers ? > ... > >> All of this is a crazy idea ? What's the best form to solve the problem ? > This is not crazy at all. > We already use this concept in our BSP, we detect the expansion > by reading data from EEPROM, and register the devices accordingly. > We solve the MUX problem by initializing the pins to some default state > and once the expansion detection is done, we reconfigure the pins > to their right state as required by connected devices. > > And yes the above is done from board file. > I don't see any reason to create a driver for the expansion, > unless it can be removed/attached "on the fly" while the SoM is up and > running. > > Nevertheless, some framework or at least an agreement on how we should > separate the SoM code from the expansion code. > > I thought of some convention like board-*.c will stay the code for the SoM > and exp-*.c will be used for the expansion code. > Now, the code in board-*.c will do the detection of the expansion and > run the appropriate exp_*_init() function, which will do the initialization > steps > for the detected expansion. > A bit more complicated solution will be needed if there are several expansions > connected all together. > > I have had this in my mind for very long time, but did not want to bother, > because there were discussions about a totally different approach which uses > device trees (DT), where the detection of expansion is moved away > from the kernel code. > > With the DT approach, the kernel (should) get(s) all the information regarding > the devices and how they are wired for free (no detection). > If I understand correctly, the information about devices > (whether on SoM or expansion) could be either statically added to the DT > structures or dynamically detected by the bootloader and passed to the > kernel (like ATAGS work now). > > I still doubt what approach would be better... > -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
On 05/03/11 20:25, Enric Balletbò i Serra wrote: > Hi guys, > I'm thinking probably in a crazy idea, I hope someone can help me or > kill definitely this idea from my mind. This is not that crazy as you think it is... > I'll explain a little more, the real problem is I don't know how to > add support for an expansion board for IGEP v2 board. I see most of > boards adds the support inside the board-x.c file, for example if > the expansion board has a Touchscreen interface using ADS7846/TSC2046 > they register ads7846 platform data in board-.c file. This is ok > beacause the ads7846 can be detected and if expansion board is not > present the detection fails, but maybe other devices in expansion > board can't be detected (for example an I/O expansion). So which is > the best form to do this ? > > I'm thinking in create a kernel module for the expansion board that > add all the new features, the expansion board should come with a I2C > E2PROM for board ID storage, so the idea is create an i2c driver that > reads the E2PROM and if found the Board ID inits all the expansion > board devices. Why do you need to create a new driver? Why don't you use the existing one? at24 works nice with most i2c EEPROMs. Let me generalize: 1) Lets call each board that actually has SoC, like IGEP, a System On Module (SoM) 2) SoM has on-board and on-SoC devices 3) expansion has additional on-board devices 4) We are talking about X SoMs and Y extensions 5) Each SoM can be connected to each extension and communicate with its devices. 6) We are looking for a solution to be able to detect the expansion and register the devices it has assembled. > I have done a few experiments, I've created a kernel module (driver) > for a custom expansion board for IGEP v2, the expansion board has : >- I2C E2PROM >- ADS7846 touch controller (spi) >- Seiko 7.0inch LCD >- General purpose I/O > > The driver is capable to register correctly i2c and spi devices and > seems is working but I have problems with the Seiko 7.0inch LCD and > configuring the MUX from driver. Like Tony already said the generic MUX API should solve the problem of MUX. But, you will still have a problem with devices that have to be initialized very early, like IO chips. > Basically I wonder if it's possible add another omap_dss_device from > kernel module to the omap DSS driver (something like > omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any > reason to not export the MUX functionality to be used for other > drivers ? ... > All of this is a crazy idea ? What's the best form to solve the problem ? This is not crazy at all. We already use this concept in our BSP, we detect the expansion by reading data from EEPROM, and register the devices accordingly. We solve the MUX problem by initializing the pins to some default state and once the expansion detection is done, we reconfigure the pins to their right state as required by connected devices. And yes the above is done from board file. I don't see any reason to create a driver for the expansion, unless it can be removed/attached "on the fly" while the SoM is up and running. Nevertheless, some framework or at least an agreement on how we should separate the SoM code from the expansion code. I thought of some convention like board-*.c will stay the code for the SoM and exp-*.c will be used for the expansion code. Now, the code in board-*.c will do the detection of the expansion and run the appropriate exp_*_init() function, which will do the initialization steps for the detected expansion. A bit more complicated solution will be needed if there are several expansions connected all together. I have had this in my mind for very long time, but did not want to bother, because there were discussions about a totally different approach which uses device trees (DT), where the detection of expansion is moved away from the kernel code. With the DT approach, the kernel (should) get(s) all the information regarding the devices and how they are wired for free (no detection). If I understand correctly, the information about devices (whether on SoM or expansion) could be either statically added to the DT structures or dynamically detected by the bootloader and passed to the kernel (like ATAGS work now). I still doubt what approach would be better... -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
2011/5/4 Vladimir Pantelic : > Enric Balletbò i Serra wrote: >> >> Hi guys, >> I'm thinking probably in a crazy idea, I hope someone can help me or >> kill definitely this idea from my mind. >> >> I'll explain a little more, the real problem is I don't know how to >> add support for an expansion board for IGEP v2 board. I see most of >> boards adds the support inside the board-x.c file, for example if >> the expansion board has a Touchscreen interface using ADS7846/TSC2046 >> they register ads7846 platform data in board-.c file. This is ok >> beacause the ads7846 can be detected and if expansion board is not >> present the detection fails, but maybe other devices in expansion >> board can't be detected (for example an I/O expansion). So which is >> the best form to do this ? >> >> I'm thinking in create a kernel module for the expansion board that >> add all the new features, the expansion board should come with a I2C >> E2PROM for board ID storage, so the idea is create an i2c driver that >> reads the E2PROM and if found the Board ID inits all the expansion >> board devices. > > don't know if you are aware of that: > > http://elinux.org/BeagleBoardPinMux#Expansion_boards > Yes I know it. > also beagle.c board file has support for some expansion boards > already, maybe there is some code to be shared. > > But I don't see any support for expansion board in board-omap3beagle.c http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=33007fd4a0835fd298129c9fda30b844707cc08b;hb=HEAD i see some patches (not published in mainline) that are reading a kernel cmdline. I mean, the bootloader (u-boot) detects if an expansion board is present (mostly via i2c) and then add to the kernel cmdline a parameter with the name of the expansion board. The kernel reads this parameter and initializes the expansion board devices. But not sure if this is a good solution. What solution do you think is better ? Using kernel cmdline or create a separate kernel module for every expansion board ? In fact the purpose of this email is discuss a bit which is the proper solution to add an expansion board to the kernel mainline. Regards, Enric -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
Enric Balletbò i Serra wrote: Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. don't know if you are aware of that: http://elinux.org/BeagleBoardPinMux#Expansion_boards also beagle.c board file has support for some expansion boards already, maybe there is some code to be shared. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] About ARM expansion boards and others things
* Enric Balletbò i Serra [110503 10:21]: > > Basically I wonder if it's possible add another omap_dss_device from > kernel module to the omap DSS driver (something like > omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any > reason to not export the MUX functionality to be used for other > drivers ? Sounds all doable. For DSS, I think the memblock needs to be reserved early. With the mux framework, we have a Linux generic mux framework coming up, that should allow you to access the pins from the driver module too. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
