From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5968311587 for ; Wed, 25 Feb 2026 13:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772026177; cv=none; b=mroM1827Ja4JCwZnCJOdC4zHNzxMONHCjPGvdobqk+7Wc2rezQ8YKzSiq3UA2OJiIvZ9xGumqx/h6IqldRQLebSK3iHBp0oeFJqK+iDxl72XcepQ+8e2/q4yRCRYjb/QOJDtf7AWNWKmIdAnQnHltESwcKEUP5MytvSLiTcgNSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772026177; c=relaxed/simple; bh=kH6pSAzc7ixvwL56p9UiHb2EASU/2oZ/f+xfxqiwvCk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=P056VrQiwcSOtpA9X7Jf33VA9ANixvy2CQDYq1KqzwnFouKOJB5O0K9RWVl2zjPkJGGekjEFflPfjTcck4lZyNWz1gicJz75AuZtPzy0l+6iT0EmoZyZiTtHXE+eXxxCx+v80wOv7lavATWiZJvVBmwU3AdFrI6GIJCaynf0ujg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JSHLFoFv; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=QFdPR5pF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JSHLFoFv"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="QFdPR5pF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772026175; 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=bolAAaL16DQVnJO0fDxqs1CZEsyfX0mApW10uOjI4S8=; b=JSHLFoFvvD7KYQ96kFjWs1VwGcoeLcvHjiD4aCfPaEmShkS6v4VtPhUB2rxCVnXuxRZ7EU 10sIe8T89sjePXIuyBynXvx1ReGbvW1FRHDz+wy2ueXlAvtcqB/QOsr49d3A6xJvJDfJHv 7WqKpTn2h3sJ3HpPesYd/quXivn60NU= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-451-Y28VMIFxOW6agBt13IrGkg-1; Wed, 25 Feb 2026 08:29:34 -0500 X-MC-Unique: Y28VMIFxOW6agBt13IrGkg-1 X-Mimecast-MFC-AGG-ID: Y28VMIFxOW6agBt13IrGkg_1772026174 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-5033b62efa7so657907431cf.1 for ; Wed, 25 Feb 2026 05:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772026174; x=1772630974; darn=vger.kernel.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bolAAaL16DQVnJO0fDxqs1CZEsyfX0mApW10uOjI4S8=; b=QFdPR5pFgRzajjax+yNvp0aCxyfIZ6qXZFDUBTtnhIWvUrPIj5eivFqXlp/OHNzi9f 6nTXU1zPLH2/Tt5T4lZjZsUnjstGjSKyD84DoTIVA6lJHmw5TQKj40irs/oSJdDaRiPG NE7v3AambwDwg5OPwBf1VMQahFmIEI2fBcL9vyiHFYJxYoWzJ2fqZ7jjKLIKvuN659fB zJG4cpWQm0euirCxWwqZ/vdGMu/ZXUcD6IvCehYY0RfiLRla0YWgN4F+uIbZE5i5pS+C NHr4vo6M5zERgHcMWGwbJj1eeio0tFTq0thuwwpCoYR4M9/6gLyKztkiM1sLFrlyhYEP rinA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772026174; x=1772630974; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bolAAaL16DQVnJO0fDxqs1CZEsyfX0mApW10uOjI4S8=; b=BndT8dsv6UsBiNw4JUjIJvb4rTs+4k2rpww6U85HlERSyOcB3QJBGp9iYbMjI7NS6M tIHtbGMnFPPhd/juUO+R+Nvt4Ng9gfFgI5JcWnTBQVjixuM6XTboGC2Kt8PPDGGF6RE1 0NYs+BxxhLGQLkCmIjIqx88moVw0vt40MjGKBxHZ7dJ2igWMLXIrIeDg0fI+hjP0XqlK UbyWC4n5lusqgvmaiNB5wWjDFuBkGrOZhCXbEkB+R9gGSEJ4XTSIWgfqfdqC9HGGpkJR fUEqnIl1DebYXCthfoOu2o72mkoWv/SW2oBY9FWPU3SpyK7dG86eHckv9vYyP5EQgwd+ uGAA== X-Forwarded-Encrypted: i=1; AJvYcCUIs2Rk1uN7tx5S2tdLH83odkEGgrYdRob41elARu1/+Q1zx4AXtH8K+7dTbSbgGFJ+vFTbmXiiLeKVEdQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxsekOQdzDyzgjNMtZ7cg1J7zO0ViNn8bx887K26qX0yr/kPMbW Who1/Ugl/lJkapoNnejI3iRTMgXbezkai4Ll/y6A0Sr2h+yC/Nea8Ka3I5e6GTH8dzZ2WBcqpEN MY92aGdjZdiSxYm6OXgMFMFdUDPwRUt9LW7SI9IfRX5Z9iHRDu6v4aNP6aq0lIT8vr1GKT80mJQ == X-Gm-Gg: ATEYQzzNbxMVAN/W3nonuL31oOfDGUeyE8rjod5iGEH1lDKX4Tg9ss2vOAEtXxNuns6 djeeSWxVXG8qUnj/FdGLU7ZI9hjQWwbI8xhBAWW8mRPHH2dyZMomLL/Bz0vPANTcZy5Tx5Krv2H iZriqCGuq7rUCm6bLFTlhCKZP8ISpdnt2ENO2hjO1LUO1Fs4suJiAuklJXm6hPoqjqwl2gysdvC OpV/hNxtEcUoAOTjA+kr6rmWU6hhdf9f/OoqK/SE4DxgI4i/SSAnH1uOdZRGMkcT+sq9ys+2a2j VukgegKmXXungCTmRHtj8+p96Sg0sZ92S+AtcAdKupX0orN5/pLn2PC62J/nZcwnIcTHY8GvtEH m+yQLVNgfnnZY+/j4umqHJnuh2jsEbTYcLnQ4ciD2r8WNj35gaJtcGsb3 X-Received: by 2002:a05:622a:48:b0:4ee:2459:3d6c with SMTP id d75a77b69052e-5070bcb29e2mr204210541cf.58.1772026173801; Wed, 25 Feb 2026 05:29:33 -0800 (PST) X-Received: by 2002:a05:622a:48:b0:4ee:2459:3d6c with SMTP id d75a77b69052e-5070bcb29e2mr204210171cf.58.1772026173289; Wed, 25 Feb 2026 05:29:33 -0800 (PST) Received: from redhat.com (c-73-183-52-120.hsd1.pa.comcast.net. [73.183.52.120]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5070d6dffadsm125621181cf.31.2026.02.25.05.29.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 05:29:32 -0800 (PST) Date: Wed, 25 Feb 2026 08:29:30 -0500 From: Brian Masney To: Xuyang Dong Cc: sboyd@kernel.org, mturquette@baylibre.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, troy.mitchell@linux.dev, ningyu@eswincomputing.com, linmin@eswincomputing.com, huangyifeng@eswincomputing.com, pinkesh.vaghela@einfochips.com, ganboing@gmail.com, marcel@ziswiler.com Subject: Re: Re: [PATCH v13 2/3] clk: eswin: Add eic7700 clock driver Message-ID: References: <20260214101421.228-1-dongxuyang@eswincomputing.com> <20260214101519.341-1-dongxuyang@eswincomputing.com> <51ff08b4.38e3.19c9394ac61.Coremail.dongxuyang@eswincomputing.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51ff08b4.38e3.19c9394ac61.Coremail.dongxuyang@eswincomputing.com> User-Agent: Mutt/2.2.14 (2025-02-20) On Wed, Feb 25, 2026 at 02:55:20PM +0800, Xuyang Dong wrote: > > > + > > > +int eswin_clk_register_divider(struct device *dev, > > > + struct eswin_divider_clock *clks, > > > + int nums, struct eswin_clock_data *data) > > > +{ > > > + struct clk_hw *clk_hw; > > > + int i; > > > + > > > + for (i = 0; i < nums; i++) { > > > + clk_hw = clk_hw_register_divider_parent_data > > > + (dev, clks[i].name, clks[i].parent_data, > > > + clks[i].flags, data->base + clks[i].offset, > > > + clks[i].shift, clks[i].width, clks[i].div_flags, > > > + &data->lock); > > > + > > > + if (IS_ERR(clk_hw)) { > > > + while (i--) > > > + clk_hw_unregister_divider > > > + (data->clk_data.hws[clks[i].id]); > > > > All of the other places you are using the devm_ variant to automate the > > cleanup, such as devm_clk_hw_register_gate_parent_data(), > > devm_clk_hw_register_mux_parent_data_table(), and > > devm_clk_hw_register_divider_parent_hw(). What do you think about adding > > a devm_clk_hw_register_divider_parent_data() for consistency? > > > > Hi Brian and Stephen, > > Thank you for the suggestions. We agree that implementing > devm_clk_hw_register_divider_parent_data() is a good approach. > In v14, we'll add this function in clk-provider.h as a separate preparatory patch. > The ESWIN clock driver will then switch to using > devm_clk_hw_register_divider_parent_data() instead of > clk_hw_register_divider_parent_data(), with the driver patch depending on the former. > Does this approach better align with upstream conventions? Yes, that sounds good. > > You can now go out to 100 characters for the line lengths instead of 80, however, > > I'm not sure how Stephen feels about that. Personally I think it'd make this > > block, plus some others in this series a bit cleaner. Taking into account the > > current indentation, this block could become this with 100 characters as the max: > > > > hw = eswin_register_clkdiv(dev, div->id, div->name, phw, > > div->flags, data->base + div->offset, > > div->shift, div->width, div->div_flags, > > div->priv_flag, &data->lock); > > > > Stephen, > Brian's feedback on line length was very helpful.  > For v14, we've kept lines within 80 characters wherever possible. > In a few cases, such as function calls with long parameter lists, we've kept  > slightly longer lines to preserve readability,  > but we're happy to rewrap them if preferred. > Does this approach work for the clk subsystem? I don't know when Stephen will be able to respond. I recommend just posting a new version. I apologize in advance if he asks you to do the opposite later. Brian