diff for duplicates of <20160726121640.2d5d9045.john@metanate.com> diff --git a/a/1.txt b/N1/1.txt index fb27901..101f29c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,60 +1,58 @@ On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote: ->=20 -> On 2016=E5=B9=B407=E6=9C=8826=E6=97=A5 17:00, John Keeping wrote: +> +> On 2016年07月26日 17:00, John Keeping wrote: > > On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote: > > > >> SARADC controller needs to be reset before programming it, otherwise > >> it will not function properly. > >> -> >> Signed-off-by: Caesar Wang <wxt@rock-chips.com> -> >> Cc: Jonathan Cameron <jic23@kernel.org> -> >> Cc: Heiko Stuebner <heiko@sntech.de> -> >> Cc: Rob Herring <robh+dt@kernel.org> -> >> Cc: linux-iio@vger.kernel.org -> >> Cc: linux-rockchip@lists.infradead.org +> >> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org> +> >> Cc: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> +> >> Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> +> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> +> >> Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org +> >> Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > >> --- > >> -> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockc= -hip_saradc.c +> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c > >> index f9ad6c2..2f0e110 100644 > >> --- a/drivers/iio/adc/rockchip_saradc.c > >> +++ b/drivers/iio/adc/rockchip_saradc.c -> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_= -device *pdev) +> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device *pdev) > >> if (IS_ERR(info->regs)) > >> return PTR_ERR(info->regs); -> >> =20 -> >> + info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb"); +> >> +> >> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb"); > >> + if (IS_ERR(info->reset)) { -> >> + ret =3D PTR_ERR(info->reset); +> >> + ret = PTR_ERR(info->reset); > >> + dev_err(&pdev->dev, "failed to get saradc reset: %d\n", ret); > >> + return ret; > >> + } > > Does this need to handle ENOENT so as to avoid failing with old device > > tree blobs? ->=20 +> > I'm no sure why we have to support the old device tree, > We can apply this series patches if we need to support the reset property. > --- ->=20 +> > Maybe, I can follow you suggestion to handle the ENOENT, as following: ->=20 +> > + /* > + * The reset should be an optional property, as it should work > + * with old devicetrees as well > + */ -> + info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb"); +> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb"); > + if (IS_ERR(info->reset)) { -> + if (PTR_ERR(info->reset) =3D=3D -EPROBE_DEFER) { -> + ret =3D -EPROBE_DEFER; +> + if (PTR_ERR(info->reset) == -EPROBE_DEFER) { +> + ret = -EPROBE_DEFER; > + return ret; > + } > + dev_dbg(&pdev->dev, "no reset control found\n"); -> + info->reset =3D NULL; +> + info->reset = NULL; > + } > ... ->=20 +> > How about it? I think it's better to handle ENOENT specifically, we still want to fail @@ -63,12 +61,12 @@ if some other errors like EINVAL is returned. Something like this, perhaps? if (IS_ERR(info->reset)) { - ret =3D PTR_ERR(info->reset); - if (ret !=3D -ENOENT) + ret = PTR_ERR(info->reset); + if (ret != -ENOENT) return ret; dev_dbg(&pdev->dev, "no reset control found\n"); - info->reset =3D NULL; + info->reset = NULL; } Although I do wonder if a devm_reset_control_get_optional() helper would diff --git a/a/content_digest b/N1/content_digest index 4448bf2..bc7479c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,78 +1,77 @@ "ref\01469513510-1516-1-git-send-email-wxt@rock-chips.com\0" "ref\020160726100007.5166e7f9.john@metanate.com\0" "ref\057974054.8040700@rock-chips.com\0" - "From\0John Keeping <john@metanate.com>\0" + "ref\057974054.8040700-TNX95d0MmH7DzftRWevZcw@public.gmane.org\0" + "From\0John Keeping <john-HooS5bfzL4hWk0Htik3J/w@public.gmane.org>\0" "Subject\0Re: [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it\0" "Date\0Tue, 26 Jul 2016 12:16:40 +0100\0" - "To\0Caesar Wang <wxt@rock-chips.com>\0" - "Cc\0Heiko Stuebner <heiko@sntech.de>" - devicetree@vger.kernel.org - linux-iio@vger.kernel.org - dianders@chromium.org - linux-kernel@vger.kernel.org - linux-rockchip@lists.infradead.org - robh+dt@kernel.org - linux@roeck-us.net - " jic23@kernel.org\0" + "To\0Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>\0" + "Cc\0Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>" + devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org + linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org + robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org + linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org + " jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org\0" "\00:1\0" "b\0" "On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:\n" "\n" - ">=20\n" - "> On 2016=E5=B9=B407=E6=9C=8826=E6=97=A5 17:00, John Keeping wrote:\n" + "> \n" + "> On 2016\345\271\26407\346\234\21026\346\227\245 17:00, John Keeping wrote:\n" "> > On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote:\n" "> >\n" "> >> SARADC controller needs to be reset before programming it, otherwise\n" "> >> it will not function properly.\n" "> >>\n" - "> >> Signed-off-by: Caesar Wang <wxt@rock-chips.com>\n" - "> >> Cc: Jonathan Cameron <jic23@kernel.org>\n" - "> >> Cc: Heiko Stuebner <heiko@sntech.de>\n" - "> >> Cc: Rob Herring <robh+dt@kernel.org>\n" - "> >> Cc: linux-iio@vger.kernel.org\n" - "> >> Cc: linux-rockchip@lists.infradead.org\n" + "> >> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>\n" + "> >> Cc: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\n" + "> >> Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>\n" + "> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\n" + "> >> Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" + "> >> Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org\n" "> >> ---\n" "> >>\n" - "> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockc=\n" - "hip_saradc.c\n" + "> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c\n" "> >> index f9ad6c2..2f0e110 100644\n" "> >> --- a/drivers/iio/adc/rockchip_saradc.c\n" "> >> +++ b/drivers/iio/adc/rockchip_saradc.c\n" - "> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_=\n" - "device *pdev)\n" + "> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device *pdev)\n" "> >> \tif (IS_ERR(info->regs))\n" "> >> \t\treturn PTR_ERR(info->regs);\n" - "> >> =20\n" - "> >> +\tinfo->reset =3D devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" + "> >> \n" + "> >> +\tinfo->reset = devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" "> >> +\tif (IS_ERR(info->reset)) {\n" - "> >> +\t\tret =3D PTR_ERR(info->reset);\n" + "> >> +\t\tret = PTR_ERR(info->reset);\n" "> >> +\t\tdev_err(&pdev->dev, \"failed to get saradc reset: %d\\n\", ret);\n" "> >> +\t\treturn ret;\n" "> >> +\t}\n" "> > Does this need to handle ENOENT so as to avoid failing with old device\n" "> > tree blobs?\n" - ">=20\n" + "> \n" "> I'm no sure why we have to support the old device tree,\n" "> We can apply this series patches if we need to support the reset property.\n" "> ---\n" - ">=20\n" + "> \n" "> Maybe, I can follow you suggestion to handle the ENOENT, as following:\n" - ">=20\n" + "> \n" "> + /*\n" "> + * The reset should be an optional property, as it should work\n" "> + * with old devicetrees as well\n" "> + */\n" - "> + info->reset =3D devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" + "> + info->reset = devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" "> + if (IS_ERR(info->reset)) {\n" - "> + if (PTR_ERR(info->reset) =3D=3D -EPROBE_DEFER) {\n" - "> + ret =3D -EPROBE_DEFER;\n" + "> + if (PTR_ERR(info->reset) == -EPROBE_DEFER) {\n" + "> + ret = -EPROBE_DEFER;\n" "> + return ret;\n" "> + }\n" "> + dev_dbg(&pdev->dev, \"no reset control found\\n\");\n" - "> + info->reset =3D NULL;\n" + "> + info->reset = NULL;\n" "> + }\n" "> ...\n" - ">=20\n" + "> \n" "> How about it?\n" "\n" "I think it's better to handle ENOENT specifically, we still want to fail\n" @@ -81,16 +80,16 @@ "Something like this, perhaps?\n" "\n" " if (IS_ERR(info->reset)) {\n" - " ret =3D PTR_ERR(info->reset);\n" - " if (ret !=3D -ENOENT)\n" + " ret = PTR_ERR(info->reset);\n" + " if (ret != -ENOENT)\n" " return ret;\n" "\n" " dev_dbg(&pdev->dev, \"no reset control found\\n\");\n" - " info->reset =3D NULL;\n" + " info->reset = NULL;\n" " }\n" "\n" "Although I do wonder if a devm_reset_control_get_optional() helper would\n" "be useful (this isn't the first time I've seen reset control added to\n" existing drivers). -7a93dfce7f68a9771e9533fed98956177efb70498663e21f3918ec564baf7f4e +4e862d05d8146b4472d65e21d47680700cb85637ebea799d4cb5f91c9fccc57a
diff --git a/a/1.txt b/N2/1.txt index fb27901..0dd9310 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,7 +1,7 @@ On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote: ->=20 -> On 2016=E5=B9=B407=E6=9C=8826=E6=97=A5 17:00, John Keeping wrote: +> +> On 2016年07月26日 17:00, John Keeping wrote: > > On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote: > > > >> SARADC controller needs to be reset before programming it, otherwise @@ -15,46 +15,44 @@ On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote: > >> Cc: linux-rockchip@lists.infradead.org > >> --- > >> -> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockc= -hip_saradc.c +> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c > >> index f9ad6c2..2f0e110 100644 > >> --- a/drivers/iio/adc/rockchip_saradc.c > >> +++ b/drivers/iio/adc/rockchip_saradc.c -> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_= -device *pdev) +> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device *pdev) > >> if (IS_ERR(info->regs)) > >> return PTR_ERR(info->regs); -> >> =20 -> >> + info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb"); +> >> +> >> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb"); > >> + if (IS_ERR(info->reset)) { -> >> + ret =3D PTR_ERR(info->reset); +> >> + ret = PTR_ERR(info->reset); > >> + dev_err(&pdev->dev, "failed to get saradc reset: %d\n", ret); > >> + return ret; > >> + } > > Does this need to handle ENOENT so as to avoid failing with old device > > tree blobs? ->=20 +> > I'm no sure why we have to support the old device tree, > We can apply this series patches if we need to support the reset property. > --- ->=20 +> > Maybe, I can follow you suggestion to handle the ENOENT, as following: ->=20 +> > + /* > + * The reset should be an optional property, as it should work > + * with old devicetrees as well > + */ -> + info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb"); +> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb"); > + if (IS_ERR(info->reset)) { -> + if (PTR_ERR(info->reset) =3D=3D -EPROBE_DEFER) { -> + ret =3D -EPROBE_DEFER; +> + if (PTR_ERR(info->reset) == -EPROBE_DEFER) { +> + ret = -EPROBE_DEFER; > + return ret; > + } > + dev_dbg(&pdev->dev, "no reset control found\n"); -> + info->reset =3D NULL; +> + info->reset = NULL; > + } > ... ->=20 +> > How about it? I think it's better to handle ENOENT specifically, we still want to fail @@ -63,12 +61,12 @@ if some other errors like EINVAL is returned. Something like this, perhaps? if (IS_ERR(info->reset)) { - ret =3D PTR_ERR(info->reset); - if (ret !=3D -ENOENT) + ret = PTR_ERR(info->reset); + if (ret != -ENOENT) return ret; dev_dbg(&pdev->dev, "no reset control found\n"); - info->reset =3D NULL; + info->reset = NULL; } Although I do wonder if a devm_reset_control_get_optional() helper would diff --git a/a/content_digest b/N2/content_digest index 4448bf2..b3a1ab1 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -18,8 +18,8 @@ "b\0" "On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:\n" "\n" - ">=20\n" - "> On 2016=E5=B9=B407=E6=9C=8826=E6=97=A5 17:00, John Keeping wrote:\n" + "> \n" + "> On 2016\345\271\26407\346\234\21026\346\227\245 17:00, John Keeping wrote:\n" "> > On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote:\n" "> >\n" "> >> SARADC controller needs to be reset before programming it, otherwise\n" @@ -33,46 +33,44 @@ "> >> Cc: linux-rockchip@lists.infradead.org\n" "> >> ---\n" "> >>\n" - "> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockc=\n" - "hip_saradc.c\n" + "> >> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c\n" "> >> index f9ad6c2..2f0e110 100644\n" "> >> --- a/drivers/iio/adc/rockchip_saradc.c\n" "> >> +++ b/drivers/iio/adc/rockchip_saradc.c\n" - "> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_=\n" - "device *pdev)\n" + "> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device *pdev)\n" "> >> \tif (IS_ERR(info->regs))\n" "> >> \t\treturn PTR_ERR(info->regs);\n" - "> >> =20\n" - "> >> +\tinfo->reset =3D devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" + "> >> \n" + "> >> +\tinfo->reset = devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" "> >> +\tif (IS_ERR(info->reset)) {\n" - "> >> +\t\tret =3D PTR_ERR(info->reset);\n" + "> >> +\t\tret = PTR_ERR(info->reset);\n" "> >> +\t\tdev_err(&pdev->dev, \"failed to get saradc reset: %d\\n\", ret);\n" "> >> +\t\treturn ret;\n" "> >> +\t}\n" "> > Does this need to handle ENOENT so as to avoid failing with old device\n" "> > tree blobs?\n" - ">=20\n" + "> \n" "> I'm no sure why we have to support the old device tree,\n" "> We can apply this series patches if we need to support the reset property.\n" "> ---\n" - ">=20\n" + "> \n" "> Maybe, I can follow you suggestion to handle the ENOENT, as following:\n" - ">=20\n" + "> \n" "> + /*\n" "> + * The reset should be an optional property, as it should work\n" "> + * with old devicetrees as well\n" "> + */\n" - "> + info->reset =3D devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" + "> + info->reset = devm_reset_control_get(&pdev->dev, \"saradc-apb\");\n" "> + if (IS_ERR(info->reset)) {\n" - "> + if (PTR_ERR(info->reset) =3D=3D -EPROBE_DEFER) {\n" - "> + ret =3D -EPROBE_DEFER;\n" + "> + if (PTR_ERR(info->reset) == -EPROBE_DEFER) {\n" + "> + ret = -EPROBE_DEFER;\n" "> + return ret;\n" "> + }\n" "> + dev_dbg(&pdev->dev, \"no reset control found\\n\");\n" - "> + info->reset =3D NULL;\n" + "> + info->reset = NULL;\n" "> + }\n" "> ...\n" - ">=20\n" + "> \n" "> How about it?\n" "\n" "I think it's better to handle ENOENT specifically, we still want to fail\n" @@ -81,16 +79,16 @@ "Something like this, perhaps?\n" "\n" " if (IS_ERR(info->reset)) {\n" - " ret =3D PTR_ERR(info->reset);\n" - " if (ret !=3D -ENOENT)\n" + " ret = PTR_ERR(info->reset);\n" + " if (ret != -ENOENT)\n" " return ret;\n" "\n" " dev_dbg(&pdev->dev, \"no reset control found\\n\");\n" - " info->reset =3D NULL;\n" + " info->reset = NULL;\n" " }\n" "\n" "Although I do wonder if a devm_reset_control_get_optional() helper would\n" "be useful (this isn't the first time I've seen reset control added to\n" existing drivers). -7a93dfce7f68a9771e9533fed98956177efb70498663e21f3918ec564baf7f4e +8ff6b6ad8abd3a115a6acfe681718d035da011c488886ac28bc47ff2f2c66be5
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.