From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m2412.xmail.ntesmail.com (mail-m2412.xmail.ntesmail.com [45.195.24.12]) (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 2C90413D891; Fri, 7 Nov 2025 03:36:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.195.24.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762486598; cv=none; b=aFYK4VISAStqmHkdIVTFLIssXym9RsOtHuKW71f9ZJ08bz1GTd+0VRNlx8lhWFOY5r31SoVGSD30vR8JkFq4fbdgz2Aeu6UD7UDq3fwIFgA2XM1MiD81IpOWjFC1+UsEm4XD6wNHbI57m78fktMIBOgSTW1lVdOJdsa9Cg2Gmt0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762486598; c=relaxed/simple; bh=uhQp4XIMiDylw9wRBxbeocknEojR0/ndrfGwuOyRdX4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=pF+VOv3j9sXPwhvExbxo1dQ71DPLPSzsyuzkhwjJw0tnfGOmLluRQ+OtJNizIVI0JSe90mmxBheSPnc192tSitiRU1mMdiguJvXM5fvQy5GIRs3WExyRvdhLaSsLdP2Pp1F6NFHTuXRHIzhHepCTlXETbd/D/NpYP1LK3riMauI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com; spf=pass smtp.mailfrom=rock-chips.com; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b=N/AjtPdW; arc=none smtp.client-ip=45.195.24.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b="N/AjtPdW" Received: from [172.16.12.129] (unknown [58.22.7.114]) by smtp.qiye.163.com (Hmail) with ESMTP id 28b7d0bc4; Fri, 7 Nov 2025 11:01:05 +0800 (GMT+08:00) Message-ID: Date: Fri, 7 Nov 2025 11:01:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: shawn.lin@rock-chips.com, Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Rob Herring , Bjorn Helgaas , Heiko Stuebner , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Krzysztof Kozlowski , Conor Dooley , Johan Jonker , linux-rockchip@lists.infradead.org Subject: Re: [PATCH] arm64: dts: rockchip: align bindings to PCIe spec To: Geraldo Nascimento , Ye Zhang References: <4b5ffcccfef2a61838aa563521672a171acb27b2.1762321976.git.geraldogabriel@gmail.com> <67b605b0-7046-448a-bc9b-d3ac56333809@rock-chips.com> From: Shawn Lin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9a5c42adf909cckunmd8a05e02f6b7ea X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZQkIaTlYfTkwdH0JKSxgYSE1WFRQJFh oXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0 hVSktLVUpCS0tZBg++ DKIM-Signature: a=rsa-sha256; b=N/AjtPdWxmqb/pFSs6gykwYAJznoZ8eog/K1ggyHgiHswHpN2h06IuYOiipUjuL3fkrH9tNI7iUErn2M+xn58GJHlBeesAuUuwLcF7xohvnZc6VYwGmJh+ip2Ox71RepKsnJaUNoX4XVoE81ZYMa3tVHxJcOI2tPNeo7AAFKCxQ=; c=relaxed/relaxed; s=default; d=rock-chips.com; v=1; bh=zVsNu3y1SfXzBdfw48QrW2mnVPUuj41sgD9Q3ySf0jw=; h=date:mime-version:subject:message-id:from; + Ye Zhang 在 2025/11/07 星期五 10:43, Geraldo Nascimento 写道: > On Wed, Nov 05, 2025 at 04:56:36PM +0800, Shawn Lin wrote: >> 在 2025/11/05 星期三 16:18, Geraldo Nascimento 写道: >>> Hi Shawn, glad to hear from you. >>> >>> Perhaps the following change is better? It resolves the issue >>> without the added complication of open drain. After you questioned >>> if open drain is actually part of the spec, I remembered that >>> GPIO_OPEN_DRAIN is actually (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) >>> so I decided to test with just GPIO_SINGLE_ENDED and it works. > > Shawn, > > I quote from the PCIe Mini Card Electromechanical Specification Rev 1.2 > > "3.4.1. Logic Signal Requirements > > The 3.3V card logic levels for single-ended digital signals (WAKE#, > CLKREQ#, PERST#, and W_DISABLE#) are given in Table 3-7. [...]" > > So while you are correct that PERST# is most definitely not Open Drain, > there's evidence on the spec that defines this signal as Single-Ended. > This's true. But I couldn't find any user in dts using either GPIO_SINGLE_ENDED or GPIO_OPEN_DRAIN for PCIe PERST#. I'm curious how these two flags affect actual behavior of chips. Ye, could you please help check it? > Thanks, > Geraldo Nascimento >