DT version of kirkwood_ge0x_init()

DISCUSSION Gerlando Falauto 5 participants 14 messages Jun 4, 2013 – Jun 5, 2013

Share & tools

Gerlando Falauto

author

2013-06-04 10:18 UTC #0 lore raw

Hi everyone,

I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.

I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?

I noticed how NS2 can somehow trick this value depeding on the compatible string, so I assume it's not really *THAT* early, as the whole DT infrastructure is already available:

	if (of_machine_is_compatible("lacie,cloudbox") ||
	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
	    of_machine_is_compatible("lacie,netspace_mini_v2"))
		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
	kirkwood_ge00_init(&ns2_ge00_data);

I guess we could remove a lot of board-specific code if we could move this last bit of information to the DT.
Unless compatibility with existing DTs is an issue -- but what about new boards?

I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").

Any feedback (swearwords included -- in case I'm talking non-sense) would be more than welcome.

Thank you!
Gerlando

Sebastian Hesselbarth

2013-06-04 10:34 UTC #1 lore raw

Quoted 6 lines · Gerlando Falauto

I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?

Gerlando,

DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.

Quoted 4 lines

I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").

All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.

Sebastian

Jason Cooper

2013-06-04 10:43 UTC #2 lore raw

Quoted 19 lines · Sebastian Hesselbarth

Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").

Quoted 4 lines

All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.

Gerlando,

Yes, the mess you describe is temporary. Those board files used to have a lot more code in them, legacy init of partitions, MPP, LEDs, etc. As we have converted drivers, they have gotten smaller and smaller.

Now, with Sebastian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :)

Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will remain. After a few releases we will deprecate any legacy boards which haven't been converted to DT.

thx,

Jason.

Simon Guinot

2013-06-04 11:59 UTC #3 lore raw

Quoted 31 lines · Jason Cooper

Quoted 19 lines · Sebastian Hesselbarth
Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").
Quoted 4 lines
All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.
Gerlando,
Yes, the mess you describe is temporary. Those board files used to have a lot more code in them, legacy init of partitions, MPP, LEDs, etc. As we have converted drivers, they have gotten smaller and smaller.

Quoted 7 lines

Now, with Sebastian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :)
Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will remain. After a few releases we will deprecate any legacy boards which haven't been converted to DT.

Hi Jason,

While I have obviously planed to convert all the LaCie boards to DT, I think that removing the legacy support so quickly is a little bit harsh.

IMHO, it could be nice to wait the end-of-life for all this products before removing their support.

Regards,

Simon

Quoted 9 lines

thx,
Jason.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130604/957339ae/attachment.sig>

Jason Cooper

2013-06-04 12:05 UTC #4 lore raw

Quoted 40 lines · Simon Guinot

Quoted 31 lines · Jason Cooper
Quoted 19 lines · Sebastian Hesselbarth
Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").
Quoted 4 lines
All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.
Gerlando,
Yes, the mess you describe is temporary. Those board files used to have a lot more code in them, legacy init of partitions, MPP, LEDs, etc. As we have converted drivers, they have gotten smaller and smaller.
Quoted 7 lines
Now, with Sebastian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :)
Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will remain. After a few releases we will deprecate any legacy boards which haven't been converted to DT.

Quoted 5 lines

Hi Jason,
While I have obviously planed to convert all the LaCie boards to DT, I think that removing the legacy support so quickly is a little bit harsh.

Yeah, my wording might not have been the best. See below.

Quoted 2 lines

IMHO, it could be nice to wait the end-of-life for all this products before removing their support.

I'd prefer to convert them to DT, then keep them as long as folks are interested in them. If no one cares about a board, and no one wants to convert it to DT or test the conversion, why keep it around?

Let me clarify, by 'deprecate them' I meant *begin* the process of deprecating them. eg marking them as deprecated for around three releases or so.

thx,

Jason.

Simon Guinot

2013-06-04 12:18 UTC #5 lore raw

Quoted 52 lines · Jason Cooper

Quoted 40 lines · Simon Guinot
Quoted 31 lines · Jason Cooper
Quoted 19 lines · Sebastian Hesselbarth
Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").
Quoted 4 lines
All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.
Gerlando,
Yes, the mess you describe is temporary. Those board files used to have a lot more code in them, legacy init of partitions, MPP, LEDs, etc. As we have converted drivers, they have gotten smaller and smaller.
Quoted 7 lines
Now, with Sebastian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :)
Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will remain. After a few releases we will deprecate any legacy boards which haven't been converted to DT.
Quoted 5 lines
Hi Jason,
While I have obviously planed to convert all the LaCie boards to DT, I think that removing the legacy support so quickly is a little bit harsh.
Yeah, my wording might not have been the best. See below.
Quoted 2 lines
IMHO, it could be nice to wait the end-of-life for all this products before removing their support.

Quoted 7 lines

I'd prefer to convert them to DT, then keep them as long as folks are interested in them. If no one cares about a board, and no one wants to convert it to DT or test the conversion, why keep it around?
Let me clarify, by 'deprecate them' I meant *begin* the process of deprecating them. eg marking them as deprecated for around three releases or so.

OK. Thanks for the clarifications.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130604/0305b17c/attachment.sig>

Jason Cooper

2013-06-04 13:10 UTC #6 lore raw

In reply to Jason Cooper

Quoted 52 lines · Jason Cooper

Quoted 40 lines · Simon Guinot
Quoted 31 lines · Jason Cooper
Quoted 19 lines · Sebastian Hesselbarth
Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").
Quoted 4 lines
All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.
Gerlando,
Yes, the mess you describe is temporary. Those board files used to have a lot more code in them, legacy init of partitions, MPP, LEDs, etc. As we have converted drivers, they have gotten smaller and smaller.
Quoted 7 lines
Now, with Sebastian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :)
Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will remain. After a few releases we will deprecate any legacy boards which haven't been converted to DT.
Quoted 5 lines
Hi Jason,
While I have obviously planed to convert all the LaCie boards to DT, I think that removing the legacy support so quickly is a little bit harsh.
Yeah, my wording might not have been the best. See below.
Quoted 2 lines
IMHO, it could be nice to wait the end-of-life for all this products before removing their support.

Quoted 7 lines

I'd prefer to convert them to DT, then keep them as long as folks are interested in them. If no one cares about a board, and no one wants to convert it to DT or test the conversion, why keep it around?
Let me clarify, by 'deprecate them' I meant *begin* the process of deprecating them. eg marking them as deprecated for around three releases or so.

And, now that I've had some coffee, I should also mention that any boards that are removed can always be brought back by reverting the commit. Sometimes people don't complain until it outright disappears ;-)

Heads up: complain = "volunteer to convert to DT"

thx,

Jason.

Gerlando Falauto

author

2013-06-04 20:53 UTC #7 lore raw

In reply to Sebastian Hesselbarth

Hi Sebastian,

thanks for your answer and your hard work about this whole cleanup.

Two more questions though -- the whole pulling sequence and the mainlining process is still very confusing to me so I really have no idea where to look or what to expect.

1) Has this been pulled somewhere? You provided a pointer to the LKML but I assume this would pop up by way of an -arm tree... is that right? I'd like to start using that.

2) About my old fixes for the IRQ conflicts on Kirkwood, I saw that Thomas Gleixner's rework was pulled into the "tip" tree, but that's more genirq related. Did you (or anyone else) also follow up on that and make the changes for Kirkwood in order to enable the separate mask registers? I'd like to test that (that's actually why I started looking at recent kernels with FDT support to begin with).
Or shall I just follow Thomas' proof of concept on irq-sun4i and do the same for Kirkwood?

Sorry, I am really more than lost when it's about tracking how/where/when changes are pulled. Any "mainlining for dummies" pointer would be more than appreciated.

Thank you,
Gerlando

Quoted 26 lines · Sebastian Hesselbarth

Quoted 6 lines · Gerlando Falauto
I noticed how most of the DT-aware board-setup files only have a single <board>_init() function, calling kirkwood_ge00_init() with a struct mv643xx_eth_platform_data as a single argument.
I was wondering -- is there a reason why we cannot remove all this board-specific code and move all this to the DT?
Gerlando,
DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then move all DT Orion SoCs to it.
Quoted 4 lines
I would really love to have all our boards under a single CONFIG_<FAMILY>_DT and a single compatible string, with all the differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>, no more of_machine_is_compatible("boardXXX").
All those will happen if there is DT support for mv643xx_eth which is the only driver left without DT and board dependencies. But there will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT and board dependent stuff described in the corresponding dts.
Sebastian

Sebastian Hesselbarth

2013-06-05 09:04 UTC #8 lore raw

Quoted 9 lines · Gerlando Falauto

thanks for your answer and your hard work about this whole cleanup.
Two more questions though -- the whole pulling sequence and the mainlining process is still very confusing to me so I really have no idea where to look or what to expect.
1) Has this been pulled somewhere? You provided a pointer to the LKML but I assume this would pop up by way of an -arm tree... is that right? I'd like to start using that.

mv643xx_eth DT support (i.e. Patches 1-6 of that patch set) have been pulled into net-next by David Miller. The rest will be pulled by Jason Cooper as soon as net-next goes into mainline linux.

Quoted 8 lines

2) About my old fixes for the IRQ conflicts on Kirkwood, I saw that Thomas Gleixner's rework was pulled into the "tip" tree, but that's more genirq related. Did you (or anyone else) also follow up on that and make the changes for Kirkwood in order to enable the separate mask registers? I'd like to test that (that's actually why I started looking at recent kernels with FDT support to begin with).
Or shall I just follow Thomas' proof of concept on irq-sun4i and do the same for Kirkwood?

I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.

Quoted 3 lines

Sorry, I am really more than lost when it's about tracking how/where/when changes are pulled. Any "mainlining for dummies" pointer would be more than appreciated.

Hmm, sometimes I am also lost especially about when branches will be merged. Jason can tell you for sure. Basically, patches go into some maintainer's or submaintainer's branch first.

For mv643xx_eth DT patches the drivers/net related part goes through net-next, the dove/kirkwood/orion5x related patches go through mvebu (Jason Cooper) which will be pulled into arm-soc. But that varies with every patch set and depends on likes and wishes.

Sebastian

Gerlando Falauto

author

2013-06-05 09:37 UTC #9 lore raw

Hi Sebastian,

thanks for the info.

On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]

Quoted 3 lines

I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.

[sorry we've moved to a different topic]
[adding Thomas Gleixner]
You mean the driver in arch/arm/plat-orion/gpio.c or the generic one in drivers/gpio/gpio-mvebu.c?

Because the first one looks like it's using generic irq chip already. For the second one I don't understand how you can handle the per-CPU registers which are peculiar to MV78200/ArmadaXP.
Unless there's already patches on top of Thomas's rework for the per-CPU registers.

Thank you,
Gerlando

Gregory CLEMENT

2013-06-05 09:45 UTC #10 lore raw

Hi Geraldo,

Quoted 15 lines · Gerlando Falauto

Hi Sebastian,
thanks for the info.
On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]
Quoted 3 lines
I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
[sorry we've moved to a different topic]
[adding Thomas Gleixner]
You mean the driver in arch/arm/plat-orion/gpio.c or the generic one in drivers/gpio/gpio-mvebu.c?

Quoted 6 lines

Because the first one looks like it's using generic irq chip already. For the second one I don't understand how you can handle the per-CPU registers which are peculiar to MV78200/ArmadaXP.
Unless there's already patches on top of Thomas's rework for the per-CPU registers.

Currently we don't use the per-CPU register for Armada XP (I am not sure for MV78200). it was the cause of bugs and we didn't find how to properly fix them, so the solution was to not use the per-cpu part.

Quoted 9 lines

Thank you,
Gerlando
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Signature · 4 lines

Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Sebastian Hesselbarth

2013-06-05 09:49 UTC #11 lore raw

In reply to Gerlando Falauto

Quoted 10 lines · Gerlando Falauto

On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]
Quoted 3 lines
I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
[sorry we've moved to a different topic]
[adding Thomas Gleixner]
You mean the driver in arch/arm/plat-orion/gpio.c or the generic one in drivers/gpio/gpio-mvebu.c?

For Kirkwood and Dove, DT kernels use gpio-mvebu. And that is there from a time when there was no irqdomain support in generic chip. That should be updated.

Sebastian

Gerlando Falauto

author

2013-06-05 09:55 UTC #12 lore raw

Quoted 7 lines · Sebastian Hesselbarth

Quoted 6 lines · Gerlando Falauto
On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]
Quoted 3 lines
I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.

Quoted 8 lines

Quoted 4 lines
[sorry we've moved to a different topic]
[adding Thomas Gleixner]
You mean the driver in arch/arm/plat-orion/gpio.c or the generic one in drivers/gpio/gpio-mvebu.c?
For Kirkwood and Dove, DT kernels use gpio-mvebu. And that is there from a time when there was no irqdomain support in generic chip. That should be updated.

I know, that's why I was wondering how it is possible to update this driver and yet support per-cpu registers.
But I am admittedly not 100% sure I know what I'm talking about.

Anyway, could you please Cc: me when you post those patches?

Thank you,
Gerlando

Jason Cooper

2013-06-05 13:23 UTC #13 lore raw

In reply to Sebastian Hesselbarth

Gerlando,

Quoted 1 line · Sebastian Hesselbarth

On 06/04/13 22:53, Gerlando Falauto wrote:

...

Quoted 7 lines

Quoted 3 lines
Sorry, I am really more than lost when it's about tracking how/where/when changes are pulled. Any "mainlining for dummies" pointer would be more than appreciated.
Hmm, sometimes I am also lost especially about when branches will be merged. Jason can tell you for sure. Basically, patches go into some maintainer's or submaintainer's branch first.

In the simple case, we look at the diffstat to see what sections of the kernel are being changed. drivers/net, arch/arm, arch/arm/mach-mvebu, arch/arm/mm are all maintained by different people. Depending on where the changes are, that dictates who it will go through, DaveM, LinusW, Arnd and Olof, Russell King, etc.

Any code changes in arch/arm that are SoC dependent go through arm-soc. Otherwise, it goes through Russell. arm-soc is maintained by Arnd and Olof. It's so large, that they've broken it up into sub-archs with maintainers for each. Myself, Andrew Lunn, and Gregory Clemente maintain code changes in arch/arm/mach-{mvebu,kirkwood,orion5x,dove,mv78xx0}. We feed those changes in the form of branches to arm-soc, who put it all together and send it to Linus.

It gets complicated when part of a patch series, like Sebastian's, needs to go through -net, and the rest through arm-soc. If the two halves don't depend on one another, then it's easy. In this case, the arm-soc changes _do_ depend on the -net changes. So, we wait for the -net changes to get into mainline Linux (because all of the branches from everyone will have merged together), in this case, in v3.11-rc1. Once that lands, I'll base a branch off of it and include Sebastian's changes to mach-kirkwood. It will then be sent up to arm-soc for inclusion in v3.12-rc1.

There's also a corner case where a driver maintainer will Ack a patch series he would normally take and allow arm-soc to take it. Usually this is only if the driver changes are limited to a SoC specific file, eg drivers/clk/mvebu/*, and the driver maintainer doesn't anticipate any drivers/clk/* changes that will conflict. Then, we can take the whole series in one merge window through arm-soc. But that's purely up to the driver maintainer(s), and is by exception, not the rule.

hth,

Jason.