Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
From:   Ricky WU <ricky_wu@realtek.com>
To:     "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
CC:     "arnd@arndb.de" <arnd@arndb.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
        "frank.li@vivo.com" <frank.li@vivo.com>,
        "u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>,
        "yangyingliang@huawei.com" <yangyingliang@huawei.com>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: RE: [PATCH v3 1/2] misc: rtsx: add to support new card reader rts5264
Thread-Topic: [PATCH v3 1/2] misc: rtsx: add to support new card reader
 rts5264
Thread-Index: AQHaAynsmhTs26pH702PHG8h5layhrBUNdwAgAJ4IRA=
Date:   Mon, 23 Oct 2023 03:31:24 +0000
Message-ID: <b31f74462ce240a18652643224e285dd@realtek.com>
References: <121ced554a9e4f4791018e8f6a72d586@realtek.com>
 <2023102153-paramedic-washboard-29e3@gregkh>
In-Reply-To: <2023102153-paramedic-washboard-29e3@gregkh>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Precedence: bulk

> > In order to support new chip rts5264, the definitions of some internal
> > registers and workflow have to be modified.
> 
> That is fine, but that should be a single patch, right?
> 

Sorry maybe about misunderstand, The modifications mentioned here, it talk about
some judgment expressions add "PID 5264" to make judgement in rtsx_pcr.c, 
so only about 30 line modified in rtsx_pcr.c

> > Added rts5264.c rts5264.h for independent functions of the new chip rts5264
> 
> And then add new support in a new patch, this is still too big as one
> patch to attempt to review it properly.  Would you like to review this
> as-is?
> 

Yes, thank you
Because rts5264.c rts5264.h only for rts5264 (new chip).
The past architecture of this driver was like this, and it will good for us to maintain the driver
different chip maybe has different functions and register definitions we used to separate different .c .h


> thanks,
> 
> greg k-h