Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
2727 discussions

by Lee Jones

On Fri, 21 Jun 2024, Markus Elfring wrote: > > The issue is one of communication and the way reviews are conducted. > > > > Reviewing other people's work is challenging and requires a certain > > skill-set, of which _excellent_ communication skills are non-negotiable. > > Patch feedback and change tolerance can vary also according to involved communities. Agreed. For this community, I suggest you build your skills for a while longer. > > Why not concentrate on more complex submissions for a while and grow > > your repertoire of common review points, > > Further collateral evolution can be considered there depending on > corresponding development resources. > > > rather than repeating the same few over and over? > > Some factors are probably known also according to corresponding statistics. > Several contributors are stumbling on recurring improvement possibilities > in published information. Right, this will always be true, however the few you've picked up on are not important enough to keep reiterating. By doing so, you're receiving undesirable attention. > > Reading other, more experienced maintainer's reviews would also be a good use > > of your time. > > I am trying to influence adjustments in desirable directions for a while. Never stop trying to improve. These are only my opinions of course. Take the advice or leave it. There's no need to reply to this. -- Lee Jones [李琼斯]

10 months, 1 week

Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure

by Lee Jones

On Fri, 21 Jun 2024, Markus Elfring wrote: > > Sadly, I am yet to see a constructive approach or even better a helpful > > patch which improve something, rather than vague suggestions on the list > > Can you get any more constructive impressions from another data representation? > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=… > > Are you aware how many change suggestions (also from my selection) are still > in various waiting queues? No one is doubting your overall contributions Markus. The issue is one of communication and the way reviews are conducted. Reviewing other people's work is challenging and requires a certain skill-set, of which _excellent_ communication skills are non-negotiable. Why not concentrate on more complex submissions for a while and grow your repertoire of common review points, rather than repeating the same few over and over? Reading other, more experienced maintainer's reviews would also be a good use of your time. -- Lee Jones [李琼斯]

10 months, 1 week

Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure

by Vinod Koul

On 20-06-24, 12:45, Markus Elfring wrote: > … > > All errors (new ones prefixed by >>): > > > >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label > > 1715 | goto err_dmabuf_unmap_attachment; > … > > Which software design options would you like to try out next > so that such a questionable compilation error message will be avoided finally? The one where all emails from Markus go to dev/null -- ~Vinod

10 months, 1 week

Re: [Patch V3] i2c: imx-lpi2c: add eDMA mode support for LPI2C

by kernel test robot

Hi, kernel test robot noticed the following build warnings: [auto build test WARNING on andi-shyti/i2c/i2c-host] [also build test WARNING on linus/master v6.10-rc4 next-20240620] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/carlos-song-nxp-com/i2c-imx-… base: git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git i2c/i2c-host patch link: https://lore.kernel.org/r/20240614045616.1751784-1-carlos.song%40nxp.com patch subject: [Patch V3] i2c: imx-lpi2c: add eDMA mode support for LPI2C config: loongarch-randconfig-r071-20240620 (https://download.01.org/0day-ci/archive/20240621/202406210604.bil4fzu2-lkp@…) compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240621/202406210604.bil4fzu2-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406210604.bil4fzu2-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/i2c/busses/i2c-imx-lpi2c.o: warning: objtool: unexpected relocation symbol type in .rela.discard.reachable -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

10 months, 1 week

Re: [PATCH v12 3/7] iio: core: Add new DMABUF interface infrastructure

by Lee Jones

On Thu, 20 Jun 2024, Markus Elfring wrote: > … > > v11: > … > > - Use guard(mutex) > > > > v12: > > - Revert to mutex_lock/mutex_unlock in iio_buffer_attach_dmabuf(), > > as it uses cleanup GOTOs > … > > I would find it nice if better design options could gain acceptance. > Will the chances grow to adjust scopes another bit for involved variables > in such function implementations? > > A) Enclosing a source code part with extra curly brackets? > > B) scoped_guard()? > https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L… > > C) Moving a locked source code part into a separate function implementation? I think it would help your cause if you quoted the exact piece of code you're referring to. Then tone down the language a bit - keep it as simple and natural as you can. Ex 1: Please place curly brackets around this section to aid with <reason> Ex 2: To save N lines of clean-up, please use scoped_guard() Ex 3: Moving out this chunk to another function would help with <reason> Etc. -- Lee Jones [李琼斯]

10 months, 1 week

Re: [PATCH v6 12/16] ASoC: codecs: add MT6357 support

by AngeloGioacchino Del Regno

Il 19/06/24 16:46, amergnat(a)baylibre.com ha scritto: > From: Nicolas Belin <nbelin(a)baylibre.com> > > Add the support of MT6357 PMIC audio codec. > > Signed-off-by: Nicolas Belin <nbelin(a)baylibre.com> > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

10 months, 1 week

Re: [PATCH v6 16/16] arm64: dts: mediatek: add audio support for mt8365-evk

by AngeloGioacchino Del Regno

Il 19/06/24 16:46, Alexandre Mergnat ha scritto: > Add the sound node which is linked to the MT8365 SoC AFE and > the MT6357 audio codec. > > Update the file header. > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

10 months, 1 week

Re: [PATCH] dma-buf/heaps: Correct the types of fd_flags and heap_flags

by Carlos Llamas

On Thu, Jun 06, 2024 at 02:02:13PM +1200, Barry Song wrote: > From: Barry Song <v-songbaohua(a)oppo.com> > > dma_heap_allocation_data defines the UAPI as follows: > > struct dma_heap_allocation_data { > __u64 len; > __u32 fd; > __u32 fd_flags; > __u64 heap_flags; > }; > > But dma heaps are casting both fd_flags and heap_flags into > unsigned long. This patch makes dma heaps - cma heap and > system heap have consistent types with UAPI. > > Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> > --- Looks good to me, thanks! Reviewed-by: Carlos Llamas <cmllamas(a)google.com>

10 months, 1 week

Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure

by Paul Cercueil

Le mercredi 19 juin 2024 à 13:56 +0200, Markus Elfring a écrit : > … > > https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.… > > > > (and responses below) > > > > It's more nuanced than I remembered. > … > > > > > * Will the desire grow for further collateral evolution according > > > to > > > affected software components? > > > > Not sure what you mean by that. > > Advanced programming interfaces were added a while ago. > > Example: > https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8 > > Corresponding attempts for increasing API usage need to adapt to > remaining change reluctance, > don't they? Sure, I guess. But that does not change the fact that I cannot use cleanup.h magic in this patchset, yet, as the required changes would have to be done in a separate one. Cheers, -Paul

10 months, 1 week

[PATCH v11 0/7] iio: new DMABUF based API v11

by Paul Cercueil

Hi Jonathan, Here's the v11 of my patchset that introduces DMABUF support to IIO. It addresses the few points that were raised in the review of the v10. It also adds Nuno as a co-developer. Changelog: - [3/7]: - Document .lock_queue / .unlock_queue buffer callbacks - Add small comment to explain what the spinlock protects - Use guard(mutex) - [4/7]: - Remove useless field "attach" in struct iio_dma_buffer_block - Document "sg_table" and "fence" fields in struct iio_block_state - [6/7]: - "a IIO buffer" -> "an IIO buffer" - Add variable name in IOCTL calls - [7/7]: New patch, to document the DMA changes Cheers, -Paul Paul Cercueil (7): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation: dmaengine: Document new dma_vec API Documentation/driver-api/dmaengine/client.rst | 9 + .../driver-api/dmaengine/provider.rst | 10 + Documentation/iio/iio_dmabuf_api.rst | 54 +++ Documentation/iio/index.rst | 1 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/Kconfig | 1 + drivers/iio/buffer/industrialio-buffer-dma.c | 178 ++++++- .../buffer/industrialio-buffer-dmaengine.c | 62 ++- drivers/iio/industrialio-buffer.c | 457 ++++++++++++++++++ include/linux/dmaengine.h | 33 ++ include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 33 ++ include/uapi/linux/iio/buffer.h | 22 + 13 files changed, 911 insertions(+), 20 deletions(-) create mode 100644 Documentation/iio/iio_dmabuf_api.rst -- 2.43.0

10 months, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig