From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 415CCC433EF for ; Mon, 25 Oct 2021 19:37:58 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E53261139 for ; Mon, 25 Oct 2021 19:37:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4E53261139 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 28E8283548; Mon, 25 Oct 2021 21:37:55 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.b="CffzUvfl"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 09E6483537; Mon, 25 Oct 2021 21:37:53 +0200 (CEST) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A14BA83544 for ; Mon, 25 Oct 2021 21:37:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=heinrich.schuchardt@canonical.com Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id CB44E3F320 for ; Mon, 25 Oct 2021 19:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1635190665; bh=eU9eY58zRUenqQ+6BUvYaMlJCNdPsSXZjaVFHZZlGhY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CffzUvfl6OTP+EVcxkXtMIyBrQU9G0RwJHOPVQHcJgMkLXK+2t9lOyYTszP0ml3/B Z9EkveZnQwF0FFcUmE+XdR1khejFB1lLubzntqbipkY0voDZnXr/XuJ5/Qf/XXfzGC /updHrN6Y7MerRbm7ekoaylNvLMS2CxRrgBnZ5A/eAkFltTJaCIe2yf/PyjECHmqyN TALZE2iBkZJjklt2c7Pile+PDqa5TyPZq9Cl3BU5CvVVHbZ06Wfx2NSvIlWkEwCGX6 A5wMRzCLwIw3fJta3W7nFvEtCiuCxv1WE4bUy0IcQZxw+J0p4RWgJ5q+yyvDuFum12 kHnBfTlkVjZyg== Received: by mail-wm1-f70.google.com with SMTP id y141-20020a1c7d93000000b0032cbd531f09so347640wmc.5 for ; Mon, 25 Oct 2021 12:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=eU9eY58zRUenqQ+6BUvYaMlJCNdPsSXZjaVFHZZlGhY=; b=gIqcuswR6+NZDbuKANFhC5NQLHTPCTtnVzdzjQPbps0tfs60eyzGu8K0q2YClEPa6X Ib/EG0lsWyLHDomG/1TDKs097Gc8doYzYh7ZBawpmoBEKliavbL3EZFCszezLv8JO1QB A50Iliop/AkW7LevI9e4SjV0lU4hs/TK2ttP0GZ9tx14772leg2rFoaTx4+s4n8izcoY 9V2EtrBnJ6K/xTZNcYUBEmg9HFxq2nYO0SygIaXzI3334FAiO2ZnXfhEpamfWgDSIvsM AajHDk1YWT/xXut2dJvh6DZ01PrPLc2PmRzwdjU01LQLVKk+3rBW93p4chQctlktZuWG zknA== X-Gm-Message-State: AOAM533+08vLLgdHDLRjvlcA3eFvWSmhKLlRw0UIvVflEHUyMGbpHOZj 1ChlXm5TVsU1nxvFrbyWa8cjVdA5aXumdpRNCUZwsKPp4UDxBr8YjZF87wcYIG11QtGUU+rchrD W57IMHUOV8YVNOQnu7piJkELWWMpNwSQ= X-Received: by 2002:a05:6000:1563:: with SMTP id 3mr26238407wrz.20.1635190665533; Mon, 25 Oct 2021 12:37:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQ/XgaeMVUMfyndoC3p7EJ2f1uCRAg9cEN8I8l5ZvIf706jHYTfmJ22cK0STzlgODekSNtUA== X-Received: by 2002:a05:6000:1563:: with SMTP id 3mr26238380wrz.20.1635190665326; Mon, 25 Oct 2021 12:37:45 -0700 (PDT) Received: from [192.168.123.35] (ip-88-152-144-157.hsi03.unitymediagroup.de. [88.152.144.157]) by smtp.gmail.com with ESMTPSA id i14sm9118384wmb.48.2021.10.25.12.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 12:37:44 -0700 (PDT) Message-ID: <7d082108-7687-2f9a-5a8b-7620573b823f@canonical.com> Date: Mon, 25 Oct 2021 21:37:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename() Content-Language: en-US To: Simon Glass Cc: Patrick Delaunay , Ilias Apalodimas , U-Boot Mailing List , Tom Rini References: <20211023140647.7661-1-heinrich.schuchardt@canonical.com> <81777666-a5e1-b32b-b41e-70d894a44b94@canonical.com> From: Heinrich Schuchardt In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 10/25/21 21:03, Simon Glass wrote: > Hi Heinrich, > > On Mon, 25 Oct 2021 at 12:41, Heinrich Schuchardt > wrote: >> >> >> >> On 10/25/21 19:29, Simon Glass wrote: >>> Hi Heinrich, >>> >>> On Mon, 25 Oct 2021 at 09:44, Heinrich Schuchardt >>> wrote: >>>> >>>> On 10/25/21 17:18, Simon Glass wrote: >>>>> Hi Heinrich, >>>>> >>>>> On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt >>>>> wrote: >>>>>> >>>>>> On 10/25/21 09:54, Heinrich Schuchardt wrote: >>>>>>> On 10/24/21 21:54, Simon Glass wrote: >>>>>>>> Hi Heinrich, >>>>>>>> >>>>>>>> On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> The block descriptor contains the if_type. There is no need to first >>>>>>>>> look >>>>>>>>> up the uclass for the if_type and then to check the parent device's >>>>>>>>> uclass >>>>>>>>> to know if the device has the correct if_type. >>>>>>>>> >>>>>>>>> Signed-off-by: Heinrich Schuchardt >>>>>>>>> --- >>>>>>>>> drivers/block/blk-uclass.c | 35 +---------------------------------- >>>>>>>>> 1 file changed, 1 insertion(+), 34 deletions(-) >>>>>>>> >>>>>>>> This seems to be heading in the wrong direction though. >>>>>>>> >>>>>>>> The IF_TYPE should really go away and be replaced with the UCLASS ID, >>>>>>>> I think. >>>>>>>> >>>>>>>> At present we have lots of calls to blk_create_device_f() which >>>>>>>> specify the type. I think we should drop the IF_TYPE_.. arg to that >>>>>>>> function and have it figured out from the uclass, in the interim. >>>>>>>> >>>>>>>> But why do we need IF_TYPE now? >>>>>>> >>>>>>> I admit that this patch is just an intermediate step. >>>>>>> >>>>>>> We can replace IF_TYPE by ULASS ID once SPL block devices are always >>>>>>> using the driver model. Have we reached this point yet? I have not seen >>>>>>> drivers/block/blk_legacy.c being deleted. >>>>>> >>>>>> qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of >>>>>> defconfigs requiring drivers/block/blk_legacy.c >>>>> >>>>> Yes, we seem to have BLK on only for MMC and USB, but malta64 (for >>>>> example) uses IDE. >>>>> >>>>> The problem seems to be HAVE_BLOCK_DEVICE which should not be used. >>>>> >>>>> +Tom Rini >>>>> >>>>> Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on BROKEN? >>>>> >>>>>> >>>>>> Best regards >>>>>> >>>>>> Heinrich >>>>>> >>>>>>> >>>>>>> Removing if_type_uclass_id[] is anyway on the right path. >>>>> >>>>> Are you sure? Instead, could we use the uclass ID in more places? >>>> >>>> Yes, you want to get rid of if_type. This means the table will become >>>> obsolete. >>> >>> Yes. >>> >>>> Once the legacy drivers are removed we can replace all occurrences of >>>> if_type by uclass_id. That uclass_id we should not take from blk_desc >>>> but from udevice. >>> >>> How do we get from a blk_desc to a udevice, though? >>> >>> Could you instead look at moving from using blk_desc to using udevice? >>> If we had that, I think I can see your point with this patch. At >>> present, it looks like a backwards step because you are reducing the >>> usage of the uclass and in fact removing it altogether. >>> >>> Can you see what I am getting at? Let's move towards migration >>> incrementally, not destroy the bridges we have built towards the goal. >> >> Once you move from if_type to uclass_id you will simply replace >> >> if (desc->if_type != if_type) >> >> by >> >> if (device_get_uclass_id(dev->uclass->uclass_id) != uclass_id) >> >> Except for this line this patch brings you to the final code. > > device_get_uclass_id() BTW > > But where does uclass_id come from?! You are removing the function > that produces it! In future you will pass uclass_id as parameter instead of if_type because if_type will be replaced by uclass_id! > > How about, instead, you update blk_create_devicef() to drop the > if_type parameter and just use the device's uclass? That would > actually head forwards towards migration, rather than away from it. > > Regards, > Simon >