by Ulf Hansson

[permalink] [raw]

Subject: Re: [PATCH V5 01/24] mmc: mmci: Change struct members from bool to u8

On 5 October 2018 at 15:22, Ludovic Barre <[email protected]> wrote:
> From: Ludovic Barre <[email protected]>
>
> Recent versions of checkpatch have a new warning based on a documented
> preference of Linus to not use bool in structures due to wasted space and
> the size of bool is implementation dependent. For more information, see
> the email thread at https://lkml.org/lkml/2017/11/21/384
>
> fix checkpatch --strict issues:
> -CHECK: Avoid using bool structure members because of possible alignment
> issues - see: https://lkml.org/lkml/2017/11/21/384
> -WARNING: Avoid using bool as bitfield. Prefer bool bitfields as
> unsigned int or u<8|16|32>
>
> Signed-off-by: Ludovic Barre <[email protected]>

Applied for next, thanks!

Kind regards
Uffe

> ---
> drivers/mmc/host/mmci.h | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 21aaf9a..01e6c6b 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -248,24 +248,24 @@ struct variant_data {
> unsigned int data_cmd_enable;
> unsigned int datactrl_mask_ddrmode;
> unsigned int datactrl_mask_sdio;
> - bool st_sdio;
> - bool st_clkdiv;
> - bool blksz_datactrl16;
> - bool blksz_datactrl4;
> + u8 st_sdio:1;
> + u8 st_clkdiv:1;
> + u8 blksz_datactrl16:1;
> + u8 blksz_datactrl4:1;
> u32 pwrreg_powerup;
> u32 f_max;
> - bool signal_direction;
> - bool pwrreg_clkgate;
> - bool busy_detect;
> + u8 signal_direction:1;
> + u8 pwrreg_clkgate:1;
> + u8 busy_detect:1;
> u32 busy_dpsm_flag;
> u32 busy_detect_flag;
> u32 busy_detect_mask;
> - bool pwrreg_nopower;
> - bool explicit_mclk_control;
> - bool qcom_fifo;
> - bool qcom_dml;
> - bool reversed_irq_handling;
> - bool mmcimask1;
> + u8 pwrreg_nopower:1;
> + u8 explicit_mclk_control:1;
> + u8 qcom_fifo:1;
> + u8 qcom_dml:1;
> + u8 reversed_irq_handling:1;
> + u8 mmcimask1:1;
> u32 start_err;
> u32 opendrain;
> void (*init)(struct mmci_host *host);
> @@ -290,7 +290,7 @@ struct mmci_host {
> struct mmc_data *data;
> struct mmc_host *mmc;
> struct clk *clk;
> - bool singleirq;
> + u8 singleirq:1;
>
> spinlock_t lock;
>
> @@ -304,7 +304,7 @@ struct mmci_host {
> u32 datactrl_reg;
> u32 busy_status;
> u32 mask1_reg;
> - bool vqmmc_enabled;
> + u8 vqmmc_enabled:1;
> struct mmci_platform_data *plat;
> struct mmci_host_ops *ops;
> struct variant_data *variant;
> @@ -330,7 +330,7 @@ struct mmci_host {
> struct dma_chan *dma_tx_channel;
> struct dma_async_tx_descriptor *dma_desc_current;
> struct mmci_host_next next_data;
> - bool dma_in_progress;
> + u8 dma_in_progress:1;
>
> #define dma_inprogress(host) ((host)->dma_in_progress)
> #endif
> --
> 2.7.4
>

2018-10-05 15:34:15

by Ludovic Barre

[permalink] [raw]

Subject: Re: [PATCH V5 02/24] mmc: mmci: create common mmci_dma_setup/release

On 10/05/2018 03:47 PM, Ulf Hansson wrote:
> On 5 October 2018 at 15:22, Ludovic Barre <[email protected]> wrote:
>> From: Ludovic Barre <[email protected]>
>>
>> This patch creates a common mmci_dma_setup/release which calls
>> dma_setup/release callbacks of mmci_host_ops and manages
>> common features like use_dma... If there is a fallbacks to
>> pio mode, dma functions must check use_dma.
>>
>> error management:
>> -mmci_dmae_setup fail if Tx and Rx dma channels are not defined
>> -qcom_dma_setup fail if one of both dma channels is not defined,
>> Qcom has no specific resource to release, just mmci dmae resource.
>
> Makes perfect sense!
>
> [...]
>
>> +void mmci_dma_setup(struct mmci_host *host)
>> +{
>> + if (!host->ops || !host->ops->dma_setup)
>> + return;
>> +
>> + if (host->ops->dma_setup(host)) {
>> + mmci_dma_release(host);
>
> Please remove this and let the variants clean up themselves. That
> makes it more straight forward.

This common call was not such a good idea.
Ok, I will back on first idea.

>
>> + return;
>> + }
>> +
>> + host->use_dma = true;
>> +}
>> +
>
> [...]
>
>> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
>> index 01e6c6b..9b0a960 100644
>> --- a/drivers/mmc/host/mmci.h
>> +++ b/drivers/mmc/host/mmci.h
>> @@ -273,7 +273,8 @@ struct variant_data {
>>
>> /* mmci variant callbacks */
>> struct mmci_host_ops {
>> - void (*dma_setup)(struct mmci_host *host);
>> + int (*dma_setup)(struct mmci_host *host);
>> + void (*dma_release)(struct mmci_host *host);
>> };
>>
>> struct mmci_host_next {
>> @@ -323,6 +324,7 @@ struct mmci_host {
>> unsigned int size;
>> int (*get_rx_fifocnt)(struct mmci_host *h, u32 status, int remain);
>>
>> + u8 use_dma:1;
>> #ifdef CONFIG_DMA_ENGINE
>> /* DMA stuff */
>> struct dma_chan *dma_current;
>> @@ -336,3 +338,14 @@ struct mmci_host {
>> #endif
>> };
>>
>> +#ifdef CONFIG_DMA_ENGINE
>> +void mmci_variant_init(struct mmci_host *host);
>> +#else
>> +static inline void mmci_variant_init(struct mmci_host *host)
>> +{
>> +}
>> +#endif
>
> This can be kept in mmci.c instead.

OK

>
>> +
>> +int mmci_dmae_setup(struct mmci_host *host);
>> +void mmci_dmae_release(struct mmci_host *host);
>> +
>> diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
>> index be3fab5..aa070a9 100644
>> --- a/drivers/mmc/host/mmci_qcom_dml.c
>> +++ b/drivers/mmc/host/mmci_qcom_dml.c
>> @@ -119,19 +119,22 @@ static int of_get_dml_pipe_index(struct device_node *np, const char *name)
>> }
>>
>> /* Initialize the dml hardware connected to SD Card controller */
>> -static void qcom_dma_setup(struct mmci_host *host)
>> +static int qcom_dma_setup(struct mmci_host *host)
>> {
>> u32 config;
>> void __iomem *base;
>> int consumer_id, producer_id;
>> struct device_node *np = host->mmc->parent->of_node;
>>
>> + if (mmci_dmae_setup(host))
>> + return -EINVAL;
>> +
>> consumer_id = of_get_dml_pipe_index(np, "tx");
>> producer_id = of_get_dml_pipe_index(np, "rx");
>>
>> if (producer_id < 0 || consumer_id < 0) {
>> host->variant->qcom_dml = false;
>> - return;
>> + return -EINVAL;
>
> This relies on error handling to be done by mmci_dma_setup(), which as
> stated, feels a bit wrong.
>
> I would rather just call mmci_dmae_realease() here, before returning -EINVAL.

OK

>
> [...]
>
> Otherwise, this looks good to me now.
>
> Kind regards
> Uffe
>