From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pv50p00im-zteg10011501.me.com (pv50p00im-zteg10011501.me.com [17.58.6.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB71716C68D for ; Wed, 28 Aug 2024 10:49:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=17.58.6.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724842146; cv=none; b=RD/Fw6NtcrFDAx3ysDy0k0jn5cw42M6CvuvggMuV7LpmqrR85pdd0OLKH5eBl1YoFwNiv8JqytUdCA/ufgu82OOn54ZFfGx3jUHht9EZwJqbMs99s3Pj12fXMiBNLjVeZiCAq4y7V9GRW/j8MRN9pJ5bGoZPLYvoFOKFzsCEZQo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724842146; c=relaxed/simple; bh=mvIj7j1Gi5H+RISXOAHqN+8KX54lI5r2QeLk9sPA5kU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=uOGfJ/Hc/pd8/Sw67BKx+YnKenF2EbUoaeifg01u65aubIRPfSxcnYUdVOWAH4PBWB6PLM4L9rtNRgoD+/2vq6qwdyB0yyBHxCseyepa5jmLi1adrsDB/XFhUI9ArDsi1fTA1GBzfeiKlhCLpE8DLYSOpcqG+LfNuWWNfrn2qfU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com; spf=pass smtp.mailfrom=icloud.com; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b=oRf35QXl; arc=none smtp.client-ip=17.58.6.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=icloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b="oRf35QXl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1724842144; bh=wahpuMvFPO+NbQtmXheKTK2Adr9fvj/gLQT3gVp6Jfo=; h=Message-ID:Date:MIME-Version:Subject:From:To:Content-Type; b=oRf35QXlR8SF+LXsjxDpJmxAhorRHdG0mG+0Y3M9DaZzsg0j4H7MyzZ0V2RF31nCm i7OmoDxjfcp7nKiIWYZnlvprn9J5HLbdmbd5OTi1KYzNHHOuqjSPoT8IQbS8ezTxus LlZWA/djb916kStb/Am/hnswG3o9r4qfssRtWk/riEm8yUzOxaF4mM4WolIC3Y9iOl oy3yGdET0LrdyZs4y2Eh8XJZPEstXpjpwpIWKkr7cZpbU3PasctVZctBr98XibnNRy YXojWVdVHbpZxhGIkhmsf10CR2qe0rmiq1kq/W93C86XR4lDlXYWkkBfeSraaTS2ME j0FzolEwiaQzg== Received: from [192.168.1.26] (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-zteg10011501.me.com (Postfix) with ESMTPSA id E8F694A04AA; Wed, 28 Aug 2024 10:48:34 +0000 (UTC) Message-ID: <30fd2355-0db0-4d9c-bcfe-88b06b8aaeae@icloud.com> Date: Wed, 28 Aug 2024 18:48:28 +0800 Precedence: bulk X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] cxl/region: Find free cxl decoder by device_for_each_child() From: Zijun Hu To: Jonathan Cameron , Ira Weiny , Dave Jiang Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Davidlohr Bueso , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Takashi Sakamoto , Timur Tabi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, netdev@vger.kernel.org, Zijun Hu References: <20240824-const_dfc_prepare-v3-0-32127ea32bba@quicinc.com> <20240824-const_dfc_prepare-v3-2-32127ea32bba@quicinc.com> <20240827123006.00004527@Huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: tb6HQHC4dIaI-_RmN3abHdv4p45pBAam X-Proofpoint-ORIG-GUID: tb6HQHC4dIaI-_RmN3abHdv4p45pBAam X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-08-28_03,2024-08-27_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 suspectscore=0 clxscore=1015 bulkscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2408280078 On 2024/8/27 19:53, Zijun Hu wrote: > On 2024/8/27 19:30, Jonathan Cameron wrote: >> On Sat, 24 Aug 2024 17:07:44 +0800 >> Zijun Hu wrote: >> >>> From: Zijun Hu >>> >>> To prepare for constifying the following old driver core API: >>> >>> struct device *device_find_child(struct device *dev, void *data, >>> int (*match)(struct device *dev, void *data)); >>> to new: >>> struct device *device_find_child(struct device *dev, const void *data, >>> int (*match)(struct device *dev, const void *data)); >>> >>> The new API does not allow its match function (*match)() to modify >>> caller's match data @*data, but match_free_decoder() as the old API's >>> match function indeed modifies relevant match data, so it is not suitable >>> for the new API any more, solved by using device_for_each_child() to >>> implement relevant finding free cxl decoder function. >>> >>> Suggested-by: Ira Weiny >>> Signed-off-by: Zijun Hu >> This seems to functionally do the same as before. >> > > yes, this change have the same logic as previous existing logic. > >> I'm not sure I like the original code though so a comment inline. >> >>> --- >>> drivers/cxl/core/region.c | 30 ++++++++++++++++++++++++------ >>> 1 file changed, 24 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c >>> index 21ad5f242875..c2068e90bf2f 100644 >>> --- a/drivers/cxl/core/region.c >>> +++ b/drivers/cxl/core/region.c >>> @@ -794,10 +794,15 @@ static size_t show_targetN(struct cxl_region *cxlr, char *buf, int pos) >>> return rc; >>> } >>> >>> +struct cxld_match_data { >>> + int id; >>> + struct device *target_device; >>> +}; >>> + >>> static int match_free_decoder(struct device *dev, void *data) >>> { >>> + struct cxld_match_data *match_data = data; >>> struct cxl_decoder *cxld; >>> - int *id = data; >>> >>> if (!is_switch_decoder(dev)) >>> return 0; >>> @@ -805,17 +810,31 @@ static int match_free_decoder(struct device *dev, void *data) >>> cxld = to_cxl_decoder(dev); >>> >>> /* enforce ordered allocation */ >>> - if (cxld->id != *id) >>> + if (cxld->id != match_data->id) >> >> Why do we carry on in this case? >> Conditions are: >> 1. Start match_data->id == 0 >> 2. First pass cxld->id == 0 (all good) or >> cxld->id == 1 say (and we skip until we match >> on cxld->id == 0 (perhaps on the second child if they are >> ordered (1, 0, 2) etc. >> >> If we skipped and then matched on second child but it was >> already in use (so region set), we will increment match_data->id to 1 >> but never find that as it was the one we skipped. >> >> So this can only work if the children are ordered. >> So if that's the case and the line above is just a sanity check >> on that, it should be noisier (so an error print) and might >> as well fail as if it doesn't match all bets are off. >> > > it seems Ira Weiny also has some concerns related to previous existing > logic as following: > > https://lore.kernel.org/all/66c4a136d9764_2ddc2429435@iweiny-mobl.notmuch/ > "Also for those working on CXL I'm questioning the use of ID here and > the dependence on the id's being added to the parent in order. Is that > a guarantee?" > Hi Jonathan, ira i don't know CXL decoder at all. For your concerns about original logic: is it okay to find a child with the minimal index as shown below ? i would like to submit it as a separate patch if you like it. diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index 21ad5f242875..d10cca02eba8 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -797,21 +797,27 @@ static size_t show_targetN(struct cxl_region *cxlr, char *buf, int pos) static int match_free_decoder(struct device *dev, void *data) { struct cxl_decoder *cxld; - int *id = data; + struct cxl_decoder *target_cxld; + struct device **target_device = data; if (!is_switch_decoder(dev)) return 0; cxld = to_cxl_decoder(dev); - /* enforce ordered allocation */ - if (cxld->id != *id) + if (cxld->region) return 0; - if (!cxld->region) - return 1; + if (!*target_device) { + *target_device = get_device(dev); + return 0; + } - (*id)++; + target_cxld = to_cxl_decoder(*target_device); + if (cxld->id < target_cxld->id) { + put_device(*target_device); + *target_device = get_device(dev); + } return 0; } @@ -839,8 +845,7 @@ cxl_region_find_decoder(struct cxl_port *port, struct cxl_endpoint_decoder *cxled, struct cxl_region *cxlr) { - struct device *dev; - int id = 0; + struct device *dev = NULL; if (port == cxled_to_port(cxled)) return &cxled->cxld; @@ -849,7 +854,7 @@ cxl_region_find_decoder(struct cxl_port *port, dev = device_find_child(&port->dev, &cxlr->params, match_auto_decoder); else - dev = device_find_child(&port->dev, &id, match_free_decoder); + device_for_each_child(&port->dev, &dev, match_free_decoder); if (!dev) return NULL; /* > perhaps, create a new dedicated thread to discuss original design. > >> Jonathan >> >>> return 0; >>> >>> - if (!cxld->region) >>> + if (!cxld->region) { >>> + match_data->target_device = get_device(dev); >>> return 1; >>> + } >>> >>> - (*id)++; >>> + match_data->id++; >>> >>> return 0; >>> } >>> >>> +/* NOTE: need to drop the reference with put_device() after use. */ >>> +static struct device *find_free_decoder(struct device *parent) >>> +{ >>> + struct cxld_match_data match_data = { >>> + .id = 0, >>> + .target_device = NULL, >>> + }; >>> + >>> + device_for_each_child(parent, &match_data, match_free_decoder); >>> + return match_data.target_device; >>> +} >>> + >>> static int match_auto_decoder(struct device *dev, void *data) >>> { >>> struct cxl_region_params *p = data; >>> @@ -840,7 +859,6 @@ cxl_region_find_decoder(struct cxl_port *port, >>> struct cxl_region *cxlr) >>> { >>> struct device *dev; >>> - int id = 0; >>> >>> if (port == cxled_to_port(cxled)) >>> return &cxled->cxld; >>> @@ -849,7 +867,7 @@ cxl_region_find_decoder(struct cxl_port *port, >>> dev = device_find_child(&port->dev, &cxlr->params, >>> match_auto_decoder); >>> else >>> - dev = device_find_child(&port->dev, &id, match_free_decoder); >>> + dev = find_free_decoder(&port->dev); >>> if (!dev) >>> return NULL; >>> /* >>> >> >