On Wed, Jan 21, 2015 at 11:17 AM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote: > On 01/21/2015 08:54 AM, Mark Rutland wrote: >> >> On Mon, Jan 19, 2015 at 07:16:28PM +0000, David Daney wrote: > > [...] >>>>> >>>>> @@ -67,6 +76,7 @@ static const struct of_device_id ahci_of_match[] = { >>>>> { .compatible = "ibm,476gtr-ahci", }, >>>>> { .compatible = "snps,dwc-ahci", }, >>>>> { .compatible = "hisilicon,hisi-ahci", }, >>>>> + { .compatible = "cavium,octeon-7130-ahci", }, >>>>> {}, >>>> >>>> >>>> I was under the impression that the strings other than "generic-ahci" >>>> were only for compatibility with existing DTBs. Why do we need to add >>>> new platform-specific strings here? >>> >>> >>> Because it is an "existing DTB", The device tree doesn't contain the >>> compatible property of "generic-ahci", only "cavium,octeon-7130-ahci". >> >> >> While the DTB may already exist, the string "cavium,octeon-7130-ahci" >> isn't in mainline, and as far as I can see has never been supported. > > > There seems to be a disconnect here. The DTB comes from the hardware boot > environment. The hardware is in some cases already deployed. It is for all > practical purposes, impossible to change the DTB. > > The idea that the kernel source code controls the content of the device tree > doesn't apply here. I have to agree that adding the compatible string here is okay. Allowing/using generic names is the exception, not the rule. We're usually pushing the other way. People often complain about having to add a compatible string when they don't need it (yet). However, the argument that the privately developed DTB has to be accepted as is is complete crap. Maybe you have done a good job and have all straightforward bindings, so having them accepted won't be a big deal. We should be reasonable and not bikeshed things which are already in use and only affect a single device. Many of the bindings in vendor trees I have seen are a complete mess, but I expect better from you. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html