linux-kernel - Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/