[RESEND][PATCH] mtd: chips: Add support for PMC SPI Flash chips in m25p80.c

[Brian Norris]

On Wed, Aug 21, 2013 at 6:10 AM, Marek Vasut <marex at denx.de> wrote:
>> On Wed, Aug 21, 2013 at 10:07:17AM +0200, Marek Vasut wrote:
>> > > On Wed, Aug 21, 2013 at 09:41:38AM +0200, Marek Vasut wrote:
>> > > > > + Marek, since he's been reviewing (with dismay?) the increase in
>> > > > > macro flags in this driver. If there are any objections, I can
>> > > > > amend/drop the patch.
>> > > >
>> > > > Hmmm ... this SECT_4K_PMC seems too combined to me. Why don't we use
>> > > > the SECT_4K flag and another flag to indicate it's a PMC part? Even
>> > > > better, I recall you can
>> > >
>> > > Separating manufacturer from SECT_4K sounds good, but it really doesn't
>> > > buy us much. See my next comments.
>> >
>> > I see, that's really bad news. Thanks for the explanation!
>> >
>> > I guess there really is nothing much we can do about such parts. But then
>> > if we take device tree probe into consideration, we might actually want
>> > to match the part name to discern the PMS device. Or am I talking
>> > complete nonsense?
>>
>> I don't think the device tree probe really gives us anything different
>> than the platform_device probe (a non-JEDEC device can be matched via
>> device-tree "compatible" property or via platform_device "name"
>> property, I think?). So in either case, are you suggesting a string
>> comparison for "pm25" on the spi_device_id.name field? Seems a bit
>> like nonsense :)
>
> Yeah, you're right.
>
>> Additionally, this still doesn't solve the problem that the old PMC
>> chips need the special opcode, but the newer one doesn't.
>
> One would have to match the full part name, but that's already happening. Please
> ignore me, I had my coffee only now.

No problem. Then I'm leaving the patch queued as-is. Thanks for taking a look.

Brian