Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Sylvain Munaut wrote: Valentine Barshak wrote: Rework ohci-ppc-of driver to use big-endian property instead of ohci-be/ohci-le compatible strings. Also remove unnecessary user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default. I don't find those options useless. If you think the defauts are not the best change them but I find these options relevant. You don't always want the support for BE on PPC ... if the only controller you have is pci ... or if you're on a soc that use little endian ... USB_OHCI_LITTLE_ENDIAN and USB_OHCI_BIG_ENDIAN are useful and I don't see anyone wanting to remove them. However, if all of the chips supported by the ohci-ppc-of driver are big-endian, then USB_OHCI_HCD_PPC_OF_LE and USB_OHCI_HCD_PPC_OF_BE are not needed. Just select USB_OHCI_BIG_ENDIAN when the ohci-ppc-of driver is selected, in the same way that we always select USB_OHCI_LITTLE_ENDIAN when the ohci-pci driver is selected. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Matt Sealey wrote:
Valentine Barshak wrote:
Matt Sealey wrote:
Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
We should also keep ohci-bigendian and ohci-be in the match table.
Eh.. maybe.
I am currently moving on the assumption that the correct device
tree for the Efika (notwithstanding the above) would be
[EMAIL PROTECTED] {
device-type = usb-ohci
compatible = mpc5200-ohci,mpc5200-usb-ohci
It should also have compatible usb-ohci entry as a more general one.
Others are for device-specific quirks:
compatible = mpc5200-usb-ohci,usb-ohci
Why? It's in the device_type. You don't need to duplicate it as compatible
with the same value as in the device_type.
The device-type thing shouldn't be used by Linux kernel.
Please, take a look at this discussion:
http://patchwork.ozlabs.org/linuxppc/patch?order=dateid=13514
Thanks,
Valentine.
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
So, do you suggest to use mpc5200-ohci instead of ohci-be in the
match table?
Yes. I think ohci-be and ohci-bigendian should die. After all, it
might get mixed with Firewire if you are not being careful.
If we had to start again, device-type of usb (that just makes it
easier all round, it allows a system based on the MPC5200B alone to
make the assumption of OHCI), compatibles of usb-ohci (since this makes
it very specific that it is not just USB, but the OHCI spec) and big-endian
property would be all there would be.
Model property would give the mpc5200-ohci value. Since nothing checks
model (and this is not set on the firmware here), figuring on
mpc5200-ohci as a compatible entry is good enough. Device-specific
quirks should (Segher? Clarify please) never be futzed into compatible
properties. At least the IEEE 1275 spec makes it clear that the model
property is meant to clarify the particular device in question and is
for information, I think defining a device as USB, then subordinately
as OHCI flavor of USB and particularly the USB controller on an
MPC5200 chip (model) is all we need here, and in fact in any device.
You could say the same about any other device - why is the current
standard to give each node a unique name based on chip docs? 5200
device tree spec says, use gpt as the name for the MPC5200 general
purpose timers. Why not timer as the name, with fsl,gpt in the
device_type or compatible property, and mpc5200-gpt in the model
property? or fsl,slt compatible and mpc5200-slt model? Or
dma-controller with a *model* of bestcomm?
Some of this makes me grind my teeth so much..
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Grant Likely wrote: On 10/24/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... Add my voice to the chorus. It's okay to change the binding, but make sure the old binding is still supported. Cheers, g. Actually, I thought that changing the DTS stuff for mpc52xx boards would suffice. Sorry, I was unaware of Efika firmware here. I'll keep old bindings as well. Does the device tree have ohci-bigendian or ohci-be compatible property on Efika? Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
On 10/25/07, Valentine Barshak [EMAIL PROTECTED] wrote: Grant Likely wrote: On 10/24/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... Add my voice to the chorus. It's okay to change the binding, but make sure the old binding is still supported. Cheers, g. Actually, I thought that changing the DTS stuff for mpc52xx boards would suffice. Sorry, I was unaware of Efika firmware here. I'll keep old bindings as well. Even if that were the case; I'm nervous about breaking compatibility with old device trees. We probably need a formal guideline here. ie. When is it okay to drop compatibility with old dts files? Does the device tree have ohci-bigendian or ohci-be compatible property on Efika? If it doesn't, it can be added during prom_init.c We're already doing a bunch of efika fixups there anyway. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
ohci-bigendian
ohci-be
mpc5200-ohci
mpc5200-usb
device_type is usb, model is mpc5200-ohci.
Although I worry about cluttering up the cleanup, it is probably just
adding an if property(big-endian) OR compatible(mpc5200-ohci)
to that small big-endian check there.
I am currently moving on the assumption that the correct device
tree for the Efika (notwithstanding the above) would be
[EMAIL PROTECTED] {
device-type = usb-ohci
compatible = mpc5200-ohci,mpc5200-usb-ohci
big-endian
}
Or some variation including all the relevant checked-for
properties.
I don't like the old ohci-bigendian and ohci-be properties.
Picking out ohci-bigendian and ohci-be was someone's drunken
idea, I'm sure, so I am happy to let them die a horrible death
and never rear up ever again.
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
There is another solution; change the properties in the Linux
device tree fixups, but I would loathe that solution as it adds
yet another part of the kernel to track.
Unfortunately the current device tree is a complete, stupid mess,
a result of a bunch of guys not looking at the problem, and I
have said this before (rant mode :) - I think device_type,
compatible should report the KIND of device it is, and the model
property should be used to pick out the particular quirks of
the chipset. We could have had a nice system where usb is paired
with compatible ohci, and model is mpc5200. No dashes or
spaces or 10 strings to compare..
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Valentine Barshak wrote:
Grant Likely wrote:
On 10/24/07, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 24 October 2007, Matt Sealey wrote:
Can we just make sure real quickly that the changing of compatibles
doesn't break existing, not-easily-flashable firmwares?
Yeah, I'm not keen on such breakage either...
Add my voice to the chorus. It's okay to change the binding, but make
sure the old binding is still supported.
Cheers,
g.
Actually, I thought that changing the DTS stuff for mpc52xx boards would
suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
bindings as well.
Does the device tree have ohci-bigendian or ohci-be compatible
property on Efika?
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Grant Likely wrote: On 10/25/07, Valentine Barshak [EMAIL PROTECTED] wrote: If it doesn't, it can be added during prom_init.c We're already doing a bunch of efika fixups there anyway. I want those to go away. Far, far away. http://www.powerdeveloper.org/platforms/efika/devicetree Not the most elegant solution right now, but it works (kinda, a few bugs to sort out). Note that Domen's ethernet driver plus a bunch of Sylvain's stuff if it is ever cleaned up (deep sleep etc.) will not work without these device tree changes. You should realise that if we plugged every tiny thing into prom_init.c we would double the size of the file just for Efika fixes. And that's dumb. Compatibility with old device trees should go away after there is a production firmware people can download - like the x86 hardware monitor drivers in lmsensors report please upgrade your BIOS if they have been disabled, users will happily update their BIOS to an updated version if it is available. For Efika, right now, it is not. And for Efika, right now, I fear the stupidity some of the device tree design (mandated by a text file..) means any new firmware update will have far more strings and reporting than it should ever truly need. Although you can restrict Linux kernels from running on firmwares below a certain version, we can't knowingly restrict the board firmware to only running Linux kernels above a certain version. Therefore, this is an exercise in not pissing people off, not really of any technical merit. We already had Pegasos keyboard support disappear because someone decided the device tree usage needed to be changed. Given the size of the fix in nvramrc, it's harmless, given that Pegasos is a dead platform, it's harmless. Efika is still in production. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Valentine, Please do the very minimal required to keep supporting the Efika. As for an little endian OHCI controller on an OF bus, I would not consider it an impossibility. But, not having the big-endian property fixes this; OHCI is little-endian by default. You need only report difference in device trees, overzealous naming of a billion kinds of 99.9% compatible controllers is just a waste of space. I prefer the new binding to a degree. I like the big-endian property and I like the reporting of a standard controller type (usb-ohci rather than building in chip names). However by making the driver support only the recommending binding, we break old platforms for the sake of making new ones cleaner. I wish someone would have sat down and defined the 5200 device tree in a design committee rather than a peer review post-commit system. In fact, that is a great idea, we can start this off with the MPC5121E right now, and get the damn thing RIGHT. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Valentine Barshak wrote: Grant Likely wrote: On 10/25/07, Valentine Barshak [EMAIL PROTECTED] wrote: Grant Likely wrote: On 10/24/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... Add my voice to the chorus. It's okay to change the binding, but make sure the old binding is still supported. Cheers, g. Actually, I thought that changing the DTS stuff for mpc52xx boards would suffice. Sorry, I was unaware of Efika firmware here. I'll keep old bindings as well. Even if that were the case; I'm nervous about breaking compatibility with old device trees. If we keep the old bindings intact in the driver code then the old dts files should work fine. But I'm starting to doubt we really need any new bindings for this if we still have to keep the old ones. BTW, does anybody know of any ohci-le devices on OF bus? Thanks, Valentine. We probably need a formal guideline here. ie. When is it okay to drop compatibility with old dts files? Does the device tree have ohci-bigendian or ohci-be compatible property on Efika? If it doesn't, it can be added during prom_init.c We're already doing a bunch of efika fixups there anyway. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Matt Sealey wrote: Valentine, Please do the very minimal required to keep supporting the Efika. As for an little endian OHCI controller on an OF bus, I would not consider it an impossibility. But, not having the big-endian property fixes this; OHCI is little-endian by default. You need only report difference in device trees, overzealous naming of a billion kinds of 99.9% compatible controllers is just a waste of space. I prefer the new binding to a degree. I like the big-endian property and I like the reporting of a standard controller type (usb-ohci rather than building in chip names). However by making the driver support only the recommending binding, we break old platforms for the sake of making new ones cleaner. I wish someone would have sat down and defined the 5200 device tree in a design committee rather than a peer review post-commit system. In fact, that is a great idea, we can start this off with the MPC5121E right now, and get the damn thing RIGHT. OK, I'll submit a new patch in a bit. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Matt Sealey wrote:
Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
ohci-bigendian
ohci-be
mpc5200-ohci
mpc5200-usb
device_type is usb, model is mpc5200-ohci.
Although I worry about cluttering up the cleanup, it is probably just
adding an if property(big-endian) OR compatible(mpc5200-ohci)
to that small big-endian check there.
We should also keep ohci-bigendian and ohci-be in the match table.
I am currently moving on the assumption that the correct device
tree for the Efika (notwithstanding the above) would be
[EMAIL PROTECTED] {
device-type = usb-ohci
compatible = mpc5200-ohci,mpc5200-usb-ohci
It should also have compatible usb-ohci entry as a more general one.
Others are for device-specific quirks:
compatible = mpc5200-usb-ohci,usb-ohci
big-endian
}
Or some variation including all the relevant checked-for
properties.
I don't like the old ohci-bigendian and ohci-be properties.
Picking out ohci-bigendian and ohci-be was someone's drunken
idea, I'm sure, so I am happy to let them die a horrible death
and never rear up ever again.
:)
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
So, do you suggest to use mpc5200-ohci instead of ohci-be in the
match table?
There is another solution; change the properties in the Linux
device tree fixups, but I would loathe that solution as it adds
yet another part of the kernel to track.
Unfortunately the current device tree is a complete, stupid mess,
a result of a bunch of guys not looking at the problem, and I
have said this before (rant mode :) - I think device_type,
compatible should report the KIND of device it is, and the model
property should be used to pick out the particular quirks of
the chipset. We could have had a nice system where usb is paired
with compatible ohci, and model is mpc5200. No dashes or
spaces or 10 strings to compare..
:)
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Valentine Barshak wrote:
Matt Sealey wrote:
Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
We should also keep ohci-bigendian and ohci-be in the match table.
Eh.. maybe.
I am currently moving on the assumption that the correct device
tree for the Efika (notwithstanding the above) would be
[EMAIL PROTECTED] {
device-type = usb-ohci
compatible = mpc5200-ohci,mpc5200-usb-ohci
It should also have compatible usb-ohci entry as a more general one.
Others are for device-specific quirks:
compatible = mpc5200-usb-ohci,usb-ohci
Why? It's in the device_type. You don't need to duplicate it as compatible
with the same value as in the device_type.
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
So, do you suggest to use mpc5200-ohci instead of ohci-be in the
match table?
Yes. I think ohci-be and ohci-bigendian should die. After all, it
might get mixed with Firewire if you are not being careful.
If we had to start again, device-type of usb (that just makes it
easier all round, it allows a system based on the MPC5200B alone to
make the assumption of OHCI), compatibles of usb-ohci (since this makes
it very specific that it is not just USB, but the OHCI spec) and big-endian
property would be all there would be.
Model property would give the mpc5200-ohci value. Since nothing checks
model (and this is not set on the firmware here), figuring on
mpc5200-ohci as a compatible entry is good enough. Device-specific
quirks should (Segher? Clarify please) never be futzed into compatible
properties. At least the IEEE 1275 spec makes it clear that the model
property is meant to clarify the particular device in question and is
for information, I think defining a device as USB, then subordinately
as OHCI flavor of USB and particularly the USB controller on an
MPC5200 chip (model) is all we need here, and in fact in any device.
You could say the same about any other device - why is the current
standard to give each node a unique name based on chip docs? 5200
device tree spec says, use gpt as the name for the MPC5200 general
purpose timers. Why not timer as the name, with fsl,gpt in the
device_type or compatible property, and mpc5200-gpt in the model
property? or fsl,slt compatible and mpc5200-slt model? Or
dma-controller with a *model* of bestcomm?
Some of this makes me grind my teeth so much..
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
On 10/24/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... Add my voice to the chorus. It's okay to change the binding, but make sure the old binding is still supported. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
