Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp514368ybz; Tue, 21 Apr 2020 13:33:17 -0700 (PDT) X-Google-Smtp-Source: APiQypJTp4OSlsyY41RI6OQlHDsBUtbQzDmv8SMQGJdynXE2hd7zfl4PuqxfcJSwEDON7vRAnl7J X-Received: by 2002:a05:6402:3056:: with SMTP id bu22mr17527904edb.192.1587501197408; Tue, 21 Apr 2020 13:33:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587501197; cv=none; d=google.com; s=arc-20160816; b=c0r7Ux4GDHl26kPMYthMorWwwWVq6e3maxdfCGvK2neroIpvvX19+jxT0Eh6+HyT3K Tla/JOUEbnzCCQR5/JLz2n9xfDg9CaMVaC+H8Q4Ej+3yg0xtKH66Z26FOVOOFZ+q5ibC 6o0DdD5+dyehHEm1yDrpCaI7HABq2fmFhZeyhGfawVD5OxQVBVdsKxPc6GGQuNzrVW+5 WLaP4GKR++bqujNoGEsmFreoFotGBU3wxog8mznB0zML5ZJ8le79Z7n21XHU+EIRx/Nf wCoQ/N7wOTPZwIMr0ou/H1uz6WHDJU1f2md5tz3kQkireS/HFtq6+xXdozP10yLfVqiC K4sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DgynPmoHWquo2i6Yyvm5x5n+FCVjD0yzZNoB+cTueB0=; b=w385XHF2pGq0d1j2FBv5OKYsn4RWOWYs4WEPBe+3uF7S/JXmvCCqjMzWpYnWOVIkcF +/LlC6JWflJMf+R/uLqtYu+5/sIOSGCHsRH+FPtkWKWpZecuwFP2fcrcLyZwPbFsbLne JJ0+9O+/GK3r7+sDCVy2JhX23trPEhnYbnfR+8Xi5UIc5unlZc30CD4WasslKnBuQ5c3 pV/p7zDaPxjAEEiLJ9x2TwIwzyczOdrjUp9jOu9fQi2qOWra8wRaBDrY60nX17T6K7m5 SFyUtcc1BTlEJxbfbP6TzqxDr7XnRJot+ocLlpiVI1W8y/yHrCxdD5aCRuDSWX/7D6lz k+yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ie6ohRqy; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s15si2124980edq.231.2020.04.21.13.32.54; Tue, 21 Apr 2020 13:33:17 -0700 (PDT) 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=@chromium.org header.s=google header.b=ie6ohRqy; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726160AbgDUUbj (ORCPT + 99 others); Tue, 21 Apr 2020 16:31:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725850AbgDUUbj (ORCPT ); Tue, 21 Apr 2020 16:31:39 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE5E5C0610D6 for ; Tue, 21 Apr 2020 13:31:37 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id e9so8866863iok.9 for ; Tue, 21 Apr 2020 13:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DgynPmoHWquo2i6Yyvm5x5n+FCVjD0yzZNoB+cTueB0=; b=ie6ohRqyPbI+C4yBuHi6QA74OoL4yfStj7tBGqZwCMM1CSqVDKrZo5EzljVuI4Nwbh E8w+vvHv6vtOly2PHR4bf5m/LDCu6LXowc5Tv2F49VGJ+gHtIvdW7VpJTdKQDUsGlSXS JS2dURYAU+iGzaWXuh4lmrsMHOChsYSg3Z7aM= 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=DgynPmoHWquo2i6Yyvm5x5n+FCVjD0yzZNoB+cTueB0=; b=iEC7xdCw9LUutfFLHNyQER2D/JZPIXRcM5afCwu0ACcRtHiUjjAvwjq4NnSuOb0P6O njxaxEhkQFLQm+lEUvb3M4p2lkdFDJmE2qbFEdETmfoEVjz64B3Lf+gIorVyyfu5s3Dk sWJPCxQFewAqQxhzBrZOsG+CV9SMyBlHZdPvYu1FE0gfsaw3zixMBhugDmPDiXNAtIlZ 6rVRxAuli4GOu5RBa1JLpoU3UOZEforBxRbr2LYVNrSSEHChJ1LvJz17fNoabSEUWJrN nwN41N53eB8PTEOSSood2UyYSvobQYaqSpqlep/xisdso2ETz/pmXwADnOyjV+vcOCWF HSmQ== X-Gm-Message-State: AGi0PuaHmYbbL+GFWu9BtUsIxS6kcK5FY7VTkNHkfWkc8hOjnNUs0y+1 yF0+H6KvB8eMKwCRbK9G3ymSn/JF+nn7VuAcLv+PqA== X-Received: by 2002:a02:90cd:: with SMTP id c13mr21792999jag.83.1587501096755; Tue, 21 Apr 2020 13:31:36 -0700 (PDT) MIME-Version: 1.0 References: <20200421110520.197930-1-evanbenn@chromium.org> <20200421210403.v2.2.Ia92bb4d4ce84bcefeba1d00aaa1c1e919b6164ef@changeid> In-Reply-To: <20200421210403.v2.2.Ia92bb4d4ce84bcefeba1d00aaa1c1e919b6164ef@changeid> From: Julius Werner Date: Tue, 21 Apr 2020 13:31:25 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] watchdog: Add new arm_smc_wdt watchdog driver To: Evan Benn Cc: LKML , Xingyu Chen , Julius Werner , Guenter Roeck , Anson Huang , Bjorn Andersson , Catalin Marinas , "David S. Miller" , Geert Uytterhoeven , Greg Kroah-Hartman , Leonard Crestez , Li Yang , Marcin Juszkiewicz , Matthias Brugger , Mauro Carvalho Chehab , Olof Johansson , Rob Herring , Shawn Guo , Valentin Schneider , Will Deacon , Wim Van Sebroeck , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "moderated list:ARM/Mediatek SoC support" , LINUX-WATCHDOG Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +static int smcwd_call(unsigned long smc_func_id, enum smcwd_call call, > + unsigned long arg, struct arm_smccc_res *res) I think you should just take a struct watchdog_device* here and do the drvdata unpacking inside the function. > +static int smcwd_probe(struct platform_device *pdev) > +{ > + struct watchdog_device *wdd; > + int err; > + struct arm_smccc_res res; > + u32 *smc_func_id; > + > + smc_func_id = > + devm_kzalloc(&pdev->dev, sizeof(*smc_func_id), GFP_KERNEL); > + if (!smc_func_id) > + return -ENOMEM; nit: Could save the allocation by just casting the value itself to a pointer? Or is that considered too hacky? > +static const struct of_device_id smcwd_dt_ids[] = { > + { .compatible = "mediatek,mt8173-smc-wdt" }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, smcwd_dt_ids); So I'm a bit confused about this... I thought the plan was to either use arm,smc-id and then there'll be no reason to put platform-specific quirks into the driver, so we can just use a generic "arm,smc-wdt" compatible string on all platforms; or we put individual compatible strings for each platform and use them to hardcode platform-specific differences (like the SMC ID) in the driver. But now you're kinda doing both by making the driver code platform-independent but still using a platform-specific compatible string, that doesn't seem to fit together. (If the driver can be platform independent, I think it's nicer to have a generic compatible string so that future platforms which support the same interface don't have to land code changes in order to just use the driver.)