On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
> On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
>
>>
>> + for (i = 0; i < ARRAY_SIZE(smsc911x_refs) * num; i++) {
>> + int id;
>> + char *name;
>> +
>> + id = board_data[i / num].id;
>> + if (id != -1)
>> + name = kasprintf(GFP_KERNEL, "smsc911x.%d", id);
>> + else
>> + name = kstrdup("smsc911x", GFP_KERNEL);
>
> This seems pretty much insane, it's costing a lot more to faff around
> like this than it's worth. Just do the setup in the individual boards,
> if you really have no idea what's supplying the device (which seems a
> bit unusual, more boards like this have things coming off the PMIC than
> don't) there's now regulator_register_fixed() which cuts down on the
> boilerplate a little.
>
> I'd have complained about the original code if I'd noticed it wasn't a
> patch for a particular board as the breakage you've found is obvious.
> The regulation constraints it adds are bogus too, it's setting
> REGULATOR_CHANGE_MODE on a regulator that doesn't support modes and
> REGULATOR_CHANGE_STATUS without supplying the enable GPIO.
The original patch for the problem was specific to the fixed regulator
on the OMAP3EVM/AMDM37xxEVM board...it was rejected. I was asked to
put something generic in gpmc-smsc911x.c like this.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
