linux-kernel - RE: [PATCH 4/7] can: mcan: enable peripheral clk to access mram

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: <01f301d8f421$5758b8c0$060a2a40$@samsung.com>
Date:   Wed, 9 Nov 2022 15:25:01 +0530
From:   "Vivek Yadav" <vivek.2311@...sung.com>
To:     "'Marc Kleine-Budde'" <mkl@...gutronix.de>
Cc:     <rcsekar@...sung.com>, <wg@...ndegger.com>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
        <pankaj.dubey@...sung.com>, <ravi.patel@...sung.com>,
        <alim.akhtar@...sung.com>, <linux-can@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 4/7] can: mcan: enable peripheral clk to access mram



> -----Original Message-----
> From: Marc Kleine-Budde <mkl@...gutronix.de>
> Sent: 25 October 2022 13:14
> To: Vivek Yadav <vivek.2311@...sung.com>
> Cc: rcsekar@...sung.com; wg@...ndegger.com; davem@...emloft.net;
> edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com;
> pankaj.dubey@...sung.com; ravi.patel@...sung.com;
> alim.akhtar@...sung.com; linux-can@...r.kernel.org;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 4/7] can: mcan: enable peripheral clk to access mram
> 
> On 21.10.2022 15:28:30, Vivek Yadav wrote:
> > When we try to access the mcan message ram addresses, make sure hclk
> > is not gated by any other drivers or disabled. Enable the clock (hclk)
> > before accessing the mram and disable it after that.
> >
> > This is required in case if by-default hclk is gated.
> 
> From my point of view it makes no sense to init the RAM during probe.
> Can you move the init_ram into the m_can_chip_config() function? The
> clocks should be enabled then.
> 
As per my understanding, we should not remove message ram init from probe because if message ram init failed then there will be no 
Storing of Tx/Rx messages onto message ram, so it's better to confirm write operations onto message ram before CAN communication.

So we can kept init_ram in the probe function only, but we will shift init_ram into m_can_dev_setup function by the time clks are already enabled.
> Marc
> 
Thanks for the review.
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   | https://protect2.fireeye.com/v1/url?k=fc7bf79b-
> 9c996ac6-fc7a7cd4-000babd9f1ba-3024ea0d5d83d168&q=1&e=87d053cd-
> e4ab-41e4-a21b-
> c348747c0ce5&u=https%3A%2F%2Fwww.pengutronix.de%2F  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |