Message ID | 20221116144305.2317573-3-xiaolei.wang@windriver.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp182031wru; Wed, 16 Nov 2022 06:52:13 -0800 (PST) X-Google-Smtp-Source: AA0mqf4cgFLuqVg6bZk2PK0oIF7kNXfmoHybu21OWTxOZO91XL1N7aKJA1pven9M4fp5Bwwpg6Ph X-Received: by 2002:a17:906:26c3:b0:76c:42b4:dea4 with SMTP id u3-20020a17090626c300b0076c42b4dea4mr17311069ejc.515.1668610332379; Wed, 16 Nov 2022 06:52:12 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1668610332; cv=pass; d=google.com; s=arc-20160816; b=xYajrkp6FJshxn6Klekr7oJGUsvpqnHOey80VWrK5b6TlNVDpLA0NVzzvmsb6EPKX/ XTFrb6TkKo+vaw8c/it/WX6QzAuYZ6WG28vzGv5MeMQs0qTB14gMA/Km1Nx4L4rZgzlp CjhEDa2yyVwpfGXGQBQsdbhYu5jUbCCQH1iNb9nfDwJMBncnTVzO7b60tWvyQy1iMR2r rX1drcqE0JEZ4EbSLp9mJkdbRTT6ssYDC29EqLuoXT1wurDYektFKLNpySr/hGCDu6z7 UuN2sr86kL1N887/GPGAogB67OEJ6r4HC9jjZx0Q6EpqEFhehNqfFZtcqHzf3FRuKIHX w69g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=FAtse1/m/cAi64LDjeXdipPJjsTqNb3WOuY2l/2xTko=; b=lk84kq6xsFncjFunKhpWWk4zcfPL1h34EuwGpSqK8wCLBTSFeu++lWZEl2I7ffyEbt eYgBZFsOvnt2r9r6UK2AeedcOX3iMgLImgg4BX2CFr8oEl3B+/2myJZDEZfaEpv1jjcM VHvv3NOoJjNqJF2zeuCGFDqCIvZIo7PHJA5cdnCddCNtJlZcRh3vqjTgNF3tiarGLt3I XkZEGDARxAGl4Fbv5i218SoXTfYbGWpsgk7F28O57lzPg8BhdXn5fJCCQQxsdH4LnTkM JYK/bM9FgGYUCoHLvxZVvTbTvWR0mBc8Exbo7ttQJVkyXgEXreubdJu+15/nhPTtDEU7 2yAw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@windriver.com header.s=PPS06212021 header.b=rVcjurYr; arc=pass (i=1 spf=pass spfdomain=windriver.com dkim=pass dkdomain=windriver.com dmarc=pass fromdomain=windriver.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=windriver.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hu9-20020a170907a08900b007ae0db0c454si14368468ejc.635.2022.11.16.06.51.47; Wed, 16 Nov 2022 06:52:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@windriver.com header.s=PPS06212021 header.b=rVcjurYr; arc=pass (i=1 spf=pass spfdomain=windriver.com dkim=pass dkdomain=windriver.com dmarc=pass fromdomain=windriver.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=windriver.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233417AbiKPOoG (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 09:44:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230459AbiKPOn7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 09:43:59 -0500 Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C6E43E09C; Wed, 16 Nov 2022 06:43:56 -0800 (PST) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AGCJ9uK002578; Wed, 16 Nov 2022 14:43:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-transfer-encoding : content-type : mime-version; s=PPS06212021; bh=FAtse1/m/cAi64LDjeXdipPJjsTqNb3WOuY2l/2xTko=; b=rVcjurYrcXscGz6U9IoJaBjiFhQxPlrNZfn6CAGwEsKXWjjC8GWSvbez8XyYRH+4ccEG B2Dx5DDaN14ZPk06G12DJHNqSOtn8U6EhPWWdl/8MWCNAYxmt2ftsHY+T/SqXxI7z5VK AtEtUVwGRtTaml/+ZZzgezgbJVgCDdjhdVojPcG0jHmLvHD6+sZN6xQlwMBJ3tyNqeQO C+coVKr/E17MZJX2b+zFwp9nUrXiaSGLgxwDbdNSms8a8i6YthnDERXt8n4QwMjHM9qx MjcomWrYNA9h25iJyEXTWr3HMKxEPJ3DHn+yXUf33lEu7wxqM8DfwgrHWsIm2NvMDVwU QA== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam04lp2042.outbound.protection.outlook.com [104.47.74.42]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3kt2fabd8f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Nov 2022 14:43:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n+V56XjP1Thq7mc9XbnOkrdzmHS4Hsmffw9bJGAm+phrgQjeulxF7+vLJILc7gh0owrkCqNj8KZ3id6WaBGPGbb1+LRsfJktByclp8E5MIZs0XCV+eqoYrTU79NY/iHAiefzpD1+j9kz/XTr4DpeqCwA3hoSkybtDEAInzViJS2I45WK8/u33HY97gsABxG6uGm8EagAykzYH6u63TBAkfh72IrVEgbtUJuDviQ1Kb5npPASSGZKxiMbvUn7ku8oqOaVIRXywGJ05QMUGWjjY4zqzT8Jy394hx5cmLDTsNB7wjF0O8jpgQDVjCcmLzTimERdQDy9Xxk6aue8dZcnmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FAtse1/m/cAi64LDjeXdipPJjsTqNb3WOuY2l/2xTko=; b=a384d8xciC96whulN9UMkIuXu/mOcNaG3upLtm3gip7CzTJSnl5HkMGzxDrazsBzx3m0kpSqgmC24DKKyA37ws2gXehtP5Zdxi2VEQ5k73TSkq+vpcAIYBAQ7cmRatoURtV+2nTK74gIbgvOBYlIQEYZS33pRyYmDML8UI8HQwUnajA81FfsD/V+zezzXGB1QTszOGwy33CCswGGq/jwk3+0+XUJeQws24xrEV6CSK6w+XqapgSgJ7NLD7StP9M9RsEXzlXGPzV5vzHcVkGksa9MUUfGcnmpvV2hU3F5QU2dvndM3k0Gf7HbvPVDh3yTxa3iZQK/abCIpTTNgLREiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from MW5PR11MB5764.namprd11.prod.outlook.com (2603:10b6:303:197::8) by PH8PR11MB6927.namprd11.prod.outlook.com (2603:10b6:510:225::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.17; Wed, 16 Nov 2022 14:43:30 +0000 Received: from MW5PR11MB5764.namprd11.prod.outlook.com ([fe80::d789:b673:44d7:b9b2]) by MW5PR11MB5764.namprd11.prod.outlook.com ([fe80::d789:b673:44d7:b9b2%5]) with mapi id 15.20.5813.018; Wed, 16 Nov 2022 14:43:30 +0000 From: Xiaolei Wang <xiaolei.wang@windriver.com> To: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] net: fec: Create device link between phy dev and mac dev Date: Wed, 16 Nov 2022 22:43:05 +0800 Message-Id: <20221116144305.2317573-3-xiaolei.wang@windriver.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221116144305.2317573-1-xiaolei.wang@windriver.com> References: <20221116144305.2317573-1-xiaolei.wang@windriver.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SL2P216CA0216.KORP216.PROD.OUTLOOK.COM (2603:1096:101:18::11) To MW5PR11MB5764.namprd11.prod.outlook.com (2603:10b6:303:197::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW5PR11MB5764:EE_|PH8PR11MB6927:EE_ X-MS-Office365-Filtering-Correlation-Id: f5aff93e-7193-416a-43e1-08dac7e0edec X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DW4h6YhBsksv6DX/iZsA3b26F+Ph7TwrMCAOnfGLOK/lS4tKjfuxQsBPJ9NDLqCBKTFlzh+syj9sKU9Jkj0Ve7j8Wp5ahrKOClEa8RSnbYIQynli2IpfH3Tordq7zKqHWeuljalqt77oDPENdt762CT0zrkbu/d7N9ogN6Cb7r1M1uKPoHl2wTEbkBS3i9u7wrnjRYJ4EXmupFfgvCJWH+BjPQA0Zd5ZnKupolXCrKPliUxQCKANbL5O1splwI/upsKYhfNMWVidQcTB2KEab3DIpmuvWgdk6W+WlocLBg/jHNcTKt69jhD/EJOgj5vdtdw4Kf2HJVcHUY67gQfW5RVvr4q/vgM9zptyMXg/G4IYVp7dyyQCq0HWljWwwNNECb549Jab10E76O7pwsa1lXc17Nv8To7Pmu4KGCWiglRGwaJ65fKejqgW1XS/LaD60LWJwhUqHVcQbR+reDHuZcCyZzFKT82JdEC4meThakmmJs9UUqmkthBNbHM26yGR8LCiiBR1YctkZZgpEWTiECuQz2szn3wxWUv37AnqDIramZG2SsKqPhNwldFimMi/MUGa6ixhCuJxHnyeazuXDqghM3MpoPKYz9cBeZET4mpXEkwgpzd/vkZGmqulfuiVP7jKDEtKcLFuM/rvyIqyBzmuARzz+z8mN/9Bv4gqbUPQdc70JkRQDTp/Jn7j+xCLzLrYZSAJZoM+/WmVBTTsRcEoZ85FZ6em+FIPjZ3IFxeDiaHBPn9gGbs+zGDzG4e4tAKcF/PAOwLimHF8PW826w== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW5PR11MB5764.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39850400004)(376002)(366004)(346002)(136003)(396003)(451199015)(83380400001)(38350700002)(186003)(2616005)(1076003)(38100700002)(2906002)(8936002)(52116002)(44832011)(6486002)(6666004)(45080400002)(6506007)(26005)(5660300002)(66556008)(66476007)(41300700001)(8676002)(6512007)(66946007)(4326008)(478600001)(316002)(86362001)(36756003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: yrv754TlxHXBFyQjLJmplpMX1gllHkhwPDwL2x7Eet5D5r+LDFItos3JN88wZB5JJ8UDjJiJSJ8MU8355nvWFs5sylxJRVaUXQCe5z2JDd4hxUNr9LKM5VLKt4622QWW1VoTkkLn8WEV74GF3wnFkWGKir5yXHnO0ZYG769EbqezSnc4Y7Wi/WbDxTsWffo68+FsOwqwXhydpCcmcN0mkFfJ/E05YeZ1dF5mUXZLgmEw1H8HJSM17PXsv30dAsOeCawwb/quFLlX8iKgLb0hsuDP7khtlgEB1gULzYjr9VmaRjQdMiDPdMc6/hWYakHLrwjy+fWyQjnKduxQLkJ5QrJxAdx4GRfGBhoOzSJZ2mAYqm3//5+ddSVX6m4xUfljo5eECoP0poToTRSOmreZKpGV2faTygSqtKD89bsC85H51lBOOFHlfo1gRXLUg84iYA9Ac2zUwJU5eUhq1Q0wkNK6eF3QIIUk2lCWnkGtzXkOThIWF9onSEU9FMvarBdHr0d9S19I9w1njY/LGLJSZLy2nnfotve0TQVDdef2sTf7izYDyrXkiL2vq8GkkpGTfwD+g+Jrzzp76EQ/oDFxFEbeYxjIgX1lh954OaNEH6O4QlIvpY7YgASF4IVz7D0IAvE1/TnCscFI89fEVc7G3F/0ZBWp2ZnpG9SxesN/Fr/3NdxUQVSTWdm8yEtlN687Sbm1/FCZ6m+tWOi50n7At80OdK/354U5E09O/tUULQw1kTloxVA3JRtph8VclYf4nBRM58dv1sDliTQANLNYaX5i1DtbeO3NLCQIc86Uh1yzUesH3FDrfyrn6mDXUfn/EkHLAyx1fNXvSZrEddhxdcay5MazquPqpBJfoJU+ej3rkA7kBxyegL4O0eFduHiEr/Ymiv4jVfZgqZwsFeYPPTkNxrO/2ye7wPPSzyxOj+59q6v531JKLS8jna/dhcSTxLxIPvL/+gc1sgjnp9YDGy7v9z9gyFNnngK9RWIEtzm8a1rnRpIKnvjNtk8vFvEwMmQ+pFhK0vWNuSoMRm2G4NuA5QYmVUdQj9Uq+BNAUgcAAhU+PmD2jX/ortJjXnsohWCcFr41D9lxH8KvsP/tbz9IgPwp4FSGb5ZKXzo/cxtE0GHSwGOI57R8jLdN7a6ZBCsfYef8XmmgxAfTTkxbMX0dr2m5s/Ut36F4BxnBLzU4Qy8svzpHhuivdd3gqrDAk3x/lAtow1rS0wwXaAH3yRCd7JPOkQiwiAZ2Wj7xwXgxGGeLRWaXBAfmiaD6dREuosOpgHvar1S7Gq2RJc3TBDJwvv9IaLAK1HgKM8A0ExurCfJsgMD11ofLaXV7JtemZSWJtOmr7Al1eoKxlZIu+iP9SyT67kwoCWRC0rnTyDEhWhm417OL7DHNWho0f1Izg9GsDz61feo4YPHyOj1Yjs8mj+weFDKjbxO+MY9urrsTAgX//jJ7jPPcXaZjoWnsvaW4lXQ6ZrTjMoVS01M0fvMhmGmAmUPo31uwon8cG0/esTvvxpH4+qKFO+C/5PKCS5svSZ0kDQb2EVGJh9L+HBZMql/Rp8k+aCX0ZmojuWyFvLj3qs2QEVWl62BkOhReIlvh0/Nt4icAY/5drPv85A== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5aff93e-7193-416a-43e1-08dac7e0edec X-MS-Exchange-CrossTenant-AuthSource: MW5PR11MB5764.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2022 14:43:30.6507 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jcK89vQqO3x1FzqNub+XQho9qyCVJCMpGER5Pi1MkrIGb4vzGaEYrzsv8UpwUh3L4WFOgEEoMhbPLiPmgkpisxgu9b4US2uKIGFvPi2BhdA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6927 X-Proofpoint-ORIG-GUID: C5ojkrXWFbRji-fFggq-mwCBjN8xKnn3 X-Proofpoint-GUID: C5ojkrXWFbRji-fFggq-mwCBjN8xKnn3 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-16_03,2022-11-16_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=502 mlxscore=0 bulkscore=0 spamscore=0 clxscore=1015 suspectscore=0 phishscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211160102 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749664748050559884?= X-GMAIL-MSGID: =?utf-8?q?1749664748050559884?= |
Series |
Add link between phy dev and mac dev
|
|
Commit Message
xiaolei wang
Nov. 16, 2022, 2:43 p.m. UTC
On imx6sx, there are two fec interfaces, but the external
phys can only be configured by fec0 mii_bus. That means
the fec1 can't work independently, it only work when the
fec0 is active. It is alright in the normal boot since the
fec0 will be probed first. But then the fec0 maybe moved
behind of fec1 in the dpm_list due to various device link.
So in system suspend and resume, we would get the following
warning when configuring the external phy of fec1 via the
fec0 mii_bus due to the inactive of fec0. In order to fix
this issue, we create a device link between phy dev and fec0.
This will make sure that fec0 is always active when fec1
is in active mode.
WARNING: CPU: 0 PID: 24 at drivers/net/phy/phy.c:983 phy_error+0x20/0x68
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:2 Not tainted 6.1.0-rc3-00011-g5aaef24b5c6d-dirty #34
Hardware name: Freescale i.MX6 SoloX (Device Tree)
Workqueue: events_power_efficient phy_state_machine
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x68/0x90
dump_stack_lvl from __warn+0xb4/0x24c
__warn from warn_slowpath_fmt+0x5c/0xd8
warn_slowpath_fmt from phy_error+0x20/0x68
phy_error from phy_state_machine+0x22c/0x23c
phy_state_machine from process_one_work+0x288/0x744
process_one_work from worker_thread+0x3c/0x500
worker_thread from kthread+0xf0/0x114
kthread from ret_from_fork+0x14/0x28
Exception stack(0xf0951fb0 to 0xf0951ff8)
Fixes: 2f664823a470 ("net: phy: at803x: add device tree binding")
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: > On imx6sx, there are two fec interfaces, but the external > phys can only be configured by fec0 mii_bus. That means > the fec1 can't work independently, it only work when the > fec0 is active. It is alright in the normal boot since the > fec0 will be probed first. But then the fec0 maybe moved > behind of fec1 in the dpm_list due to various device link. > So in system suspend and resume, we would get the following > warning when configuring the external phy of fec1 via the > fec0 mii_bus due to the inactive of fec0. In order to fix > this issue, we create a device link between phy dev and fec0. > This will make sure that fec0 is always active when fec1 > is in active mode. > > WARNING: CPU: 0 PID: 24 at drivers/net/phy/phy.c:983 phy_error+0x20/0x68 > Modules linked in: > CPU: 0 PID: 24 Comm: kworker/0:2 Not tainted 6.1.0-rc3-00011-g5aaef24b5c6d-dirty #34 > Hardware name: Freescale i.MX6 SoloX (Device Tree) > Workqueue: events_power_efficient phy_state_machine > unwind_backtrace from show_stack+0x10/0x14 > show_stack from dump_stack_lvl+0x68/0x90 > dump_stack_lvl from __warn+0xb4/0x24c > __warn from warn_slowpath_fmt+0x5c/0xd8 > warn_slowpath_fmt from phy_error+0x20/0x68 > phy_error from phy_state_machine+0x22c/0x23c > phy_state_machine from process_one_work+0x288/0x744 > process_one_work from worker_thread+0x3c/0x500 > worker_thread from kthread+0xf0/0x114 > kthread from ret_from_fork+0x14/0x28 > Exception stack(0xf0951fb0 to 0xf0951ff8) Please add an explanation why you only do this for the FEC? Is this not a problem for any board which has the PHY on an MDIO bus not direct child of the MAC? Andrew
On 11/16/22 07:07, Andrew Lunn wrote: > On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: >> On imx6sx, there are two fec interfaces, but the external >> phys can only be configured by fec0 mii_bus. That means >> the fec1 can't work independently, it only work when the >> fec0 is active. It is alright in the normal boot since the >> fec0 will be probed first. But then the fec0 maybe moved >> behind of fec1 in the dpm_list due to various device link. Humm, but if FEC1 depends upon its PHY to be available by the FEC0 MDIO bus provider, then surely we will need to make sure that FEC0's MDIO bus is always functional, and that includes surviving re-ordering as well as any sort of run-time power management that can occur. >> So in system suspend and resume, we would get the following >> warning when configuring the external phy of fec1 via the >> fec0 mii_bus due to the inactive of fec0. In order to fix >> this issue, we create a device link between phy dev and fec0. >> This will make sure that fec0 is always active when fec1 >> is in active mode. Still not clear to me how the proposed fix works, let alone how it does not leak device links since there is no device_link_del(), also you are going to be creating guaranteed regressions by putting that change in the PHY library. It seems to me that you need to address a more fundamental issue within the FEC driver and how it registers its internal MDIO busses. The device link between the PHY and MAC does have the MDIO bus in between as a device. Have you verified your patch is still needed even with 557d5dc83f6831b4e54d141e9b121850406f9a60 ("net: fec: use mac-managed PHY PM")?
On Wed, Nov 16, 2022 at 03:27:39PM -0800, Florian Fainelli wrote: > On 11/16/22 07:07, Andrew Lunn wrote: > > On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: > > > On imx6sx, there are two fec interfaces, but the external > > > phys can only be configured by fec0 mii_bus. That means > > > the fec1 can't work independently, it only work when the > > > fec0 is active. It is alright in the normal boot since the > > > fec0 will be probed first. But then the fec0 maybe moved > > > behind of fec1 in the dpm_list due to various device link. > > Humm, but if FEC1 depends upon its PHY to be available by the FEC0 MDIO bus > provider, then surely we will need to make sure that FEC0's MDIO bus is > always functional, and that includes surviving re-ordering as well as any > sort of run-time power management that can occur. Runtime PM is solved for the FECs MDIO bus, because there are switches hanging off it, which have their own life cycle independent of the MAC. This is something i had to fix many moons ago, when the FEC would power off the MDIO bus when the interface is admin down, stopping access to the switch. The mdio read and write functions now do run time pm get and put as needed. I've never done suspend/resume with a switch, it is not something needed in the use cases i've covered. > > > So in system suspend and resume, we would get the following > > > warning when configuring the external phy of fec1 via the > > > fec0 mii_bus due to the inactive of fec0. In order to fix > > > this issue, we create a device link between phy dev and fec0. > > > This will make sure that fec0 is always active when fec1 > > > is in active mode. > > Still not clear to me how the proposed fix works, let alone how it does not > leak device links since there is no device_link_del(), also you are going to > be creating guaranteed regressions by putting that change in the PHY > library. The reference leak is bad, but i think phylib is the correct place to fix this general issue. It is not specific to the FEC. There are other boards with dual MAC SoCs and they save a couple of pins by putting both PHYs on one MDIO bus. Having the link should help better represent the device tree so that suspend/resume can do stuff in the right order. Andrew
On 11/16/22 15:57, Andrew Lunn wrote: > On Wed, Nov 16, 2022 at 03:27:39PM -0800, Florian Fainelli wrote: >> On 11/16/22 07:07, Andrew Lunn wrote: >>> On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: >>>> On imx6sx, there are two fec interfaces, but the external >>>> phys can only be configured by fec0 mii_bus. That means >>>> the fec1 can't work independently, it only work when the >>>> fec0 is active. It is alright in the normal boot since the >>>> fec0 will be probed first. But then the fec0 maybe moved >>>> behind of fec1 in the dpm_list due to various device link. >> >> Humm, but if FEC1 depends upon its PHY to be available by the FEC0 MDIO bus >> provider, then surely we will need to make sure that FEC0's MDIO bus is >> always functional, and that includes surviving re-ordering as well as any >> sort of run-time power management that can occur. > > Runtime PM is solved for the FECs MDIO bus, because there are switches > hanging off it, which have their own life cycle independent of the > MAC. This is something i had to fix many moons ago, when the FEC would > power off the MDIO bus when the interface is admin down, stopping > access to the switch. The mdio read and write functions now do run > time pm get and put as needed. > > I've never done suspend/resume with a switch, it is not something > needed in the use cases i've covered. All of the systems with integrated I worked on had to support suspend/resume both with HW maintaining the state, and with HW losing the state because of being powered off. The whole thing is IMHO still not quite well supported upstream if you have applied some configuration more complicated than a bridge or standalone ports. Anyway, this is a topic for another 10 years to come :) > >>>> So in system suspend and resume, we would get the following >>>> warning when configuring the external phy of fec1 via the >>>> fec0 mii_bus due to the inactive of fec0. In order to fix >>>> this issue, we create a device link between phy dev and fec0. >>>> This will make sure that fec0 is always active when fec1 >>>> is in active mode. >> >> Still not clear to me how the proposed fix works, let alone how it does not >> leak device links since there is no device_link_del(), also you are going to >> be creating guaranteed regressions by putting that change in the PHY >> library. > > The reference leak is bad, but i think phylib is the correct place to > fix this general issue. It is not specific to the FEC. There are other > boards with dual MAC SoCs and they save a couple of pins by putting > both PHYs on one MDIO bus. Having the link should help better > represent the device tree so that suspend/resume can do stuff in the > right order. My concern is that we already have had a hard time solving the proper suspend/resume sequence whether the MAC suspends the PHY or the MDIO bus suspends the PHY and throwing device links will either change the ordering in subtle ways, or hopefully just provide the same piece of information we already have via mac_managed_pm. It seems like in Xiaolei's case, the MDIO bus should suspend the PHY and that ought to take care of all dependencies, one would think.
On 11/16/2022 11:07 PM, Andrew Lunn wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: >> On imx6sx, there are two fec interfaces, but the external >> phys can only be configured by fec0 mii_bus. That means >> the fec1 can't work independently, it only work when the >> fec0 is active. It is alright in the normal boot since the >> fec0 will be probed first. But then the fec0 maybe moved >> behind of fec1 in the dpm_list due to various device link. >> So in system suspend and resume, we would get the following >> warning when configuring the external phy of fec1 via the >> fec0 mii_bus due to the inactive of fec0. In order to fix >> this issue, we create a device link between phy dev and fec0. >> This will make sure that fec0 is always active when fec1 >> is in active mode. >> >> WARNING: CPU: 0 PID: 24 at drivers/net/phy/phy.c:983 phy_error+0x20/0x68 >> Modules linked in: >> CPU: 0 PID: 24 Comm: kworker/0:2 Not tainted 6.1.0-rc3-00011-g5aaef24b5c6d-dirty #34 >> Hardware name: Freescale i.MX6 SoloX (Device Tree) >> Workqueue: events_power_efficient phy_state_machine >> unwind_backtrace from show_stack+0x10/0x14 >> show_stack from dump_stack_lvl+0x68/0x90 >> dump_stack_lvl from __warn+0xb4/0x24c >> __warn from warn_slowpath_fmt+0x5c/0xd8 >> warn_slowpath_fmt from phy_error+0x20/0x68 >> phy_error from phy_state_machine+0x22c/0x23c >> phy_state_machine from process_one_work+0x288/0x744 >> process_one_work from worker_thread+0x3c/0x500 >> worker_thread from kthread+0xf0/0x114 >> kthread from ret_from_fork+0x14/0x28 >> Exception stack(0xf0951fb0 to 0xf0951ff8) > Please add an explanation why you only do this for the FEC? Is this > not a problem for any board which has the PHY on an MDIO bus not > direct child of the MAC? Hi Oh, my initial idea is to provide such an interface, we can add links manually in such cases, if it is to solve this type of problem, my idea is to create a link in phy_connect_direct, or is there any better suggestion? thanks xiaolei > > Andrew
On 11/17/2022 8:21 AM, Florian Fainelli wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender > and know the content is safe. > > On 11/16/22 15:57, Andrew Lunn wrote: >> On Wed, Nov 16, 2022 at 03:27:39PM -0800, Florian Fainelli wrote: >>> On 11/16/22 07:07, Andrew Lunn wrote: >>>> On Wed, Nov 16, 2022 at 10:43:05PM +0800, Xiaolei Wang wrote: >>>>> On imx6sx, there are two fec interfaces, but the external >>>>> phys can only be configured by fec0 mii_bus. That means >>>>> the fec1 can't work independently, it only work when the >>>>> fec0 is active. It is alright in the normal boot since the >>>>> fec0 will be probed first. But then the fec0 maybe moved >>>>> behind of fec1 in the dpm_list due to various device link. >>> >>> Humm, but if FEC1 depends upon its PHY to be available by the FEC0 >>> MDIO bus >>> provider, then surely we will need to make sure that FEC0's MDIO bus is >>> always functional, and that includes surviving re-ordering as well >>> as any >>> sort of run-time power management that can occur. >> >> Runtime PM is solved for the FECs MDIO bus, because there are switches >> hanging off it, which have their own life cycle independent of the >> MAC. This is something i had to fix many moons ago, when the FEC would >> power off the MDIO bus when the interface is admin down, stopping >> access to the switch. The mdio read and write functions now do run >> time pm get and put as needed. >> >> I've never done suspend/resume with a switch, it is not something >> needed in the use cases i've covered. > > All of the systems with integrated I worked on had to support > suspend/resume both with HW maintaining the state, and with HW losing > the state because of being powered off. The whole thing is IMHO still > not quite well supported upstream if you have applied some configuration > more complicated than a bridge or standalone ports. Anyway, this is a > topic for another 10 years to come :) > >> >>>>> So in system suspend and resume, we would get the following >>>>> warning when configuring the external phy of fec1 via the >>>>> fec0 mii_bus due to the inactive of fec0. In order to fix >>>>> this issue, we create a device link between phy dev and fec0. >>>>> This will make sure that fec0 is always active when fec1 >>>>> is in active mode. >>> >>> Still not clear to me how the proposed fix works, let alone how it >>> does not >>> leak device links since there is no device_link_del(), also you are >>> going to >>> be creating guaranteed regressions by putting that change in the PHY >>> library. >> >> The reference leak is bad, but i think phylib is the correct place to >> fix this general issue. It is not specific to the FEC. There are other >> boards with dual MAC SoCs and they save a couple of pins by putting >> both PHYs on one MDIO bus. Having the link should help better >> represent the device tree so that suspend/resume can do stuff in the >> right order. > > My concern is that we already have had a hard time solving the proper > suspend/resume sequence whether the MAC suspends the PHY or the MDIO bus > suspends the PHY and throwing device links will either change the > ordering in subtle ways, or hopefully just provide the same piece of > information we already have via mac_managed_pm. > > It seems like in Xiaolei's case, the MDIO bus should suspend the PHY and > that ought to take care of all dependencies, one would think. Hi mac_managed_pm solves the soft reset triggered during aeg. If you modify it back to MDIO bus to suspend phy, you still need to solve the problem of auto-negotiation, thanks xiaolei > -- > Florian >
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index f623c12eaf95..036e1bbafdd2 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3963,6 +3963,9 @@ fec_probe(struct platform_device *pdev) goto failed_stop_mode; phy_node = of_parse_phandle(np, "phy-handle", 0); + if (phy_node) { + phy_mac_link_add(phy_node, ndev); + } if (!phy_node && of_phy_is_fixed_link(np)) { ret = of_phy_register_fixed_link(np); if (ret < 0) {