From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (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 EB75F1C9EB3; Tue, 1 Oct 2024 16:06:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727798791; cv=none; b=u5jPDJCe3ZwytreLWrDnjurpGeReZDpobr9RpJikTQpWOfEo/aJzCNQ0MilMgB3uLWXUsV2tiaNGYMzWXhUxUfZFdbNjOujKHJUvKO2Kv4ttZXPjdpJjLA5XnwGGoWfbHNUXpV1wqO3jADRvEYhaEgN25nbpy5Y9YrL6XwatN+U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727798791; c=relaxed/simple; bh=yolmBkz3ljbf7antDyyquX8zhL5x+7PHzQi1hzQFCW8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=onbCrgmAJZbpp2nn6m3iNz819tRMCv2t/tn7LTGC0hdIBMGYqMNq55RgNZjmele3xh5B098UVyl+twujZE9XB7h5WFnRlakiRZRN31qKcKJrpZLxg0WrRZqG/89FlqkNz75TQ2W6J1F9JgdKAfAuU0on5KVbNK0WdxbJLULejNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=LCTKsXvn; arc=none smtp.client-ip=217.70.183.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="LCTKsXvn" Received: by mail.gandi.net (Postfix) with ESMTPSA id 841EE240007; Tue, 1 Oct 2024 16:06:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1727798784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s11bFBgMBVIa6r2QYg0pEn8AS/G0E8C5GTuxI/JostY=; b=LCTKsXvny5ow713Z5B9P3m5gIl1LomlDIIFV4K4NhG9ZBLcsrZszohOY8EoNbHzDZENz7t AiRVmpztdPYhIurAa72idPmj68cfoPNQUSVmMsITFbBMe75bUtPgbyeIVWZ9Yns014jdfH KitzdWIyWXPGVzSdIaInKLapGSt6HIRaYZRqRpmehSGsYezMV6WjVeHyAiEFdx5YV7qSwR B2c0TLSHUKM2eRPTlrAOr3ZqhV7JKhIC1BQa7roOZq8tU1ze9EzTVw3TvDukjKcQZCsD4H usFRtN1AkfU1B1P1FgtxtN6l1cU3iVZD3AlFyXhqXqGdrYDoJDSWkk5CyoEqKA== Date: Tue, 1 Oct 2024 18:06:21 +0200 From: Herve Codina To: Krzysztof Kozlowski Cc: Geert Uytterhoeven , Andy Shevchenko , Simon Horman , Lee Jones , Arnd Bergmann , Derek Kiernan , Dragan Cvetic , Greg Kroah-Hartman , Bjorn Helgaas , Philipp Zabel , Lars Povlsen , Steen Hegelund , Daniel Machon , UNGLinuxDriver@microchip.com, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Saravana Kannan , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Horatiu Vultur , Andrew Lunn , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Allan Nielsen , Luca Ceresoli , Thomas Petazzoni Subject: Re: [PATCH v6 1/7] dt-bindings: reset: microchip,rst: Allow to replace cpu-syscon by an additional reg item Message-ID: <20241001180621.76e497d0@bootlin.com> In-Reply-To: References: <20240930121601.172216-1-herve.codina@bootlin.com> <20240930121601.172216-2-herve.codina@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Sasl: herve.codina@bootlin.com Hi Krystoff, On Tue, 1 Oct 2024 08:43:23 +0200 Krzysztof Kozlowski wrote: > On Mon, Sep 30, 2024 at 02:15:41PM +0200, Herve Codina wrote: > > In the LAN966x PCI device use case, syscon cannot be used as syscon > > devices do not support removal [1]. A syscon device is a core "system" > > device and not a device available in some addon boards and so, it is not > > supposed to be removed. > > That's not accurate. syscon is our own, Linux term which means also > anything exposing set of registers. > > If you need to unload syscons, implement it. syscon is the same resource > as all others so should be handled same way. > > > > > In order to remove the syscon device usage, allow the reset controller > > to have a direct access to the address range it needs to use. > > So you map same address twice? That's not good, because you have no > locking over concurrent register accesses. > I will remove this patch and keep using the syscon node in the next iteration. Best regards, Hervé