Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3994830pxb; Tue, 25 Jan 2022 00:57:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJwROUtyVOvKJwCUlURU9fwh52r6vxi7LNJtUgAKcNy65MabC6CXr/bB1Uz6yw8b1GDBmaYA X-Received: by 2002:aa7:c757:: with SMTP id c23mr7700258eds.133.1643101067172; Tue, 25 Jan 2022 00:57:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643101067; cv=none; d=google.com; s=arc-20160816; b=WUnj7QRSkM2xKdo87LbDvHgYaTO115uCIboBHERfQDWZjxnq4hekKfy0kQW3r1igmS IX+5mP8uQ+WmAN/FU9rZX9xFkIBsLGjlpSbbpukf8YE6BZg+PcHTOP3cUE9FEII/XYVY tmCCtdy0pXwpZsqSv6DEH6YT2nzNW3zLJXKF+N+OTXkrwmyTmTmejlQ+byfvAzeXlcOg kBogtJeqJHuFNSeeTVE9u8P7jKcGdXG2ccsXdOASCVDwSSuIn4nHdNmCYmTsp4FRNf9m PShK25ashvddu/Us5mXOlmlVA99UhzjRw7sCo3SyfTHVzx99pt32ml2TcZZjEvMFcXae Hy7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4bYxTK4CI5NQXpadWMVdmVIRSBqI/OmdC+Kql5VSL7w=; b=POOj3Tk5rknRoYnqFqhXZQ6TWzl5qE9ThIk6FZQmye8b6dhqCmY8sPPG6AjZPrdPdb 1b3+vN+3ACiggJ+06Uh8OxI4gqc7v+GfokCQeD1SWqy/lUa3dh7N46NdpsK+KcNvNc7N t6K/9mYsJ2M/IijULhKV4F3KkIk8uaN7wO+jS69E4ukTEV0GSKvsYUYz+dXmwMPhfisC 9OEQIN5M6BlT00xLZlfDgHR2xLqPS2e8XqTcG3VjQl8N4zjD+LgobW6krgkgI78qW9T2 NwNg+9NiHDiKxkbMA3V5JFQHXawj9r7nemLtRnPhtFRdCE6Xz1+saSQmBW3ku5xkobou K8kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=O4Pvk+PA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h1si9607806edl.102.2022.01.25.00.57.21; Tue, 25 Jan 2022 00:57:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=O4Pvk+PA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350794AbiAYGGX (ORCPT + 99 others); Tue, 25 Jan 2022 01:06:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240166AbiAYGBH (ORCPT ); Tue, 25 Jan 2022 01:01:07 -0500 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF525C0C537F for ; Mon, 24 Jan 2022 20:17:04 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id y27so14048682pfa.0 for ; Mon, 24 Jan 2022 20:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4bYxTK4CI5NQXpadWMVdmVIRSBqI/OmdC+Kql5VSL7w=; b=O4Pvk+PACasjJ/fKSW9Edb8jDXppN9gEi4WADl6EY1ekHMkwcTbzWIPFp9Y8Sq9iYd 33YFgEkCPkQWHk1QuwAKol2JTbTIoroRs1JveUDeYSaXgrdmQ3f5RDDUPMV/j/uKo0b7 cwHsktuFtBxwb1kuFdULOYzrSAzaEC8EGB/iJ1p9l+UN9sgiMLnVvl9HLwJcdAbO7Gqc +EPsFR3m/UiE9YCch6CD/XYGb2t6iY6rZk31AkIOgW2i5SNfLURoBqh4Z7nG3pvCfXIJ jv1XsRekl9wkfk/owm9IMrgsB+2FH1ijPUZDFj9utjNQXgBSlCGMNvjWKPM7XIEyt76S CFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4bYxTK4CI5NQXpadWMVdmVIRSBqI/OmdC+Kql5VSL7w=; b=l31Jzv+8ArqeaJmK27tvik5K3i7Q0UcMugpUOr67lO4dps8UCme3xWo7FZlvXAKi3h XXcCxhwrXyo7TV+WOvr+Ke4WQKj1zMnygMJr4ow3x5eFBmNfokbUxkso9NbrmB1JWvnT 49zhZcS8L1L+upEwj+G7SBCg9R2AsFUfTZZY8Kf9rvcB3/UAqEDvgg9yf1aV5cUgr0XR 4AJG1GAXnYjeikPivtwrtMBzBvrRZZLNnfe4IzVlrK1O4/5Wm7JdLzIYHExywfbhaK2Z DqSpZgfDhHFLdRYwoKbmeX+ee/pSrnPY0g4WW8KZd2wv4RT6gMnvppI2LRJ36doEOJFV SvGw== X-Gm-Message-State: AOAM530ZpJGqHq5Xr4amUnLCGqbgh8C2BjI3u5fGJz8LurV0tVwaHjDo Nb5CwUUBB/1McmuygnDhkqPeMg== X-Received: by 2002:a05:6a00:180e:b0:4c8:f0b8:2382 with SMTP id y14-20020a056a00180e00b004c8f0b82382mr8587146pfa.59.1643084224105; Mon, 24 Jan 2022 20:17:04 -0800 (PST) Received: from google.com ([2401:fa00:1:10:5978:14f2:157f:f050]) by smtp.gmail.com with ESMTPSA id y15sm6039953pfi.87.2022.01.24.20.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 20:17:03 -0800 (PST) Date: Tue, 25 Jan 2022 12:17:01 +0800 From: Tzung-Bi Shih To: "Dustin L. Howett" Cc: "Dustin L. Howett" , linux-kernel@vger.kernel.org, Benson Leung , Guenter Roeck Subject: Re: [PATCH 2/2] platform/chrome: reserve only the I/O ports required for the MEC EC Message-ID: References: <20220105031242.287751-1-dustin@howett.net> <20220105031242.287751-3-dustin@howett.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 11:42:29AM +0800, Tzung-Bi Shih wrote: > On Tue, Jan 25, 2022 at 9:35 AM Dustin L. Howett wrote: > > diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c > > index 458eb59db2ff..06fdfe365710 100644 > > --- a/drivers/platform/chrome/cros_ec_lpc.c > > +++ b/drivers/platform/chrome/cros_ec_lpc.c > > @@ -341,9 +341,14 @@ static int cros_ec_lpc_probe(struct platform_device *pdev) > > u8 buf[2]; > > int irq, ret; > > > > - if (!devm_request_region(dev, EC_LPC_ADDR_MEMMAP, EC_MEMMAP_SIZE, > > - dev_name(dev))) { > > - dev_err(dev, "couldn't reserve memmap region\n"); > > + /* > > + * The Framework Laptop (and possibly other non-ChromeOS devices) > > + * only exposes the eight I/O ports that are required for the Microchip EC. > > + * Requesting a larger reservation will fail. > > + */ > > + if (!devm_request_region(dev, EC_HOST_CMD_REGION0, > > + EC_HOST_CMD_MEC_REGION_SIZE, dev_name(dev))) { > > + dev_err(dev, "couldn't reserve MEC region\n"); > > return -EBUSY; The original code: - devm_request_region(dev, EC_LPC_ADDR_MEMMAP, ...) and then - cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, ...). After the patch: - devm_request_region(dev, EC_HOST_CMD_REGION0, ...) and then - cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, ...). Does it work if it reads out of request_region range? > > @@ -366,17 +377,19 @@ static int cros_ec_lpc_probe(struct platform_device *pdev) > > dev_err(dev, "EC ID not detected\n"); > > return -ENODEV; > > } > > - } > > > > - if (!devm_request_region(dev, EC_HOST_CMD_REGION0, > > - EC_HOST_CMD_REGION_SIZE, dev_name(dev))) { > > - dev_err(dev, "couldn't reserve region0\n"); > > - return -EBUSY; > > - } > > - if (!devm_request_region(dev, EC_HOST_CMD_REGION1, > > - EC_HOST_CMD_REGION_SIZE, dev_name(dev))) { > > - dev_err(dev, "couldn't reserve region1\n"); > > - return -EBUSY; > > + /* Reserve the remaining I/O ports required by the non-MEC protocol. */ > > + if (!devm_request_region(dev, EC_HOST_CMD_REGION0 + EC_HOST_CMD_MEC_REGION_SIZE, > > + EC_HOST_CMD_REGION_SIZE - EC_HOST_CMD_MEC_REGION_SIZE, > > + dev_name(dev))) { > > + dev_err(dev, "couldn't reserve remainder of region0\n"); > > + return -EBUSY; > > + } > > + if (!devm_request_region(dev, EC_HOST_CMD_REGION1, > > + EC_HOST_CMD_REGION_SIZE, dev_name(dev))) { > > + dev_err(dev, "couldn't reserve region1\n"); > > + return -EBUSY; > > + } The 2 request_region are now guarded by the first "if (buf[0] != 'E' || buf[1] != 'C')". That is, only non-MEC will request the 2 regions. Doesn't other MECs (e.g. non-Framework Laptop) need the 2 regions?