Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 23 Jun 2019 12:46:40 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Anson.Huang@nxp.com
cc:     daniel.lezcano@linaro.org, robh+dt@kernel.org,
        mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
        kernel@pengutronix.de, festevam@gmail.com, l.stach@pengutronix.de,
        abel.vesa@nxp.com, ccaione@baylibre.com, angus@akkea.ca,
        andrew.smirnov@gmail.com, agx@sigxcpu.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Linux-imx@nxp.com
Subject: Re: [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
 property
In-Reply-To: <20190621082838.12630-1-Anson.Huang@nxp.com>
Message-ID: <alpine.DEB.2.21.1906231232520.32342@nanos.tec.linutronix.de>
References: <20190621082838.12630-1-Anson.Huang@nxp.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Anson,

On Fri, 21 Jun 2019, Anson.Huang@nxp.com wrote:

> Subject : [PATCH 1/3] clocksource/drivers/sysctr: Add an optional property

That subject line is not really informative. From Documentation:

     The ``summary phrase`` in the email's Subject should concisely
     describe the patch which that email contains.

That means that it should tell which property it adds so it's immediately
clear what this is about. Something like:

 Subject: clocksource/drivers/sysctr: Add optional clock-frequency property

Hmm?

> From: Anson Huang <Anson.Huang@nxp.com>
> 
> This patch adds an optional property "clock-frequency" to pass

Please read Documentation/process/submitting-patches.rst and search for
'This patch'

> the system counter frequency value to kernel system counter
> driver and indicate the driver to skip of_clk operations, this
> is to support those platforms using platform driver model for
> clock driver.

That sentence does not parse. Please structure your changelog in the
following order:

   1) Context or problem

   2) Detailed analysis (if applicable and necessary)

   3) Short description of the solution (the rest is obvious from the patch
      itself).

So something like this (assumed I decoded the above correctly):

   Systems which use the system counter with the platform driver model
   require the clock frequency to be supplied via device tree.

   This is necessary as in the platform driver model the of_clk operations
   do not work correctly because LENGHTY EXPLANATION WHY ...

   Add the optinal clock-frequency to the device tree bindings of the NXP
   system counter so the frequency can be handed in and the of_clk
   operations can be skipped.

The important part is the missing LENGTHY EXPLANATION WHY. I can't fill
that in because you did not provide that information.

Thanks,

	tglx