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: <20121206103515.GQ2718@gmail.com> Date: Thu, 6 Dec 2012 10:35:15 +0000 From: Lee Jones <lee.jones@...aro.org> To: Viresh Kumar <viresh.kumar@...aro.org> Cc: Grant Likely <grant.likely@...retlab.ca>, Samuel Ortiz <sameo@...ux.intel.com>, rabin.vincent@...ricsson.com, shiraz.hashim@...com, devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org, spear-devel@...t.st.com, linus.walleij@...aro.org, Vipul Kumar Samar <vipulkumar.samar@...com> Subject: Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver On Thu, 06 Dec 2012, Viresh Kumar wrote: > On 6 December 2012 15:41, Lee Jones <lee.jones@...aro.org> wrote: > > So then I'm back to my original question, why? > > > > What is it used for? What difference does it make? > > > > I could understand if the .data attribute was used in the driver > > to make vital decisions based on STMPE version, but it's not. So > > why are we burdening the driver with unused code that's not > > required? Other than to get your mainlined patch-count up of > > course? This has an air of "placing header files in alphabetical > > order" about it. ;) > > The count would still be the same as some part of this patch will > go :) > > I said that because of Grant's comment: "An of_match_table is the > robust way of identifying specific devices and allows for matching > against any entry in the compatible list." > > So, thought its better we keep it. Only if you're going to use it, or else it's just unused cruft. > Now, the problem is, with this new table we will bind device and > driver based on of_device_id table and probe it using device_id > table. Ahh.. that's broken. Maybe yes, can remove it unless we > have a real need of it. Broken or otherwise, if it's unused, it's cruft. :) > >> By chance > >> our non-DT and DT tables had a difference of "st," only in the name > >> of instances and so it worked without tables. Otherwise it couldn't > >> have worked. > >> > >> Over that, i am looking to bring the "stmpe,id" binding back again (unless > >> you have a better option), as device name is not coming from DT currently, > >> which we discussed earlier. > > > > Or you could not put unnecessary bindings into the Device Tree > > by putting two and two together and realise that using the table > > is the correct thing to do instead. This actually gives reason > > to you previous patch, but should probably be fixed-up into it > > so it has some proper meaning/purpose. ;) > > Couldn't understand this one :( Really? Let's break it down - what do you need "stmpe,id" for? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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