From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A262C4708F for ; Fri, 4 Jun 2021 13:27:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D207613F9 for ; Fri, 4 Jun 2021 13:27:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230428AbhFDN3m (ORCPT ); Fri, 4 Jun 2021 09:29:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230193AbhFDN3i (ORCPT ); Fri, 4 Jun 2021 09:29:38 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F4173C061740; Fri, 4 Jun 2021 06:27:51 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id A2C2222236; Fri, 4 Jun 2021 15:27:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1622813268; 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=9ZjZ/byVkXGSw+O6l13Rn+fjw8dkV3sOkTd2A/W0i54=; b=MLmf/xp7b4YHnZoE2WvlCSHDfXoQV3VvD9B2yj4v7Z4vEwD3tdrFxcUJtz9mknmLVIO9cG 6vrFLUToHmU+uEr11SJy3BRprSvKLCpBfNcL1WjDCyynavAGU0VpLnk9GcC7LfYAFfJuCm DcHAyebEU+OOYWGeByJiNyyMqh5R9E0= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 Jun 2021 15:27:48 +0200 From: Michael Walle To: Heiner Kallweit Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Claudiu Manoil , "David S . Miller" , Jakub Kicinski , Vladimir Oltean Subject: Re: [PATCH net-next] net: enetc: use get/put_unaligned() for mac address handling In-Reply-To: References: <20210604123018.24940-1-michael@walle.cc> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: michael@walle.cc Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2021-06-04 14:44, schrieb Heiner Kallweit: > On 04.06.2021 14:30, Michael Walle wrote: >> The supplied buffer for the MAC address might not be aligned. Thus >> doing a 32bit (or 16bit) access could be on an unaligned address. For >> now, enetc is only used on aarch64 which can do unaligned accesses, >> thus >> there is no error. In any case, be correct and use the >> get/put_unaligned() >> helpers. >> >> Signed-off-by: Michael Walle >> --- >> drivers/net/ethernet/freescale/enetc/enetc_pf.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c >> b/drivers/net/ethernet/freescale/enetc/enetc_pf.c >> index 31274325159a..a96d2acb5e11 100644 >> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c >> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c >> @@ -1,6 +1,7 @@ >> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) >> /* Copyright 2017-2019 NXP */ >> >> +#include >> #include >> #include >> #include >> @@ -17,15 +18,15 @@ static void enetc_pf_get_primary_mac_addr(struct >> enetc_hw *hw, int si, u8 *addr) >> u32 upper = __raw_readl(hw->port + ENETC_PSIPMAR0(si)); >> u16 lower = __raw_readw(hw->port + ENETC_PSIPMAR1(si)); >> >> - *(u32 *)addr = upper; >> - *(u16 *)(addr + 4) = lower; >> + put_unaligned(upper, (u32 *)addr); >> + put_unaligned(lower, (u16 *)(addr + 4)); > > I think you want to write little endian, therefore on a BE platform > this code may be wrong. Better use put_unaligned_le32? > By using these versions of the unaligned helpers you could also > remove the pointer cast. I wasn't sure about the endianness. Might be the case, that on BE platforms, the endianess of the register will swap too. (OTOH I could use aarch64 with BE..) But I'm fine with changing it. I'd presume this being the only platform for now it doesn't really matter. -michael