linux-kernel - RE: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <00d201cf5ee2$d55c4e90$8014ebb0$%tikhomirov@samsung.com>
Date:	Wed, 23 Apr 2014 19:57:35 +0900
From:	Anton Tikhomirov <av.tikhomirov@...sung.com>
To:	'Vivek Gautam' <gautam.vivek@...sung.com>
Cc:	'Linux USB Mailing List' <linux-usb@...r.kernel.org>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	'Greg KH' <gregkh@...uxfoundation.org>,
	'Alan Stern' <stern@...land.harvard.edu>,
	'Felipe Balbi' <balbi@...com>,
	'Kukjin Kim' <kgene.kim@...sung.com>
Subject: RE: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators

Hi,

> Hi Anton,
> 
> 
> On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
> <av.tikhomirov@...sung.com> wrote:
> > Hello,
> >
> >> -----Original Message-----
> >> From: Vivek Gautam [mailto:gautamvivek1987@...il.com] On Behalf Of
> >> Vivek Gautam
> >> Sent: Monday, April 21, 2014 9:17 PM
> >> To: linux-usb@...r.kernel.org; linux-samsung-soc@...r.kernel.org
> >> Cc: linux-kernel@...r.kernel.org; linux-omap@...r.kernel.org; linux-
> >> arm-kernel@...ts.infradead.org; gregkh@...uxfoundation.org;
> >> stern@...land.harvard.edu; balbi@...com; kgene.kim@...sung.com;
> Vivek
> >> Gautam; Anton Tikhomirov
> >> Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
> >> regulators
> >>
> >> Facilitate getting required 3.3V and 1.0V VDD supply for
> >> DWC3 controller on Exynos.
> >>
> >> With patches for regulators' nodes merged in 3.15:
> >> c8c253f ARM: dts: Add regulator entries to smdk5420
> >> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >>
> >> certain perripherals will now need to ensure that,
> >> they request VDD regulators in their drivers, and enable
> >> them so as to make them working.
> >>
> >> Signed-off-by: Vivek Gautam <gautam.vivek@...sung.com>
> >> Cc: Anton Tikhomirov <av.tikhomirov@...sung.com>
> >> ---
> >>
> >> Based on 'usb-next' branch of Greg's USB tree.
> >> Also cleanly applies on 'next' branch of Balbi's USB tree.
> >>
> >>  drivers/usb/dwc3/dwc3-exynos.c |   51
> >> ++++++++++++++++++++++++++++++++++++++--
> >>  1 file changed, 49 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
> >> exynos.c
> >> index 28c8ad7..c9d9102 100644
> >> --- a/drivers/usb/dwc3/dwc3-exynos.c
> >> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> @@ -27,6 +27,7 @@
> >>  #include <linux/usb/usb_phy_gen_xceiv.h>
> >>  #include <linux/of.h>
> >>  #include <linux/of_platform.h>
> >> +#include <linux/regulator/consumer.h>
> >>
> >>  struct dwc3_exynos {
> >>       struct platform_device  *usb2_phy;
> >> @@ -34,6 +35,8 @@ struct dwc3_exynos {
> >>       struct device           *dev;
> >>
> >>       struct clk              *clk;
> >> +     struct regulator        *vdd33;
> >> +     struct regulator        *vdd10;
> >>  };
> >>
> >>  static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
> >> @@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
> >> platform_device *pdev)
> >>
> >>       clk_prepare_enable(exynos->clk);
> >>
> >> +     exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> >> +     if (IS_ERR(exynos->vdd33)) {
> >> +             ret = PTR_ERR(exynos->vdd33);
> >> +             goto err2;
> >
> > Is regulator property mandatory for dwc3-exynos? If it is not
> > and device tree doesn't provide it, dwc3-exynos driver probe
> shouldn't
> > fail here.
> 
> These are the VDD regulators (from PMIC ldo supplies), in absence of
> which the controller will not be powered up.
> So doesn't it make sense to stop the probe when these are not supplied
> by device tree ?

Agree. Just curious, is there special reason for this change except making
things right?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/