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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D300FC433F5 for ; Sat, 21 May 2022 09:13:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232193AbiEUJNz (ORCPT ); Sat, 21 May 2022 05:13:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230144AbiEUJNy (ORCPT ); Sat, 21 May 2022 05:13:54 -0400 Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51F3354198; Sat, 21 May 2022 02:13:53 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id 63so3687795uaw.10; Sat, 21 May 2022 02:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xLfza2d9jzWSXETuWGWxHMn70hKxdLj4BEKjI+ZN4KU=; b=oSIMjo+HBdeabEZsbQ2Tknmp8ML4BwyqlGIQbOvpgvEgNmn7vZeTww6VUJqw9sLz37 a3uXXO18DxKzzA8bTJazl+uJ6rFE9nZTMhXdFWl3LJRDhADCRszXzAHbhw1cWIrc+xIi 5jSjPrkpKkJ5hZoNeB86u1oZDgOphLkh7CCZdoO3job5/1ffzcxGIZeQGbQ4xCOax/hl 8yXkFoVSN36VhJ0BsrwsxrHoh183yVltVm39xSwrooDgDtgMPj+JGD/EQQC9AHGOUXbM 4cKbJOwhWlGiH36Xqbe65bsdyQac0gTbpDYYR3w/Qonby0sGWeRtx5Wy0wejprXd1qT7 qibQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xLfza2d9jzWSXETuWGWxHMn70hKxdLj4BEKjI+ZN4KU=; b=fWbFIdo869+PVN6F/yjoP9OjxUNzeKDYfZevgk7cEGYDfYY2unleGqadXYlqbyfPsr Ub8FHB7qPPIE38UPnN0wFg/nnxH9gWlFkzBZ+tt0/G/vGgpYEIenseGP1s4eMoaZXm/A 4tTkImQ31YvdmV6zdQwBhqVawKwKxbLPT6L5xyLuyeq7c+hSnzuTD/Bc86YzXif0ppTF +R5seXbP+v1cydnh1ED+i1QAYSYpr63QXP1gbbYTSaI0ah5u/17KaBwwROCoyCTb8rZR EL5FXo8XsrYHnlJYLubS8mLXbk74m+SJuzArzq2w2F6tWhuNFhtNZWOgr2U05QRSe5vo 9o6A== X-Gm-Message-State: AOAM531HQSLKNRsbV9u0Yf61MqhcVm4rfeLY2pnwvinw/EKW4fQN3Tte sPikxymcTkxWX7u2tJCoYdvOdaaR8bXfkfGgGY4= X-Google-Smtp-Source: ABdhPJyhyvWZH9qrdJngswSfpnin3gAydt0836+qEP+NLvaL1+4syh6qaBPTfW5wDBLc4t4TyTFHx0CWjQq10QuKJUo= X-Received: by 2002:a9f:354f:0:b0:368:c2c0:f2b5 with SMTP id o73-20020a9f354f000000b00368c2c0f2b5mr5086632uao.96.1653124432029; Sat, 21 May 2022 02:13:52 -0700 (PDT) MIME-Version: 1.0 References: <20220518092619.1269111-1-chenhuacai@loongson.cn> <20220518092619.1269111-10-chenhuacai@loongson.cn> <0bae0df1-48ae-d02f-bce4-d1f69acf269e@redhat.com> <256e0b82-5d0f-cf40-87c6-c2505d2a6d3b@redhat.com> <859d5489-9361-3db0-1da4-1417ed2fad6c@redhat.com> <7caec251-20e7-4a8c-93ee-b28558ec580f@redhat.com> In-Reply-To: <7caec251-20e7-4a8c-93ee-b28558ec580f@redhat.com> From: Huacai Chen Date: Sat, 21 May 2022 17:13:45 +0800 Message-ID: Subject: Re: [PATCH V11 09/22] LoongArch: Add boot and setup routines To: Javier Martinez Canillas Cc: Ard Biesheuvel , Huacai Chen , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , Linux Doc Mailing List , Linux Kernel Mailing List , Xuefeng Li , Yanteng Si , Guo Ren , Xuerui Wang , Jiaxun Yang , Stephen Rothwell , linux-efi Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Hi, Javier, On Sat, May 21, 2022 at 5:06 PM Javier Martinez Canillas wrote: > > Hello Huacai, > > On 5/21/22 09:37, Huacai Chen wrote: > > [snip] > > >> > >> A problem with moving to subsys_initcall_sync() is that this will delay > >> more when a display is available in the system, and just to cope up with > >> a corner case (as mentioned the common case is native drivers as module). > > OK, your method seems better, but I think moving to > > subsys_initcall_sync() can make the screen display as early as > > possible. > > > > But it doesn't cover all cases. For example, you will get the same error > if for example your native driver is built-in and efifb built as module. > > So my opinion is that instead of playing with the init call levels, is > just better for you to build your native driver as a module instead of > making it built-in. I mean moving to subsys_initcall_sync() on top of your patchset, not replacing them (Just for display earlier). Huacai > > -- > Best regards, > > Javier Martinez Canillas > Linux Engineering > Red Hat >