On 1/24/2020 9:55 AM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
24.01.2020 06:27, Sameer Pujar пишет:
On 1/24/2020 6:58 AM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
20.01.2020 17:23, Sameer Pujar пишет: [snip]
+static bool tegra_admaif_wr_reg(struct device *dev, unsigned int reg) +{
struct tegra_admaif *admaif = dev_get_drvdata(dev);unsigned int ch_stride = TEGRA_ADMAIF_CHANNEL_REG_STRIDE;unsigned int num_ch = admaif->soc_data->num_ch;unsigned int rx_base = admaif->soc_data->rx_base;unsigned int tx_base = admaif->soc_data->tx_base;unsigned int global_base = admaif->soc_data->global_base;unsigned int reg_max =admaif->soc_data->regmap_conf->max_register;
unsigned int rx_max = rx_base + (num_ch * ch_stride);unsigned int tx_max = tx_base + (num_ch * ch_stride);if ((reg >= rx_base) && (reg < rx_max)) {The braces are not needed around the comparisons because they precede the AND. Same for all other similar occurrences in the code.
While that is true, some prefer to use explicit braces to make it more readable. In the past I was told to use explicitly in such cases.
At least most of code in kernel (I've seen) doesn't have superfluous parens (the curvy thingies actually should be the braces). Readability is arguable in this case, I'm finding such code a bit more difficult to read, although in some cases parens and spacing may help to read more complex constructions.
Yes this is subjective and depends on the individual reading the code. It is confusing every time, for the sender, about which guideline to follow. Resending the patch/series for only this reason may not be really necessary. Since I need to fix couple of issues in this series I may consider removing the explicit braces.