lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 27 Jan 2020 10:38:39 +0530 From: Sameer Pujar <spujar@...dia.com> To: Dmitry Osipenko <digetx@...il.com>, <perex@...ex.cz>, <tiwai@...e.com>, <robh+dt@...nel.org> CC: <spujar@...dia.com>, <devicetree@...r.kernel.org>, <alsa-devel@...a-project.org>, <atalambedu@...dia.com>, <linux-kernel@...r.kernel.org>, <lgirdwood@...il.com>, <jonathanh@...dia.com>, <viswanathl@...dia.com>, <sharadg@...dia.com>, <broonie@...nel.org>, <thierry.reding@...il.com>, <linux-tegra@...r.kernel.org>, <rlokhande@...dia.com>, <mkumard@...dia.com>, <dramesh@...dia.com> Subject: Re: [alsa-devel] [PATCH 7/9] ASoC: tegra: add Tegra210 based ADMAIF driver 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.
Powered by blists - more mailing lists