Message ID | 20221017162807.1692691-1-sean.anderson@seco.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1539641wrs; Mon, 17 Oct 2022 09:33:23 -0700 (PDT) X-Google-Smtp-Source: AMsMyM45l8GK20kddkz2a7PyHWhM2cQ2o9FVk3+DhF0MBBNJtfHEuCg0P1dSXPXkS4a1OaT3N8wL X-Received: by 2002:a05:6402:34c7:b0:45c:c02c:e256 with SMTP id w7-20020a05640234c700b0045cc02ce256mr11456139edc.198.1666024403272; Mon, 17 Oct 2022 09:33:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1666024403; cv=pass; d=google.com; s=arc-20160816; b=QXw+9DTSYpe7ycTyvJUaPyFZiW4uKSJ3nplSBosoq7DK7w45nnIYlZXRDiAjSJ1fts EUUQORrPrOoPD6jwRrk2bRTwxkPKkc/ebsdqOuaocWbUWnx/Hb22B65PU7DInp2JH0/H Gua4tx2ceUKLiPppT96UMNG3bvIeUl70M51d3Abyl4289BeIpexJS/tm02tXAACR4uW0 H0xEIuowMQRaiGPq3gDz4XM0YuQeX5pM9lUvo1ZShEgk8U60lYjf3hSrEEyO3Etegcwt lJ9zGjCCGRl+FHDd6vZIeyatnzx2omRVY1AhgTmGirFb+1SiRc+VoX/j7ElLWd/lgFo/ Jm5A== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=l02Z7s41/WNVOU8sDakWTlz4mTX9WdW7/RM/RrMiBrg=; b=lizXcKxdxeg/mq9txMyZvsFumpk4YYts1+nXjs9CTFbbg5xI4cQGV1+/K9GES41YpD b8jT0tCNDHmmXobRHmoi/laKkNN4KPbfEUM4Ti+zhm3CcvnyLy0TcXyl8STJIDc7L8Cv LUwiqYcqzG9Dp01M3wgdZBR9cYxFWiSQfmwvFNrGo6vCcpV0rLxf+PjxyKzTww/7GSJS YpTTxkqh6ZucjL1JAGdVFeqP0qbCNUkHNpq0BCkm/11XG+5pc6aGvpO0LcFJR5ovsbS/ 8++TQolCB4A36q2lAyLY8jBU7SWGiA0chL9gDzrowEFGmNYoK3Aqd5cfXfGq3htm6dbd 0VTQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@seco.com header.s=selector1 header.b=YPH5ghlq; arc=pass (i=1 spf=pass spfdomain=seco.com dkim=pass dkdomain=seco.com dmarc=pass fromdomain=seco.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=REJECT sp=REJECT dis=NONE) header.from=seco.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f9-20020a50fe09000000b00458a0aa9216si8348030edt.634.2022.10.17.09.32.57; Mon, 17 Oct 2022 09:33:23 -0700 (PDT) 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=@seco.com header.s=selector1 header.b=YPH5ghlq; arc=pass (i=1 spf=pass spfdomain=seco.com dkim=pass dkdomain=seco.com dmarc=pass fromdomain=seco.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=REJECT sp=REJECT dis=NONE) header.from=seco.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229979AbiJQQ2Y (ORCPT <rfc822;kernel.ruili@gmail.com> + 99 others); Mon, 17 Oct 2022 12:28:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229954AbiJQQ2W (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Oct 2022 12:28:22 -0400 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2080.outbound.protection.outlook.com [40.107.22.80]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3836B6E2EA; Mon, 17 Oct 2022 09:28:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JzY8nm5mC5tsroVr8fxjxejUL5nebKJXDiuLBOxOAM1zfRxiWoSrvwesIkWI02DOWwNK8Sa4FiXObNJoA1sel+44OwZKmya/dwflhgan27oEgi9o7dO+lSYYjMJcionYYkTI4nU64gr80ErvXehegMrAZjsBze0ZiWoHvwLIo9kJZIUuSzQCSENOfZVySKnpCPpRTuIeb6IVYBEF5NAwNGG0iAjIGzvWnTJDLznNRSlqpXDaTgYQ7Y6jhYD01RK2NePmBKjFB9ug+FE42puWH06bJDn7Tvz3Re7/kUpBfQKFar2NWrONVZ348x3qDvLHWq5tdJr8UR0da1+N37L57Q== 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=l02Z7s41/WNVOU8sDakWTlz4mTX9WdW7/RM/RrMiBrg=; b=c1UV35LHU/qRwfBW4ldy4lXcMGUChDpoDGJMolqwvgTVX07fNcfPZK8PmrfWKQ3JIiZS1OjFIuB6AnEvA2GZ4BHS4ho05PcqsdeGRcKIU5m+qe4IHI/M82Xj1st3cnjGDgz605YEWsR9XveLGf6u+GjUzuVr+kozEZmmCKK/mASgCl+f35R9ajSf1jW05n7KiSDe/r5iaEracUK5zNLdLtYBEtdpoNWqVaqQ1VGYFm5Gohs+xFEbUU6FNJgBJomPdGBj2xLV8frRMcZdt9MsdUbQtGgCnWrAmVuKJCvyc9Vlk1ZwBInoDTm9l/XrynIvRnELZKfpuT8XB6LrP/Dv0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=seco.com; dmarc=pass action=none header.from=seco.com; dkim=pass header.d=seco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l02Z7s41/WNVOU8sDakWTlz4mTX9WdW7/RM/RrMiBrg=; b=YPH5ghlqlBYVBiuXnDcbscHMQ1DgA7JZT+IsKY/0J5xBKOrIbaHjxcQw1k8ezG8d31BgeWyJOMKe6HWeGff+cHI0G3IhDfJ/IembAHi+26noVyfjKHcP/DZnlIhfoxD755IfUYv/lIake1FZjqDZTaQacTnWIuLiqQqdmRIKrAGJY1MZfno2/aVxV+F89yL5y1dNT+ltsqXHllGz93E8TKMUIG1A+FLTGWtkuhDFH1sN1nzKzJIrRDGGIdcGNTJl7C2sZsQI8EaNQM/Se8VNwz3zTGDc8kBxpjAhCMdPINSsd5GyIN76ohNmaj9H8KZNP/SMbVNE7YdCAaPE9u2gTg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=seco.com; Received: from DB7PR03MB4972.eurprd03.prod.outlook.com (2603:10a6:10:7d::22) by DB9PR03MB9686.eurprd03.prod.outlook.com (2603:10a6:10:45b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.32; Mon, 17 Oct 2022 16:28:17 +0000 Received: from DB7PR03MB4972.eurprd03.prod.outlook.com ([fe80::204a:de22:b651:f86d]) by DB7PR03MB4972.eurprd03.prod.outlook.com ([fe80::204a:de22:b651:f86d%6]) with mapi id 15.20.5723.033; Mon, 17 Oct 2022 16:28:16 +0000 From: Sean Anderson <sean.anderson@seco.com> To: "David S . Miller" <davem@davemloft.net>, netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Madalin Bucur <madalin.bucur@nxp.com>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Camelia Groza <camelia.groza@nxp.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Sean Anderson <sean.anderson@seco.com> Subject: [PATCH net] net: fman: Use physical address for userspace interfaces Date: Mon, 17 Oct 2022 12:28:06 -0400 Message-Id: <20221017162807.1692691-1-sean.anderson@seco.com> X-Mailer: git-send-email 2.35.1.1320.gc452695387.dirty Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BLAPR03CA0069.namprd03.prod.outlook.com (2603:10b6:208:329::14) To DB7PR03MB4972.eurprd03.prod.outlook.com (2603:10a6:10:7d::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB7PR03MB4972:EE_|DB9PR03MB9686:EE_ X-MS-Office365-Filtering-Correlation-Id: b8e52444-25b7-4610-bfe1-08dab05c986f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nym4jq2lZSl8VVN6YJ5p38bnuQ1Teq+XV8wPcZ+XqjG1IbT321AQ1saz9UAFTS42SdM7uH7rAz3rmVTS+7YdCftTGvO29+ZPcVAVv7/cLfbbPJvi1u4M1Eo5dUmPFxWU0zXxanotjmfPxsfCxeyEe0crSIYL5eRuYEkRjSCzxL9mr/ROH4oXYTRJUfQiyWPrix69HuGLt1/KNSl8LfJRspR/807bgx5ioLgZr09U9uN6ALF5eznKHf+S5Gpg8rcFoYyJrgq4tjhDpTA1Rjs5yVavfYCDB2rJ0N5fCK4SrotDKWtgUt0KQSq0nQqBtlsd+v2oAz8xQ8KYFm9c3Yk7gMRy7yskWYnhqkrvK98MEKU4zcfJQG3IiegMrcVZuBQRU8lOHnYzTSEVCvo28Se79Qj+/2g24u/wApX93JmBiTlP8zVmxBxEFNox0CCluOy6eDF0/Dg/MtR1ok0SxRaAxbIDbMWTOEAiLBIbpVAqSq6QHTCjjTMAB+JmNDsXcXnWRJtJwbkeNllbMXrJiHnm7YdzgbWeEMFrnz4PsJnQ6T3jZ04+7mQPsy2i93GyEHBoPWNL8OzSmxJ788WCz6Mf1qf5PNwDvD1V+9Z0lY7CKhoHTM/eJKkaVWvlnK6g9ghMNbcRDwVpriyUPxMWnqdFbfZq0iWZJXQoAUalrZmvwjLr6l+D0OOQkLgtJ4D//XXM44tJLAv3tjlRUR/ZmAR/DT1vk6Ni5TzaOAt3aaSBxilZLujOqIeYMQ8j5DPKq+GcoiS9Un+n+1ovL4NP6uJ2nw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR03MB4972.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(376002)(39850400004)(346002)(366004)(396003)(136003)(451199015)(6486002)(478600001)(38100700002)(38350700002)(316002)(5660300002)(8936002)(54906003)(4326008)(66946007)(66556008)(83380400001)(8676002)(107886003)(6666004)(41300700001)(6506007)(52116002)(66476007)(86362001)(2616005)(186003)(26005)(1076003)(6512007)(2906002)(36756003)(44832011);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: S/FGjbmDJBY24ChW/QPr3H4oktKCf4X9NBYaFvxwFfgAFeUcPOpygFpJe79klUTyA+rbPDNVlg6frJsKNhkkhcEr2p7rb6WhvA5PQejYNT9z7xK2m1fjP+fZyjkS9hK0jupw48sUY+0QIWVEyPAS4wrSQ9V3bRmo0IkVXAL5mlRAQwb0sHrA1pdndxva4YnGN24GqBnfj73q6rDQ0eqfEbDMAJ/fl+2tBHMlrpUzQQeVUR8fh6uIsgdlY1NDTLI2AiaNqyd2shWCqdyLUaTlFO8EkJyagKzN51rkYgzU0sXu0R8homnE3BrqQYsZNazMRQtvRuG8aUt1b4skNRxPHDvKxb41a/mWBSSGjoaiuMNVG++hcCD6h+WdbKv4AnHGYuo4t9oaHoChi01dqoql0F8xosORZ8OFDYhqBBYzgewZCZWy2prt6RxNZmcmRTklqYcx+UkgO79kLPPX/svLeCRdtHCZ7y4rkWDuH/pvqU3mQISmoh9aSAzgcUe/6ErAlMIDDiuz9/CoGQ0li6IWFF2sLiP6ZvNJdiV+JAkVfLnFc73J1feRXqIg72IO30VBDFf57f3kaCu9qaQ9BGLVTqTZIJHB9h2JKWqWtfs/+R5XBUIOKkAzqPdcwW+/9fLNfo88KMXJ0ZoT44cZyu472aT2EZJVGcaoSsa9VcDLa5uanOIN16JL4ha3b1FoXdx6OK6Z9Ynun0SCGfuyQKX71ggGUTzHtvUHDdQ+76Gr6zHFpdug/tjBPSXW5aBiRZRIh6BQd0gqKjyAVevb/s5Cr93yF3hncfAI67bKX1qB8ke6JPKPHJOdkofXj811Pqbl1t2ePBvyjZvrbyvDChV8U1+OCdrD1VUKY/BJJs5pob5z2pXVz/3PiP95DoBUfgaHFhlcbib+IMWHBbR7QuqSy1dGbZSzzI7Fqc0AJG4Ec4pDYkK8ktLJEza+I0xBPU8gpCQ2UITIymYANtN84meVbM7Df9cB1an/xqNcPsLp+LWSh5cocKwM1n2XB/8MPX6YU/o5heQY6ehzr1LQtG3YWJKMREB0DH2wCLVFDk6ulcJ2PT7OKSciTpBJu4RKkcTOEfVpHBH61twm4s/m8Xo1lv/YG+H1aOPl0VOSKkHY+AF59zdm47QVSIBKh274USjTfoaQtawwbQ9+oL1hzt+nY82MSYYBeSv6+BAxlD9JDUIWyCCyOss7TenIkjnt9nR3Io6eH98Ts+fjzlDk0futNXaDCI0rzywbCNlwIrGPAHCBsiU/54L60W44njt9rqlNxQxOui3+eGb7x8++h8F/qQ2G5CqjODZkxhxwTJvfdLg+IUM7ZEYZN789p2IjV9MTJZx07NzuONQeeMIRvnrwocmpBg3dsu/IypEdSZjfcb64LbQS86iUllwEDg2jxt4O3ymSZeOPMAy5oouNOddot1Bjg2XC4GM4khxXbFv14RbeFk50k6FS2c4BhH8zlSxNO2sM1bl5p0Gnde1lVpK0lEm8hrxMOgmDDVdYR6++WYh/ttRkZ2WcISRyEK8XZkKDENga3Bc3GgKzJulxig93Aal/ArrMTM79ydHl5Kswf9jRssOX6RM5asCpE75n7ydQRTBOeErakdpDkOWL5xIf9A== X-OriginatorOrg: seco.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8e52444-25b7-4610-bfe1-08dab05c986f X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB4972.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2022 16:28:16.8849 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bebe97c3-6438-442e-ade3-ff17aa50e733 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: S5drUY5vkzssriGudQUSAERf9gaIcZl2xs0I2dutr92fA8Pn7io9ROhb2/iMD0YwPEg3C99MJw7vvkfMgzG4dQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9686 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, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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?1746953204741192910?= X-GMAIL-MSGID: =?utf-8?q?1746953204741192910?= |
Series |
[net] net: fman: Use physical address for userspace interfaces
|
|
Commit Message
Sean Anderson
Oct. 17, 2022, 4:28 p.m. UTC
For whatever reason, the address of the MAC is exposed to userspace in
several places. We need to use the physical address for this purpose to
avoid leaking information about the kernel's memory layout, and to keep
backwards compatibility.
Fixes: 262f2b782e25 ("net: fman: Map the base address once")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 ++--
drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c | 2 +-
drivers/net/ethernet/freescale/fman/mac.c | 12 ++++++------
drivers/net/ethernet/freescale/fman/mac.h | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
Comments
> -----Original Message----- > From: Sean Anderson <sean.anderson@seco.com> > Sent: 17 October 2022 19:28 > To: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>; > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; > Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza > <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org>; Sean > Anderson <sean.anderson@seco.com> > Subject: [PATCH net] net: fman: Use physical address for userspace > interfaces > > For whatever reason, the address of the MAC is exposed to userspace in > several places. We need to use the physical address for this purpose to > avoid leaking information about the kernel's memory layout, and to keep > backwards compatibility. > > Fixes: 262f2b782e25 ("net: fman: Map the base address once") > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Sean Anderson <sean.anderson@seco.com> > --- > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 ++-- > drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c | 2 +- > drivers/net/ethernet/freescale/fman/mac.c | 12 ++++++------ > drivers/net/ethernet/freescale/fman/mac.h | 2 +- > 4 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > index 31cfa121333d..fc68a32ce2f7 100644 > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > @@ -221,8 +221,8 @@ static int dpaa_netdev_init(struct net_device *net_dev, > net_dev->netdev_ops = dpaa_ops; > mac_addr = mac_dev->addr; > > - net_dev->mem_start = (unsigned long)mac_dev->vaddr; > - net_dev->mem_end = (unsigned long)mac_dev->vaddr_end; > + net_dev->mem_start = (unsigned long)priv->mac_dev->res->start; > + net_dev->mem_end = (unsigned long)priv->mac_dev->res->end; > > net_dev->min_mtu = ETH_MIN_MTU; > net_dev->max_mtu = dpaa_get_max_mtu(); > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c > b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c > index 258eb6c8f4c0..4fee74c024bd 100644 > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c > @@ -18,7 +18,7 @@ static ssize_t dpaa_eth_show_addr(struct device *dev, > > if (mac_dev) > return sprintf(buf, "%llx", > - (unsigned long long)mac_dev->vaddr); > + (unsigned long long)mac_dev->res->start); > else > return sprintf(buf, "none"); > } > diff --git a/drivers/net/ethernet/freescale/fman/mac.c > b/drivers/net/ethernet/freescale/fman/mac.c > index 7b7526fd7da3..65df308bad97 100644 > --- a/drivers/net/ethernet/freescale/fman/mac.c > +++ b/drivers/net/ethernet/freescale/fman/mac.c > @@ -279,7 +279,6 @@ static int mac_probe(struct platform_device *_of_dev) > struct device_node *mac_node, *dev_node; > struct mac_device *mac_dev; > struct platform_device *of_dev; > - struct resource *res; > struct mac_priv_s *priv; > struct fman_mac_params params; > u32 val; > @@ -338,24 +337,25 @@ static int mac_probe(struct platform_device *_of_dev) > of_node_put(dev_node); > > /* Get the address of the memory mapped registers */ > - res = platform_get_mem_or_io(_of_dev, 0); > - if (!res) { > + mac_dev->res = platform_get_mem_or_io(_of_dev, 0); > + if (!mac_dev->res) { > dev_err(dev, "could not get registers\n"); > return -EINVAL; > } > > - err = devm_request_resource(dev, fman_get_mem_region(priv->fman), > res); > + err = devm_request_resource(dev, fman_get_mem_region(priv->fman), > + mac_dev->res); > if (err) { > dev_err_probe(dev, err, "could not request resource\n"); > return err; > } > > - mac_dev->vaddr = devm_ioremap(dev, res->start, resource_size(res)); > + mac_dev->vaddr = devm_ioremap(dev, mac_dev->res->start, > + resource_size(mac_dev->res)); > if (!mac_dev->vaddr) { > dev_err(dev, "devm_ioremap() failed\n"); > return -EIO; > } > - mac_dev->vaddr_end = mac_dev->vaddr + resource_size(res); > > if (!of_device_is_available(mac_node)) > return -ENODEV; > diff --git a/drivers/net/ethernet/freescale/fman/mac.h > b/drivers/net/ethernet/freescale/fman/mac.h > index b95d384271bd..13b69ca5f00c 100644 > --- a/drivers/net/ethernet/freescale/fman/mac.h > +++ b/drivers/net/ethernet/freescale/fman/mac.h > @@ -20,8 +20,8 @@ struct mac_priv_s; > > struct mac_device { > void __iomem *vaddr; > - void __iomem *vaddr_end; > struct device *dev; > + struct resource *res; > u8 addr[ETH_ALEN]; > struct fman_port *port[2]; > u32 if_support; > -- > 2.35.1.1320.gc452695387.dirty Thanks for the fix, Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: > For whatever reason, the address of the MAC is exposed to userspace in > several places. We need to use the physical address for this purpose to > avoid leaking information about the kernel's memory layout, and to keep > backwards compatibility. How does this keep backwards compatibility? Whatever is in user space using this virtual address expects a virtual address. If it now gets a physical address it will probably do the wrong thing. Unless there is a one to one mapping, and you are exposing virtual addresses anyway. If you are going to break backwards compatibility Maybe it would be better to return 0xdeadbeef? Or 0? Andrew
Hi Andrew, On 10/18/22 1:22 PM, Andrew Lunn wrote: > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: >> For whatever reason, the address of the MAC is exposed to userspace in >> several places. We need to use the physical address for this purpose to >> avoid leaking information about the kernel's memory layout, and to keep >> backwards compatibility. > > How does this keep backwards compatibility? Whatever is in user space > using this virtual address expects a virtual address. If it now gets a > physical address it will probably do the wrong thing. Unless there is > a one to one mapping, and you are exposing virtual addresses anyway. > > If you are going to break backwards compatibility Maybe it would be > better to return 0xdeadbeef? Or 0? > > Andrew > The fixed commit was added in v6.1-rc1 and switched from physical to virtual. So this is effectively a partial revert to the previous behavior (but keeping the other changes). See [1] for discussion. --Sean [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262
On 10/18/22 12:37 PM, Sean Anderson wrote: > Hi Andrew, > > On 10/18/22 1:22 PM, Andrew Lunn wrote: >> On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: >>> For whatever reason, the address of the MAC is exposed to userspace in >>> several places. We need to use the physical address for this purpose to >>> avoid leaking information about the kernel's memory layout, and to keep >>> backwards compatibility. >> >> How does this keep backwards compatibility? Whatever is in user space >> using this virtual address expects a virtual address. If it now gets a >> physical address it will probably do the wrong thing. Unless there is >> a one to one mapping, and you are exposing virtual addresses anyway. >> >> If you are going to break backwards compatibility Maybe it would be >> better to return 0xdeadbeef? Or 0? >> >> Andrew >> > > The fixed commit was added in v6.1-rc1 and switched from physical to > virtual. So this is effectively a partial revert to the previous > behavior (but keeping the other changes). See [1] for discussion. > > --Sean > > [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262 I see it asked in that thread, but not answered. Why are you exposing "physical" addresses to userspace? There should be no reason for that. Andrew
On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote: > On 10/18/22 12:37 PM, Sean Anderson wrote: > > Hi Andrew, > > > > On 10/18/22 1:22 PM, Andrew Lunn wrote: > > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: > > > > For whatever reason, the address of the MAC is exposed to userspace in > > > > several places. We need to use the physical address for this purpose to > > > > avoid leaking information about the kernel's memory layout, and to keep > > > > backwards compatibility. > > > > > > How does this keep backwards compatibility? Whatever is in user space > > > using this virtual address expects a virtual address. If it now gets a > > > physical address it will probably do the wrong thing. Unless there is > > > a one to one mapping, and you are exposing virtual addresses anyway. > > > > > > If you are going to break backwards compatibility Maybe it would be > > > better to return 0xdeadbeef? Or 0? > > > > > > Andrew > > > > > > > The fixed commit was added in v6.1-rc1 and switched from physical to > > virtual. So this is effectively a partial revert to the previous > > behavior (but keeping the other changes). See [1] for discussion. Please don't assume a reviewer has seen the previous discussion. Include the background in the commit message to help such reviewers. > > > > --Sean > > > > [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262 > > I see it asked in that thread, but not answered. Why are you exposing > "physical" addresses to userspace? There should be no reason for that. I don't see anything about needing physical or virtual address in the discussion, or i've missed it. If nobody knows why it is needed, either use an obfusticated value, or remove it all together. If somebody/something does need it, they will report the regression. Andrew
On 10/18/22 5:39 PM, Andrew Lunn wrote: > On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote: >> On 10/18/22 12:37 PM, Sean Anderson wrote: >> > Hi Andrew, >> > >> > On 10/18/22 1:22 PM, Andrew Lunn wrote: >> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: >> > > > For whatever reason, the address of the MAC is exposed to userspace in >> > > > several places. We need to use the physical address for this purpose to >> > > > avoid leaking information about the kernel's memory layout, and to keep >> > > > backwards compatibility. >> > > >> > > How does this keep backwards compatibility? Whatever is in user space >> > > using this virtual address expects a virtual address. If it now gets a >> > > physical address it will probably do the wrong thing. Unless there is >> > > a one to one mapping, and you are exposing virtual addresses anyway. >> > > >> > > If you are going to break backwards compatibility Maybe it would be >> > > better to return 0xdeadbeef? Or 0? >> > > >> > > Andrew >> > > >> > >> > The fixed commit was added in v6.1-rc1 and switched from physical to >> > virtual. So this is effectively a partial revert to the previous >> > behavior (but keeping the other changes). See [1] for discussion. > > Please don't assume a reviewer has seen the previous > discussion. Include the background in the commit message to help such > reviewers. > >> > >> > --Sean >> > >> > [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262 >> >> I see it asked in that thread, but not answered. Why are you exposing >> "physical" addresses to userspace? There should be no reason for that. > > I don't see anything about needing physical or virtual address in the > discussion, or i've missed it. Well, Madalin originally added this, so perhaps she has some insight. I have no idea why we set the IFMAP stuff, since that seems like it's for PCMCIA. Not sure about sysfs either. > If nobody knows why it is needed, either use an obfusticated value, or > remove it all together. If somebody/something does need it, they will > report the regression. I'd rather apply this (or v2 of this) and then remove the "feature" in follow-up. --Sean
> -----Original Message----- > From: Sean Anderson <sean.anderson@seco.com> > Sent: 19 October 2022 00:47 > To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com> > Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>; > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; > Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza > <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org> > Subject: Re: [PATCH net] net: fman: Use physical address for userspace > interfaces > > > > On 10/18/22 5:39 PM, Andrew Lunn wrote: > > On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote: > >> On 10/18/22 12:37 PM, Sean Anderson wrote: > >> > Hi Andrew, > >> > > >> > On 10/18/22 1:22 PM, Andrew Lunn wrote: > >> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: > >> > > > For whatever reason, the address of the MAC is exposed to > userspace in > >> > > > several places. We need to use the physical address for this > purpose to > >> > > > avoid leaking information about the kernel's memory layout, and > to keep > >> > > > backwards compatibility. > >> > > > >> > > How does this keep backwards compatibility? Whatever is in user > space > >> > > using this virtual address expects a virtual address. If it now > gets a > >> > > physical address it will probably do the wrong thing. Unless there > is > >> > > a one to one mapping, and you are exposing virtual addresses > anyway. > >> > > > >> > > If you are going to break backwards compatibility Maybe it would > be > >> > > better to return 0xdeadbeef? Or 0? > >> > > > >> > > Andrew > >> > > > >> > > >> > The fixed commit was added in v6.1-rc1 and switched from physical to > >> > virtual. So this is effectively a partial revert to the previous > >> > behavior (but keeping the other changes). See [1] for discussion. > > > > Please don't assume a reviewer has seen the previous > > discussion. Include the background in the commit message to help such > > reviewers. > > > >> > > >> > --Sean > >> > > >> > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Fnetdev%2F20220902215737.981341-1- > sean.anderson%40seco.com%2FT%2F%23md5c6b66bc229c09062d205352a7d127c02b8d2 > 62&data=05%7C01%7Cmadalin.bucur%40nxp.com%7Cb35d8b37f9224e4b793408dab > 1525b5a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638017264524356126%7 > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BcoXaNNlcqzKLsGC5WKuk8Mwette > D51cCbzJvHfG7Vs%3D&reserved=0 > >> > >> I see it asked in that thread, but not answered. Why are you exposing > >> "physical" addresses to userspace? There should be no reason for that. > > > > I don't see anything about needing physical or virtual address in the > > discussion, or i've missed it. > > Well, Madalin originally added this, so perhaps she has some insight. > > I have no idea why we set the IFMAP stuff, since that seems like it's for > PCMCIA. Not sure about sysfs either. > > > If nobody knows why it is needed, either use an obfusticated value, or > > remove it all together. If somebody/something does need it, they will > > report the regression. > > I'd rather apply this (or v2 of this) and then remove the "feature" in > follow-up. > > --Sean root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1" SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2" SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3" SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4" SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5" SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6" root@localhost:~# grep 1ae /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000 /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000 /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000 /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000 Have a great day! Madalin
Hi Madalin, On Wed, Oct 19, 2022 at 7:20 AM Madalin Bucur <madalin.bucur@nxp.com> wrote: > > -----Original Message----- > > From: Sean Anderson <sean.anderson@seco.com> > > Sent: 19 October 2022 00:47 > > To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com> > > Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org; > > linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>; > > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; > > Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza > > <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org> > > Subject: Re: [PATCH net] net: fman: Use physical address for userspace > > interfaces > > > > > > > > On 10/18/22 5:39 PM, Andrew Lunn wrote: > > > On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote: > > >> On 10/18/22 12:37 PM, Sean Anderson wrote: > > >> > Hi Andrew, > > >> > > > >> > On 10/18/22 1:22 PM, Andrew Lunn wrote: > > >> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: > > >> > > > For whatever reason, the address of the MAC is exposed to > > userspace in > > >> > > > several places. We need to use the physical address for this > > purpose to > > >> > > > avoid leaking information about the kernel's memory layout, and > > to keep > > >> > > > backwards compatibility. > > >> > > > > >> > > How does this keep backwards compatibility? Whatever is in user > > space > > >> > > using this virtual address expects a virtual address. If it now > > gets a > > >> > > physical address it will probably do the wrong thing. Unless there > > is > > >> > > a one to one mapping, and you are exposing virtual addresses > > anyway. > > >> > > > > >> > > If you are going to break backwards compatibility Maybe it would > > be > > >> > > better to return 0xdeadbeef? Or 0? > > >> > > > > >> > > Andrew > > >> > > > > >> > > > >> > The fixed commit was added in v6.1-rc1 and switched from physical to > > >> > virtual. So this is effectively a partial revert to the previous > > >> > behavior (but keeping the other changes). See [1] for discussion. > > > > > > Please don't assume a reviewer has seen the previous > > > discussion. Include the background in the commit message to help such > > > reviewers. > > >> I see it asked in that thread, but not answered. Why are you exposing > > >> "physical" addresses to userspace? There should be no reason for that. > > > > > > I don't see anything about needing physical or virtual address in the > > > discussion, or i've missed it. > > > > Well, Madalin originally added this, so perhaps she has some insight. > > > > I have no idea why we set the IFMAP stuff, since that seems like it's for > > PCMCIA. Not sure about sysfs either. > > > > > If nobody knows why it is needed, either use an obfusticated value, or > > > remove it all together. If somebody/something does need it, they will > > > report the regression. > > > > I'd rather apply this (or v2 of this) and then remove the "feature" in > > follow-up. > > > > --Sean > > > root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1" > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2" > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3" > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4" > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5" > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6" So you rely on the physical address. It's a pity this uses a custom sysfs file. Can't you obtain this information some other way? Anyway, as this is in use, it became part of the ABI. > root@localhost:~# grep 1ae /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr > /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000 > /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000 > /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000 > /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
> > root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1" > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2" > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3" > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4" > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5" > > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6" > > So you rely on the physical address. > It's a pity this uses a custom sysfs file. > Can't you obtain this information some other way? > Anyway, as this is in use, it became part of the ABI. I agree about the ABI thing. Please add this to the commit messages as a justification. It would also be good to move user space away from this. You should be able to use the port id in the place of the physical address. That is what is used by Ethernet switches etc, in the udev rules for giving switch ports names. Andrew
On 10/19/22 02:46, Geert Uytterhoeven wrote: > Hi Madalin, > > On Wed, Oct 19, 2022 at 7:20 AM Madalin Bucur <madalin.bucur@nxp.com> wrote: >>> -----Original Message----- >>> From: Sean Anderson <sean.anderson@seco.com> >>> Sent: 19 October 2022 00:47 >>> To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com> >>> Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org; >>> linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>; >>> Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; >>> Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza >>> <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org> >>> Subject: Re: [PATCH net] net: fman: Use physical address for userspace >>> interfaces >>> >>> >>> >>> On 10/18/22 5:39 PM, Andrew Lunn wrote: >>>> On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote: >>>>> On 10/18/22 12:37 PM, Sean Anderson wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> On 10/18/22 1:22 PM, Andrew Lunn wrote: >>>>>>> On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote: >>>>>>>> For whatever reason, the address of the MAC is exposed to >>> userspace in >>>>>>>> several places. We need to use the physical address for this >>> purpose to >>>>>>>> avoid leaking information about the kernel's memory layout, and >>> to keep >>>>>>>> backwards compatibility. >>>>>>> >>>>>>> How does this keep backwards compatibility? Whatever is in user >>> space >>>>>>> using this virtual address expects a virtual address. If it now >>> gets a >>>>>>> physical address it will probably do the wrong thing. Unless there >>> is >>>>>>> a one to one mapping, and you are exposing virtual addresses >>> anyway. >>>>>>> >>>>>>> If you are going to break backwards compatibility Maybe it would >>> be >>>>>>> better to return 0xdeadbeef? Or 0? >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>> >>>>>> The fixed commit was added in v6.1-rc1 and switched from physical to >>>>>> virtual. So this is effectively a partial revert to the previous >>>>>> behavior (but keeping the other changes). See [1] for discussion. >>>> >>>> Please don't assume a reviewer has seen the previous >>>> discussion. Include the background in the commit message to help such >>>> reviewers. > >>>>> I see it asked in that thread, but not answered. Why are you exposing >>>>> "physical" addresses to userspace? There should be no reason for that. >>>> >>>> I don't see anything about needing physical or virtual address in the >>>> discussion, or i've missed it. >>> >>> Well, Madalin originally added this, so perhaps she has some insight. >>> >>> I have no idea why we set the IFMAP stuff, since that seems like it's for >>> PCMCIA. Not sure about sysfs either. >>> >>>> If nobody knows why it is needed, either use an obfusticated value, or >>>> remove it all together. If somebody/something does need it, they will >>>> report the regression. >>> >>> I'd rather apply this (or v2 of this) and then remove the "feature" in >>> follow-up. >>> >>> --Sean >> >> >> root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1" >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2" >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3" >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4" >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5" >> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6" > > So you rely on the physical address. > It's a pity this uses a custom sysfs file. > Can't you obtain this information some other way? > Anyway, as this is in use, it became part of the ABI. In my udev rules I use ID_PATH. Since this is a devicetree platform, the path name includes the device address by convention. --Sean >> root@localhost:~# grep 1ae /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr >> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000 >> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000 >> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000 >> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000 > > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c index 31cfa121333d..fc68a32ce2f7 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -221,8 +221,8 @@ static int dpaa_netdev_init(struct net_device *net_dev, net_dev->netdev_ops = dpaa_ops; mac_addr = mac_dev->addr; - net_dev->mem_start = (unsigned long)mac_dev->vaddr; - net_dev->mem_end = (unsigned long)mac_dev->vaddr_end; + net_dev->mem_start = (unsigned long)priv->mac_dev->res->start; + net_dev->mem_end = (unsigned long)priv->mac_dev->res->end; net_dev->min_mtu = ETH_MIN_MTU; net_dev->max_mtu = dpaa_get_max_mtu(); diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c index 258eb6c8f4c0..4fee74c024bd 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c @@ -18,7 +18,7 @@ static ssize_t dpaa_eth_show_addr(struct device *dev, if (mac_dev) return sprintf(buf, "%llx", - (unsigned long long)mac_dev->vaddr); + (unsigned long long)mac_dev->res->start); else return sprintf(buf, "none"); } diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c index 7b7526fd7da3..65df308bad97 100644 --- a/drivers/net/ethernet/freescale/fman/mac.c +++ b/drivers/net/ethernet/freescale/fman/mac.c @@ -279,7 +279,6 @@ static int mac_probe(struct platform_device *_of_dev) struct device_node *mac_node, *dev_node; struct mac_device *mac_dev; struct platform_device *of_dev; - struct resource *res; struct mac_priv_s *priv; struct fman_mac_params params; u32 val; @@ -338,24 +337,25 @@ static int mac_probe(struct platform_device *_of_dev) of_node_put(dev_node); /* Get the address of the memory mapped registers */ - res = platform_get_mem_or_io(_of_dev, 0); - if (!res) { + mac_dev->res = platform_get_mem_or_io(_of_dev, 0); + if (!mac_dev->res) { dev_err(dev, "could not get registers\n"); return -EINVAL; } - err = devm_request_resource(dev, fman_get_mem_region(priv->fman), res); + err = devm_request_resource(dev, fman_get_mem_region(priv->fman), + mac_dev->res); if (err) { dev_err_probe(dev, err, "could not request resource\n"); return err; } - mac_dev->vaddr = devm_ioremap(dev, res->start, resource_size(res)); + mac_dev->vaddr = devm_ioremap(dev, mac_dev->res->start, + resource_size(mac_dev->res)); if (!mac_dev->vaddr) { dev_err(dev, "devm_ioremap() failed\n"); return -EIO; } - mac_dev->vaddr_end = mac_dev->vaddr + resource_size(res); if (!of_device_is_available(mac_node)) return -ENODEV; diff --git a/drivers/net/ethernet/freescale/fman/mac.h b/drivers/net/ethernet/freescale/fman/mac.h index b95d384271bd..13b69ca5f00c 100644 --- a/drivers/net/ethernet/freescale/fman/mac.h +++ b/drivers/net/ethernet/freescale/fman/mac.h @@ -20,8 +20,8 @@ struct mac_priv_s; struct mac_device { void __iomem *vaddr; - void __iomem *vaddr_end; struct device *dev; + struct resource *res; u8 addr[ETH_ALEN]; struct fman_port *port[2]; u32 if_support;