Received-SPF: pass (google.com: domain of linux-kernel+bounces-91268-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Frank Li <Frank.li@nxp.com>
CC: Manivannan Sadhasivam <mani@kernel.org>, "imx@lists.linux.dev"
	<imx@lists.linux.dev>, Jingoo Han <jingoohan1@gmail.com>, Gustavo Pimentel
	<gustavo.pimentel@synopsys.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>,
	=?iso-8859-2?Q?Krzysztof_Wilczy=F1ski?= <kw@linux.com>, Rob Herring
	<robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Jon Mason
	<jdmason@kudzu.us>, "open list:PCI DRIVER FOR SYNOPSYS DESIGNWARE"
	<linux-pci@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] PCI: dwc: Fix BAR0 wrong map to iATU6 after root
 complex reinit endpoint
Thread-Topic: [PATCH 1/1] PCI: dwc: Fix BAR0 wrong map to iATU6 after root
 complex reinit endpoint
Thread-Index:
 AQHaMja1NResTHTkFE6//FhBs62b57CwYdiAgABGuYCAAAUWgIB3lVEXgAAW+ICAABG0gIAAHwcA
Date: Mon, 4 Mar 2024 21:04:30 +0000
Message-ID: <ZeY3XqgUf84qAMCL@fedora>
References: <20231219044844.1195294-1-Frank.Li@nxp.com>
 <ZYFrUWM7JXdv7rtb@x1-carbon> <ZYGmpaf18pJgM/qj@lizhi-Precision-Tower-5810>
 <ZYGq6RdCfdhXFF/9@x1-carbon> <20240304084841.GJ2647@thinkpad>
 <ZeX7KDuwLWxwb5Kw@lizhi-Precision-Tower-5810>
 <20240304181005.GF31079@thinkpad>
 <ZeYdV3xMWa0nbz3k@lizhi-Precision-Tower-5810>
In-Reply-To: <ZeYdV3xMWa0nbz3k@lizhi-Precision-Tower-5810>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-2?Q?Yw5HEYzSYzfI65s8oLWgMbc2ooNZwVaLiCwaPQ5/Uqv3H7HyTOn2gxPKcG?=
 =?iso-8859-2?Q?NkQP34xpRyFReXZwTrtCrCQDYLq67YxMJujldDjAsfBar8A4qhGLoIVFSD?=
 =?iso-8859-2?Q?zEHkeaH3Zy4rOwkwsqh7TiVt8I9aE0y3eFHq9gEC2vHuMwRGcCnfZjZpPd?=
 =?iso-8859-2?Q?pl55vU1eDi4vpJtvxnIZG0Eo5QvVWYYpX3bmyho7FhQ1PWM89VrKyPMfPQ?=
 =?iso-8859-2?Q?r9SsYOlDCUgxi9Zljlzx0Ppf/tcUJQGoAGOQA6nBB0+s6ZPaUkQlOgRkyX?=
 =?iso-8859-2?Q?XUh3SkRY+zSnIvG0vxaicT1m8EPg4Nz/5dC8oF29yfH5NausB6eQIPgrtO?=
 =?iso-8859-2?Q?a917ZNzR1N+3OmAHcRYoK3tp4RY9s8q8VesbnE+mFKiAA9hzVZvBW5+7RV?=
 =?iso-8859-2?Q?Wkuol+Z/nvffxVS2A0wQ6O1yG27bg76tIlHWHe5zET0MkYzqhx/OkCQwxR?=
 =?iso-8859-2?Q?oEdu4/HNajW3ikg9fatIY1nfDAzcDY7046nfm0fJKB9USiNW+avK5w53MF?=
 =?iso-8859-2?Q?pyyILr5yz4EjqYrWuosW3n0Q0f9VVkQvQwQff2JJmJEAQP6W/tOJOUelhc?=
 =?iso-8859-2?Q?MbyALXbC22m1WeRCqQ5Qz0Z5W5lDN6B2ef1U3gcPYrl89DpJttBshIWBqd?=
 =?iso-8859-2?Q?3RT+EYJbpMH7ABgoImbDXHEmHmuacRgpni4qGO8u0w/GNHWM2cEr8Sxv5h?=
 =?iso-8859-2?Q?OHN5icIv9szUxoagvKAZ5AEzo7YvJLRiJMJVVBqXZxmC8k7h4X54ZyJRiG?=
 =?iso-8859-2?Q?vrvYAX/HgXOI54uKmQii53UpJx+7OzZIkPPq1MRNLI/7FX1nWW9RoDC5mo?=
 =?iso-8859-2?Q?qlLQLtL7qyCdUu1FM51Js8h9/EBq5uhxqXqrTu9AkOJemJIfRxeFcKroyz?=
 =?iso-8859-2?Q?hjqekeVVcfMzlneUjsFVuwH4pQI1+X9eFF+jv3969LK850k+CZW7/7JFQJ?=
 =?iso-8859-2?Q?T8N3KjT/1tWhib4DfNep+VDrc18ooTt4iKlhmJhBkHQMp3RT/rYbcp8IVz?=
 =?iso-8859-2?Q?p2ODgekq72YvUH5ZxFdv4sWNJUlI6dqMetQH6VxNm/KSiz2PtfsVBCqjVB?=
 =?iso-8859-2?Q?85bc/myQh7AjSBw4589rTkCXgoXynbWt53AP9cfYLANVI5JWIU7aroXwB6?=
 =?iso-8859-2?Q?VLSycFWm6Tr6mul5CIf4VNvRIs7S/B3iLUR5PQBUKu+SwX+PT9ArVL25Uh?=
 =?iso-8859-2?Q?tMWY//BG460PbpFtA5f+842oZInFml+xYwLahGCL5bGKc+Cv03Mjnh/s96?=
 =?iso-8859-2?Q?9VozTTuveE0I32N7G+7EgHTfy6Opw4FHBOuIGRsdgIUW8uLQv8jz3J6yVA?=
 =?iso-8859-2?Q?GE356lFG+iaP1bKWg9VY2X13YDj2/s+nSnSO9t6+we8vAhGygztKO3PcYd?=
 =?iso-8859-2?Q?khEZjc3qEbcj+Rd1QDK0PNDCFuxBaddcFgRNGM9YD/+rmeGtmF+89CImAU?=
 =?iso-8859-2?Q?YMJ74FS18joKFZK4VBExzfbMbakcI/kvdQdNBYbS3MCKWA3W+BC875h0Pm?=
 =?iso-8859-2?Q?xodapHlU7aJnA8BO3HkVW+XOpxQnMVpcLWBk/wiCV/H9cvYQAOTs9Y6sBM?=
 =?iso-8859-2?Q?MEK0+qTcJK51HCXMt4jzLeS3SvNH7+SQmYY1puF8aAYDSRSBZrp9PF5Nvc?=
 =?iso-8859-2?Q?9FTRg9dgLymgO45k29wvkuJJVtQlzar02tsHf90GpJrKLVSnXfKficXw?=
 =?iso-8859-2?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <5124D72B5B2CEE4F86F1CF50DAD77673@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	dDike5KwL2GHiI//p4xjJKL0SuqAyI+0roW8LS9TwWAd4Mcf4eKdO7S66J+PopYB0iWh42o2yyBSQbLkr0OpKwVUBx60v4aHW8UWb1lvXkTpAeazp8q45j+hR12pMDn1xq+U3WzUGrSkZcoX3m8SUmOutoyt4oFSEWMXnwh22vMjC71kWUom50oshfH6W2YRipI2hvFFan5ZQNPmIcMJBfHhWXkCikFXgzxH39YXH34wu4hGBUDwd19sT8DXCAoUOb69bKcc2FqhNjCVeHrPfJWYPink8H3jupmXBGHmthBKt5hSPus/VU5FQ4UhRFODJGTS4oK1DbA2P6AWOSAxuLak+WHjENB9Ty4esobdfei64m9Z+mcy5+cCv+C5I0oax/CPIjpC8HmDhLXStzUhc85JVXSOra71v+1o/x8473RMg+yxKP4tTxhHJNGSpZjPjpm0xHIqUHNEK7iEUjCbH9r4dnUVwZ+xdiXShgVouNWTSlh2pvtkWnsXSx61KhJDwkfjUh/sGw2gK4muSJBZ8iZvPLpNFYXIL5rvrOcmvSOzF2F9qaDGYsUVixoi7JkAkjAh6DRE5rEIi8/fCN26S9I3j0UCiqEDqYtV35DKTJurjgIzhBPnDKCUgmthIvmU
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR04MB8326.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dace8d74-d200-4e18-a79d-08dc3c8eaf7e
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2024 21:04:30.6734
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0GPPovrwFJHQRY7JAvfSsVTrEAhyfpWlGls+HMUd3zyZ6fdUX4xh5oUoi0hN4DgQb6mR4Ei5N3217AX13nmNVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB6398

On Mon, Mar 04, 2024 at 02:13:27PM -0500, Frank Li wrote:
> >=20
> > Niklas's initial suggestion of keeping u8 for the array and 0 as the un=
allocated
> > placeholder sounds good to me. Please use that instead.
> >=20
>=20
> It is impossible to keep u8, because 255 + 1 will 0 for u8. Previously
> Niklas's initial suggestion have not consider this condition. If u8 have =
to
> change to u16 or s16 anyways, I prefer use -1 as free.

Well, to be fair, my suggestion was:
"If we continue to use a u8, and offset the saved value by one,
we will at least be able to support 255-1 =3D=3D 254 iATUs."

But we have this define:
drivers/pci/controller/dwc/pcie-designware.h:#define MAX_IATU_IN 256
(Even if it isn't used anywhere.)

But as ridiculous as it may seem to support that many inbound ranges,
that is the max number of windows supported by the hardware, so why
not just let the driver support the max supported by the hardware?


We are talking about:
struct dw_pcie_ep {
	...
        u8                      bar_to_atu[PCI_STD_NUM_BARS];
	...
}

where PCI_STD_NUM_BARS =3D=3D 6.

And where struct dw_pcie_ep is kzalloced for what I assume is all drivers.

So I'm actually for your idea of changing it to u16, or even unsigned int.

If the code is simplified if we use a u16 or unsigned int (because we don't
need any weird if (val < MAX_IATU_IN - 1) check), then I'm all for it.


What I personally don't like with your patch in $subject,
was that you changed both dw_pcie_ep_clear_bar() to set the "clear value"
to -1, but you also need a
memset(ep->bar_to_atu, -1, sizeof(ep->bar_to_atu)); in dw_pcie_ep_init().


I much prefer to have 0 as the default/unused value, because it will
automatically get set when you do kzalloc().
Seeing a memset -1 just looks a bit hackish to be, but I realize that
it is personal preference.


If it is super important to save 8 bytes from the heap, then I would
even prefer changing the MAX_IATU_IN 256 to something smaller, like
127 or whatever, just as long as we don't need that extra memset -1 :)


Kind regards,
Niklas