Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1164023pxb; Fri, 21 Jan 2022 11:12:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJxApXOG06EO3ZX9YQbZtb0Wjgjl0+ga7hVllnpPbdvjS9Fep2LlcHnWK4HVWU6+kq0CKoE8 X-Received: by 2002:a63:7509:: with SMTP id q9mr3963408pgc.173.1642792351051; Fri, 21 Jan 2022 11:12:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642792351; cv=none; d=google.com; s=arc-20160816; b=A+Iib26laNsKX/Hlu1udqda9NFe8bZkKkNyP6YvGWJnfsoEDeJw/cEwvp+pPnTcKY4 KzoACM+RDus+EuMR+Y5Cb4nQ/ZAlHd7xegzoj1d0VfUbtmTHmL14HG+vuDF0xfFRguEn dDyv8o9YfZt/WjxZ7Lj0qU0wnK4hCr4EFZS2lSwFxobD3RwpVRb9cSV+tfMmU3rfkEFy nb1gUEXEbvF0x8Y0K5mwMybUHUYq+7hoefe8RIcFHZtENbOalKplLqab02sR8FpNv+06 OSRSITvrTimEll8UTkUvgFWgkYQbLx1EGleV8XPI0wBBedaevzFcBKS8YEXSIZ74aS5J TFSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=PS6rF1/qC7hs4eJz9gJcqA6Dx/xMCX3EO5vU88DfZZc=; b=dXmuyrFyuPjLa8AUSv/WGPGlx/uZ8LzVcfGUzUIyMlOWA+P7eOCmZfnMb2HRNw8UOC ZNBU6rgHzXA3UxDqn5P9itrwIS5n6F/v5SPcgKXRFYiOuZUFTTSxtmXLqcb60e/1nyz9 2pBVF8xa8Ev156ap3ZzV6yvScY41vG+9Qlaa2uO0dpJYtDR+Q7cSBU8KOp5CbU2Mv96b OPNZPA9KL6yvwzlQxwP/c8tu+oFcZ1SyVY7Tj0EapJWXSuaotRqBUUcJqMXy+k/IDygI fnRtquFtP+0zhA3+4kVljIENZ5sKnpsJ9+SoLpFALq1RdfvYkLTU4n0JqFMVDkp62pde U4yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=M7CPAyDL; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s27si8859684pfg.237.2022.01.21.11.12.18; Fri, 21 Jan 2022 11:12:31 -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=@gmail.com header.s=20210112 header.b=M7CPAyDL; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354368AbiASLy7 (ORCPT + 99 others); Wed, 19 Jan 2022 06:54:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346033AbiASLy6 (ORCPT ); Wed, 19 Jan 2022 06:54:58 -0500 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50B85C061574; Wed, 19 Jan 2022 03:54:57 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id j23so4884016edp.5; Wed, 19 Jan 2022 03:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PS6rF1/qC7hs4eJz9gJcqA6Dx/xMCX3EO5vU88DfZZc=; b=M7CPAyDLJkK51lli8eGjFkvNRTyy8qp3E++q68zhCMEl86F8fz18sa0Yx7gGvlOIoX yPFtEjvq0TbGkGBVu02onAkQI6LBbYynWWfkRyy+d2U4Tc03AAW1ysx2pA1Coer3Dg0T DFIuCMs+GHVrkJ469lLT8f/wSbYP7HSYAqOBPS6RXjvqdy3ngibKBIgy/291aNvKeAiv uwOtASk4ZQhAZXtbsVrEnQ5LlQSD4/Hy4RAUh5xAeM7W8uZ6Aj12ugMfZg9kDRFfVMWT oJfEI4iGB8yGaRaIy5BD3RCcSnPSIQkbrdpmfw4OSE9l6Z2BvkSNF5MO73+cC+ufgEpk kY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PS6rF1/qC7hs4eJz9gJcqA6Dx/xMCX3EO5vU88DfZZc=; b=YhEFx4/de4oBebjLG6XRMi5wjAaeZpsErANTilzM1leNmUpmv8g1MMujzky7v7xVNs aAhOs08wfGQ8XFgD8M8WsQRGqpkjn569FQcM7efP3qpqkZwuAyx1c7SVIJ4aGmUYpQfx 5fYXLx4VDGtL+J1BL8hqrn293G0cZOZoM2EX/nJ1PFULpJX9suVyGZyE186psB/S1pnD xftWWVAFkyOn7dmJm6rTQFC7GjA4E8OrOb06LGQG4ZENPMZIK64Br8rJEDe4jjLEIhvs 5Bh3g6eBiNbgcPackuMs/uNS2bTg83paRoZhtXYRhdpAKiK7N0Z3m4Ng6oXSaH304vSd 61vg== X-Gm-Message-State: AOAM533RHu8PnN3FOAyCHurJTacZwGsp6RTTX4DaZU11QWaB3MEqLeNp 9wmSNaQAv/Vqa4vZBdbt3AlxVd6h9jVoqwer9b+s2wz9YClbwQ== X-Received: by 2002:a50:c388:: with SMTP id h8mr24181980edf.218.1642593295904; Wed, 19 Jan 2022 03:54:55 -0800 (PST) MIME-Version: 1.0 References: <20220118202234.410555-1-terry.bowman@amd.com> <20220118202234.410555-3-terry.bowman@amd.com> In-Reply-To: <20220118202234.410555-3-terry.bowman@amd.com> From: Andy Shevchenko Date: Wed, 19 Jan 2022 13:53:13 +0200 Message-ID: Subject: Re: [PATCH v3 2/4] Watchdog: sp5100_tco: Refactor MMIO base address initialization To: Terry Bowman Cc: Guenter Roeck , linux-watchdog@vger.kernel.org, Jean Delvare , linux-i2c , Wolfram Sang , "Rafael J. Wysocki" , Linux Kernel Mailing List , Wim Van Sebroeck , Robert Richter , Tom Lendacky , "Shah, Nehal-bakulchandra" , Basavaraj Natikar , Shyam Sundar S K , Mario Limonciello Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022 at 10:23 PM Terry Bowman wrote: > > Combine MMIO base address and alternate base address detection. Combine > based on layout type. This will simplify the function by eliminating > a switch case. > > Move existing request/release code into functions. This currently only > supports port I/O request/release. The move into a separate function > will make it ready for adding MMIO region support. ... > To: Guenter Roeck > To: linux-watchdog@vger.kernel.org > To: Jean Delvare > To: linux-i2c@vger.kernel.org > To: Wolfram Sang > To: Andy Shevchenko > To: Rafael J. Wysocki > Cc: linux-kernel@vger.kernel.org > Cc: Wim Van Sebroeck > Cc: Robert Richter > Cc: Thomas Lendacky Same comment to all your patches. ... > +static int __sp5100_tco_prepare_base(struct sp5100_tco *tco, > + u32 mmio_addr, > + const char *dev_name) > +{ > + struct device *dev = tco->wdd.parent; > + int ret = 0; Not really used variable. > + if (!mmio_addr) > + return -ENOMEM; > + > + if (!devm_request_mem_region(dev, mmio_addr, > + SP5100_WDT_MEM_MAP_SIZE, > + dev_name)) { > + dev_dbg(dev, "MMIO address 0x%08x already in use\n", > + mmio_addr); > + return -EBUSY; > + } > + > + tco->tcobase = devm_ioremap(dev, mmio_addr, > + SP5100_WDT_MEM_MAP_SIZE); > + if (!tco->tcobase) { > + dev_dbg(dev, "MMIO address 0x%08x failed mapping.\n", > + mmio_addr); > + devm_release_mem_region(dev, mmio_addr, > + SP5100_WDT_MEM_MAP_SIZE); Why? If it's a short live mapping, do not use devm. > + return -ENOMEM; > + } > + dev_info(dev, "Using 0x%08x for watchdog MMIO address\n", > + mmio_addr); Unneeded noise. > + return ret; On top of above it's a NIH devm_ioremap_resource(). > +} ... > + int ret = 0; Redundant assignment. ... > + /* Check MMIO address conflict */ > + ret = __sp5100_tco_prepare_base(tco, mmio_addr, dev_name); > + > + /* Check alternate MMIO address conflict */ Unify this with the previous comment. > + if (ret) > + ret = __sp5100_tco_prepare_base(tco, alt_mmio_addr, > + dev_name); ... > + if (alt_mmio_addr & ((SB800_ACPI_MMIO_DECODE_EN | > + SB800_ACPI_MMIO_SEL) != > + SB800_ACPI_MMIO_DECODE_EN)) { The split looks ugly. Consider to use temporary variables or somehow rearrange the condition that it doesn't break in the middle of the one logical token. > + alt_mmio_addr &= ~0xFFF; Why capital letters? > + alt_mmio_addr += SB800_PM_WDT_MMIO_OFFSET; > + } ... > + if (!(alt_mmio_addr & (((SB800_ACPI_MMIO_DECODE_EN | > + SB800_ACPI_MMIO_SEL)) != > + SB800_ACPI_MMIO_DECODE_EN))) { Ditto. > + alt_mmio_addr &= ~0xFFF; Ditto. > + alt_mmio_addr += SB800_PM_WDT_MMIO_OFFSET; ... Okay, I see this is the original code like this... Perhaps it makes sense to reshuffle them (indentation-wise) at the same time and mention this in the changelog. ... > release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE); Is it still needed? I have no context to say if devm_iomap() and this are not colliding, please double check the correctness. -- With Best Regards, Andy Shevchenko