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 2C2EDC433EF for ; Sat, 13 Nov 2021 09:05:21 +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 00AB6610A1 for ; Sat, 13 Nov 2021 09:05:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 00AB6610A1 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 6F7FF830F2; Sat, 13 Nov 2021 10:05:17 +0100 (CET) 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="JLy15Jwb"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B9ECC830F6; Sat, 13 Nov 2021 10:05:15 +0100 (CET) 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 C9A688307B for ; Sat, 13 Nov 2021 10:05:11 +0100 (CET) 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-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (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 4FA593F179 for ; Sat, 13 Nov 2021 09:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1636794311; bh=IBnnc6yQCTw9oIFRIbprbQgBUZr810fy7ecVaxBhaBs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JLy15JwbhF1dgMDfDahQt5ve6y40SdBv6ZoV0bNf9kNPHTs0zSe45NBEwI26y5HSe kPJE0pF6SmDJv0M1Zwe1z0hWCChEIWo6m9tn6qslO4EG0XoTmPitQ7wMpQ9F8s/Eg7 ZYGG8d6k5WOpH0qC6sISy6QsrIvyQauK1PPmoVpaxgtCE9kHcnlN/8vM6YXN0xOAqC dtH3cnsnPIzoHuXz8JmHTIPcV2hkzUgEnZwwxVLThu4aF7otzZFrQXJNOtNvtO40MO fgwkWpco+DddkTGDV449C7e1ixRIQ3mvqr6b2b+bDNOByXeye6L+1LX0Gt6AiOqF9E 0a1nFQwqdH0pQ== Received: by mail-wm1-f72.google.com with SMTP id b145-20020a1c8097000000b003335872db8dso4807543wmd.2 for ; Sat, 13 Nov 2021 01:05:11 -0800 (PST) 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=IBnnc6yQCTw9oIFRIbprbQgBUZr810fy7ecVaxBhaBs=; b=nLzF2NvDke3ONn9c4sQQAEbnO188tpX6VXhFwursmF5Tdjq+P1F1FXLdSDzQapNNB0 lA4Rtc3pqSZbu/Mtu6jiF9djveOKfzIw1LYpwLC8qCyWFsaCouQCeJEYuahGVzZ0vAAf bk1Tb1SgNLhoGFkABbG0JzQHY64czjnZsh4zvD7wYZLaK1NEr2RiUq/clKpl9JkB1Je7 4Qy5VetHimXCGrGlUgTfkoJTE7LSpvzAWoCDswa+HiFj2EU1xawykVLt7z3ahfKfV7IO e4Cmie3HQwV0mpLjp2Gzz0PgEDhWGM4FG1VpTsLiNd4g2wr3Nq6nxjYUWyDqK1enjj3z gJ5w== X-Gm-Message-State: AOAM532nF3rwXF4qpBh4848y33iPaw9ILeK08C5fkjdSbwW0KNdmLjvK SvB1qOzJ94/0dEeX30TWDe/1btnZ/KOsc9rvW1hEpYP9CvjvGM9TFIi4/TD/18q1Hg7Toby3Aum K0oNwbyVQD9zBnNfDpe2sVK4nAUuaPV8= X-Received: by 2002:a1c:21d7:: with SMTP id h206mr24249854wmh.60.1636794310868; Sat, 13 Nov 2021 01:05:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+8Ol5BB8zSCXHuFmAivUNa/Ws0+vEZg0bHbh41F45FKNCR4XeO1xHf21wOjbocrLi89JQOw== X-Received: by 2002:a1c:21d7:: with SMTP id h206mr24249819wmh.60.1636794310566; Sat, 13 Nov 2021 01:05:10 -0800 (PST) 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 z8sm8319874wrh.54.2021.11.13.01.05.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Nov 2021 01:05:10 -0800 (PST) Message-ID: <4f0e2b9b-77fc-49ac-ff2c-0415b2fd6c36@canonical.com> Date: Sat, 13 Nov 2021 10:05:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 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> <7d082108-7687-2f9a-5a8b-7620573b823f@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.35 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:46, Simon Glass wrote: > Hi Heinrich, > > On Mon, 25 Oct 2021 at 13:37, Heinrich Schuchardt > wrote: >> >> >> >> 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! > > Perhaps we can discuss this on the contributor call as we are not > getting anywhere. > > You are removing the ability to translate between the old value and > the new value, but still using the old value in the function call. I > have already suggested how you could contribute to the migration > effort if you have time. Rather than increasing reliance on if_type, > we should be removing use of it, e.g. dropping it from blk_desc, etc. > > > - Simon > >> >>> >>> 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 >>> Without this patch the following fails: make sandconfig make menuconfig # set CONFIG_EFI_SELFTEST=y make -j$(nproc) ./u-boot -T setenv efi_selftest block device bootefi selftest ls efi 0:1 load efi 0:1 $fdt_addr_r hello.txt Best regards Heinrich