| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1377128031.5029.75.camel@snotra.buserror.net> Date: Wed, 21 Aug 2013 18:33:51 -0500 From: Scott Wood <scottwood@...escale.com> To: Stephen Warren <swarren@...dotorg.org> CC: <hongbo.zhang@...escale.com>, <vinod.koul@...el.com>, <djbw@...com>, <leoli@...escale.com>, <linuxppc-dev@...ts.ozlabs.org>, <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document On Wed, 2013-08-21 at 17:12 -0600, Stephen Warren wrote: > OK, if there's some alternative run-time way of enabling chip-specific > quirking, it's probably fine to remove the extra compatible values. > > Now, that does rather assume that this DMA IP block will only ever be > used within SoCs that have that SVR concept, but perhaps if that's ever > not the case, we can simply go back to requiring extra compatible values > in those specific cases? The only situation I can see where SVR would be absent is if we were to integrate this device into an ARM chip, in which case I'd expect there to be some equivalent way to find the SoC identification. If the driver knows what SoC version it expects, it will know the way that that SoC advertises its version. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists