From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: "Viresh Kumar" <vireshk@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
dmaengine@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] dmaengine: dw: Add peripheral bus width verification
Date: Tue, 16 Apr 2024 21:00:50 +0300 [thread overview]
Message-ID: <Zh680h4h6hURIb82@smile.fi.intel.com> (raw)
In-Reply-To: <20240416162908.24180-2-fancer.lancer@gmail.com>
On Tue, Apr 16, 2024 at 07:28:55PM +0300, Serge Semin wrote:
> Currently the src_addr_width and dst_addr_width fields of the
> dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and
> CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the
> properly aligned data passed to the target device. It's done just by
> converting the passed peripheral bus width to the encoded value using the
> __ffs() function. This implementation has several problematic sides:
>
> 1. __ffs() is undefined if no bit exist in the passed value. Thus if the
> specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return
> unexpected value depending on the platform-specific implementation.
>
> 2. DW AHB DMA-engine permits having the power-of-2 transfer width limited
> by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying
> bus-width out of that constraints scope will definitely cause unexpected
> result since the destination reg will be only partly touched than the
> client driver implied.
>
> Let's fix all of that by adding the peripheral bus width verification
> method which would make sure that the passed source or destination address
> width is valid and if undefined then the driver will just fallback to the
> 1-byte width transfer.
Please, add a word that you apply the check in the dwc_config() which is
supposed to be called before preparing any transfer?
...
> +static int dwc_verify_p_buswidth(struct dma_chan *chan)
> +{
> + struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
> + struct dw_dma *dw = to_dw_dma(chan->device);
> + u32 reg_width, max_width;
> +
> + if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> + reg_width = dwc->dma_sconfig.dst_addr_width;
> + else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> + reg_width = dwc->dma_sconfig.src_addr_width;
> + else /* DMA_MEM_TO_MEM */
Actually not only this direction, but TBH I do not see value in these comments.
> + return 0;
> +
> + max_width = dw->pdata->data_width[dwc->dws.p_master];
> +
> + /* Fall-back to 1byte transfer width if undefined */
1-byte
(as you even used in the commit message correctly)
> + if (reg_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
> + reg_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> + else if (!is_power_of_2(reg_width) || reg_width > max_width)
> + return -EINVAL;
> + else /* bus width is valid */
> + return 0;
> +
> + /* Update undefined addr width value */
> + if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> + dwc->dma_sconfig.dst_addr_width = reg_width;
> + else /* DMA_DEV_TO_MEM */
> + dwc->dma_sconfig.src_addr_width = reg_width;
So, can't you simply call clamp() for both fields in dwc_config()?
> + return 0;
> +}
...
> + int err;
Hmm... we have two functions one of which is using different name for this.
Can we have a patch to convert to err the other one?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-04-16 18:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 16:28 [PATCH 0/4] dmaengine: dw: Fix src/dst addr width misconfig Serge Semin
2024-04-16 16:28 ` [PATCH 1/4] dmaengine: dw: Add peripheral bus width verification Serge Semin
2024-04-16 18:00 ` Andy Shevchenko [this message]
2024-04-17 19:54 ` Serge Semin
2024-04-18 9:43 ` Andy Shevchenko
2024-04-18 15:47 ` Serge Semin
2024-04-16 16:28 ` [PATCH 2/4] dmaengine: dw: Add memory " Serge Semin
2024-04-16 18:47 ` Andy Shevchenko
2024-04-17 17:13 ` Serge Semin
2024-04-17 17:28 ` Andy Shevchenko
2024-04-17 18:52 ` Serge Semin
2024-04-18 9:37 ` Andy Shevchenko
2024-04-18 15:52 ` Serge Semin
2024-04-16 16:28 ` [PATCH 3/4] dmaengine: dw: Simplify prepare CTL_LO methods Serge Semin
2024-04-16 19:04 ` Andy Shevchenko
2024-04-17 20:11 ` Serge Semin
2024-04-18 11:47 ` Andy Shevchenko
2024-04-18 19:00 ` Serge Semin
2024-04-18 21:00 ` Andy Shevchenko
2024-04-19 9:19 ` Serge Semin
2024-04-16 16:28 ` [PATCH 4/4] dmaengine: dw: Simplify max-burst calculation procedure Serge Semin
2024-04-16 19:11 ` Andy Shevchenko
2024-04-17 20:35 ` Serge Semin
2024-04-18 11:49 ` Andy Shevchenko
2024-04-18 19:10 ` Serge Semin
2024-04-16 19:13 ` [PATCH 0/4] dmaengine: dw: Fix src/dst addr width misconfig Andy Shevchenko
2024-04-17 17:34 ` Serge Semin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zh680h4h6hURIb82@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=vireshk@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox