Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.62.198 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.62.198; helo=xsj-pvapexch01.xlnx.xilinx.com;
Envelope-to: jacmet@sunsite.dk,
 linux-serial@vger.kernel.org,
 linux-kernel@vger.kernel.org,
 gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/1] tty: serial: uartlite: allow 64 bit address
To:     Greg KH <gregkh@linuxfoundation.org>,
        Lizhi Hou <lizhi.hou@xilinx.com>
CC:     <linux-kernel@vger.kernel.org>, <linux-serial@vger.kernel.org>,
        <jacmet@sunsite.dk>
References: <20211123184506.1184561-1-lizhi.hou@xilinx.com>
 <YZ05/73+BhIANNGF@kroah.com>
From:   Lizhi Hou <lizhi.hou@xilinx.com>
Message-ID: <0e212384-396b-f765-be28-f9319c64b5f7@xilinx.com>
Date:   Tue, 23 Nov 2021 12:12:06 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <YZ05/73+BhIANNGF@kroah.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2021 20:12:07.0666
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b3d5f064-2cc5-4e3e-f92a-08d9aebd8620
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.62.198];Helo=[xsj-pvapexch01.xlnx.xilinx.com]
X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT011.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR02MB4018
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 11/23/21 10:59 AM, Greg KH wrote:
>
> On Tue, Nov 23, 2021 at 10:45:06AM -0800, Lizhi Hou wrote:
>> Fix the uartlite probe failure when it is mapped to address above 4G.
> Fix it how?

Does this detail comment look ok to you?

The base address of uartlite registers could be 64 bit address which is 
from device resource. When ulite_probe() calls ulite_assign(), this 64 
bit address is casted to 32-bit. The fix is to replace "u32" type with 
"phys_addr_t" type for the base address in ulite_assign() argument list.

>
>> Signed-off-by: Lizhi Hou <lizhi.hou@xilinx.com>
> What commit caused this problem?  What commit does this fix?  Should it
> go to stable kernels?

I searched the history. This problem was introduced by 
https://github.com/torvalds/linux/commit/8fa7b6100693e0b648ffd34564f6f41226502a19

And yes, I agree this should go to stable kernels. I will add 
stable@vger.kernel.org to cc list.

>
>> ---
>>   drivers/tty/serial/uartlite.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
>> index d3d9566e5dbd..e1fa52d31474 100644
>> --- a/drivers/tty/serial/uartlite.c
>> +++ b/drivers/tty/serial/uartlite.c
>> @@ -626,7 +626,7 @@ static struct uart_driver ulite_uart_driver = {
>>    *
>>    * Returns: 0 on success, <0 otherwise
>>    */
>> -static int ulite_assign(struct device *dev, int id, u32 base, int irq,
>> +static int ulite_assign(struct device *dev, int id, phys_addr_t base, int irq,
>>                        struct uartlite_data *pdata)
> So you changed the variable type which does what exactly here?

ulite_probe()

    -> ulite_assign(&pdev->dev, id, res->start, irq, pdata)

                                                        ^^^^^^ could be 
64-bit address. Thus "u32 base" may lose the high 32-bit.

Hopefully this makes sense to you. And I can re-submit an updated patch.

Thanks,

Lizhi

>
> thanks,
>
> greg k-h