Messages in this thread | | | Subject | Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision | From | Robin Murphy <> | Date | Fri, 10 Nov 2017 14:17:16 +0000 |
| |
On 10/11/17 14:03, Sinan Kaya wrote: > +linux-acpi, +Rafael for context > > On 11/8/2017 12:51 PM, Robin Murphy wrote: >> Apologies if I wasn't very clear, but what I meant to imply by dropping the of_device_get_match_data() hint was to follow one of the common patterns where you either just have some version token: >> >> enum foo_ver { >> FOO_V1, >> ... >> } >> >> struct acpi_device_id foo_acpi_ids[] = { >> { "_FOO0001", FOO_V1 }, >> ... >> } >> >> struct of_device_id foo_of_match[] = { >> { .compatible = "foo,v1", .data = (void *)FOO_V1 }, >> ... >> } >> >> int foo_probe(struct device *dev) { >> ... >> foodev->version = (enum foo_ver) >> of_device_get_match_data(&dev->of_node) >> ... >> } >> >> int foo_reset(struct foodev *foodev) { >> if (foodev->version == FOO_V1) >> writel(0, foodev->base + 0x20); >> else >> writel(0, foodev->base + 0x30); >> } > > I did post v3 with this approach. However, I could not really find a ACPI function that > returns the driver data very similar to of_device_get_match_data(). The only thing > that is closer is acpi_match_device().
Yeah, I left the "follow the status quo and open-code it" part out of the above example for brevity ;)
Probably 95% of the calls to acpi_match_device() are only doing so to retrieve the driver_data, so the helper could provide scope for further cleanup if anyone wants, too.
> I introduced this new function as part of the v3 series. > > Let me know if I'm missing something. v3 looks good, thanks for persevering - I'll leave the rest up to Vinod and Rafael.
Cheers, Robin.
| |