From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfram Sang Subject: Re: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Date: Sun, 22 Jul 2012 10:33:43 +0200 Message-ID: <20120722083343.GA31508@pengutronix.de> References: <1341850974-11977-1-git-send-email-marex@denx.de> <201207211611.58956.marex@denx.de> <20120721154153.GA25874@pengutronix.de> <201207211754.29372.marex@denx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Return-path: Content-Disposition: inline In-Reply-To: <201207211754.29372.marex-ynQEQJNshbs@public.gmane.org> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Marek Vasut Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Shawn Guo , Fabio Estevam , devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Wolfgang Denk , Detlev Zundel , Stefano Babic , Sascha Hauer , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Uwe =?iso-8859-15?Q?Kleine-K=F6nig?= , Dong Aisheng , pavel-+ZI9xUNit7I@public.gmane.org List-Id: devicetree@vger.kernel.org --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Even if the driver was matched because of an MX23-I2C "compatible" > > binding, both devicetree and runtime could provide data that it actually > > runs on MX28. That shouldn't be a problem. >=20 > You mean like ... cpu_is_mx28() ? We got rid of that in favor of DT. Might be. But the information is probably somewhere. > > IIRC I mentioned that a discussion about the bindings won't make the > > next merge window. >=20 > Yet another merge window, I have to mention. And only because very long p= auses=20 > inbetween reviews and very minor nitpicks. I'm being annoyed by this patc= h so=20 > much I'm thinking of giving up on this. I wasted too much of my free time= on=20 > this and the result is as is. For you it might be a minor nitpick, for me (as a maintainer) it is not. You have to deal with just one binding, I have to deal with many. And since they have to be supported forever, this can easily mess up code and make the subsystem clumsy and whatnot. > > That's why I proposed either module_parameter >=20 > Which I explained is not a way to go. That's why I called it inbetween solution so the patch could go in. It's fine if you don't like it, I prefer dropping the binding as well. > > or > > dropping the binding entirely as possible inbetween options. >=20 > Which is not an option either. It would enable you to add the binding as an out-of-tree patch. > And this discussion is only further stalling the=20 > patch. > We're adding fsl,something properties all over the DT all the time, yet t= his one=20 > is of concern? Yes. Adding all these properties is IMO not the right way, and I have the impression they often came in because of time pressure like this. If I think it is wrong for the kernel, I have to reject a patch unless I am convinced otherwise. Which did not happen yet; as you found out discussions on devicetree-discuss are slow. Might be another indication that devictree things happen too much at the time currently. This is not specific to your patch, there are more which need discussion or had to be reworked. Regards, Wolfram --=20 Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlALuucACgkQD27XaX1/VRs5+wCgxLOznYyW6Lt/sGcSL97v6nB5 7xAAnRyJdvW22RkrzPmag1CxbmEXRA61 =KScQ -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm--