Re: [PATCH 1/1] ptp: ptp_dte: simplify getting .driver_data
From: Wolfram Sang Date: Sun, 21 Oct 2018 22:00:39 +0200 > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Applied.
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Dear Laurent-san Thank you for your reply and comments! On 2018/10/22 20:23, Laurent Pinchart wrote: Hello Hoan, Thank you for the patch. On Monday, 22 October 2018 09:30:54 EEST Nguyen An Hoan wrote: From: Hoan Nguyen An From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to ensure known initial value" What exact commit are you referring to ? The mainline commit that has this subject is 9144adc5e5a99577bce0d4ee2ca3615f53b9d296. Seems I have cited the wrong Commit-ID、it is 9144adc5e5a99577bce0d4ee2ca3615f53b9d296 drm: rcar-du: Cache DSYSR value to ensure known initial value We only need to update DSYSR0, DSYSR2 for start/stop. So using rgrp-> mmio_offset is enough, the change back from rcar_du_crtc -> rcar_du_group -> rcar_du_crtc leading to mmio addresses for DSYSR may be different. Is this fixing an actual problem ? If you look at the code, the line struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2]; makes sure that we select DU0 or DU2 only, so the register write rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN, start ? DSYSR_DEN : DSYSR_DRES); should only access DSYSR0 and DSYSR2. This seems I think to fix the rcar-du problem with M3N-r8a77965, With M3N-R8a77965 we have DU0, DU1, DU3 So, when Laurent-san divide objetcs into rcar_du_group, rcar_du_crtc. DU0, DU1 -> du_group[0] rgrp-> mmio_offset = DU0_REG_OFFSET DU3->du_group[1] and rgrp-> mmio_offset = DU2_REG_OFFSET, but rcrtc->mmio_offset=DU3_REG_OFFSET (with M3N) M3N-R8a77965 not have DU2, So after the command: struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2]; So in fact, with M3N we are updating DSYSR3 (In this my TC, this reference to start/stop DU3-RGB) This will not affect H3, since the H3 lines always have enough DU0, DU1,DU2,DU3. Thank you very much ! Hoan.
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Dear Sergei Shtylyov-san
On 2018/10/22 17:21, Sergei Shtylyov wrote:
Hello!
On 22.10.2018 9:30, Nguyen An Hoan wrote:
From: Hoan Nguyen An
From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to
ensure known initial value"
When you cite an commit, at least 12 digits of SHA1 are needed, and
the summary needs to enclosed in (""), no just "".
We only need to update DSYSR0, DSYSR2 for start/stop. So using rgrp->
mmio_offset is enough,
the change back from rcar_du_crtc -> rcar_du_group -> rcar_du_crtc
leading to
mmio addresses for DSYSR may be different.
Signed-off-by: Hoan Nguyen An
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index d85f0a1..a5f7eed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -202,10 +202,9 @@ void rcar_du_group_put(struct rcar_du_group *rgrp)
static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp,
bool start)
{
- struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2];
-
- rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
- start ? DSYSR_DEN : DSYSR_DRES);
The continuation line indentation style used above is different
from yours below.
would be preferable to keep the existing style...
Thank you for the comments, and the notes to me about code rules.
I note and improve for the next time, thank you!
Hoan.
+ rcar_du_group_write(rgrp, DSYSR,
+ (rcar_du_group_read(rgrp, DSYSR) & ~(DSYSR_DRES |
DSYSR_DEN)) |
+ (start ? DSYSR_DEN : DSYSR_DRES));
}
void rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
MBR, Sergei
Re: [PATCH 1/1] ptp: ptp_dte: simplify getting .driver_data
On Sun, Oct 21, 2018 at 10:00:39PM +0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. Acked-by: Richard Cochran
Re: [PATCH 1/1] rtc: ds1685: simplify getting .driver_data
> By the way, is there any reason why this was not part of your patch back > in April? I had a deja vu feeling ;) I haven't checked but I guess the driver looked different back then. I didn't update the rule, so it should have matched back then, too. signature.asc Description: PGP signature
Re: [PATCH 4/6] gpio: gpio-omap: simplify getting .driver_data
On 10/21/18 2:59 PM, Wolfram Sang wrote: We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Thank you Acked-by: Grygorii Strashko -- regards, -grygorii
Re: [PATCH 1/1] rtc: ds1685: simplify getting .driver_data
On 22/10/2018 17:53:35+0200, Alexandre Belloni wrote: > On 21/10/2018 22:00:41+0200, Wolfram Sang wrote: > > We should get 'driver_data' from 'struct device' directly. Going via > > platform_device is an unneeded step back and forth. > > > > Signed-off-by: Wolfram Sang > > --- > > > > Build tested only. buildbot is happy. > > > > drivers/rtc/rtc-ds1685.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > Applied, thanks. > By the way, is there any reason why this was not part of your patch back in April? I had a deja vu feeling ;) -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 0/9] net: simplify getting .driver_data
On 10/21/18 1:00 PM, Wolfram Sang wrote: > I got tired of fixing this in Renesas drivers manually, so I took the big > hammer. Remove this cumbersome code pattern which got copy-pasted too much > already: > > - struct platform_device *pdev = to_platform_device(dev); > - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev); > + struct ep93xx_keypad *keypad = dev_get_drvdata(dev); > > A branch, tested by buildbot, can be found here: > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git > coccinelle/get_drvdata > > I have been asked if it couldn't be done for dev_set_drvdata as well. I > checked > it and did not find one occasion where it could be simplified like this. Not > much of a surprise because driver_data is usually set in probe() functions > which access struct platform_device in many other ways. > > I am open for other comments, suggestions, too, of course. Would it make sense to annotate platform_get_drvdata() with __deprecated or something like that to prevent further uses by driver authors? Do you mind submitting the cocci-script to the maintainers of the coccinelle scripts that way it can be included and run by automated tools? Thanks! > > Here is the cocci-script I created: > > @@ > struct device* d; > identifier pdev; > expression *ptr; > @@ > ( > - struct platform_device *pdev = to_platform_device(d); > | > - struct platform_device *pdev; > ... > - pdev = to_platform_device(d); > ) > <... when != pdev > - &pdev->dev > + d > ...> > > ptr = > - platform_get_drvdata(pdev) > + dev_get_drvdata(d) > > <... when != pdev > - &pdev->dev > + d > ...> > > Kind regards, > >Wolfram > > > Wolfram Sang (9): > net: dsa: bcm_sf2: simplify getting .driver_data > net: dsa: qca8k: simplify getting .driver_data > net: ethernet: cadence: macb_main: simplify getting .driver_data > net: ethernet: davicom: dm9000: simplify getting .driver_data > net: ethernet: smsc: smc91x: simplify getting .driver_data > net: ethernet: ti: cpsw: simplify getting .driver_data > net: ethernet: ti: davinci_emac: simplify getting .driver_data > net: ethernet: wiznet: w5300: simplify getting .driver_data > net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data > > drivers/net/dsa/bcm_sf2.c| 6 ++ > drivers/net/dsa/qca8k.c | 6 ++ > drivers/net/ethernet/cadence/macb_main.c | 6 ++ > drivers/net/ethernet/davicom/dm9000.c| 6 ++ > drivers/net/ethernet/smsc/smc91x.c | 3 +-- > drivers/net/ethernet/ti/cpsw.c | 6 ++ > drivers/net/ethernet/ti/davinci_emac.c | 6 ++ > drivers/net/ethernet/wiznet/w5300.c | 6 ++ > drivers/net/phy/mdio-mux-bcm-iproc.c | 6 ++ > 9 files changed, 17 insertions(+), 34 deletions(-) > -- Florian
Re: [PATCH 9/9] net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data
On 10/21/18 1:00 PM, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH 2/9] net: dsa: qca8k: simplify getting .driver_data
On 10/21/18 1:00 PM, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH 1/9] net: dsa: bcm_sf2: simplify getting .driver_data
On 10/21/18 1:00 PM, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH 1/1] net: dsa: legacy: simplify getting .driver_data
On 10/21/18 1:01 PM, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH 1/1] rtc: ds1685: simplify getting .driver_data
On 21/10/2018 22:00:41+0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. > > drivers/rtc/rtc-ds1685.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Hello Hoan,
Thank you for the patch.
On Monday, 22 October 2018 09:30:54 EEST Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to ensure
> known initial value"
What exact commit are you referring to ? The mainline commit that has this
subject is 9144adc5e5a99577bce0d4ee2ca3615f53b9d296.
> We only need to update DSYSR0, DSYSR2 for start/stop.
> So using rgrp-> mmio_offset is enough, the change back from rcar_du_crtc ->
> rcar_du_group -> rcar_du_crtc leading to mmio addresses for DSYSR may be
> different.
Is this fixing an actual problem ? If you look at the code, the line
struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2];
makes sure that we select DU0 or DU2 only, so the register write
rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
start ? DSYSR_DEN : DSYSR_DRES);
should only access DSYSR0 and DSYSR2.
> Signed-off-by: Hoan Nguyen An
> ---
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c index d85f0a1..a5f7eed 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -202,10 +202,9 @@ void rcar_du_group_put(struct rcar_du_group *rgrp)
>
> static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool
> start) {
> - struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2];
> -
> - rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
> -start ? DSYSR_DEN : DSYSR_DRES);
> + rcar_du_group_write(rgrp, DSYSR,
> + (rcar_du_group_read(rgrp, DSYSR) & ~(DSYSR_DRES |
> DSYSR_DEN)) |
> + (start ? DSYSR_DEN : DSYSR_DRES));
> }
>
> void rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
--
Regards,
Laurent Pinchart
Re: [PATCH 1/5] pinctrl: intel: pinctrl-baytrail: simplify getting .driver_data
On Mon, Oct 22, 2018 at 11:51 AM Mika Westerberg wrote: > On Mon, Oct 22, 2018 at 12:19:51AM +0300, Andy Shevchenko wrote: > > On Sun, Oct 21, 2018 at 10:00:27PM +0200, Wolfram Sang wrote: > > > We should get 'driver_data' from 'struct device' directly. Going via > > > platform_device is an unneeded step back and forth. > > Thanks! > > > > I see only 3 out of 5 patches. > > > > Since we are about to establish a separate tree as well as an additional > > record > > in MAINTAINERS data base for Intel pinctrl driver, I ask you to resend only > > Intel related stuff in a separate series. > > Well, it is easy enough to apply to our tree even if part of larger > series :) So no need to resend anything IMHO. I think it's slightly harder to sort things out for the more complex series, anyway, I'm right now talking to Wolfram and he shared how he did this series. The split is based on records in MAINTAINERS data base, that's why we have non-Intel parts there. Whenever we push new record, this automatically fixes the split. > Looks good to me, > > Acked-by: Mika Westerberg Thanks! -- With Best Regards, Andy Shevchenko
Re: [PATCH] drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
Hi Laurent, On Thu, Oct 11, 2018 at 1:48 PM Daniel Vetter wrote: > > On Mon, Oct 08, 2018 at 09:57:52PM +0530, Souptick Joarder wrote: > > Hi Laurent, > > On Mon, Oct 1, 2018 at 6:12 PM Noralf Trønnes wrote: > > > > > > > > > Den 01.10.2018 13.56, skrev Laurent Pinchart: > > > > Hi Daniel, > > > > > > > > On Monday, 1 October 2018 09:52:20 EEST Daniel Vetter wrote: > > > >> On Fri, Sep 28, 2018 at 06:30:35PM +0300, Laurent Pinchart wrote: > > > >>> On Friday, 28 September 2018 18:05:18 EEST Laurent Pinchart wrote: > > > On Thursday, 27 September 2018 09:34:18 EEST Souptick Joarder wrote: > > > > On Tue, Sep 18, 2018 at 10:05 PM Souptick Joarder wrote: > > > >> convert drm_atomic_helper_suspend/resume() to use > > > >> drm_mode_config_helper_suspend/resume(). > > > >> > > > >> remove suspend_state field from the rcar_du_device > > > >> structure as it is no more required. > > > >> > > > >> With this conversion, also drm_fbdev_cma_set_suspend_unlocked() > > > >> will left with no consumer. So this function can be removed. > > > >> > > > >> Signed-off-by: Souptick Joarder > > > > Laurent, any comment on this patch ?? > > > Sorry for the delay, and thanks for pinging me. > > > > > > Reviewed-by: Laurent Pinchart > > > > > > Should I apply this to my tree or do you plan to merge it through > > > drm-misc > > > as it touches drm_fb_cma_helper.c ? > > > >>> I just realized that the same patch got supplied by Noralf Trønnes > > > >>> nearly > > > >>> a > > > >>> year ago, and was later superseded by > > > >>> https://patchwork.freedesktop.org/patch/247861/. I think we should > > > >>> thus > > > >>> apply Noralf's patches instead (once he sends v4 out). > > > >> I don't think Noralf is still actively working on this, he's busy with > > > >> the > > > >> fbdev emulation stuff. Probably better if you pick up one of the > > > >> existing > > > >> ones, than waiting another year or so :-) > > > > Isn't https://patchwork.freedesktop.org/patch/247861/ part of the fbdev > > > > emulation stuff ? That patch series is from less than a month ago, so I > > > > thought it was actively developed. > > > > > > > > Let's ask him. Noralf, any comment ? :-) > > > > > > I see now that I've caused some confusion here. > > > > > > I did some refactoring of the fbdev stuff in the CMA helper last year. > > > In the last series of that work there is this patch: > > > > > > [v3,07/11] drm/rcar-du: Use drm_mode_config_helper_suspend/resume() > > > https://patchwork.freedesktop.org/patch/192414/ > > > > > > During Christmas I got the idea that maybe it was possible to use a dumb > > > buffer to do generic fbdev emulation. That work took me 6 months before a > > > solution using a general internal DRM client was hammered out. By the > > > time I started to convert drivers I had forgotten about that patch. > > > > > > When I wrote the patch (#247861) to convert rcar to the generic fbdev, I > > > just bundled up the suspend/resume change with the fbdev conversion. > > > Laurent and Sam commented on that bundling, so I said that I would split > > > it up in the next version. > > > > > > All that being said, I think that this patch should be applied and I'll > > > just rebase the rcar fbdev conversion patch on top of that. > > > It's the easiest for me at least :-) > > > > > Any conclusion on this patch ? :-) > > Laurent should pick it up and apply to his rcar-du tree I think. We can > also stuff it into drm-misc as a fallback. Can we get this patch in queue for 4.20 ? > -Daniel > > > > > ers/gpu/drm/drm_fb_cma_helper.c | 18 -- > > > >> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 ++--- > > > >> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 - > > > >> include/drm/drm_fb_cma_helper.h | 2 -- > > > >> 4 files changed, 2 insertions(+), 40 deletions(-) > > > >> > > > >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > > > >> b/drivers/gpu/drm/drm_fb_cma_helper.c index 47e0e2f..96efc88 100644 > > > >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c > > > >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > > > >> @@ -224,21 +224,3 @@ void drm_fbdev_cma_hotplug_event(struct > > > >> drm_fbdev_cma *fbdev_cma) > > > >> > > > >> > > > >> drm_fb_helper_hotplug_event(&fbdev_cma->fb_helper); > > > >> > > > >> } > > > >> EXPORT_SYMBOL_GPL(drm_fbdev_cma_hotplug_event); > > > >> > > > >> - > > > >> -/** > > > >> - * drm_fbdev_cma_set_suspend_unlocked - wrapper around > > > >> - * > > > >> drm_fb_helper_set_suspend_unlocked > > > >> - * @fbdev_cma: The drm_fbdev_cma struct, may be NULL > > > >> - * @state: desired state, zero to resume, non-zero to suspend > > > >> - * > > > >> - * Calls drm_fb_helper_set_suspend, which is a wrapper around > > > >> - * fb_set_suspend implemented by fbdev core. > > >
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Hello!
On 22.10.2018 9:30, Nguyen An Hoan wrote:
From: Hoan Nguyen An
From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to ensure known
initial value"
When you cite an commit, at least 12 digits of SHA1 are needed, and the
summary needs to enclosed in (""), no just "".
We only need to update DSYSR0, DSYSR2 for start/stop. So using rgrp->
mmio_offset is enough,
the change back from rcar_du_crtc -> rcar_du_group -> rcar_du_crtc leading to
mmio addresses for DSYSR may be different.
Signed-off-by: Hoan Nguyen An
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index d85f0a1..a5f7eed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -202,10 +202,9 @@ void rcar_du_group_put(struct rcar_du_group *rgrp)
static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
{
- struct rcar_du_crtc *rcrtc = &rgrp->dev->crtcs[rgrp->index * 2];
-
- rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
- start ? DSYSR_DEN : DSYSR_DRES);
The continuation line indentation style used above is different from yours
below.
would be preferable to keep the existing style...
+ rcar_du_group_write(rgrp, DSYSR,
+ (rcar_du_group_read(rgrp, DSYSR) & ~(DSYSR_DRES |
DSYSR_DEN)) |
+ (start ? DSYSR_DEN : DSYSR_DRES));
}
void rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
MBR, Sergei
Re: [PATCH 3/5] pinctrl: intel: pinctrl-intel: simplify getting .driver_data
On Sun, Oct 21, 2018 at 10:00:29PM +0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Mika Westerberg
Re: [PATCH 2/5] pinctrl: intel: pinctrl-cherryview: simplify getting .driver_data
On Sun, Oct 21, 2018 at 10:00:28PM +0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Mika Westerberg
Re: [PATCH 1/5] pinctrl: intel: pinctrl-baytrail: simplify getting .driver_data
On Mon, Oct 22, 2018 at 12:19:51AM +0300, Andy Shevchenko wrote: > On Sun, Oct 21, 2018 at 10:00:27PM +0200, Wolfram Sang wrote: > > We should get 'driver_data' from 'struct device' directly. Going via > > platform_device is an unneeded step back and forth. > > > > Thanks! > > I see only 3 out of 5 patches. > > Since we are about to establish a separate tree as well as an additional > record > in MAINTAINERS data base for Intel pinctrl driver, I ask you to resend only > Intel related stuff in a separate series. Well, it is easy enough to apply to our tree even if part of larger series :) So no need to resend anything IMHO. Looks good to me, Acked-by: Mika Westerberg
Re: [PATCH 03/03] arm: dts: Include SoC name in DTSI for sh73a0
Hello! 2 patches with the same name? On 21.10.2018 21:21, Magnus Damm wrote: From: Magnus Damm Update the Emma Mobile EV2 DTSI to include product name. Shouldn't this be in the subject instead of sh73a0? Signed-off-by: Magnus Damm [...] MBR, Sergei
Re: [PATCH 5/6] gpio: gpio-tegra: simplify getting .driver_data
On Sun, Oct 21, 2018 at 10:00:00PM +0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. > > drivers/gpio/gpio-tegra.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
