Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Prafulla, On 06/12/2012 06:39 AM, Prafulla Wadaskar wrote: > > >> -Original Message- >> From: u-boot-boun...@lists.denx.de [mailto:u-boot- >> boun...@lists.denx.de] On Behalf Of Valentin Longchamp >> Sent: 07 June 2012 15:37 >> To: prafu...@mavell.com >> Cc: Valentin Longchamp; holger.bru...@keymile.com; u- >> b...@lists.denx.de >> Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external >> switch configuration >> >> This can be used if we do not want to use an EEPROM for the >> configuration. >> >> Signed-off-by: Valentin Longchamp >> --- >> board/keymile/common/common.h |7 -- >> board/keymile/km_arm/managed_switch.c | 169 >> +++-- >> board/keymile/km_arm/managed_switch.h | 99 +++ > > What is managed switch? Which chip it supports? Why it is sitting here and > not in generic folder? > In this case, the switch is a Marvell 88E52xxx (don't remember the exact model) that is connected to the GE port of the Kirkwood and that gets configured by the Kirkwood through a MDIO link, using indirect addressing. We do not have the pretention to write a generic driver for such switches/addressing, but we need this functionnality on some boards, that's why we have kept it in our own folder and not in a generic driver folder. I will add the above precisions to the commit message for an optional v3 of the "updates for the Keymile Marvell boards" series so that this is more clear. Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
> -Original Message- > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] > Sent: 21 June 2012 18:40 > To: Prafulla Wadaskar > Cc: prafu...@mavell.com; holger.bru...@keymile.com; u- > b...@lists.denx.de > Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external > switchconfiguration > > Hi Prafulla, > > On 06/12/2012 06:39 AM, Prafulla Wadaskar wrote: > > > > > >> -Original Message- > >> From: u-boot-boun...@lists.denx.de [mailto:u-boot- > >> boun...@lists.denx.de] On Behalf Of Valentin Longchamp > >> Sent: 07 June 2012 15:37 > >> To: prafu...@mavell.com > >> Cc: Valentin Longchamp; holger.bru...@keymile.com; u- > >> b...@lists.denx.de > >> Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external > >> switch configuration > >> > >> This can be used if we do not want to use an EEPROM for the > >> configuration. > >> > >> Signed-off-by: Valentin Longchamp > >> --- > >> board/keymile/common/common.h |7 -- > >> board/keymile/km_arm/managed_switch.c | 169 > >> +++-- > >> board/keymile/km_arm/managed_switch.h | 99 +++ > > > > What is managed switch? Which chip it supports? Why it is sitting > here and not in generic folder? > > > > In this case, the switch is a Marvell 88E52xxx (don't remember the > exact model) > that is connected to the GE port of the Kirkwood and that gets > configured by the > Kirkwood through a MDIO link, using indirect addressing. > > We do not have the pretention to write a generic driver for such > switches/addressing, but we need this functionnality on some boards, > that's why > we have kept it in our own folder and not in a generic driver folder. > > I will add the above precisions to the commit message for an optional > v3 of the > "updates for the Keymile Marvell boards" series so that this is more > clear. Dear Valentin We must keep develop it as generic driver. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hello Prafulla, On 07/03/2012 10:17 AM, Prafulla Wadaskar wrote: >> -Original Message- >> From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] >> Sent: 21 June 2012 18:40 >> To: Prafulla Wadaskar >> Cc: prafu...@mavell.com; holger.bru...@keymile.com; u- >> b...@lists.denx.de >> Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external >> switchconfiguration >> >> Hi Prafulla, >> >> On 06/12/2012 06:39 AM, Prafulla Wadaskar wrote: >>> >>> >>>> -Original Message- >>>> From: u-boot-boun...@lists.denx.de [mailto:u-boot- >>>> boun...@lists.denx.de] On Behalf Of Valentin Longchamp >>>> Sent: 07 June 2012 15:37 >>>> To: prafu...@mavell.com >>>> Cc: Valentin Longchamp; holger.bru...@keymile.com; u- >>>> b...@lists.denx.de >>>> Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external >>>> switch configuration >>>> >>>> This can be used if we do not want to use an EEPROM for the >>>> configuration. >>>> >>>> Signed-off-by: Valentin Longchamp >>>> --- >>>> board/keymile/common/common.h |7 -- >>>> board/keymile/km_arm/managed_switch.c | 169 >>>> +++-- >>>> board/keymile/km_arm/managed_switch.h | 99 +++ >>> >>> What is managed switch? Which chip it supports? Why it is sitting >> here and not in generic folder? >>> >> >> In this case, the switch is a Marvell 88E52xxx (don't remember the >> exact model) >> that is connected to the GE port of the Kirkwood and that gets >> configured by the >> Kirkwood through a MDIO link, using indirect addressing. >> >> We do not have the pretention to write a generic driver for such >> switches/addressing, but we need this functionnality on some boards, >> that's why >> we have kept it in our own folder and not in a generic driver folder. >> >> I will add the above precisions to the commit message for an optional >> v3 of the >> "updates for the Keymile Marvell boards" series so that this is more >> clear. > > Dear Valentin > We must keep develop it as generic driver. > > Regards... > Prafulla . . . > Sure it would be great if we had the time and resources to contribute a generic driver for these switches. Unfortunately it is not the case and we have only developed a simple driver with limited features that suits our current needs. Since we know it's very limited, we have intentionally chosen to put in in our board/keymile directory so that it's obvious that it is (currently) not intended to be used nor was it tested on other boards or with other switches. The question now is: does u-boot allow some boards (or family of boards) to integrate some board codes or drivers ? It was until now our understanding that u-boot allows this. This code definitely fits into this category. As for the generic driver, if someone contributes one (the current driver can be used as a basis), we will be very happy to drop this code and use the generic driver. Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Valentin and Prafulla, [...] >> Dear Valentin >> We must keep develop it as generic driver. >> >> Regards... >> Prafulla . . . >> > > Sure it would be great if we had the time and resources to contribute a > generic > driver for these switches. Unfortunately it is not the case and we have only > developed a simple driver with limited features that suits our current needs. > > Since we know it's very limited, we have intentionally chosen to put in in our > board/keymile directory so that it's obvious that it is (currently) not > intended > to be used nor was it tested on other boards or with other switches. Personally I welcome such a driver submission to mainline as it can be a starting point for someone else later. > The question now is: does u-boot allow some boards (or family of boards) to > integrate some board codes or drivers ? It was until now our understanding > that > u-boot allows this. This code definitely fits into this category. This is also my understanding and actually our source code has lots of them and many people are thankful to find such code (if they are able to find it ;) > As for the generic driver, if someone contributes one (the current driver can > be > used as a basis), we will be very happy to drop this code and use the generic > driver. Actually I would go even further and say that a generic driver can only be started when there are at least two or more users of the code. One should probably think about not making too many short-sighted assumptions when working on a driver but to think that one could develop a generic driver from one device only would be foolish. So Prafulla, can you please reconsider to add the driver? Thanks Detlev -- Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands. -- principles of X Window System -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
> -Original Message- > From: Detlev Zundel [mailto:d...@denx.de] > Sent: 04 July 2012 13:38 > To: Valentin Longchamp > Cc: Prafulla Wadaskar; u-boot@lists.denx.de; holger.bru...@keymile.com > Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external > switchconfiguration > > Hi Valentin and Prafulla, > > [...] > > >> Dear Valentin > >> We must keep develop it as generic driver. > >> > >> Regards... > >> Prafulla . . . > >> > > > > Sure it would be great if we had the time and resources to > contribute a generic > > driver for these switches. Unfortunately it is not the case and we > have only > > developed a simple driver with limited features that suits our > current needs. > > > > Since we know it's very limited, we have intentionally chosen to put > in in our > > board/keymile directory so that it's obvious that it is (currently) > not intended > > to be used nor was it tested on other boards or with other switches. > > Personally I welcome such a driver submission to mainline as it can be > a > starting point for someone else later. > > > The question now is: does u-boot allow some boards (or family of > boards) to > > integrate some board codes or drivers ? It was until now our > understanding that > > u-boot allows this. This code definitely fits into this category. > > This is also my understanding and actually our source code has lots of > them and many people are thankful to find such code (if they are able > to > find it ;) > > > As for the generic driver, if someone contributes one (the current > driver can be > > used as a basis), we will be very happy to drop this code and use > the generic > > driver. > > Actually I would go even further and say that a generic driver can > only > be started when there are at least two or more users of the code. > One should probably think about not making too many short-sighted > assumptions when working on a driver but to think that one could > develop > a generic driver from one device only would be foolish. > > So Prafulla, can you please reconsider to add the driver? Hi Detlev Clear NAK for this patch Let's put it in drivers/net/phy/ FYI: there are several drivers used by just one board, [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS" include/configs/* include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS1 [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM" include/configs/* include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1 Anyways peripheral driver should go in drivers/ Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi, On 07/04/2012 11:20 AM, Prafulla Wadaskar wrote: >>> Sure it would be great if we had the time and resources to >> contribute a generic >>> driver for these switches. Unfortunately it is not the case and we >> have only >>> developed a simple driver with limited features that suits our >> current needs. >>> >>> Since we know it's very limited, we have intentionally chosen to put >> in in our >>> board/keymile directory so that it's obvious that it is (currently) >> not intended >>> to be used nor was it tested on other boards or with other switches. >> >> Personally I welcome such a driver submission to mainline as it can be >> a >> starting point for someone else later. >> >>> The question now is: does u-boot allow some boards (or family of >> boards) to >>> integrate some board codes or drivers ? It was until now our >> understanding that >>> u-boot allows this. This code definitely fits into this category. >> >> This is also my understanding and actually our source code has lots of >> them and many people are thankful to find such code (if they are able >> to >> find it ;) >> >>> As for the generic driver, if someone contributes one (the current >> driver can be >>> used as a basis), we will be very happy to drop this code and use >> the generic >>> driver. >> >> Actually I would go even further and say that a generic driver can >> only >> be started when there are at least two or more users of the code. >> One should probably think about not making too many short-sighted >> assumptions when working on a driver but to think that one could >> develop >> a generic driver from one device only would be foolish. >> >> So Prafulla, can you please reconsider to add the driver? > > Hi Detlev > Clear NAK for this patch > > Let's put it in drivers/net/phy/ > FYI: there are several drivers used by just one board, > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_ATHEROS" include/configs/* > include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS1 > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_BROADCOM" include/configs/* > include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1 > > Anyways peripheral driver should go in drivers/ > yes there are maybe drivers which proof your concept, but there are many others in the board related code which do the opposite. But I think this topic should be discussed not in the context of this patch. It's a general question. I 100% agree with Detlev's explanation. If a new very limited HW driver is added to the repo I see good reasons to keep it in the folder for the board. If a second user comes up and wants to enhance the driver for his needs he can still move driver then. But if no other user for this driver is there and maybe in the future the board needs to be removed because it's broken it's much easier to remove _all_ related code when it's located in one directory. If the code is spread over several directories it's much harder to track. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Dear Holger, In message <4ffac8c9.1020...@keymile.com> you wrote: > > > Anyways peripheral driver should go in drivers/ > > yes there are maybe drivers which proof your concept, but there are many > others > in the board related code which do the opposite. Yes, but bad examples are not a good reason to repeat mistakes either. > But I think this topic should be discussed not in the context of this patch. > It's a general question. I 100% agree with Detlev's explanation. If a new very > limited HW driver is added to the repo I see good reasons to keep it in the > folder for the board. If a second user comes up and wants to enhance the > driver > for his needs he can still move driver then. But if no other user for this > driver is there and maybe in the future the board needs to be removed because > it's broken it's much easier to remove _all_ related code when it's located in > one directory. If the code is spread over several directories it's much harder > to track. Sorry, but I disagree. How many board directories are there in U-Boot? Several hundreds... How many board directories did you check to make sure none of them contains any driver that is similar to what you implement here? If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy. I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions. To make sure everybody sees such code, we should really add it to the standard locations. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The best things in life are for a fee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Wolfgang, [...] > Sorry, but I disagree. How many board directories are there in > U-Boot? Several hundreds... How many board directories did you check > to make sure none of them contains any driver that is similar to what > you implement here? > > If we place the driver in your board diretory, the chances are huge it > will simply sit there and rot, and the next one who needs something > similar will reinvent the wheel because he did not find your copy. > > I agree that even very simple and uncomplete implementations can co in > if the fulfil some purpose, and can form a basis for future > extensions. > > To make sure everybody sees such code, we should really add it to the > standard locations. According to the current situation, we have the choice of getting good code into a board directory or no code at all because Prafulla doesn't accept the code in its current incarnation into a general place. I don't need a crystal ball to see that the project will loose code this way. I'm sorry that the project rejects working code and I re-ask Prafulla to reconsider his NAK which has impact on the whole project. Cheers Detlev -- debian is a prototype for a future version of emacs. -- Thien-Thi Nguyen in <7eekubiffq@ada2.unipv.it> -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Wolfgang, [...] > If we place the driver in your board diretory, the chances are huge it > will simply sit there and rot, and the next one who needs something > similar will reinvent the wheel because he did not find your copy. > > I agree that even very simple and uncomplete implementations can co in > if the fulfil some purpose, and can form a basis for future > extensions. I just read through our documentation on the Wiki and found nothing relavant to such a topic. If we make this a requirement, we should add it so people know about it beforehand. How about amending the U-Boot design principles with 11. Keep It Generic - Generic code shall be added as high as possible to the U-Boot abstraction hierarchy and only as a last resort into board directories. This entails that peripheral drivers should be put below "drivers" even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point. How does that sound? Cheers Detlev -- The only thing worse than generalizing from one example is generalizing from no examples at all. -- principles of X Window System -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Prafulla, [...] > Hi Detlev > Clear NAK for this patch Do you mean clear NAK for "the patch" or "for the location of the files"? > Let's put it in drivers/net/phy/ > FYI: there are several drivers used by just one board, > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > drivers/net/phy/Makefile > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_ATHEROS" include/configs/* > include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS1 > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > drivers/net/phy/Makefile > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_BROADCOM" include/configs/* > include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1 > > Anyways peripheral driver should go in drivers/ Ok, so if the files are moved to drivers/net/phy, then you will ACK the patch? If this is the case, then Valentin please move the files and be done with it. Cheers Detlev -- ... that every year or so they're going to give you a new release full of 50 000 additional lines of code all written by monkeys. Because they generally follow the ``million monkeys typing, and eventually they'll come up with something useful'' school of system development. -- Richard M. Stallman -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Detlev, On 07/09/2012 04:31 PM, Detlev Zundel wrote: > Hi Prafulla, > > [...] > >> Hi Detlev >> Clear NAK for this patch > > Do you mean clear NAK for "the patch" or "for the location of the > files"? > >> Let's put it in drivers/net/phy/ >> FYI: there are several drivers used by just one board, >> [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim >> drivers/net/phy/Makefile >> [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn >> "CONFIG_PHY_ATHEROS" include/configs/* >> include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS1 >> [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim >> drivers/net/phy/Makefile >> [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn >> "CONFIG_PHY_BROADCOM" include/configs/* >> include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1 >> >> Anyways peripheral driver should go in drivers/ > > Ok, so if the files are moved to drivers/net/phy, then you will ACK the > patch? If this is the case, then Valentin please move the files and be > done with it. > Already working on it ;) Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Detlev, On 07/09/2012 03:06 PM, Detlev Zundel wrote: >> If we place the driver in your board diretory, the chances are huge it >> will simply sit there and rot, and the next one who needs something >> similar will reinvent the wheel because he did not find your copy. >> >> I agree that even very simple and uncomplete implementations can co in >> if the fulfil some purpose, and can form a basis for future >> extensions. > > I just read through our documentation on the Wiki and found nothing > relavant to such a topic. If we make this a requirement, we should add > it so people know about it beforehand. > > How about amending the U-Boot design principles with > > 11. Keep It Generic > > - Generic code shall be added as high as possible to the U-Boot > abstraction hierarchy and only as a last resort into board > directories. This entails that peripheral drivers should be put below > "drivers" even if they start out supporting only one specific > configuration. Note that it is not a requirement for such a first > instance to be generic as genericity generally cannot be extrapolated > from a single data point. > > How does that sound? > shouldn't be there an exception for strictly board specific peripheral drivers like an custom-made FPGA? Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Dear Detlev, In message you wrote: > > > I agree that even very simple and uncomplete implementations can co in should read: ...can go in... > > if the fulfil some purpose, and can form a basis for future > > extensions. > > > > To make sure everybody sees such code, we should really add it to the > > standard locations. > > According to the current situation, we have the choice of getting good > code into a board directory or no code at all because Prafulla doesn't > accept the code in its current incarnation into a general place. I I just tried to explain that my wish is that 1) this code can go in, even if not perfectly universal yet, and 2) that it should go into the standard location for such drivers. > don't need a crystal ball to see that the project will loose code this > way. I'm sorry that the project rejects working code and I re-ask > Prafulla to reconsider his NAK which has impact on the whole project. I don't see why you are taking about rejecting code here. Didn't I make clear that I vote for adding this code? I hope Prafulla finds this recommendation acceptable (especially after I added him to Cc: so he actually gets aware of this discussion). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Dear Detlev, In message you wrote: > > I just read through our documentation on the Wiki and found nothing > relavant to such a topic. If we make this a requirement, we should add > it so people know about it beforehand. You know all too well that our wiki suffers from a mismatch of what people expect to it and what htey contribute to it. > How about amending the U-Boot design principles with Go for it - it's a wiki. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to stay up nights to succeed; you have to stay awake days. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Dear Holger, In message <4ffaee4f.3090...@keymile.com> you wrote: > > shouldn't be there an exception for strictly board specific peripheral drivers > like an custom-made FPGA? I see two situations: 1) We are talking about code to load a bitstream into the FPGA, i. e. to "program it". Such code should always be generic enough to put it under drivers/fpga/ (if the existing code there does not already cover the task). 2) We are talking about driver code for some preipheral implemented in the FPGA. In many cases we find these peripherals to be pretty generic (say, UARTs, GPIOs, network interfaces, etc.). In such cases there is no doubt that driver code should go to drivers/ . ONly in case you have areally, really special feature implemented that you need supported in U-Boot. OK, then such drivers are probably better kept in your board directory. Note that there will always be cases where hindsight will show that the initial location was not perfect. That is perfectly normal ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 'What shall we do?' said Twoflower. 'Panic?' said Rincewind hope- fully. He always held that panic was the best means of survival; back in the olden days, his theory went, people faced with hungry sabre- toothed tigers could be divided very simply in those who panicked and those who stood there saying 'What a magnificent brute!' or 'Here, pussy.' - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 09 July 2012 17:34 > To: Prafulla Wadaskar > Cc: Detlev Zundel; Valentin Longchamp; u-boot@lists.denx.de > Subject: Re: [PATCH 12/20] arm/km: add support for external > switchconfiguration > ...snip... > > > > Hi Detlev > > Clear NAK for this patch > > > > Let's put it in drivers/net/phy/ > > FYI: there are several drivers used by just one board, > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > drivers/net/phy/Makefile > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_ATHEROS" include/configs/* > > include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS > 1 > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > drivers/net/phy/Makefile > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > "CONFIG_PHY_BROADCOM" include/configs/* > > include/configs/microblaze-generic.h:347:# define > CONFIG_PHY_BROADCOM 1 > > > > Anyways peripheral driver should go in drivers/ > > > > yes there are maybe drivers which proof your concept, but there are > many others > in the board related code which do the opposite. > > But I think this topic should be discussed not in the context of this > patch. > It's a general question. I 100% agree with Detlev's explanation. If a > new very > limited HW driver is added to the repo I see good reasons to keep it > in the > folder for the board. If a second user comes up and wants to enhance > the driver > for his needs he can still move driver then. But if no other user for > this > driver is there and maybe in the future the board needs to be removed > because > it's broken it's much easier to remove _all_ related code when it's > located in > one directory. If the code is spread over several directories it's > much harder > to track. Dear Holger, The peripheral (switch/PHY) is being considered to be supported as a driver is interfaced through standard interface and can be used by any other CPU/architecture/SoC on any other board. So I think there is no reason to keep it in board specific folder. Someone may correct me if I am wrong. Copying Joe (net custodian) Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
> -Original Message- > From: Detlev Zundel [mailto:d...@denx.de] > Sent: 09 July 2012 20:02 > To: Prafulla Wadaskar > Cc: Valentin Longchamp; u-boot@lists.denx.de; > holger.bru...@keymile.com > Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external > switchconfiguration > > Hi Prafulla, > > [...] > > > Hi Detlev > > Clear NAK for this patch > > Do you mean clear NAK for "the patch" or "for the location of the > files"? Dear Detlev Location, I have not gone through the rest of the patch. > > > Let's put it in drivers/net/phy/ > > FYI: there are several drivers used by just one board, > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > > drivers/net/phy/Makefile > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > > "CONFIG_PHY_ATHEROS" include/configs/* > > include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS > 1 > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim > > drivers/net/phy/Makefile > > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn > > "CONFIG_PHY_BROADCOM" include/configs/* > > include/configs/microblaze-generic.h:347:# define > CONFIG_PHY_BROADCOM 1 > > > > Anyways peripheral driver should go in drivers/ > > Ok, so if the files are moved to drivers/net/phy, then you will ACK > the > patch? If this is the case, then Valentin please move the files and > be > done with it. Thanks... Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Prafulla, On Mon, Jul 9, 2012 at 3:42 PM, Prafulla Wadaskar wrote: > > >> -Original Message- >> From: Holger Brunck [mailto:holger.bru...@keymile.com] >> Sent: 09 July 2012 17:34 >> To: Prafulla Wadaskar >> Cc: Detlev Zundel; Valentin Longchamp; u-boot@lists.denx.de >> Subject: Re: [PATCH 12/20] arm/km: add support for external >> switchconfiguration >> > ...snip... >> > >> > Hi Detlev >> > Clear NAK for this patch >> > >> > Let's put it in drivers/net/phy/ >> > FYI: there are several drivers used by just one board, >> > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim >> drivers/net/phy/Makefile >> > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn >> "CONFIG_PHY_ATHEROS" include/configs/* >> > include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS >> 1 >> > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim >> drivers/net/phy/Makefile >> > [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn >> "CONFIG_PHY_BROADCOM" include/configs/* >> > include/configs/microblaze-generic.h:347:# define >> CONFIG_PHY_BROADCOM 1 >> > >> > Anyways peripheral driver should go in drivers/ >> > >> >> yes there are maybe drivers which proof your concept, but there are >> many others >> in the board related code which do the opposite. >> >> But I think this topic should be discussed not in the context of this >> patch. >> It's a general question. I 100% agree with Detlev's explanation. If a >> new very >> limited HW driver is added to the repo I see good reasons to keep it >> in the >> folder for the board. If a second user comes up and wants to enhance >> the driver >> for his needs he can still move driver then. But if no other user for >> this >> driver is there and maybe in the future the board needs to be removed >> because >> it's broken it's much easier to remove _all_ related code when it's >> located in >> one directory. If the code is spread over several directories it's >> much harder >> to track. > > Dear Holger, > The peripheral (switch/PHY) is being considered to be supported as a driver > is interfaced through standard interface and can be used by any other > CPU/architecture/SoC on any other board. > > So I think there is no reason to keep it in board specific folder. > Someone may correct me if I am wrong. I agree. It belongs in drivers/net/phy/. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi, >> How about amending the U-Boot design principles with > > Go for it - it's a wiki. Thinking about it, I turned it not into a rule, but into a Lemma from the 10 rules: Lemmas from the golden rules 1. Generic Code is Good Code New code shall be as generic as possible and added to the U-Boot abstraction hierarchy as high as possible. As few code as possible shall be added in board directories as people usually do not expect re-usable code there. Thus peripheral drivers should be put below "drivers" even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point. Feel free to amend / modify that. Cheers Detlev [1] http://www.denx.de/wiki/rdiff/U-Boot/DesignPrinciples?rev1=1.14&rev2=1.13 PS: Ok, actually I didn't want to ruin the magic 10 ;) -- Question: If you were redesigning UNIX, what would you do differently? Ken Thompson: I'd spell creat with an e. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
