On Thursday, September 12, 2013 2:55 PM, Michal Simek wrote:
>
> Simplify driver probe and release function.
>
> Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Jingoo Han <[email protected]>
> ---
> drivers/video/xilinxfb.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
On Thursday, September 12, 2013 2:55 PM, Michal Simek wrote:
>
> devm_iounmap is called automatically that's why remove it from the code
> dev_set_drvdata(dev, NULL) is called by generic code
> after device_release or on probe failure.
>
> Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Jingoo Han <[email protected]>
> ---
> drivers/video/xilinxfb.c | 28 ++++++----------------------
> 1 file changed, 6 insertions(+), 22 deletions(-)
On 12/09/13 08:54, Michal Simek wrote:
> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
> /* Turn off the display */
> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>
> - /* Release the resources, as allocated based on interface */
> - if (drvdata->flags & BUS_ACCESS_FLAG)
> - devm_iounmap(dev, drvdata->regs);
> #ifdef CONFIG_PPC_DCR
> - else
> + /* Release the resources, as allocated based on interface */
> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
> #endif
I might be mistaken, and it's not strictly part of this series, but
shouldn't dcr_unmap be called somewhere else also, if the probe fails?
Tomi
On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
> On 12/09/13 08:54, Michal Simek wrote:
>
>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>> /* Turn off the display */
>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>
>> - /* Release the resources, as allocated based on interface */
>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>> - devm_iounmap(dev, drvdata->regs);
>> #ifdef CONFIG_PPC_DCR
>> - else
>> + /* Release the resources, as allocated based on interface */
>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>> #endif
>
> I might be mistaken, and it's not strictly part of this series, but
> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
yes. It should.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
On 16/09/13 13:33, Michal Simek wrote:
> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>> On 12/09/13 08:54, Michal Simek wrote:
>>
>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>> /* Turn off the display */
>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>
>>> - /* Release the resources, as allocated based on interface */
>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>> - devm_iounmap(dev, drvdata->regs);
>>> #ifdef CONFIG_PPC_DCR
>>> - else
>>> + /* Release the resources, as allocated based on interface */
>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>> #endif
>>
>> I might be mistaken, and it's not strictly part of this series, but
>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>
> yes. It should.
Do you want me to apply these patches as they are, or do you want to
improve the series to include the dcr_unmap fix?
Tomi
Hi Tomi,
On 09/16/2013 12:34 PM, Tomi Valkeinen wrote:
> On 16/09/13 13:33, Michal Simek wrote:
>> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>>> On 12/09/13 08:54, Michal Simek wrote:
>>>
>>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>>> /* Turn off the display */
>>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>>
>>>> - /* Release the resources, as allocated based on interface */
>>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>>> - devm_iounmap(dev, drvdata->regs);
>>>> #ifdef CONFIG_PPC_DCR
>>>> - else
>>>> + /* Release the resources, as allocated based on interface */
>>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>>> #endif
>>>
>>> I might be mistaken, and it's not strictly part of this series, but
>>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>>
>> yes. It should.
>
> Do you want me to apply these patches as they are, or do you want to
> improve the series to include the dcr_unmap fix?
Sorry I have missed this email.
Yes please apply it as is. I don't have ppc hw here to be able to test this
change.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
On 30/09/13 15:05, Michal Simek wrote:
> Hi Tomi,
>
> On 09/16/2013 12:34 PM, Tomi Valkeinen wrote:
>> On 16/09/13 13:33, Michal Simek wrote:
>>> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>>>> On 12/09/13 08:54, Michal Simek wrote:
>>>>
>>>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>>>> /* Turn off the display */
>>>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>>>
>>>>> - /* Release the resources, as allocated based on interface */
>>>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>>>> - devm_iounmap(dev, drvdata->regs);
>>>>> #ifdef CONFIG_PPC_DCR
>>>>> - else
>>>>> + /* Release the resources, as allocated based on interface */
>>>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>>>> #endif
>>>>
>>>> I might be mistaken, and it's not strictly part of this series, but
>>>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>>>
>>> yes. It should.
>>
>> Do you want me to apply these patches as they are, or do you want to
>> improve the series to include the dcr_unmap fix?
>
> Sorry I have missed this email.
>
> Yes please apply it as is. I don't have ppc hw here to be able to test this
> change.
This series does not apply. Can you rebase on top of linux-next, and resend?
Tomi
On 10/09/2013 11:02 AM, Tomi Valkeinen wrote:
> On 30/09/13 15:05, Michal Simek wrote:
>> Hi Tomi,
>>
>> On 09/16/2013 12:34 PM, Tomi Valkeinen wrote:
>>> On 16/09/13 13:33, Michal Simek wrote:
>>>> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>>>>> On 12/09/13 08:54, Michal Simek wrote:
>>>>>
>>>>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>>>>> /* Turn off the display */
>>>>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>>>>
>>>>>> - /* Release the resources, as allocated based on interface */
>>>>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>>>>> - devm_iounmap(dev, drvdata->regs);
>>>>>> #ifdef CONFIG_PPC_DCR
>>>>>> - else
>>>>>> + /* Release the resources, as allocated based on interface */
>>>>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>>>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>>>>> #endif
>>>>>
>>>>> I might be mistaken, and it's not strictly part of this series, but
>>>>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>>>>
>>>> yes. It should.
>>>
>>> Do you want me to apply these patches as they are, or do you want to
>>> improve the series to include the dcr_unmap fix?
>>
>> Sorry I have missed this email.
>>
>> Yes please apply it as is. I don't have ppc hw here to be able to test this
>> change.
>
> This series does not apply. Can you rebase on top of linux-next, and resend?
Do you mean Stephen Rothwell linux-next or any your linux-next branch?
No problem to do so if you send me link to the repo.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
On 09/10/13 13:25, Michal Simek wrote:
>> This series does not apply. Can you rebase on top of linux-next, and resend?
>
> Do you mean Stephen Rothwell linux-next or any your linux-next branch?
> No problem to do so if you send me link to the repo.
Either one, my for-next is in Stephen's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
Tomi