From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 37DCF56458 for ; Thu, 2 May 2024 09:32:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714642369; cv=none; b=OVdfmhzxUIXfXfKMsX7AV8nBsPbVC54GQaUQ/D3MZ/uOLNsfr+x+JdB7HJBfRUCs6GzHdKUk+Nx+z/9qIvGZjNeVG+x3Wxw9A83x16b6PWFMRVOL4GHGBOtQE7JxFiBHY5K9zvf2KBXewBsGddxVuUs7c0GUFEhYYsvS8cjtbuE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714642369; c=relaxed/simple; bh=+KdPWEN16wQ9Tm9ok2b58EnczYYvk8kPtRWjVxLHs/Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H1uStz136EMRsjEHwR6JV5GT63arkfBcFww0cc9ajm4kY0NgYPw/Wyvy+uRPwCbN4SnNSd2TvT9KSkBrQ81stAVaMeczYGdVMI80H3f0a+n+gMQfdqpGJ+e+qL1+N+d4kX4ygmcLRJZIDdFGi0FzXog2+eRU3Gc7jJSFmo1k08M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=DwXyx+W+; arc=none smtp.client-ip=209.85.167.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="DwXyx+W+" Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-3c868e82bf8so2015068b6e.0 for ; Thu, 02 May 2024 02:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1714642367; x=1715247167; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FvW/lnO7fBno/xaBzZIt3Emz2T8DvtxIkgq7/bGwou8=; b=DwXyx+W+pWfnM9wYHa72GjpVprpdBGam9RpvSG9+9kkamynTrgG5bloqc3+pk9W2tq sskWEAHuVKxFm0TbNw1gMKZM91SNaivjTutAcvLnPpj/Ss9Bc+LVEpKrwvGv7ZKG0W1v eNFVjAonGFfNW4CsybtnpF7Bs4L2e6P0cQHH24bP6kcWwDjugSA6nAUkDh2AmFilv7JA nDaST58oFc5APPG4Ej5fWXalQCqYdfKjYvXb3SqgY7sNR0+Ho1OpfO2XdLsCAHGkXtAC UIo29DH2UbgWh17At3cNeflKxUomjy9j0peZjL5/x2l3ms4dd3gY7SzNLtwT1zOMVUhb Ii5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714642367; x=1715247167; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FvW/lnO7fBno/xaBzZIt3Emz2T8DvtxIkgq7/bGwou8=; b=K/zaR7mt7LyHHX5STM2GqCiJ80/2VUqDG8cUDD679oIttmvZJ2lblbaDlAAKT943I8 D5a1PgnNs6YrP4R1+SvEtA052vMM7Ir7vWhyiMwjOn5KKfOQGreTF89bG18qmLmMH3ll ItVgm3Dy+xemkp4928gl3ND45shwFJDxgitSEb5qg63sLxufuXId96y2fCYzXqE2y8tg LEnRFmQ/zkhxLv25pE652GZuu+SBLeCwyF3byEzJbOFxRLGNnvrEd8qz4hy6mt5LJaJt CTD8I+dms1Lgjx8lLBufKdbeQhW042+itSi07xgLcjHWvRGXy5XqCBN7cw/RoPQkcj5r WjTg== X-Forwarded-Encrypted: i=1; AJvYcCUKytt7cOllJrKOp6Qutzlt4e07WEsnGvcjYYuouPVOidChSfl7+TktCiKyHXWPNjqbemweUbEwfTfdjd0DxY3EC5pvJzKB5PGu+L2e X-Gm-Message-State: AOJu0YwmXnljb0tiuJYkwi8sr51w7Nsx2GD77ImeuXgGyovXn4mwh9Jp YYJ0fCP14NYXd2uUHp0V+lOS9fwdBc+3EHVdMNbiIRkwPi3+eQJF3dBVTdMrwek= X-Google-Smtp-Source: AGHT+IF4b+lPGskb1gHK2IpUgfNkpEMYBXho2rUofukPTZVb0za3mVEu5Rsh7KTHfVzjAbIKdeiEtg== X-Received: by 2002:a05:6359:4c9e:b0:18f:673e:fce2 with SMTP id kk30-20020a0563594c9e00b0018f673efce2mr6283164rwc.6.1714642367069; Thu, 02 May 2024 02:32:47 -0700 (PDT) Received: from sunil-laptop ([106.51.190.19]) by smtp.gmail.com with ESMTPSA id l25-20020a63ba59000000b0060795a08227sm692025pgu.37.2024.05.02.02.32.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 May 2024 02:32:46 -0700 (PDT) Date: Thu, 2 May 2024 15:02:33 +0530 From: Sunil V L To: Andy Shevchenko Cc: Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, acpica-devel@lists.linux.dev, Catalin Marinas , Will Deacon , Paul Walmsley , Albert Ou , "Rafael J . Wysocki" , Len Brown , Bjorn Helgaas , Anup Patel , Thomas Gleixner , Samuel Holland , Greg Kroah-Hartman , Jiri Slaby , Robert Moore , Conor Dooley , Andrew Jones , Marc Zyngier , Atish Kumar Patra , Andrei Warkentin , Haibo1 Xu , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= Subject: Re: [PATCH v5 08/17] ACPI: pci_link: Clear the dependencies after probe Message-ID: References: <20240501121742.1215792-9-sunilvl@ventanamicro.com> <20240501165615.GA758227@bhelgaas> Precedence: bulk X-Mailing-List: linux-serial@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, May 02, 2024 at 12:25:35PM +0300, Andy Shevchenko wrote: > On Wed, May 01, 2024 at 11:56:15AM -0500, Bjorn Helgaas wrote: > > On Wed, May 01, 2024 at 05:47:33PM +0530, Sunil V L wrote: > > > RISC-V platforms need to use dependencies between PCI host bridge, Link > > > devices and the interrupt controllers to ensure probe order. The > > > dependency is like below. > > > > > > Interrupt controller <-- Link Device <-- PCI Host bridge. > > > > > > If there is no dependency added between Link device and PCI Host Bridge, > > > then the PCI end points can get probed prior to link device, unable to > > > get mapping for INTx. > > > > > > So, add the link device's HID to dependency honor list and also clear it > > > after its probe. > > > > > > Since this is required only for architectures like RISC-V, enable this > > > code under a new config option and set this only in RISC-V. > > ... > > > > + if (IS_ENABLED(CONFIG_ARCH_ACPI_DEFERRED_GSI)) > > > + acpi_dev_clear_dependencies(device); > > > > This is really a question for Rafael, but it doesn't seem right that > > this completely depends on a config option. > > +1 here, fells like a hack and looks like a hack. > I can remove the config option. I just thought this would probably never required to be called on other architectures. Unless there is an objection, I will remove it in next version. Thanks! Sunil > > Is there a reason this wouldn't work for all architectures, i.e., what > > would happen if you just called acpi_dev_clear_dependencies() > > unconditionally? > > -- > With Best Regards, > Andy Shevchenko > >