On Tue, Jan 10, 2023 at 01:46:37PM +0100, Andrzej Hajda wrote:
> On 10.01.2023 12:07, Andy Shevchenko wrote:
> > On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote:
...
> > > + return __xchg(&p_chain->p_prod_elem,
> > > + (v
gt; + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) +
> p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle
Reviewed-by: Andy Shevchenko
> Signed-off-by: Andrzej Hajda
> ---
> include/linux/non-atomic/xchg.h | 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/linux/non-atomic/xchg.h
>
> diff --git a/include/linux/non-atomic/xchg.h b/include/l
e, the kernel has always
> assumed if there is a device described, then there is or will be a
> driver for it. The result is you can't use new DTs (if they add
> providers) with older kernels.
>
> We've ended up with a
flag for all serial drivers that at DT based. This way,
> fw_devlink will know not to delay the probing of the consoles past
> kernel boot.
Same question, do you think only serial drivers need that?
--
With Best Regards,
Andy Shevchenko
___
ole
> probe times back to how they were before the deferred_probe_timeout
> clean up series[2].
Are you sure it's only limited to the serial drivers?
(just asking, I don't know myself the answer)
--
With Best Regards,
Andy Shevchenko
__
h/powerpc/kernel/setup-common.c | 3 ++
> arch/riscv/kernel/setup.c | 2 +
> arch/sh/kernel/setup.c | 3 ++
> arch/xtensa/kernel/setup.c | 2 +
Isn't x86 missed? Is it on purpose?
Would be nice to have this in the commit me
; Signed-off-by: Andrey Abramov
> Reviewed by: George Spelvin
FWIW,
Reviewed-by: Andy Shevchenko
> ---
> arch/x86/kernel/unwind_orc.c | 2 +-
> include/linux/sort.h | 2 +-
> kernel/jump_label.c | 2 +-
> lib/extable.c| 2 +-
> lib/sort.c
On Mon, Apr 01, 2019 at 09:56:07AM +, George Spelvin wrote:
> On Mon, 1 Apr 2019 at 12:35:55 +0300, Andy Shevchenko wrote:
> > Hmm... If (*swap)() is called recursively it means the change might increase
> > stack usage on 64-bit platforms.
> >
> > Am I missing
gt; else
> - swap_func(a, b, (int)size);
> + swap_func(a, b, size);
> }
>
> /**
> @@ -187,7 +187,7 @@ static size_t parent(size_t i, unsigned int lsbit, size_t
> size)
> */
> void sort(void *base, size_t num, size_t size,
>
ifs: find.c: replace swap function with built-in one
> Lib: sort.h: replace int size with size_t size in the swap function
You have to do something about Cc list.
50 people is complete overkill. Seems as your series is a set of
independent fixes. Why not to split a
8250/8250_omap.c | 6 +++-
> drivers/tty/serial/8250/8250_port.c | 8 ++---
> drivers/tty/serial/qcom_geni_serial.c | 10 --
> include/linux/kgdb.h| 9 ++---
> include/linux/serial_core.h | 38 -
&g
ze_t size,
> void *kvaddr;
> int need_coh = 1, need_kvaddr = 0;
>
> - page = alloc_pages(gfp, order);
> + page = alloc_pages(gfp | __GFP_ZERO, order);
>
> if (!page)
> return NULL;
> ->8-
>
> B
e may only compile stuff on a very few arches.
>
> Lets cast this multiply to u64 type which prevents overflow.
>
FWIW,
Reviewed-by: Andy Shevchenko
> Tested-by: Vineet Gupta
> Reported-by: Vineet Gupta # ARC STAR 9001306872
> HSDK, sdio: board crashes when copying big f
On Tue, Feb 27, 2018 at 5:52 AM, Jisheng Zhang
wrote:
> On Mon, 26 Feb 2018 20:27:22 + Alexey Brodkin wrote:
>> On Mon, 2018-02-26 at 20:30 +0200, Andy Shevchenko wrote:
>> > On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
>> > wrote:
>> > > On Mon, 201
On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
wrote:
> On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
>> wrote:
>> > On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
>> > > On Mon, Fe
On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
wrote:
> On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
>> wrote:
>> > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
>>
nable(chip->core_clk);
Each of them may fail. Is it okay?
> +static const struct dev_pm_ops dw_axi_dma_pm_ops = {
> + SET_RUNTIME_PM_OPS(axi_dma_runtime_suspend, axi_dma_runtime_resume,
> NULL)
> +};
No system suspend?
> +/*
> + * Synopsys DesignWare AXI DMA Controller driver.
> + *
> + * Copyright (C) 2017-2018 Synopsys, Inc. (www.synopsys.com)
> + * Author: Eugeniy Paltsev
> + *
> + * SPDX-License-Identifier:GPL-2.0
First line, but C style of the comment.
> + */
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
nings
> and stacktrace splat (such as below) when accessing the SD Card.
> + drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
>host->bus_hz);
Same as per patch 2.
--
With Best Regards,
Andy Shevchenko
, someone commented on this or similar, i.e.
DIV_ROUND_UP_ULL() ?
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
* 2;
> if (drto_div == 0)
> drto_div = 1;
> - drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
> + drto_ms = DIV_ROUND_UP((uint64_t)MSEC_PER_SEC * drto_clks * drto_div,
>host->bu
ret = 0;
> + break;
> + }
> + udelay(2);
> + } while (timeout--);
Off-by-one. You will have 21 tries here.
} while (--timeout);
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
such a combination of parameters?
P.S. For doulble output ask Sergey and Petr (they are quite concerned
about it). Actually strange I didn't see their names in Cc list for
console related stuff,
--
With Best Regards,
Andy Shevchenko
___
linux-snps-a
On Thu, 2017-04-27 at 13:21 +, Eugeniy Paltsev wrote:
> On Wed, 2017-04-26 at 18:04 +0300, Andy Shevchenko wrote:
> > On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> > > On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote:
> > > > On Mon, 2
On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote:
> > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote:
> > > Descriptor is acti
On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote:
> On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote:
> > > Hi,
> > > On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote:
> > >
On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote:
> Hi,
> On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote:
> > On Fri, 2017-04-21 at 14:29 +, Eugeniy Paltsev wrote:
> > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:
> > > >
On Fri, 2017-04-21 at 14:29 +, Eugeniy Paltsev wrote:
> On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:
> > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:
> > > This patch adds support for the DW AXI DMAC controller.
> > >
> > > +#incl
gt; + * @DWAXIDMAC_IRQ_DST_SLV_ERR: Destination slave error
> + * @DWAXIDMAC_IRQ_LLI_RD_DEC_ERR: LLI read decode error
> + * @DWAXIDMAC_IRQ_LLI_WR_DEC_ERR: LLI write decode error
> + * @DWAXIDMAC_IRQ_LLI_RD_SLV_ERR: LLI read slave error
> + * @DWAXIDMAC_IRQ_LLI_WR_SLV_ERR: LLI write sl
> >
> >
> > This surprises me. I would expect more then 100+ LOC reduction when
> > switched to virt-dma API. Can you double check that you are using it
> > effectively?
>
> There is a simple explanation: I switched to virt-dma API (and it
> cause
> LOC reduction) and I implemented some TODOs (and it cause LOC
> increase).
Ah, that explains, indeed.
> Also about previous comment, which I missed before:
> > > +static u32 axi_chan_get_xfer_width(struct axi_dma_chan *chan,
> > > dma_addr_t src, dma_addr_t dst, size_t len)
> > > +{
> > > + u32 width;
> > > + dma_addr_t sdl = (src | dst | len);
> > > + u32 max_width = chan->chip->dw->hdata->m_data_width;
> >
> >
> > Use reverse tree.
> >
> > dma_addr_t use above is wrong. (size_t might be bigger in some
> > cases)
>
> What do you mean by the phrase "Use reverse tree" ?
Just convenient pattern: longest first.
On top of that logical groups of definitions:
a) assignments based on parameters;
b) other variables;
c) return variable last;
d) flags for spin lock -> depends.
Thus:
u32 max_width = chan->chip->dw->hdata->m_data_width;
dma_addr_t sdl = (src | dst | len);
u32 width;
But pay attention to your sdl, which is always nonzero.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
it.
You channel and driver, I'm sure, can't serve in interleaved mode with
descriptors. So, that makes channel(paused) == active
descriptor(paused).
The trick allows to make code cleaner.
> + ret = device_property_read_u32_array(dev, "priori
> drivers/dma/axi_dma_platform_reg.h | 189
> 6 files changed, 1415 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-
> dmac.txt
> create mode 100644 drivers/dma/axi_dma_platform.c
> create mode 100644 drivers/dma/axi_d
On Fri, Jan 20, 2017 at 8:21 PM, Eugeniy Paltsev
wrote:
> Hi Andy,
> thanks for respond.
>
> I'm agree with most of the comments.
> My comments below.
So my answers!
> On Fri, 2017-01-20 at 15:38 +0200, Andy Shevchenko wrote:
>> On Fri, 2017-01-20 at 13:50
On Fri, Jan 6, 2017 at 11:43 AM, Nicolas Dichtel
wrote:
> This header file is exported, thus move it to uapi.
Just hint for the future:
-M (move)
-C (copy)
-D (delete) [though this is NOT for applying]
--
With Best Regards,
Andy Shevchenko
___
li
On Fri, 2016-11-25 at 11:40 +, Eugeniy Paltsev wrote:
> On Thu, 2016-11-24 at 17:58 +0200, Andy Shevchenko wrote:
> > On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> > >
> > > On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > > &g
On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > Several versions of DW DMAC have multi block transfers hardware
> > support. Hardware support of multi block transfers is disabled
> > by default if we use
pdate. Basically I'm fine with this one.
So, we still have question about autoconfiguration in SPEAr SoCs, and
your ARC SoC but it's a different story. I would expect once you will
clarify it.
Another one is minor listed below, otherwise
Acked-by: Andy Shevchenko
> Signed-off-b
On Mon, 2016-11-21 at 10:02 +, Alexey Brodkin wrote:
> Hi Andy,
>
> On Fri, 2016-11-18 at 21:26 +0200, Andy Shevchenko wrote:
> > On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> > >
> > > It wasn't possible to enable some features like
>
itive property you have to update DTS. By the way, I'm
pretty sure that spare13xx boards has auto configuration enabled, though
it has to be checked with vendor (I assume you may have fast response
from them).
> }
> }
>
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
ers. So enable it by default.
> + */
> + pdata->is_memcpy = true;
> +
> if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
>
--
Andy Shevchenko
Intel Finland Oy
> Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 11 +++
> drivers/tty/serial/8250/8250_lpss.c|
On Fri, 2016-11-18 at 19:53 +0300, Eugeniy Paltsev wrote:
> All known devices, which use DT for configuration, support
> memory-to-memory transfers. So enable it by default, if we read
> configuration from DT.
>
Acked-by: Andy Shevchenko
> Signed-off-by: Eugeniy Paltsev
>
OCATION_DESCENDING 1 /* seven to zero
> */
> unsigned char chan_allocation_order;
> @@ -62,6 +61,7 @@ struct dw_dma_platform_data {
> unsigned intblock_size;
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> + unsigned char multi_block[DW_DMA_MAX_NR_MASTERS];
> };
>
> #endif /* _PLATFORM_DATA_DMA_DW_H */
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed, 2016-11-16 at 17:01 +, Eugeniy Paltsev wrote:
> On Wed, 2016-11-16 at 17:10 +0200, Andy Shevchenko wrote:
> > Overall, since we are going to expose some properties to the Device
> > Tree
> > I would really think twice about naming. Better if we reuse
> > som
tation/devicetree/bindings/dma/snps-dma.txt | 10 --
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 10 ++
> include/linux/platform_data/dma-dw.h | 4 ++--
&
nollp;
> #define CHAN_ALLOCATION_ASCENDING0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
> unsigned char chan_allocation_order;
> @@ -62,6 +61,7 @@ struct dw_dma_platform_data {
> unsigned intblock_size;
>
;is-memcpu"))
> + pdata->is_memcpy = true;
> +
> if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
>
--
Andy Shevchenko
Intel Finland Oy
___
han_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
t;
> @@ -56,7 +62,7 @@ The four cells in order are:
> 4. Peripheral master for transfers on allocated channel
>
> Example:
> -
> +
No, no need to touch this.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Nov 10, 2016 at 6:28 PM, Eugeniy Paltsev
wrote:
> On Tue, 2016-11-08 at 15:36 +0200, Andy Shevchenko wrote:
>> On Tue, 2016-11-08 at 12:22 +, Eugeniy Paltsev wrote:
>> > On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
>> > > > @@ -52,6 +55
On Tue, 2016-11-08 at 12:22 +, Eugeniy Paltsev wrote:
> On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
> > > + * @only_quirks_used: Only read quirks (like "is_private" or
> > > "is_memcpy") from
> > > + * platform data
ers/dma/dw/platform.c| 53 +++
> > ---
> > --
> > drivers/dma/dw/regs.h| 2 +-
> > include/linux/platform_data/dma-dw.h | 5
> > 4 files changed, 54 insertions(+), 40 deletions(-)
> >
>
> --
> Paltsev Eugeniy
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
" to "dwc->flags"
>
> drivers/dma/dw/core.c| 34 +--
> drivers/dma/dw/platform.c| 53 +++--
> ---
> drivers/dma/dw/regs.h| 2 +-
> include/linux/platform_data/dma-dw.h | 5
> 4 files cha
rting from 0 or 7
> * @chan_priority: Set channel priority increasing from 0 to 7 or 7
> to 0.
> @@ -52,6 +55,7 @@ struct dw_dma_platform_data {
> unsigned intnr_channels;
> boolis_private;
> boolis_memcpy;
> + boolonly_quirks_used;
Perhaps add if at the end of quirk list and name just
> boolis_nollp;
...here
bool use_quirks;
> #define CHAN_ALLOCATION_ASCENDING0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, 2016-10-20 at 13:16 +, Eugeniy Paltsev wrote:
> On Thu, 2016-10-20 at 13:48 +0300, Andy Shevchenko wrote:
> > On Thu, 2016-09-15 at 16:14 +0300, Eugeniy Paltsev wrote:
> > >
> > > This patch is to address a proposal by Andy in this thread:
> > > ht
p: The device channels does not support multi block
> transfers.
> + * @quirks: Bit field with platform quirks
> * @chan_allocation_order: Allocate channels starting from 0 or 7
> * @chan_priority: Set channel priority increasing from 0 to 7 or 7
> to 0.
>
On Wed, 2016-10-05 at 15:14 +, Eugeniy Paltsev wrote:
> Hi Andy,
> what do you think about these changes?
I was off for few weeks, will look at this next week.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-sn
n't support memory-
> to-memory transfers, I can disable "is_memcpy" in this board .dts
> file.
> Am I wrong?
Some of the properties are set or unset due to support in the driver and
/ or issues of the hardware _related_ to the driver in question.
Though if anyone has different opinion I would appreciate to listen to.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
his one (besides that fact that it misses documentation
update and '-' instead of '_' as ordered by DT policy) is unacceptable
in DT since it represents *OS related* quirks. (Btw, is_private is also
should not be there in the first place)
Rob Herring (Cc'ed) might shed a light h
On Tue, 2016-08-16 at 11:32 +, Eugeniy Paltsev wrote:
> On Mon, 2016-08-15 at 15:41 +0300, Andy Shevchenko wrote:
> > On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:
> > Consider to review
> > http://www.spinics.net/lists/dmaengine/msg10682.html
> Looks go
On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:
> On Fri, 2016-08-12 at 17:08 +0300, Andy Shevchenko wrote:
> >
> > > > > "nollp" parameter defines if DW DMAC channel supports multi
> > > > > block
> > > > > transfe
On Fri, 2016-08-12 at 13:36 +, Eugeniy Paltsev wrote:
> On Fri, 2016-08-12 at 13:59 +0300, Andy Shevchenko wrote:
> >
> > On Fri, 2016-08-12 at 08:03 +, Eugeniy Paltsev wrote:
> > >
> > >
> > > Hi,
> > >
> > > "
e we use "is_private" or "is_memcpu"
> fields)
Yeah, perhaps we can remove that trick since we need this flag to be set
on Intel Quark which might have the same issue as your case [1].
[1] http://www.spinics.net/lists/linux-serial/msg22948.html
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed, 2016-08-10 at 12:22 +, Alexey Brodkin wrote:
> Hi Andy,
>
> On Wed, 2016-08-10 at 15:15 +0300, Andy Shevchenko wrote:
> >
> > On Wed, 2016-08-10 at 11:06 +, Eugeniy Paltsev wrote:
> > >
> > >
> > > dmatest on ARC SDP with DW DMA
from only one source (pdata/device
> tree/autoconfig) or we may mix some of them (for example getting
> missing data from autoconf regs)?
See above.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
esn't really seem worth doing to me.
The big issue with DT, you know, is hanging around names. This moves
name to be de facto standard for similar in the other drivers.
--
Andy Shevchenko
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps
On Mon, 2016-01-25 at 10:31 +, Måns Rullgård wrote:
> Andy Shevchenko writes:
>
> > On Mon, 2016-01-25 at 07:32 +, Vineet Gupta wrote:
> > > On Monday 25 January 2016 12:55 AM, Mans Rullgard wrote:
> > > > --- a/Documentation/devicetree/bindin
On Mon, 2016-01-25 at 07:32 +, Vineet Gupta wrote:
> On Monday 25 January 2016 12:55 AM, Mans Rullgard wrote:
> > From: Andy Shevchenko
> >
> > There are several changes are done here:
> >
> > - Convert the property to be in bytes
> >
> > Mu
On Sun, 2016-01-24 at 19:21 +, Mans Rullgard wrote:
> From: Andy Shevchenko
>
> There are several changes are done here:
>
> - Convert the property to be in bytes
>
> Much more convenient than keeping encoded value.
>
> - Use one value for all AHB masters
69 matches
Mail list logo
