Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Vivek Yadav" <vivek.2311@samsung.com>
To:     "'Marc Kleine-Budde'" <mkl@pengutronix.de>
Cc:     <rcsekar@samsung.com>, <wg@grandegger.com>, <davem@davemloft.net>,
        <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
        <pankaj.dubey@samsung.com>, <ravi.patel@samsung.com>,
        <alim.akhtar@samsung.com>, <linux-can@vger.kernel.org>,
        <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
In-Reply-To: <20221025074424.udfltascaqjc6dhs@pengutronix.de>
Subject: RE: [PATCH 4/7] can: mcan: enable peripheral clk to access mram
Date:   Wed, 9 Nov 2022 15:25:01 +0530
Message-ID: <01f301d8f421$5758b8c0$060a2a40$@samsung.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJD6JMFT7t8BSDsfE8Wj4Sh/mZZ1gIQFV+aApEtDMUCdlaOq60ntEFA
Content-Language: en-in
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 105P
DLP-Filter: Pass
References: <20221021095833.62406-1-vivek.2311@samsung.com>
        <CGME20221021102632epcas5p29333840201aacbae42bc90f651ac85cd@epcas5p2.samsung.com>
        <20221021095833.62406-5-vivek.2311@samsung.com>
        <20221025074424.udfltascaqjc6dhs@pengutronix.de>
Precedence: bulk


> -----Original Message-----
> From: Marc Kleine-Budde <mkl=40pengutronix.de>
> Sent: 25 October 2022 13:14
> To: Vivek Yadav <vivek.2311=40samsung.com>
> Cc: rcsekar=40samsung.com; wg=40grandegger.com; davem=40davemloft.net;
> edumazet=40google.com; kuba=40kernel.org; pabeni=40redhat.com;
> pankaj.dubey=40samsung.com; ravi.patel=40samsung.com;
> alim.akhtar=40samsung.com; linux-can=40vger.kernel.org;
> netdev=40vger.kernel.org; linux-kernel=40vger.kernel.org
> Subject: Re: =5BPATCH 4/7=5D can: mcan: enable peripheral clk to access m=
ram
>=20
> 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.
>=20
> 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.
>=20
As per my understanding, we should not remove message ram init from probe b=
ecause if message ram init failed then there will be no=20
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
>=20
Thanks for the review.
> --
> Pengutronix e.K.                 =7C Marc Kleine-Budde           =7C
> Embedded Linux                   =7C https://protect2.fireeye.com/v1/url?=
k=3Dfc7bf79b-
> 9c996ac6-fc7a7cd4-000babd9f1ba-3024ea0d5d83d168&q=3D1&e=3D87d053cd-
> e4ab-41e4-a21b-
> c348747c0ce5&u=3Dhttps%3A%2F%2Fwww.pengutronix.de%2F  =7C
> Vertretung West/Dortmund         =7C Phone: +49-231-2826-924     =7C
> Amtsgericht Hildesheim, HRA 2686 =7C Fax:   +49-5121-206917-5555 =7C