From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (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 DCD533C552E for ; Fri, 24 Apr 2026 15:56:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777046169; cv=none; b=poWdJWWRNBIQX5fsxUklZ/Yrx5SMSZlD1YUc36yM2gjmdaQlli10zuSIPcOuqpcAIQl21Ph9h5Z5tb+/97T3TfYAdKI0rR3oYvQN/YvLINFoSTJZh6FZYcI1MEpp33deUIpwK6AfoN+3yxsHWb3i5fB3caz/qfa3V7JJFYxF0bU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777046169; c=relaxed/simple; bh=8/pA7xf/cW18UNiyVoPNBFYLDRY5aiSy+Q13RphUShg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mmqkeEIWR1aKG0U55n6g/709gqsd6cmx+DcDiKoBa/qhwoe61BGKo6Q+4XjCbrIvJzdS30Os5YDiVUPnLI2n/BfwhOSJBvkroWZGRAoNz6WSvUDqv1TIk4WOjw9DXPorfbUP+tDqZqNgmHeI4Nqxts/FQlj97k7S+JSDLR9OtCM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NZhC0SGd; arc=none smtp.client-ip=209.85.215.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NZhC0SGd" Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-c70c112cb61so5263048a12.0 for ; Fri, 24 Apr 2026 08:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777046167; x=1777650967; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M6apAuausA1UMgxW+RA+bbqT9q3F9cbab1NfTivqhaU=; b=NZhC0SGdXHWnQ15lirxbe7C9HBMFzZXG3eciYRML0F4BmkKSHpfaHS9Aub5fOoZfc7 rPAatT8qS+S9ZU7TekpNFsXU+66mMuAGibTuQlPGd6a0uchnVUGzvLI+wQihFJ3kiLnD NiYUck204rdTtz41xGFuJPPtLWmcpNQ79671hC7xWlF0VcbHJyN2ewFBTnoXUeTbU2Tf h3SeSLiKLL0k19hF7kzFJDQbr+vy+8UzCdq7B+Zb/KRhtkdWlCfaLMWPo+8aSf1gmy9A 4Wo0hW8uub0un4nI4zaNe1NFtMxQ1n0r+8d0v4oVr2xWrR07GW+kk0bmNzcafPwQJdxk vw0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777046167; x=1777650967; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M6apAuausA1UMgxW+RA+bbqT9q3F9cbab1NfTivqhaU=; b=mAhjI55MxZ92iP7zvBnJ9iOv+CCEy3f8QQZenr9XLYesgqBPVvF4li9wGA2BPDAqdn dskpvkVbZSW09nuCXmlMNNNZJE7JcVE7+dKuLx2inPsC/+9O7sZNKHyHi+dUraPefXyW 7cCk7mne1EWsQVORTWvRm6VlIdH4oUJzdplkqCiwzQgQcJvilkiCBTBbzmZpLIUNxcRi 06apkhu1afuJ2Cbc93LOmXrPOseclzwaTIwF8hd/GCGVfPdZeq4vu94rx+qBZvTvwgIv TQEtMGSpP29hoz+nkAg5OeaZJ8xHM/dm6Ok77j9GR1u3eA3SGd+H+goibr8yqV2ss8RI ioWw== X-Forwarded-Encrypted: i=1; AFNElJ8tnvgMXBJ2N74xFJkiemxHoqirXRzUlnCaAWqtWgWsh481XLb/RZ8aHHCDFAnv4FuMz6OAA5+oasF8PzA=@vger.kernel.org X-Gm-Message-State: AOJu0YydM2lbSk4zHVWgpiYWulYrMnGickamW6vdhv84AD7R4sy+vYDk 1e4fazQ0UqvOWeTLmnhWfznNto3Z0Of4pnNzfzUmWNnzortzIrgcFTXA X-Gm-Gg: AeBDiesLlOtBYjPh/UtfJ1g1N/PCgffM/6LMu0kHZvFcJ9Lk6Gdv2ZKJVmkPa4ZdPB1 dDZsGej2zCh1U4T9nO320VF/4GANC8F/rYUOQQBL9AZeYGB6lj3R05dQ6lbT2XUkLSYTNwXfPw/ hG3GLKuShokRw4vahgriyHidxhBltRxMJxCqW2Hn0uEXbbGD3iIHd9ly6Nl+GBc69I42Tz+fJrY w4ORVv7hOejFYw+pL2sPSmOMxRwCAzCwSBoLARGmjqdCFCSww7+XHA8JD2k6fxM0LR80vk+oht+ 1YYNEzxh+VYYoRv17faC/iTrpbwABzKzvo8KkB4ShCC7ZubydlPJp1dAO7aeiY2F+WE5WTJItXu BXMlCARilW7+8IYuo3RoGz/qsQnRYMW8VCe4aETdpoenwf5l4Qz6/4X0yaR9myBLEStiydhVwQ2 wDf64TAPTgU1BFf8KRm8obHINm5uhWEQYDrNcJHH2P0qsRc4EtpqiGwWXnPFOpXgzkBNzI+fUhX lUGG3SKSBBfMkLHHOL5gg== X-Received: by 2002:a05:6a20:9149:b0:3a2:dfb2:f03d with SMTP id adf61e73a8af0-3a2dfb2fe0cmr24796895637.56.1777046167242; Fri, 24 Apr 2026 08:56:07 -0700 (PDT) Received: from [192.168.0.5] (124-218-201-66.cm.dynamic.apol.com.tw. [124.218.201.66]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f8ec037e1sm28692658b3a.54.2026.04.24.08.56.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2026 08:56:06 -0700 (PDT) Message-ID: Date: Fri, 24 Apr 2026 23:56:03 +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 Subject: Re: [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support To: Paolo Abeni , andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bjorn@mork.no Cc: ericwouds@gmail.com, frank-w@public-files.de, daniel@makrotopia.org, lucien.jheng@airoha.com, albert-al.lee@airoha.com References: <20260420134506.35164-1-lucienzx159@gmail.com> <2f6fd850-e187-4e63-9a32-6b4b72c09905@redhat.com> Content-Language: en-US From: "Lucien.Jheng" In-Reply-To: <2f6fd850-e187-4e63-9a32-6b4b72c09905@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Paolo Abeni 於 2026/4/23 下午 07:19 寫道: > On 4/20/26 3:45 PM, Lucien.Jheng wrote: >> AN8811HB needs a MCU soft-reset cycle before firmware loading begins. >> Assert the MCU (hold it in reset) and immediately deassert (release) >> via a dedicated PBUS register pair (0x5cf9f8 / 0x5cf9fc), accessed >> through a registered mdio_device at PHY-addr+8. >> >> Add __air_pbus_reg_write() as a low-level helper taking a struct >> mdio_device *, create and register the PBUS mdio_device in >> an8811hb_probe() and store it in priv->pbusdev, then implement >> an8811hb_mcu_assert() / _deassert() on top of it. Add >> an8811hb_remove() to unregister the PBUS device on teardown. Wire >> both calls into an8811hb_load_firmware() and en8811h_restart_mcu() >> so every firmware load or MCU restart on AN8811HB correctly sequences >> the reset control registers. >> >> Fixes: 0a55766b7711 ("net: phy: air_en8811h: add Airoha AN8811HB support") > The hash is incorrect, should be 5afda1d734ed I will fix it in the next patch. > > [...] >> @@ -254,6 +267,31 @@ static int air_phy_write_page(struct phy_device *phydev, int page) >> return __phy_write(phydev, AIR_EXT_PAGE_ACCESS, page); >> } >> >> +static int __air_pbus_reg_write(struct mdio_device *mdiodev, >> + u32 pbus_reg, u32 pbus_data) >> +{ >> + int ret; >> + >> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_EXT_PAGE_ACCESS, >> + upper_16_bits(pbus_reg)); >> + if (ret < 0) >> + return ret; >> + >> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_ADDR_HIGH, >> + (pbus_reg & GENMASK(15, 6)) >> 6); >> + if (ret < 0) >> + return ret; >> + >> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, >> + (pbus_reg & GENMASK(5, 2)) >> 2, >> + lower_16_bits(pbus_data)); >> + if (ret < 0) >> + return ret; >> + >> + return __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_DATA_HIGH, >> + upper_16_bits(pbus_data)); > Sashiko says: > > Will writing the lower 16 bits before the upper 16 bits cause the > hardware transaction to fire with stale upper data? > The __air_buckpbus_reg_write() helper triggers the 32-bit transaction > using the lower 16 bits as the execution trigger. If this hardware > behaves similarly, should AIR_PBUS_DATA_HIGH be populated before writing > the lower 16 bits? This is an8811hb pbus sequence. Therefore, it doesn't need to be modified. > [...] >> @@ -1175,10 +1281,22 @@ static int an8811hb_probe(struct phy_device *phydev) >> return -ENOMEM; >> phydev->priv = priv; >> >> + mdiodev = mdio_device_create(phydev->mdio.bus, >> + phydev->mdio.addr + EN8811H_PBUS_ADDR_OFFS); > Sashiko says: > > Can this create an out-of-bounds array access if the base PHY address is > high? > The mdio_map array in struct mii_bus has a fixed size of PHY_MAX_ADDR (32). > If phydev->mdio.addr is 24 or higher, adding EN8811H_PBUS_ADDR_OFFS (8) > will result in an address of 32 or more. > Neither mdio_device_create() nor mdio_device_register() validate that > the address is within PHY_MAX_ADDR. When mdiobus_register_device() > executes mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev, could this > write past the end of the array and corrupt adjacent memory? > > /P >