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 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 72EC1C433DB for ; Tue, 22 Dec 2020 04:09:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3376D22ADC for ; Tue, 22 Dec 2020 04:09:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725870AbgLVEJI (ORCPT ); Mon, 21 Dec 2020 23:09:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbgLVEJF (ORCPT ); Mon, 21 Dec 2020 23:09:05 -0500 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DFA8C0613D3; Mon, 21 Dec 2020 20:08:25 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id p14so10908437qke.6; Mon, 21 Dec 2020 20:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lferK7S/WcuZtuM8G00rHoo+wxuBCDmc8Awl4Gm4XE=; b=LcJ6hqjgmBAF3xenw/wLMRvZFXCxq5WfdX0WYJkCtYW+AWEWFGMR2Ejt+j75UFN9Zi Q7j6VLS5nIvfMZJLi6g6fT+oqP766/otVRSBnLMYqA/pqOAT2Ftt3DoM/ApQKlUHigkX 3U8IrKrq1yuC7eIT12I4mjZ35Wwp16Y+R/Yl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1lferK7S/WcuZtuM8G00rHoo+wxuBCDmc8Awl4Gm4XE=; b=g9hPgQ2pUkae1ubMgCbcLbgi+hb8oY+PbsYiNe6owfnREd9XyWUjN6r1pS86RNCu5x 4F7U3ju9aaw+bk9zJeU2ycV1Axg5lWhPmg2NI/fWSakyzzUZVB16zd41nzmEMW61GtfS yYn/Ig5eXSYR9CwCzRRMd7q1Njh//zTmX2KFeSsNeX3TfE4PcAXDPiCyLddxCrbuMNnb 34FjjXT+8mIL5cpDxFykjz7Bxu0rhh2w4hDsgZPuRkLsLpPpPq/aX/tBeJZmZKkXTeiP /+MD8pYjemcVFXnE/ILRmgtTvZNSnYGrOEA1zFKgPGLzpmwqAqisRoosA3JAwMygnrZI 0GWA== X-Gm-Message-State: AOAM531qY81iGB7mwvoW4SFt1sf+a+o/fd2FwAhb9vdnNapJe4OzOrDQ VZVbUkSIDCB76c2Ccd8rPRQHqZKYmY45dvW2ne0= X-Google-Smtp-Source: ABdhPJxOJe0aczqoEqz1cNRhFogu+B29Eal0/8X5iQGiNPeLLyhWKCYJdy4Trd8iFlfSL98eHlhm7D5RyKOBwJpQMIM= X-Received: by 2002:a05:620a:31a:: with SMTP id s26mr20267871qkm.66.1608610104425; Mon, 21 Dec 2020 20:08:24 -0800 (PST) MIME-Version: 1.0 References: <20200915184525.29665-1-zev@bewilderbeest.net> <20201218213952.refmqjlxdclsquzg@hatter.bewilderbeest.net> In-Reply-To: <20201218213952.refmqjlxdclsquzg@hatter.bewilderbeest.net> From: Joel Stanley Date: Tue, 22 Dec 2020 04:08:12 +0000 Message-ID: Subject: Re: [PATCH] i2c: aspeed: disable additional device addresses on ast2[56]xx To: Zev Weiss Cc: Brendan Higgins , Benjamin Herrenschmidt , Andrew Jeffery , linux-i2c@vger.kernel.org, OpenBMC Maillist , Linux ARM , linux-aspeed , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On Fri, 18 Dec 2020 at 21:40, Zev Weiss wrote: > > On Tue, Sep 15, 2020 at 01:45:25PM CDT, Zev Weiss wrote: > >The ast25xx and ast26xx have, respectively, two and three configurable > >slave device addresses to the ast24xx's one. We only support using > >one at a time, but the others may come up in an indeterminate state > >depending on hardware/bootloader behavior, so we need to make sure we > >disable them so as to avoid ending up with phantom devices on the bus. > > > >Signed-off-by: Zev Weiss > >--- > > drivers/i2c/busses/i2c-aspeed.c | 50 +++++++++++++++++++++++++++------ > > 1 file changed, 41 insertions(+), 9 deletions(-) > > > > > > Ping...any thoughts on this patch? Apologies for the delay, this one slipped through the cracks. The rework is fine, and lends itself to supporting the other addresses in the future. However, a simpler fix would be to construct reg 0x18 from zero, so only the functions that are supported are enabled. static void __aspeed_i2c_reg_slave(struct aspeed_i2c_bus *bus, u16 slave_addr) { u32 addr_reg_val, func_ctrl_reg_val; /* Set slave addr. */ addr_reg_val = slave_addr & ASPEED_I2CD_DEV_ADDR_MASK; writel(addr_reg_val, bus->base + ASPEED_I2C_DEV_ADDR_REG); /* Turn on slave mode. */ func_ctrl_reg_val = readl(bus->base + ASPEED_I2C_FUN_CTRL_REG); func_ctrl_reg_val |= ASPEED_I2CD_SLAVE_EN; writel(func_ctrl_reg_val, bus->base + ASPEED_I2C_FUN_CTRL_REG); } You could go further and ensure slave mode is always disabled unless requested by clearing 0x18 when 0x00 is cleared at aspeed_i2c_init. Cheers, Joel > > > Thanks, > Zev >