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  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]
Date:   Fri, 21 Feb 2020 09:09:18 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Faiz Abbas <faiz_abbas@...com>, Dan Murphy <dmurphy@...com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        linux-can@...r.kernel.org
Cc:     broonie@...nel.org, lgirdwood@...il.com, catalin.marinas@....com,
        mark.rutland@....com, robh+dt@...nel.org, wg@...ndegger.com,
        sriram.dash@...sung.com
Subject: Re: [PATCH v2 2/3] can: m_can: m_can_platform: Add support for
 enabling transceiver

On 2/21/20 8:54 AM, Faiz Abbas wrote:
> Hi Dan,
> 
> On 17/02/20 8:40 pm, Dan Murphy wrote:
>> Faiz
>>
>> On 2/17/20 8:28 AM, Faiz Abbas wrote:
>>> CAN transceivers on some boards have a standby line which can be
>>> toggled to enable/disable the transceiver. Model this as an optional
>>> fixed xceiver regulator.
>>>
>>> Signed-off-by: Faiz Abbas <faiz_abbas@...com>
>>> Acked-by: Sriram Dash <sriram.dash@...sung.com>
>>> ---
>>>   drivers/net/can/m_can/m_can_platform.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/net/can/m_can/m_can_platform.c
>>> b/drivers/net/can/m_can/m_can_platform.c
>>> index 38ea5e600fb8..719468fab507 100644
>>> --- a/drivers/net/can/m_can/m_can_platform.c
>>> +++ b/drivers/net/can/m_can/m_can_platform.c
>>> @@ -6,6 +6,7 @@
>>>   // Copyright (C) 2018-19 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>>     #include <linux/platform_device.h>
>>> +#include <linux/regulator/consumer.h>
>>>     #include "m_can.h"
>>>   @@ -57,6 +58,7 @@ static int m_can_plat_probe(struct platform_device
>>> *pdev)
>>>   {
>>>       struct m_can_classdev *mcan_class;
>>>       struct m_can_plat_priv *priv;
>>> +    struct regulator *reg_xceiver;
>>>       struct resource *res;
>>>       void __iomem *addr;
>>>       void __iomem *mram_addr;
>>> @@ -111,6 +113,10 @@ static int m_can_plat_probe(struct
>>> platform_device *pdev)
>>>         m_can_init_ram(mcan_class);
>>>   +    reg_xceiver = devm_regulator_get_optional(&pdev->dev, "xceiver");
>>> +    if (PTR_ERR(reg_xceiver) == -EPROBE_DEFER)
>>> +        return -EPROBE_DEFER;
>>> +
>>
>> Where is this regulator enabled?
> 
> I have set regulator-boot-on flag in the dt so this didn't require an
> enable.

Please don't do this, please handle it properly.

>> Shouldn't the regulator be managed by runtime PM as well?

If so, then make the runtime pm kconfig option mandatory.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists