* Help needed: supporting new device with unique register bitfields @ 2023-04-23 8:19 Feiyang Chen 2023-04-24 19:53 ` Jakub Kicinski 0 siblings, 1 reply; 5+ messages in thread From: Feiyang Chen @ 2023-04-23 8:19 UTC (permalink / raw) To: netdev Hi, all, We are hoping to add support for a new device which shares almost identical logic with dwmac1000 (dwmac_lib.c, dwmac1000_core.c, and dwmac1000_dma.c), but with significant differences in the register bitfields (dwmac_dma.h and dwmac1000.h). We are seeking guidance on the best approach to support this new device. Any advice on how to proceed would be greatly appreciated. Thank you for your time and expertise. Thanks, Feiyang ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help needed: supporting new device with unique register bitfields 2023-04-23 8:19 Help needed: supporting new device with unique register bitfields Feiyang Chen @ 2023-04-24 19:53 ` Jakub Kicinski 2023-04-28 8:47 ` Daniel.Machon 2023-05-05 1:25 ` Feiyang Chen 0 siblings, 2 replies; 5+ messages in thread From: Jakub Kicinski @ 2023-04-24 19:53 UTC (permalink / raw) To: Feiyang Chen, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu; +Cc: netdev On Sun, 23 Apr 2023 16:19:11 +0800 Feiyang Chen wrote: > We are hoping to add support for a new device which shares almost > identical logic with dwmac1000 (dwmac_lib.c, dwmac1000_core.c, and > dwmac1000_dma.c), but with significant differences in the register > bitfields (dwmac_dma.h and dwmac1000.h). > > We are seeking guidance on the best approach to support this new > device. Any advice on how to proceed would be greatly appreciated. > > Thank you for your time and expertise. There's no recipe on how to support devices with different register layout :( You'll need to find the right balance of (1) indirect calls, (2) if conditions and (3) static description data that's right for you. Static description data (e.g. putting register addresses in a struct and using the members of that struct rather than #defines) is probably the best but the least flexible. Adding the stmmac maintainers. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help needed: supporting new device with unique register bitfields 2023-04-24 19:53 ` Jakub Kicinski @ 2023-04-28 8:47 ` Daniel.Machon 2023-05-05 1:26 ` Feiyang Chen 2023-05-05 1:25 ` Feiyang Chen 1 sibling, 1 reply; 5+ messages in thread From: Daniel.Machon @ 2023-04-28 8:47 UTC (permalink / raw) To: kuba; +Cc: chris.chenfeiyang, peppe.cavallaro, alexandre.torgue, joabreu, netdev Den Mon, Apr 24, 2023 at 12:53:57PM -0700 skrev Jakub Kicinski: > On Sun, 23 Apr 2023 16:19:11 +0800 Feiyang Chen wrote: > > We are hoping to add support for a new device which shares almost > > identical logic with dwmac1000 (dwmac_lib.c, dwmac1000_core.c, and > > dwmac1000_dma.c), but with significant differences in the register > > bitfields (dwmac_dma.h and dwmac1000.h). > > > > We are seeking guidance on the best approach to support this new > > device. Any advice on how to proceed would be greatly appreciated. > > > > Thank you for your time and expertise. > > There's no recipe on how to support devices with different register > layout :( You'll need to find the right balance of (1) indirect calls, > (2) if conditions and (3) static description data that's right for you. > > Static description data (e.g. putting register addresses in a struct > and using the members of that struct rather than #defines) is probably > the best but the least flexible. > > Adding the stmmac maintainers. Hi, I thought I would chip in, as we are facing a similar case as described here. I am working on adding support for a new chip, that shares most of the same logic as Sparx5, yet with differences in register layout. Our approach has basically been what Jakub describes. - We use a macro-based approach for accessing registers (see sparx5_main_regs.h). We have added a layer of indirection, so that any _differences_ between the two chips (offset, count, width etc.) have been moved into respective structs, which is then consulted when accessing registers. This allows us to reuse most of the Sparx5 code. - Any unique chip features or similar are ops'ed out. In a few cases handled by if's. - Additionally, chip-specific constants like port count, buffer sizes etc. are statically described for the driver. I think this has worked out pretty well so far. But again, this is balance, as Jakub said. If the differences are too great, it might not be the best solution for you. /Daniel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help needed: supporting new device with unique register bitfields 2023-04-28 8:47 ` Daniel.Machon @ 2023-05-05 1:26 ` Feiyang Chen 0 siblings, 0 replies; 5+ messages in thread From: Feiyang Chen @ 2023-05-05 1:26 UTC (permalink / raw) To: Daniel.Machon; +Cc: kuba, peppe.cavallaro, alexandre.torgue, joabreu, netdev On Fri, Apr 28, 2023 at 4:47 PM <Daniel.Machon@microchip.com> wrote: > > Den Mon, Apr 24, 2023 at 12:53:57PM -0700 skrev Jakub Kicinski: > > On Sun, 23 Apr 2023 16:19:11 +0800 Feiyang Chen wrote: > > > We are hoping to add support for a new device which shares almost > > > identical logic with dwmac1000 (dwmac_lib.c, dwmac1000_core.c, and > > > dwmac1000_dma.c), but with significant differences in the register > > > bitfields (dwmac_dma.h and dwmac1000.h). > > > > > > We are seeking guidance on the best approach to support this new > > > device. Any advice on how to proceed would be greatly appreciated. > > > > > > Thank you for your time and expertise. > > > > There's no recipe on how to support devices with different register > > layout :( You'll need to find the right balance of (1) indirect calls, > > (2) if conditions and (3) static description data that's right for you. > > > > Static description data (e.g. putting register addresses in a struct > > and using the members of that struct rather than #defines) is probably > > the best but the least flexible. > > > > Adding the stmmac maintainers. > > Hi, > > I thought I would chip in, as we are facing a similar case as described > here. > > I am working on adding support for a new chip, that shares most of the > same logic as Sparx5, yet with differences in register layout. Our > approach has basically been what Jakub describes. > > - We use a macro-based approach for accessing registers (see > sparx5_main_regs.h). We have added a layer of indirection, so that any > _differences_ between the two chips (offset, count, width etc.) have > been moved into respective structs, which is then consulted when > accessing registers. This allows us to reuse most of the Sparx5 code. > > - Any unique chip features or similar are ops'ed out. In a few cases > handled by if's. > > - Additionally, chip-specific constants like port count, buffer sizes > etc. are statically described for the driver. > Hi, Daniel, That sounds like a great idea. I'll definitely give it a try. Thanks, Feiyang > I think this has worked out pretty well so far. But again, this is > balance, as Jakub said. If the differences are too great, it might not > be the best solution for you. > > /Daniel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help needed: supporting new device with unique register bitfields 2023-04-24 19:53 ` Jakub Kicinski 2023-04-28 8:47 ` Daniel.Machon @ 2023-05-05 1:25 ` Feiyang Chen 1 sibling, 0 replies; 5+ messages in thread From: Feiyang Chen @ 2023-05-05 1:25 UTC (permalink / raw) To: Jakub Kicinski; +Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev On Tue, Apr 25, 2023 at 3:54 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Sun, 23 Apr 2023 16:19:11 +0800 Feiyang Chen wrote: > > We are hoping to add support for a new device which shares almost > > identical logic with dwmac1000 (dwmac_lib.c, dwmac1000_core.c, and > > dwmac1000_dma.c), but with significant differences in the register > > bitfields (dwmac_dma.h and dwmac1000.h). > > > > We are seeking guidance on the best approach to support this new > > device. Any advice on how to proceed would be greatly appreciated. > > > > Thank you for your time and expertise. > > There's no recipe on how to support devices with different register > layout :( You'll need to find the right balance of (1) indirect calls, > (2) if conditions and (3) static description data that's right for you. > > Static description data (e.g. putting register addresses in a struct > and using the members of that struct rather than #defines) is probably > the best but the least flexible. > > Adding the stmmac maintainers. Hi, Jakub, Thank you very much! Thanks, Feiyang ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-05-05 1:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-04-23 8:19 Help needed: supporting new device with unique register bitfields Feiyang Chen 2023-04-24 19:53 ` Jakub Kicinski 2023-04-28 8:47 ` Daniel.Machon 2023-05-05 1:26 ` Feiyang Chen 2023-05-05 1:25 ` Feiyang Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).