On Fri, Apr 15, 2016 at 8:05 AM, Darren Hart <dvhart@xxxxxxxxxxxxx> wrote:
>> >>>> + /*
>> >>>> + * The following resources are optional
>> >>>> + * - ISPDRIVER_IPC BASE_DATA
>> >>>> + * - ISPDRIVER_IPC BASE_IFACE
>> >>>> + * - GTDRIVER_IPC BASE_DATA
>> >>>> + * - GTDRIVER_IPC BASE_IFACE
>> >>>> + */
>> >>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
>> >>>> - addr = devm_ioremap_resource(&pdev->dev, res);
>> >>>> - if (IS_ERR(addr))
>> >>>> - return PTR_ERR(addr);
>> >>>> - punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
>> >>>> + if (res) {
>> >>>> + addr = devm_ioremap_resource(&pdev->dev, res);
>> >>>> + if (!IS_ERR(addr))
>> >>>> + punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
>> >>>> + }
>> >>>
>> >>> And here, what about just replacing return to dev_warn()?
>> >>
>> >> I don't think we need to continue the subsequent ops if an error address
>> >> returns.
>> >
>> > Why is that? Will the driver fail to provide any functionality? Or could it be
>> > the other IFACEs could still be of some use?
>> >
>> > This one does need a justification.
>> >
>> We discussed this.
>> - For the necessary resources, if we obtain an error address, we should
>> return immediately.
>> - For the optional resources, we keep quiet if we don't get them, that
>> is, not throwing a warning out.
>
> Andy, he's checking for "res" now too, which is a good extra check since
> devm_ioremap_resource will issue a dev_err "invalid resource" if it's NULL, even
> though in our case, that's expected for an optional resource. This adds the
> extra nesting, and a dev_warn wouldn't be appropriate for an option resource.
>
> I'm happy to queue this to fixes at this point. Andy, are you OK with the
> resolution here?
Gmail hided this mail from me by some reason. I'm fine with the resolution.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
