Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem
On Tue, Jan 22, 2019 at 4:50 PM Miquel Raynal wrote:
>
> Hi Masahiro,
>
> Masahiro Yamada wrote on Tue, 22 Jan
> 2019 16:42:55 +0900:
>
> > Although drivers do not directly get access to the private data of
> > instruction patterns, let's use unnamed union field to be consistent
> > with nand_op_instr.
> >
>
> Actually this is how we wrote it the first time. Then we got robots
> reporting that anonymous unions where not allowed with older (still
> supported) GCC versions and I had to do this:
>
>
> commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce
> Author: Miquel Raynal
> Date: Fri Jan 19 19:11:27 2018 +0100
>
> mtd: nand: Fix build issues due to an anonymous union
>
> GCC-4.4.4 raises errors when assigning a parameter in an anonymous
> union, leading to this kind of failure:
>
> drivers/mtd/nand/marvell_nand.c:1936:
> warning: missing braces around initializer
> warning: (near initialization for '(anonymous)[1].')
> error: unknown field 'data' specified in initializer
> error: unknown field 'addr' specified in initializer
>
> Work around the situation by naming these unions.
>
> Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
> Reported-by: Andrew Morton
> Signed-off-by: Miquel Raynal
> Tested-by: Andrew Morton
> Signed-off-by: Boris Brezillon
>
Hmm, how come Andrew's compiler was fine with the following?
struct nand_flash_dev {
char *name;
union {
struct {
uint8_t mfr_id;
uint8_t dev_id;
};
uint8_t id[NAND_MAX_ID_LEN];
};
unsigned int pagesize;
...
};
The current minimum version is GCC 4.6
(commit cafa0010cd51fb7)
but I am not sure if this restriction is remaining.
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/3] scsi: arcmsr: Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2
On Tue, 2019-01-22 at 10:48 +0300, Dan Carpenter wrote:
> On Thu, Jan 17, 2019 at 05:52:28PM +0800, Ching Huang wrote:
> > On Thu, 2019-01-17 at 12:16 +0300, Dan Carpenter wrote:
> > > On Thu, Jan 17, 2019 at 04:47:07PM +0800, Ching Huang wrote:
> > > > On Thu, 2019-01-17 at 10:59 +0300, Dan Carpenter wrote:
> > > > > On Thu, Jan 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > > > > > >From Ching Huang
> > > > > >
> > > > > > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
> > > > > >
> > > > >
> > > > > What does this look like from a user perspective? Does it fail every
> > > > > time or does it only fail sometimes?
> > > > >
> > > > > What's the bug exactly?
> > > > >
> > > > > There is no Fixes tag...
> > > > >From user's perspective, hibernate/resume are OK.
> > > > But following IO may cause 'isr get an illegal ccb command' in
> > > > log/messages sometime.
> > > > >
> > >
> > >
> > > You will need to resend with that information included in the commit
> > > message.
> > OK. I will resend this patch later.
> > >
> > > > > > Signed-off-by: Ching Huang
> > > > > > ---
> > > > > >
> > > > > > diff --git a/drivers/scsi/arcmsr/arcmsr.h
> > > > > > b/drivers/scsi/arcmsr/arcmsr.h
> > > > > > index a94c513..b98c632 100755
> > > > > > --- a/drivers/scsi/arcmsr/arcmsr.h
> > > > > > +++ b/drivers/scsi/arcmsr/arcmsr.h
> > > > > > @@ -508,9 +508,9 @@ struct MessageUnit_A
> > > > > > struct MessageUnit_B
> > > > > > {
> > > > > > uint32_tpost_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > > > - uint32_tdone_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > > > + volatile uint32_t done_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
> > > > >
> > > > > There is a well known rule of thumb that when someone uses "volatile"
> > > > > in the kernel it means there is a locking problem... Is this __iomem
> > > > > or
> > > > > something?
> > > > The done_qbuffer was a command completion queue, it was an area written
> > > > by IO processor and read by device driver. So, ...
> > >
> > > I'm not totally positive I understand this sentence. I can find a bunch
> > > of places which read from this buffer, but I haven't immediately found
> > > which place writes to it. Can you give me a function name that I should
> > > read?
> > Well, we allocate memory for struct MessageUnit_B in
> > arcmsr_alloc_ccb_pool(), by assign to acb->dma_coherent_handle2.
> > Then we tell IO controller its DMA address in arcmsr_iop_confirm().
> > When a command was completed, controller's firmware program will write a
> > completion ccb in done_qbuffer through DMA. So, you can't see any driver
> > funtion write to it.
>
> DMA memory doesn't need to be marked as volatile.
I see. So I have removed the volatile in patch v2.
>
> regards,
> dan carpenter
>
Re: [PATCH v2 3/6] usb: host: Stops USB controller init if PLL fails to lock
On Mon, Jan 21, 2019 at 10:25:10AM +, Yinbo Zhu wrote: > From: yinbo.zhu This line is still wrong :(
Re: [PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On 01/22/2019 07:26 AM, Alexandre Courbot wrote: > Documents the protocol that user-space should follow when > communicating with stateless video decoders. > > The stateless video decoding API makes use of the new request and tags > APIs. While it has been implemented with the Cedrus driver so far, it > should probably still be considered staging for a short while. > > Signed-off-by: Alexandre Courbot > --- > Changes since v1: > > * Use timestamps instead of tags to reference frames, > * Applied Paul's suggestions to not require one frame worth of data per OUTPUT > buffer > > One of the effects of requiring sub-frame units to be submitted per request is > that the stateless decoders are not exactly "stateless" anymore: if a frame is > made of several slices, then the decoder must keep track of the buffer in > which > the current frame is being decoded between requests, and all the slices for > the > current frame must be submitted before we can consider decoding the next one. > > Also if we decide to force clients to submit one slice per request, then > doesn't > some of the H.264 controls need to change? For instance, in the current v2 > there is still a v4l2_ctrl_h264_decode_param::num_slices member. It is used in > Chromium to specify the number of slices given to the > V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS control, but is apparently ignored by > the > Cedrus driver. Maxime, can you comment on this? > > Documentation/media/uapi/v4l/dev-codec.rst| 5 + > .../media/uapi/v4l/dev-stateless-decoder.rst | 378 ++ > 2 files changed, 383 insertions(+) > create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst > Thank you! I have uploaded a version of the V4L2 spec with this and the two older stateful codec patches applied: https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-codec.html Regards, Hans
[PATCH 1/2] x86: respect memory size limiting via mem= parameter
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices due to corresponding ACPI table entries.
Not respecting "mem=" can be corrected by adding a global max_mem_size
variable set by parse_memopt() which will result in rejecting adding
memory areas resulting in a memory size above the allowed limit.
Signed-off-by: Juergen Gross
---
arch/x86/kernel/e820.c | 5 +
include/linux/memory_hotplug.h | 2 ++
mm/memory_hotplug.c| 6 ++
3 files changed, 13 insertions(+)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 50895c2f937d..e67513e2cbbb 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -881,6 +882,10 @@ static int __init parse_memopt(char *p)
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
+#ifdef CONFIG_MEMORY_HOTPLUG
+ max_mem_size = mem_size;
+#endif
+
return 0;
}
early_param("mem", parse_memopt);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 07da5c6c5ba0..fb6bd0022d41 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -98,6 +98,8 @@ extern void __online_page_free(struct page *page);
extern int try_online_node(int nid);
+extern u64 max_mem_size;
+
extern bool memhp_auto_online;
/* If movable_node boot option specified */
extern bool movable_node_enabled;
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b9a667d36c55..7fc2a87110a3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -96,10 +96,16 @@ void mem_hotplug_done(void)
cpus_read_unlock();
}
+u64 max_mem_size = -1;
+
/* add this memory to iomem resource */
static struct resource *register_memory_resource(u64 start, u64 size)
{
struct resource *res, *conflict;
+
+ if (start + size > max_mem_size)
+ return ERR_PTR(-E2BIG);
+
res = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!res)
return ERR_PTR(-ENOMEM);
--
2.16.4
[PATCH 0/2] x86: respect memory size limits
On a customer system running Xen a boot problem was observed due to the kernel not respecting the memory size limit imposed by the Xen hypervisor. During analysis I found the same problem should be able to occur on bare metal in case the memory would be limited via the "mem=" boot parameter. The system this problem has been observed on has tons of memory added via PCI. So while in the E820 map the not to be used memory has been wiped out the additional PCI memory is detected during ACPI scan and it is added via __add_memory(). This small series tries to repair the issue by testing the imposed memory limit during the memory hotplug process and refusing to add it in case the limit is being violated. I've chosen to refuse adding the complete memory chunk in case the limit is reached instead of adding only some of the memory, as I thought this would result in less problems (e.g. avoiding to add only parts of a 128MB memory bar which might be difficult to remove later). Juergen Gross (2): x86: respect memory size limiting via mem= parameter x86/xen: dont add memory above max allowed allocation arch/x86/kernel/e820.c | 5 + arch/x86/xen/setup.c | 5 + include/linux/memory_hotplug.h | 2 ++ mm/memory_hotplug.c| 6 ++ 4 files changed, 18 insertions(+) -- 2.16.4
[PATCH 2/2] x86/xen: dont add memory above max allowed allocation
Don't allow memory to be added above the allowed maximum allocation limit set by Xen. Trying to do so would result in cases like the following: [ 584.559652] [ cut here ] [ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129 xen_alloc_pte+0x1c7/0x390() [ 584.575151] Modules linked in: [ 584.578643] Supported: Yes [ 584.581750] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.120-92.70-default #1 [ 584.59] Hardware name: Cisco Systems Inc UCSC-C460-M4/UCSC-C460-M4, BIOS C460M4.4.0.1b.0.0629181419 06/29/2018 [ 584.601862] 813175a0 8184777c [ 584.610200] 8107f4e1 880487eb7000 8801862b79c0 88048608d290 [ 584.618537] 00487eb7 ea000201 81009de7 81068561 [ 584.626876] Call Trace: [ 584.629699] [] dump_trace+0x59/0x340 [ 584.635645] [] show_stack_log_lvl+0xea/0x170 [ 584.642391] [] show_stack+0x21/0x40 [ 584.648238] [] dump_stack+0x5c/0x7c [ 584.654085] [] warn_slowpath_common+0x81/0xb0 [ 584.660932] [] xen_alloc_pte+0x1c7/0x390 [ 584.667289] [] pmd_populate_kernel.constprop.6+0x40/0x80 [ 584.675241] [] phys_pmd_init+0x210/0x255 [ 584.681587] [] phys_pud_init+0x1da/0x247 [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 [ 584.695682] [] init_memory_mapping+0x18d/0x380 [ 584.702631] [] arch_add_memory+0x59/0xf0 Signed-off-by: Juergen Gross --- arch/x86/xen/setup.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index d5f303c0e656..5929a6ba5c25 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -785,6 +786,10 @@ char * __init xen_memory_setup(void) /* How many extra pages do we need due to remapping? */ max_pages += xen_foreach_remap_area(max_pfn, xen_count_remap_pages); +#ifdef CONFIG_MEMORY_HOTPLUG + max_mem_size = PFN_PHYS(max_pages); +#endif + if (max_pages > max_pfn) extra_pages += max_pages - max_pfn; -- 2.16.4
Re: [PATCH v2 1/6] usb: fsl: Set USB_EN bit to select ULPI phy
On Mon, Jan 21, 2019 at 10:25:00AM +, Yinbo Zhu wrote: > From: Nikhil Badola > > Set USB_EN bit to select ULPI phy for USB controller version 2.5 > > Signed-off-by: Nikhil Badola > Signed-off-by: Yinbo Zhu > --- > Change in v2: > replace Yinbo.Zhu with Yinbo Zhu > > drivers/usb/host/ehci-fsl.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) This patch doesn't apply against my usb-next branch, what did you generate it against? thanks, greg k-h
Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem
Hi Masahiro,
Masahiro Yamada wrote on Tue, 22 Jan
2019 17:00:54 +0900:
> On Tue, Jan 22, 2019 at 4:50 PM Miquel Raynal
> wrote:
> >
> > Hi Masahiro,
> >
> > Masahiro Yamada wrote on Tue, 22 Jan
> > 2019 16:42:55 +0900:
> >
> > > Although drivers do not directly get access to the private data of
> > > instruction patterns, let's use unnamed union field to be consistent
> > > with nand_op_instr.
> > >
> >
> > Actually this is how we wrote it the first time. Then we got robots
> > reporting that anonymous unions where not allowed with older (still
> > supported) GCC versions and I had to do this:
> >
> >
> > commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce
> > Author: Miquel Raynal
> > Date: Fri Jan 19 19:11:27 2018 +0100
> >
> > mtd: nand: Fix build issues due to an anonymous union
> >
> > GCC-4.4.4 raises errors when assigning a parameter in an anonymous
> > union, leading to this kind of failure:
> >
> > drivers/mtd/nand/marvell_nand.c:1936:
> > warning: missing braces around initializer
> > warning: (near initialization for '(anonymous)[1].')
> > error: unknown field 'data' specified in initializer
> > error: unknown field 'addr' specified in initializer
> >
> > Work around the situation by naming these unions.
> >
> > Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
> > Reported-by: Andrew Morton
> > Signed-off-by: Miquel Raynal
> > Tested-by: Andrew Morton
> > Signed-off-by: Boris Brezillon
> >
>
>
> Hmm, how come Andrew's compiler was fine with the following?
>
> struct nand_flash_dev {
> char *name;
> union {
> struct {
> uint8_t mfr_id;
> uint8_t dev_id;
> };
> uint8_t id[NAND_MAX_ID_LEN];
> };
> unsigned int pagesize;
> ...
> };
>
It is probably not :)
>
>
> The current minimum version is GCC 4.6
> (commit cafa0010cd51fb7)
> but I am not sure if this restriction is remaining.
>
That's right, can you please test if this limitation is still
ongoing wit GCC 4.6?
Thanks,
Miquèl
Re: [PATCH 3/4] dt-bindings: spi: Add the DMA properties for the SPI dma mode
Hi Baolin,
On Tue, Jan 22, 2019 at 3:23 AM Baolin Wang wrote:
> On Mon, 21 Jan 2019 at 21:53, Rob Herring wrote:
> > On Tue, Jan 15, 2019 at 7:47 AM Baolin Wang wrote:
> > > From: Lanqing Liu
> >
> > The email address should be updated with unisoc.com.
>
> Sure.
>
> >
> > > Add the DMA properties for the SPI dma mode.
> > >
> > > Signed-off-by: Lanqing Liu
> > > Signed-off-by: Baolin Wang
> > > ---
> > > Documentation/devicetree/bindings/spi/spi-sprd.txt |9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > b/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > index bad211a..01ef53f 100644
> > > --- a/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > +++ b/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > @@ -14,6 +14,12 @@ Required properties:
> > > address on the SPI bus. Should be set to 1.
> > > - #size-cells: Should be set to 0.
> > >
> > > +Optional properties:
> > > +dma-names: Should contain names of the SPI used DMA channel.
> > > +dmas: Should contain DMA channels which the SPI used sorted in the
> > > + same order as the dma-names property.
> > > +sprd,dma-slave-ids: Should contain the DMA number that the SPI hardware
> > > required.
> > > +
> > > Example:
> > > spi0: spi@70a0{
> > > compatible = "sprd,sc9860-spi";
> > > @@ -21,6 +27,9 @@ spi0: spi@70a0{
> > > interrupts = ;
> > > clock-names = "spi", "source","enable";
> > > clocks = <&clk_spi0>, <&ext_26m>, <&clk_ap_apb_gates 5>;
> > > + dma-names = "rx_chn", "tx_chn";
> > > + dmas = <&apdma 11>, <&apdma 12>;
> > > + sprd,dma-slave-ids = <11 12>;
> >
> > When would this be different values from what's in 'dmas'?
>
> Slave id is not always same with the DMA channel number in 'dmas', and
> it is just coincident for SPI driver. Moreover for different SoC , the
> slave ids for DMA engine consumers are not same. So we need one
> property to specify the slave id for the consumers to trigger DMA
> transfer.
Perhaps the DMA controller should use #dma-cells = <2>, so you can specify
the second value in the dmas property?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Greetings From Mrs Elodie Antoine,
-- Greetings From Mrs Elodie Antoine, May be this letter will definitely come to you as a huge surprise, but I implore you to take the time to go through it carefully as the decision you make will go off a long way to determine my future and continued existence. I am Mrs.Elodie Antoine aging widow of 59 years old suffering from long time illness. I have some funds I inherited from my late husband Dr. jean baptiste Adrien,The sum of (US$4.5 Million Dollars) please i want you to withdraw this fund and use it for Charity works. I found your email address from the internet after honest prayers to the LORD to bring me a good person that can handle this project and i decided to contact you, if you may be willing and interested to handle these trust funds in good faith before anything happens to me, Please kindly respond for further details. Thanks and God bless you, Mrs Elodie Antoine --
[PATCH] clk: sunxi-ng: v3s: Fix TCON reset de-assert bit
According to the datasheet and the reference code from Allwinner, the
bit used to de-assert the TCON reset is bit 4, not bit 3.
Fix it in the V3s CCU driver.
Signed-off-by: Paul Kocialkowski
---
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
index 621b1cd996db..ac12f261f8ca 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
@@ -542,7 +542,7 @@ static struct ccu_reset_map sun8i_v3s_ccu_resets[] = {
[RST_BUS_OHCI0] = { 0x2c0, BIT(29) },
[RST_BUS_VE]= { 0x2c4, BIT(0) },
- [RST_BUS_TCON0] = { 0x2c4, BIT(3) },
+ [RST_BUS_TCON0] = { 0x2c4, BIT(4) },
[RST_BUS_CSI] = { 0x2c4, BIT(8) },
[RST_BUS_DE]= { 0x2c4, BIT(12) },
[RST_BUS_DBG] = { 0x2c4, BIT(31) },
--
2.20.1
Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework
Hello Dan,
looks already quite good...
Am 17.01.19 um 21:05 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration
> support of the IP.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/net/can/m_can/m_can.c | 6 +
> drivers/net/can/m_can/m_can_platform.c | 209 +
> drivers/net/can/m_can/m_can_platform.h | 163 +++
> 3 files changed, 378 insertions(+)
> create mode 100644 drivers/net/can/m_can/m_can_platform.c
> create mode 100644 drivers/net/can/m_can/m_can_platform.h
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..f817b28582e9 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -414,6 +414,9 @@ static inline void m_can_config_endisable(const struct
> m_can_priv *priv,
> u32 timeout = 10;
> u32 val = 0;
>
> + if (cccr & CCCR_CSR)
> + cccr &= ~CCCR_CSR;
> +
This is an unrelated change/fix. Should go somewhere else.
> if (enable) {
> /* enable m_can configuration */
> m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT);
> @@ -1155,6 +1158,9 @@ static void m_can_chip_config(struct net_device *dev)
> m_can_set_bittiming(dev);
>
> m_can_config_endisable(priv, false);
> +
> + if (priv->device_init)
> + priv->device_init(priv);
> }
>
> static void m_can_start(struct net_device *dev)
> diff --git a/drivers/net/can/m_can/m_can_platform.c
> b/drivers/net/can/m_can/m_can_platform.c
> new file mode 100644
> index ..03172911323a
> --- /dev/null
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -0,0 +1,209 @@
> +/*
> + * CAN bus driver for Bosch M_CAN controller
> + *
> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
> + * Dong Aisheng
> + *
> + * Bosch M_CAN user manual can be obtained from:
> + * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
> + * mcan_users_manual_v302.pdf
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "m_can_platform.h"
> +
> +struct m_can_plat_priv {
> + void __iomem *base;
> + void __iomem *mram_base;
> +};
> +
> +static u32 iomap_read_reg(struct m_can_classdev *m_can_class, int reg)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv
> *)m_can_class->device_data;
> +
> + return readl(priv->base + reg);
> +}
> +
> +static u32 iomap_read_fifo(struct m_can_classdev *m_can_class, int
> addr_offset)
Why not just "offset".
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv
> *)m_can_class->device_data;
> +
> + return readl(priv->mram_base + addr_offset);
> +}
> +
> +static int iomap_write_reg(struct m_can_classdev *m_can_class, int reg, int
> val)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv
> *)m_can_class->device_data;
> +
> + writel(val, priv->base + reg);
> +
> + return 0;
> +}
> +
> +static int iomap_write_fifo(struct m_can_classdev *m_can_class, int
> addr_offset, int val)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv
> *)m_can_class->device_data;
> +
> + writel(val, priv->base + addr_offset);
> +
> + return 0;
> +}
> +
> +static int m_can_plat_probe(struct platform_device *pdev)
> +{
> + struct m_can_classdev *mcan_class;
> + struct m_can_plat_priv *priv;
> + struct resource *res;
> + void __iomem *addr;
> + void __iomem *mram_addr;
> + int irq, ret = 0;
> +
> + mcan_class = m_can_core_allocate_dev(&pdev->dev);
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + mcan_class->device_data = priv;
> +
> + m_can_core_get_clocks(mcan_class);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
> + addr = devm_ioremap_resource(&pdev->dev, res);
> + irq = platform_get_irq_byname(pdev, "int0");
> + if (IS_ERR(addr) || irq < 0) {
> + ret = -EINVAL;
> + goto failed_ret;
> + }
> +
> + /* message ram could be shared */
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram");
> + if (!res) {
> + ret = -ENODEV;
> + goto failed_ret;
> + }
> +
> + mram_addr = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!mram_addr) {
> + ret = -ENOMEM;
> + goto failed_ret;
> + }
> +
> + priv->base = addr;
> + priv->mram_base = mram_addr;
> +
> + mcan_class->net->irq = irq;
> +
Re: [PATCH] media: docs-rst: Document m2m stateless video decoder interface
Hi Paul,
On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> Thanks for this new version! I only have one comment left, see below.
>
> On Wed, 2018-12-05 at 19:01 +0900, Alexandre Courbot wrote:
> > Documents the protocol that user-space should follow when
> > communicating with stateless video decoders.
> >
> > The stateless video decoding API makes use of the new request and tags
> > APIs. While it has been implemented with the Cedrus driver so far, it
> > should probably still be considered staging for a short while.
> >
> > Signed-off-by: Alexandre Courbot
> > ---
> > Removing the RFC flag this time. Changes since RFCv3:
> >
> > * Included Tomasz and Hans feedback,
> > * Expanded the decoding section to better describe the use of requests,
> > * Use the tags API.
> >
> > Documentation/media/uapi/v4l/dev-codec.rst| 5 +
> > .../media/uapi/v4l/dev-stateless-decoder.rst | 399 ++
> > 2 files changed, 404 insertions(+)
> > create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> >
> > diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
> > b/Documentation/media/uapi/v4l/dev-codec.rst
> > index c61e938bd8dc..3e6a3e883f11 100644
> > --- a/Documentation/media/uapi/v4l/dev-codec.rst
> > +++ b/Documentation/media/uapi/v4l/dev-codec.rst
> > @@ -6,6 +6,11 @@
> > Codec Interface
> > ***
> >
> > +.. toctree::
> > +:maxdepth: 1
> > +
> > +dev-stateless-decoder
> > +
> > A V4L2 codec can compress, decompress, transform, or otherwise convert
> > video data from one format into another format, in memory. Typically
> > such devices are memory-to-memory devices (i.e. devices with the
> > diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > new file mode 100644
> > index ..7a781c89bd59
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > @@ -0,0 +1,399 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _stateless_decoder:
> > +
> > +**
> > +Memory-to-memory Stateless Video Decoder Interface
> > +**
> > +
> > +A stateless decoder is a decoder that works without retaining any kind of
> > state
> > +between processing frames. This means that each frame is decoded
> > independently
> > +of any previous and future frames, and that the client is responsible for
> > +maintaining the decoding state and providing it to the decoder with each
> > +decoding request. This is in contrast to the stateful video decoder
> > interface,
> > +where the hardware and driver maintain the decoding state and all the
> > client
> > +has to do is to provide the raw encoded stream.
> > +
> > +This section describes how user-space ("the client") is expected to
> > communicate
> > +with such decoders in order to successfully decode an encoded stream.
> > Compared
> > +to stateful codecs, the decoder/client sequence is simpler, but the cost of
> > +this simplicity is extra complexity in the client which must maintain a
> > +consistent decoding state.
> > +
> > +Stateless decoders make use of the request API and buffer tags. A stateless
> > +decoder must thus expose the following capabilities on its queues when
> > +:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are invoked:
> > +
> > +* The ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability must be set on the
> > + ``OUTPUT`` queue,
> > +
> > +* The ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability must be set on the
> > ``OUTPUT``
> > + and ``CAPTURE`` queues,
> > +
>
> [...]
>
> > +Decoding
> > +
> > +
> > +For each frame, the client is responsible for submitting a request to
> > which the
> > +following is attached:
> > +
> > +* Exactly one frame worth of encoded data in a buffer submitted to the
> > + ``OUTPUT`` queue,
>
> Although this is still the case in the cedrus driver (but will be fixed
> eventually), this requirement should be dropped because metadata is
> per-slice and not per-picture in the formats we're currently aiming to
> support.
>
> I think it would be safer to mention something like filling the output
> buffer with the minimum unit size for the selected output format, to
> which the associated metadata applies.
I'm not sure it's a good idea. Some of the reasons why I think so:
1) There are streams that can have even 32 slices. With that, you
instantly run out of V4L2 buffers even just for 1 frame.
2) The Rockchip hardware which seems to just pick all the slices one
after another and which was the reason to actually put the slice data
in the buffer like that.
3) Not all the metadata is per-slice. Actually most of the metadata
is per frame and only what is located inside v4l2_h264_slice_param is
per-slice. The corresponding control is an array, which has an entry
for each slice in the buffer. Each entry includes an offset field,
which points to th
Re: [PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On Tue, Jan 22, 2019 at 5:06 PM Hans Verkuil wrote: > > On 01/22/2019 07:26 AM, Alexandre Courbot wrote: > > Documents the protocol that user-space should follow when > > communicating with stateless video decoders. > > > > The stateless video decoding API makes use of the new request and tags > > APIs. While it has been implemented with the Cedrus driver so far, it > > should probably still be considered staging for a short while. > > > > Signed-off-by: Alexandre Courbot > > --- > > Changes since v1: > > > > * Use timestamps instead of tags to reference frames, > > * Applied Paul's suggestions to not require one frame worth of data per > > OUTPUT > > buffer > > > > One of the effects of requiring sub-frame units to be submitted per request > > is > > that the stateless decoders are not exactly "stateless" anymore: if a frame > > is > > made of several slices, then the decoder must keep track of the buffer in > > which > > the current frame is being decoded between requests, and all the slices for > > the > > current frame must be submitted before we can consider decoding the next > > one. > > > > Also if we decide to force clients to submit one slice per request, then > > doesn't > > some of the H.264 controls need to change? For instance, in the current v2 > > there is still a v4l2_ctrl_h264_decode_param::num_slices member. It is used > > in > > Chromium to specify the number of slices given to the > > V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS control, but is apparently ignored by > > the > > Cedrus driver. Maxime, can you comment on this? > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 + > > .../media/uapi/v4l/dev-stateless-decoder.rst | 378 ++ > > 2 files changed, 383 insertions(+) > > create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst > > > > Thank you! I have uploaded a version of the V4L2 spec with this and the two > older > stateful codec patches applied: > > https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-codec.html Thanks! A v3 will likely be necessary (and I'll likely be more reactive producing it) because of that one-slice-per-request requirement. After discussing with Tomasz we think it would be safer/simpler to require one frame per request in a first time, as we initially agreed. Anyway, we can discuss the details once Tomasz chimes in.
Re: kmemleak panic
On 1/21/2019 7:24 PM, Marc Gonzalez wrote: On 21/01/2019 14:35, Rob Herring wrote: On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote: On 21/01/2019 11:57, Marc Gonzalez wrote: [...] # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak kmemleak: Object 0xffc021e0 (size 2097152): kmemleak: comm "swapper/0", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: kmemleak_alloc_phys+0x48/0x60 memblock_alloc_range_nid+0x8c/0xa4 memblock_alloc_base_nid+0x4c/0x60 __memblock_alloc_base+0x3c/0x4c early_init_dt_alloc_reserved_memory_arch+0x54/0xa4 fdt_init_reserved_mem+0x308/0x3ec early_init_fdt_scan_reserved_mem+0x88/0xb0 arm64_memblock_init+0x1dc/0x254 setup_arch+0x1c8/0x4ec start_kernel+0x84/0x44c 0x OK, so via the __va(phys) call in kmemleak_alloc_phys(), you end up with the linear map address of a no-map reservation, which unsurprisingly turns out not to be mapped. Is there a way to tell kmemleak that it can't scan within a particular object? Yes, kmemleak_no_scan() do this which is done in patch https://patchwork.ozlabs.org/patch/995367/ This was done to avoid kmemleak scanning on the blocks which are nomaped and should not have linear mapping created in kernel page table. There was this patch posted[1]. I never got a reply, so it hasn't been applied. Rob https://patchwork.ozlabs.org/patch/995367/ It is worth noting that the author's email address appears to be dead. : host hqemgate08.nvidia.com[216.228.121.117] said: 550 #5.1.0 Address rejected. (in reply to RCPT TO command) Adding a few nvidia devs for comment.
Re: [PATCH v2] usb: dwc3: exynos: Fix error handling of clk_prepare_enable
Hi Alexey,
On 2019-01-21 22:23, Alexey Khoroshilov wrote:
> If clk_prepare_enable() fails in dwc3_exynos_probe() or in
> dwc3_exynos_resume(), exynos->clks[0] is left undisabled
> because of usage preincrement in while condition.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> Fixes: 9f2168367a0a ("usb: dwc3: exynos: Rework clock handling and prepare
> for new variants")
Acked-by: Marek Szyprowski
> ---
> v2: Add fix for the second instance in dwc3_exynos_resume() per Marek
> Szyprowski note.
>
> drivers/usb/dwc3/dwc3-exynos.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index cb7fcd7c0ad8..c1e9ea621f41 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -78,7 +78,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> for (i = 0; i < exynos->num_clks; i++) {
> ret = clk_prepare_enable(exynos->clks[i]);
> if (ret) {
> - while (--i > 0)
> + while (i-- > 0)
> clk_disable_unprepare(exynos->clks[i]);
> return ret;
> }
> @@ -223,7 +223,7 @@ static int dwc3_exynos_resume(struct device *dev)
> for (i = 0; i < exynos->num_clks; i++) {
> ret = clk_prepare_enable(exynos->clks[i]);
> if (ret) {
> - while (--i > 0)
> + while (i-- > 0)
> clk_disable_unprepare(exynos->clks[i]);
> return ret;
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH] media: v4l2-core: expose the device after it was registered.
device_register exposes the device to userspace.
Therefore, while the register process is ongoing, the userspace program
will fail to open the device (ENODEV will be set to errno currently).
The program in userspace must re-open the device to cover this case.
It is more reasonable to expose the device after everythings ready.
Signed-off-by: Liu, Xinwu
---
drivers/media/v4l2-core/v4l2-dev.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index d7528f8..01e5cc9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -993,16 +993,11 @@ int __video_register_device(struct video_device *vdev,
goto cleanup;
}
- /* Part 4: register the device with sysfs */
+ /* Part 4: Prepare to register the device */
vdev->dev.class = &video_class;
vdev->dev.devt = MKDEV(VIDEO_MAJOR, vdev->minor);
vdev->dev.parent = vdev->dev_parent;
dev_set_name(&vdev->dev, "%s%d", name_base, vdev->num);
- ret = device_register(&vdev->dev);
- if (ret < 0) {
- pr_err("%s: device_register failed\n", __func__);
- goto cleanup;
- }
/* Register the release callback that will be called when the last
reference to the device goes away. */
vdev->dev.release = v4l2_device_release;
@@ -1020,6 +1015,13 @@ int __video_register_device(struct video_device *vdev,
/* Part 6: Activate this minor. The char device can now be used. */
set_bit(V4L2_FL_REGISTERED, &vdev->flags);
+ /* Part 7: Register the device with sysfs */
+ ret = device_register(&vdev->dev);
+ if (ret < 0) {
+ pr_err("%s: device_register failed\n", __func__);
+ goto cleanup;
+ }
+
return 0;
cleanup:
--
2.7.4
Re: [PATCH RFC 03/24] mm: allow VM_FAULT_RETRY for multiple times
On Mon, Jan 21, 2019 at 10:55:36AM -0500, Jerome Glisse wrote: > On Mon, Jan 21, 2019 at 03:57:01PM +0800, Peter Xu wrote: > > The idea comes from a discussion between Linus and Andrea [1]. > > > > Before this patch we only allow a page fault to retry once. We achieved > > this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing > > handle_mm_fault() the second time. This was majorly used to avoid > > unexpected starvation of the system by looping over forever to handle > > the page fault on a single page. However that should hardly happen, and > > after all for each code path to return a VM_FAULT_RETRY we'll first wait > > for a condition (during which time we should possibly yield the cpu) to > > happen before VM_FAULT_RETRY is really returned. > > > > This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY > > flag when we receive VM_FAULT_RETRY. It means that the page fault > > handler now can retry the page fault for multiple times if necessary > > without the need to generate another page fault event. Meanwhile we > > still keep the FAULT_FLAG_TRIED flag so page fault handler can still > > identify whether a page fault is the first attempt or not. > > So there is nothing protecting starvation after this patch ? AFAICT. > Do we sufficient proof that we never have a scenario where one process > might starve fault another ? > > For instance some page locking could starve one process. Hi, Jerome, Do you mean lock_page()? AFAIU lock_page() will only yield the process itself until the lock is released, so IMHO it's not really starving the process but a natural behavior. After all the process may not continue without handling the page fault correctly. Or when you say "starvation" do you mean that we might return VM_FAULT_RETRY from handle_mm_fault() continuously so we'll looping over and over inside the page fault handler? Thanks, > > > > > > GUP code is not touched yet and will be covered in follow up patch. > > > > This will be a nice enhancement for current code at the same time a > > supporting material for the future userfaultfd-writeprotect work since > > in that work there will always be an explicit userfault writeprotect > > retry for protected pages, and if that cannot resolve the page > > fault (e.g., when userfaultfd-writeprotect is used in conjunction with > > shared memory) then we'll possibly need a 3rd retry of the page fault. > > It might also benefit other potential users who will have similar > > requirement like userfault write-protection. > > > > Please read the thread below for more information. > > > > [1] https://lkml.org/lkml/2017/11/2/833 > > > > Suggested-by: Linus Torvalds > > Suggested-by: Andrea Arcangeli > > Signed-off-by: Peter Xu > > --- Regards, -- Peter Xu
[PATCH] efirtc: remove unnecessary code efi_rtc_open & efi_rtc_close
From: Naveen Kumar Parna
There is no advantage to keep 'struct file_operations.open & .close'
API's. So removed the unnecessary code efi_rtc_open & efi_rtc_close.
Signed-off-by: Naveen Kumar Parna
---
drivers/char/efirtc.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/char/efirtc.c b/drivers/char/efirtc.c
index d9aab643997e..11781ebffbf7 100644
--- a/drivers/char/efirtc.c
+++ b/drivers/char/efirtc.c
@@ -254,27 +254,6 @@ static long efi_rtc_ioctl(struct file *file, unsigned int
cmd,
return -ENOTTY;
}
-/*
- * We enforce only one user at a time here with the open/close.
- * Also clear the previous interrupt data on an open, and clean
- * up things on a close.
- */
-
-static int efi_rtc_open(struct inode *inode, struct file *file)
-{
- /*
-* nothing special to do here
-* We do accept multiple open files at the same time as we
-* synchronize on the per call operation.
-*/
- return 0;
-}
-
-static int efi_rtc_close(struct inode *inode, struct file *file)
-{
- return 0;
-}
-
/*
* The various file operations we support.
*/
@@ -282,8 +261,6 @@ static int efi_rtc_close(struct inode *inode, struct file
*file)
static const struct file_operations efi_rtc_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = efi_rtc_ioctl,
- .open = efi_rtc_open,
- .release= efi_rtc_close,
.llseek = no_llseek,
};
--
2.17.1
Re: [PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On Tue, Jan 22, 2019 at 5:19 PM Alexandre Courbot wrote: > > On Tue, Jan 22, 2019 at 5:06 PM Hans Verkuil wrote: > > > > On 01/22/2019 07:26 AM, Alexandre Courbot wrote: > > > Documents the protocol that user-space should follow when > > > communicating with stateless video decoders. > > > > > > The stateless video decoding API makes use of the new request and tags > > > APIs. While it has been implemented with the Cedrus driver so far, it > > > should probably still be considered staging for a short while. > > > > > > Signed-off-by: Alexandre Courbot > > > --- > > > Changes since v1: > > > > > > * Use timestamps instead of tags to reference frames, > > > * Applied Paul's suggestions to not require one frame worth of data per > > > OUTPUT > > > buffer > > > > > > One of the effects of requiring sub-frame units to be submitted per > > > request is > > > that the stateless decoders are not exactly "stateless" anymore: if a > > > frame is > > > made of several slices, then the decoder must keep track of the buffer in > > > which > > > the current frame is being decoded between requests, and all the slices > > > for the > > > current frame must be submitted before we can consider decoding the next > > > one. > > > > > > Also if we decide to force clients to submit one slice per request, then > > > doesn't > > > some of the H.264 controls need to change? For instance, in the current v2 > > > there is still a v4l2_ctrl_h264_decode_param::num_slices member. It is > > > used in > > > Chromium to specify the number of slices given to the > > > V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS control, but is apparently ignored > > > by the > > > Cedrus driver. Maxime, can you comment on this? > > > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 + > > > .../media/uapi/v4l/dev-stateless-decoder.rst | 378 ++ > > > 2 files changed, 383 insertions(+) > > > create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst > > > > > > > Thank you! I have uploaded a version of the V4L2 spec with this and the two > > older > > stateful codec patches applied: > > > > https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-codec.html > > Thanks! A v3 will likely be necessary (and I'll likely be more > reactive producing it) because of that one-slice-per-request > requirement. After discussing with Tomasz we think it would be > safer/simpler to require one frame per request in a first time, as we > initially agreed. > > Anyway, we can discuss the details once Tomasz chimes in. I've replied in the v1 thread, in reply to Paul's email. Best regards, Tomasz
Re: [PATCH RFC 05/24] userfaultfd: wp: add helper for writeprotect check
On Mon, Jan 21, 2019 at 12:23:12PM +0200, Mike Rapoport wrote:
> On Mon, Jan 21, 2019 at 03:57:03PM +0800, Peter Xu wrote:
> > From: Shaohua Li
> >
> > add helper for writeprotect check. Will use it later.
>
> I'd merge this with the commit that actually uses this helper.
Hi, Mike,
Yeah actually that's what I'd prefer for most of the time. But I'm
trying to avoid doing that because I wanted to keep the credit of the
original authors, not only for this single patch, but also for the
whole series. Meanwhile, since this work has been there for quite a
few years (starting from 2015), IMHO keeping the old patches mostly
untouched at least in the RFC stage might also help the reviewers if
they have read or prior knowledge of the previous work.
And if the patch cannot even stand on itself (this one can; it only
introduces new functions) I'll do the merge no matter what.
Please correct me if this is not the good way to do.
Thanks!
>
> > Cc: Andrea Arcangeli
> > Cc: Pavel Emelyanov
> > Cc: Rik van Riel
> > Cc: Kirill A. Shutemov
> > Cc: Mel Gorman
> > Cc: Hugh Dickins
> > Cc: Johannes Weiner
> > Signed-off-by: Shaohua Li
> > Signed-off-by: Andrea Arcangeli
> > Signed-off-by: Peter Xu
> > ---
> > include/linux/userfaultfd_k.h | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> > index 37c9eba75c98..38f748e7186e 100644
> > --- a/include/linux/userfaultfd_k.h
> > +++ b/include/linux/userfaultfd_k.h
> > @@ -50,6 +50,11 @@ static inline bool userfaultfd_missing(struct
> > vm_area_struct *vma)
> > return vma->vm_flags & VM_UFFD_MISSING;
> > }
> >
> > +static inline bool userfaultfd_wp(struct vm_area_struct *vma)
> > +{
> > + return vma->vm_flags & VM_UFFD_WP;
> > +}
> > +
> > static inline bool userfaultfd_armed(struct vm_area_struct *vma)
> > {
> > return vma->vm_flags & (VM_UFFD_MISSING | VM_UFFD_WP);
> > @@ -94,6 +99,11 @@ static inline bool userfaultfd_missing(struct
> > vm_area_struct *vma)
> > return false;
> > }
> >
> > +static inline bool userfaultfd_wp(struct vm_area_struct *vma)
> > +{
> > + return false;
> > +}
> > +
> > static inline bool userfaultfd_armed(struct vm_area_struct *vma)
> > {
> > return false;
> > --
> > 2.17.1
> >
>
> --
> Sincerely yours,
> Mike.
>
Regards,
--
Peter Xu
[PATCH] Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()
h4_recv_buf() callers store the return value to socket buffer and
recursively pass the buffer to h4_recv_buf() without protection. So,
ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
before setting the socket buffer to NULL from previous error. Check if
skb is ERR_PTR in h4_recv_buf().
Reported-by: syzbot+017a32f149406df32...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
---
drivers/bluetooth/h4_recv.h | 4
drivers/bluetooth/hci_h4.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/bluetooth/h4_recv.h b/drivers/bluetooth/h4_recv.h
index b432651f8236..285cf72190b7 100644
--- a/drivers/bluetooth/h4_recv.h
+++ b/drivers/bluetooth/h4_recv.h
@@ -60,6 +60,10 @@ static inline struct sk_buff *h4_recv_buf(struct hci_dev
*hdev,
const struct h4_recv_pkt *pkts,
int pkts_count)
{
+ /* Check if socket buffer is not reset yet from previous error */
+ if (IS_ERR(skb))
+ skb = NULL;
+
while (count) {
int i, len;
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index fb97a3bf069b..dea48090d2dc 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -174,6 +174,10 @@ struct sk_buff *h4_recv_buf(struct hci_dev *hdev, struct
sk_buff *skb,
struct hci_uart *hu = hci_get_drvdata(hdev);
u8 alignment = hu->alignment ? hu->alignment : 1;
+ /* Check if socket buffer is not reset yet from previous error */
+ if (IS_ERR(skb))
+ skb = NULL;
+
while (count) {
int i, len;
--
2.17.1
Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem
On Tue, 22 Jan 2019 09:08:30 +0100
Miquel Raynal wrote:
> Hi Masahiro,
>
> Masahiro Yamada wrote on Tue, 22 Jan
> 2019 17:00:54 +0900:
>
> > On Tue, Jan 22, 2019 at 4:50 PM Miquel Raynal
> > wrote:
> > >
> > > Hi Masahiro,
> > >
> > > Masahiro Yamada wrote on Tue, 22 Jan
> > > 2019 16:42:55 +0900:
> > >
> > > > Although drivers do not directly get access to the private data of
> > > > instruction patterns, let's use unnamed union field to be consistent
> > > > with nand_op_instr.
> > > >
> > >
> > > Actually this is how we wrote it the first time. Then we got robots
> > > reporting that anonymous unions where not allowed with older (still
> > > supported) GCC versions and I had to do this:
> > >
> > >
> > > commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce
> > > Author: Miquel Raynal
> > > Date: Fri Jan 19 19:11:27 2018 +0100
> > >
> > > mtd: nand: Fix build issues due to an anonymous union
> > >
> > > GCC-4.4.4 raises errors when assigning a parameter in an anonymous
> > > union, leading to this kind of failure:
> > >
> > > drivers/mtd/nand/marvell_nand.c:1936:
> > > warning: missing braces around initializer
> > > warning: (near initialization for '(anonymous)[1].')
> > > error: unknown field 'data' specified in initializer
> > > error: unknown field 'addr' specified in initializer
> > >
> > > Work around the situation by naming these unions.
> > >
> > > Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
> > > Reported-by: Andrew Morton
> > > Signed-off-by: Miquel Raynal
> > > Tested-by: Andrew Morton
> > > Signed-off-by: Boris Brezillon
> > >
> >
> >
> > Hmm, how come Andrew's compiler was fine with the following?
> >
> > struct nand_flash_dev {
> > char *name;
> > union {
> > struct {
> > uint8_t mfr_id;
> > uint8_t dev_id;
> > };
> > uint8_t id[NAND_MAX_ID_LEN];
> > };
> > unsigned int pagesize;
> > ...
> > };
> >
>
> It is probably not :)
It was compile fine. I don't know all the subtleties, but maybe it's
because ->id[] is a base type and not a struct.
>
> >
> >
> > The current minimum version is GCC 4.6
> > (commit cafa0010cd51fb7)
> > but I am not sure if this restriction is remaining.
> >
>
> That's right, can you please test if this limitation is still
> ongoing wit GCC 4.6?
I have a more important question: why should we go bad back to unnamed
unions? Why is that a problem to have a named union? Sure, we initially
started with an unnamed ones because it made lines shorter, but now that
we switched to named unions I don't see the point of going back and
patching all drivers again (at the risk of seeing this problem appear
again when compiled with an old compiler version).
Re: rcutorture: meaning of "End of test: RCU_HOTPLUG"
Thanks for your quick reply! Paul
On 1/22/19 12:01 PM, Paul E. McKenney wrote:
On Tue, Jan 22, 2019 at 11:40:53AM +0800, Su Yue wrote:
Hi, guys
While running rcutorture tests with "onoff_interval", some tests
failed and results show like:
=
[ 316.354501] srcud-torture:--- End of test: RCU_HOTPLUG:
nreaders=1 nfakewriters=4 stat_interval=60 verbose=2
test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fq\
s_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0
test_boost_interval=7 test_boost_duration=4 shutdown_secs=0
stall_cpu=0 stall_cpu_holdoff=10 stall_cpu_irqsoff=0 n_ba\
rrier_cbs=0 onoff_interval=3 onoff_holdoff=0
I am wondering that meaning of "RCU_HOTPLUG". Is it expected because
cpu hotplug is enabled in the test? Or just represents another type of
failure?
This says that at least one CPU hotplug operation failed, that is,
the CPU didn't actually come online or go offline as requested. If you
are introducing CPU hotplug to an architecture, this usually indicates
that you have bugs in your CPU-hotplug code. Or it nmight be that
It should hit the case since there is no RCU CPU stall warnings.
RCU grace periods failed to progress -- though this would normally
also result in RCU CPU stall warnings.
There should be lines containing "ver:" in your console output. What
does one of the later one of these say?
The line says:
==
[ 318.850175] busted_srcud-torture: rtc: (null) ver: 27040
tfle: 0 rta: 27040 rtaf: 0 rtf: 27027 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0
rtbf: 0 rtb: 0 \
nt: 9497 onoff: 2639/2639:2640/5310 40,373:10,355 162868:67542 (HZ=1000)
barrier: 0/0:0
=
And here are useful errors:
=
kern :info : [ 135.379693] KVM setup async PF for cpu 1
kern :info : [ 135.381412] kvm-stealtime: cpu 1, msr 23fd16180
kern :alert : [ 135.386897] busted_srcud-torture:torture_onoff task:
onlined 1
kern :alert : [ 135.408241] busted_srcud-torture:torture_onoff task:
offlining 1
kern :info : [ 135.423310] Unregister pv shared memory for cpu 1
kern :info : [ 135.427940] smpboot: CPU 1 is now offline
kern :alert : [ 135.430106] busted_srcud-torture:torture_onoff task:
offlined 1
kern :alert : [ 135.436404] busted_srcud-torture:torture_onoff task:
offlining 0
kern :alert : [ 135.446173] busted_srcud-torture:torture_onoff task:
offline 0 failed: errno -16
kern :alert : [ 135.453076] busted_srcud-torture:torture_onoff task:
offlining 0
kern :alert : [ 135.457461] busted_srcud-torture:torture_onoff task:
offline 0 failed: errno -16
=
There are only two CPUs on the VM. Torture try to offline the last one
but -EBUSY occured.
I spent time to understand kernel/torture.c.
There is torture_onoff():
225while (!torture_must_stop()) {
226cpu = (torture_random(&rand) >> 4) % (maxcpu + 1);
227if (!torture_offline(cpu,
228 &n_offline_attempts,
&n_offline_successes,
229 &sum_offline, &min_offline,
&max_offline))
230torture_online(cpu,
231 &n_online_attempts,
&n_online_successes,
232 &sum_online, &min_online,
&max_online);
233schedule_timeout_interruptible(onoff_interval);
234}
235
torture_offline() and torture_offline() don't pre judge if the current
cpu is only one usable.
Our test machines are configured with CONFIG_BOOTPARAM_HOTPLUG_CPU0. If
there are only one oneline and hotplugable cpux, then
n_offline_successes != n_offline_attempts which caused "End of test:
RCU_HOTPLUG".
Does I misunderstand something above? Feel free to correct me.
Thanks,
Su
Thanx, Paul
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote: > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote: > >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote: > On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: > > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote: > >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote: > >>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig > >>> wrote: > >>> > Until that happens we should just change the driver ifdefs to default > the hacks to off and only enable them on setups where we 100% > positively know that they actually work. And document that fact > in big fat comments. > >>> > >>> Well, as I mentioned in my commit log as well, if we default to off > >>> unless CONFIG_X86, we may break working setups on MIPS and Power where > >>> the device is in fact non-cache coherent, and relies on this > >>> 'optimization' to get things working. > >> > >> FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > >> correct basic operation (the scenario Christian brought up is a very > >> specialized use-case), so that shouldn't be an issue. > > > > The point is that this is only true for x86. > > > > On other architectures, the use of non-cached mappings on the CPU side > > means that you /do/ rely on non-snooped transfers, since if those > > transfers turn out not to snoop inadvertently, the accesses are > > incoherent with the CPU's view of memory. > > The driver generally only uses non-cached mappings if > drm_arch/device_can_wc_memory returns true. > >>> > >>> Indeed. And so we should take care to only return 'true' from that > >>> function if it is guaranteed that non-cached CPU mappings are coherent > >>> with the mappings used by the GPU, either because that is always the > >>> case (like on x86), or because we know that the platform in question > >>> implements NoSnoop correctly throughout the interconnect. > >>> > >>> What seems to be complicating matters is that in some cases, the > >>> device is non-cache coherent to begin with, so regardless of whether > >>> the NoSnoop attribute is used or not, those accesses will not snoop in > >>> the caches and be coherent with the non-cached mappings used by the > >>> CPU. So if we restrict this optimization [on non-X86] to platforms > >>> that are known to implement NoSnoop correctly, we may break platforms > >>> that are implicitly NoSnoop all the time. > >> > >> Since the driver generally doesn't rely on non-snooped accesses for > >> correctness, that couldn't "break" anything that hasn't always been broken. > > > > Again, that is only true on x86. > > > > On other architectures, DMA writes from the device may allocate in the > > caches, and be invisible to the CPU when it uses non-cached mappings. > > Let me try one last time: > > If drm_arch_can_wc_memory returns false, the driver falls back to the > normal mode of operation, using a cacheable CPU mapping and snooped GPU > transfers, even if userspace asks (as a performance optimization) for a > write-combined CPU mapping and non-snooped GPU transfers via > AMDGPU_GEM_CREATE_CPU_GTT_USWC. Another question: when userspace requests for such a mapping to be created, does this involve pages that are mapped cacheable into the userland process?
[PATCH v3] pinctrl: freescale: fix link errors
Fix link errors when PINCTRL_IMX_SCU, PINCTRL_IMX8QM or PINCTRL_IMXBQXP is enabled as a module and the dependent module is built-in. ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function `imx_pinctrl_sc_ipc_init': pinctrl-scu.c:(.text+0x10): undefined reference to `imx_scu_get_handle' ld: pinctrl-scu.c:(.text+0x10): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `imx_scu_get_handle' ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function `imx_pinconf_get_scu': pinctrl-scu.c:(.text+0xa0): undefined reference to `imx_scu_call_rpc' ld: pinctrl-scu.c:(.text+0xa0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `imx_scu_call_rpc' ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function `imx_pinconf_set_scu': pinctrl-scu.c:(.text+0x1b4): undefined reference to `imx_scu_call_rpc' ld: pinctrl-scu.c:(.text+0x1b4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `imx_scu_call_rpc' ld: drivers/pinctrl/freescale/pinctrl-imx8qxp.o: in function `imx8qxp_pinctrl_probe': pinctrl-imx8qxp.c:(.text+0x28): undefined reference to `imx_pinctrl_probe' ld: pinctrl-imx8qxp.c:(.text+0x28): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `imx_pinctrl_probe' Rework so that PINCTRL_IMX_SCU and the config's that 'select PINCTRL_IMX_SCU' depends on IMX_SCU=y. Suggested-by: Arnd Bergmann Signed-off-by: Anders Roxell --- drivers/pinctrl/freescale/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig index b318c24b61be..af141dd2331d 100644 --- a/drivers/pinctrl/freescale/Kconfig +++ b/drivers/pinctrl/freescale/Kconfig @@ -7,7 +7,7 @@ config PINCTRL_IMX config PINCTRL_IMX_SCU bool - depends on IMX_SCU + depends on IMX_SCU=y select PINCTRL_IMX config PINCTRL_IMX1_CORE @@ -131,14 +131,14 @@ config PINCTRL_IMX8MQ config PINCTRL_IMX8QM bool "IMX8QM pinctrl driver" - depends on ARCH_MXC && ARM64 + depends on IMX_SCU && ARCH_MXC && ARM64 select PINCTRL_IMX_SCU help Say Y here to enable the imx8qm pinctrl driver config PINCTRL_IMX8QXP bool "IMX8QXP pinctrl driver" - depends on ARCH_MXC && ARM64 + depends on IMX_SCU && ARCH_MXC && ARM64 select PINCTRL_IMX_SCU help Say Y here to enable the imx8qxp pinctrl driver -- 2.19.2
Re: [PATCH v2 2/5] gnss: sirf: power on logic for devices without wakeup signal
On Mon, Jan 14, 2019 at 01:13:46PM +0100, Andreas Kemnade wrote: > On Mon, 14 Jan 2019 11:51:29 +0100 > Johan Hovold wrote: > > Good point. Unless we know the current state, we'd need to sleep for > > HIBERNATE_TIMEOUT before waiting for data reception. > > > > > > - timeout: failure > > > > > > > > hibernate: > > > >- toggle on-off > > > >- sleep(HIBERNATE_TIMEOUT) > > > we could also additionally check here for > > >if (last_bytes_received == GOODBYE_MSG) > > > > Caching and parsing the stream for this could get messy. And is the > > expected message clearly defined somewhere, or would it be device (and > > firmware) dependent? > > > I think so but I must check. > $PSRF150.0 > > But as said, these ideas are be for a possibly later patchset. Yeah, and remember that the receiver can be in binary sirf mode as well, so this do indeed seem like something that will need to wait. Thanks, Johan
Re: [PATCH 3/4] dt-bindings: spi: Add the DMA properties for the SPI dma mode
Hi Geert,
On Tue, 22 Jan 2019 at 16:11, Geert Uytterhoeven wrote:
>
> Hi Baolin,
>
> On Tue, Jan 22, 2019 at 3:23 AM Baolin Wang wrote:
> > On Mon, 21 Jan 2019 at 21:53, Rob Herring wrote:
> > > On Tue, Jan 15, 2019 at 7:47 AM Baolin Wang
> > > wrote:
> > > > From: Lanqing Liu
> > >
> > > The email address should be updated with unisoc.com.
> >
> > Sure.
> >
> > >
> > > > Add the DMA properties for the SPI dma mode.
> > > >
> > > > Signed-off-by: Lanqing Liu
> > > > Signed-off-by: Baolin Wang
> > > > ---
> > > > Documentation/devicetree/bindings/spi/spi-sprd.txt |9 +
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > > b/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > > index bad211a..01ef53f 100644
> > > > --- a/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > > +++ b/Documentation/devicetree/bindings/spi/spi-sprd.txt
> > > > @@ -14,6 +14,12 @@ Required properties:
> > > > address on the SPI bus. Should be set to 1.
> > > > - #size-cells: Should be set to 0.
> > > >
> > > > +Optional properties:
> > > > +dma-names: Should contain names of the SPI used DMA channel.
> > > > +dmas: Should contain DMA channels which the SPI used sorted in the
> > > > + same order as the dma-names property.
> > > > +sprd,dma-slave-ids: Should contain the DMA number that the SPI
> > > > hardware required.
> > > > +
> > > > Example:
> > > > spi0: spi@70a0{
> > > > compatible = "sprd,sc9860-spi";
> > > > @@ -21,6 +27,9 @@ spi0: spi@70a0{
> > > > interrupts = ;
> > > > clock-names = "spi", "source","enable";
> > > > clocks = <&clk_spi0>, <&ext_26m>, <&clk_ap_apb_gates 5>;
> > > > + dma-names = "rx_chn", "tx_chn";
> > > > + dmas = <&apdma 11>, <&apdma 12>;
> > > > + sprd,dma-slave-ids = <11 12>;
> > >
> > > When would this be different values from what's in 'dmas'?
> >
> > Slave id is not always same with the DMA channel number in 'dmas', and
> > it is just coincident for SPI driver. Moreover for different SoC , the
> > slave ids for DMA engine consumers are not same. So we need one
> > property to specify the slave id for the consumers to trigger DMA
> > transfer.
>
> Perhaps the DMA controller should use #dma-cells = <2>, so you can specify
> the second value in the dmas property?
Yes, that's a good point. I will try to change our DMA driver. Thanks.
--
Baolin Wang
Best Regards
Re: [PATCH] of: reserved_mem: disable kmemleak scan on removed memory blocks
On 11/10/2018 2:58 AM, Rob Herring wrote:
On Fri, Nov 9, 2018 at 1:09 AM Prateek Patel wrote:
From: Sri Krishna chowdary
Memory reserved with "nomap" DT property in of_reserved_mem.c
removes the memory block. The removed memory blocks don't have
VA to PA mapping created in kernel page table. Kmemleak scan on
removed memory blocks is causing page faults and leading to
kernel panic. So, Disable kmemleak scan on the removed memory
blocks.
Following is the observed crash log:
[ 154.846370] Unable to handle kernel paging request at virtual address
ffc070a0
<1>[ 154.846576] Mem abort info:
<1>[ 154.846635] Exception class = DABT (current EL), IL = 32 bits
<1>[ 154.846737] SET = 0, FnV = 0
<1>[ 154.846796] EA = 0, S1PTW = 0
<1>[ 154.846859] Data abort info:
<1>[ 154.846913] ISV = 0, ISS = 0x0006
<1>[ 154.846983] CM = 0, WnR = 0
<1>[ 154.847053] swapper pgtable: 4k pages, 39-bit VAs, pgd = ff8009df7000
<1>[ 154.847228] [ffc070a0] *pgd=00087fff5803,
*pud=00087fff5803, *pmd=
<0>[ 154.847408] Internal error: Oops: 9606 [#1] PREEMPT SMP
<4>[ 154.847511] Modules linked in: nvs_led_test nvs_bmi160 nvs_cm3218
nvs_bh1730fvc nvi_bmpX80 nvi_ak89xx nvi_mpu cdc_acm uas lr388k7_ts imx268 imx318
imx204 imx274 imx185 lc898212 ov23850 ov10823 ov9281 ov5693 tc358840 pca9570 nvs
snd_soc_tegra_machine_driver_mobile lp855x_bl spidev input_cfboost pwm_tegra
tegra_cryptodev tegra_se_nvhost tegra_se_elp tegra_se ghash_ce sha2_ce sha1_ce
aes_ce_ccm cryptd nvgpu cpufreq_userspace snd_soc_tegra186_alt_dspk
snd_soc_tegra186_alt_asrc snd_soc_tegra186_alt_arad snd_soc_tegra210_alt_ope
snd_soc_tegra210_alt_mvc snd_soc_tegra210_alt_dmic snd_soc_tegra210_alt_amx
snd_soc_tegra210_alt_adx snd_soc_tegra210_alt_afc snd_soc_tegra210_alt_mixer
snd_soc_tegra210_alt_i2s snd_soc_tegra210_alt_sfc snd_soc_tegra210_alt_adsp
snd_soc_tegra210_alt_admaif snd_soc_tegra210_alt_xbar
<4>[ 154.882606] snd_soc_tegra_alt_utils snd_hda_tegra
<4>[ 154.888133] CPU: 2 PID: 8079 Comm: sh Not tainted
4.14.53-tegra-05132-g9c33465 #2
<4>[ 154.895983] Hardware name: e3360_1099 (DT)
<4>[ 154.900447] task: ffc7d62dda00 task.stack: ff800e2b
<4>[ 154.906502] PC is at scan_block+0x7c/0x148
<4>[ 154.911234] LR is at scan_block+0x78/0x148
<4>[ 154.915689] pc : [] lr : [] pstate:
804000c9
<4>[ 154.923290] sp : ff800e2b3b80
<4>[ 154.927228] x29: ff800e2b3b80 x28: ffc7d62dda00
<4>[ 154.932999] x27: ff8009aaa000 x26: ffc070c0
<4>[ 154.938769] x25: 00c0 x24: ff8009d90608
<4>[ 154.944287] x23: ffc7dc6c6000 x22: ff8009d9
<4>[ 154.950320] x21: ff8009aeb320 x20: ffc070a00ff9
<4>[ 154.955919] x19: ffc070a0 x18: bec4c3f2
<4>[ 154.961438] x17: 002224777924 x16: ff80080bb0e0
<4>[ 154.967124] x15: x14: 0f75
<4>[ 154.973069] x13: 000f x12: ffbf1e9f4240
<4>[ 154.978670] x11: 0040 x10: 0ad0
<4>[ 154.984107] x9 : ff800e2b3ab0 x8 : ffc7d62de530
<4>[ 154.989958] x7 : 00078000 x6 : 0018
<4>[ 154.995645] x5 : x4 :
<4>[ 155.001245] x3 : ff8009aaa000 x2 : 0047f6712000
<4>[ 155.006846] x1 : ffc7d1ae6900 x0 :
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Prateek
---
drivers/of/of_reserved_mem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..ac8f377 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MAX_RESERVED_REGIONS 32
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -50,8 +51,10 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
*res_base = base;
- if (nomap)
+ if (nomap) {
+ kmemleak_no_scan(__va(base));
return memblock_remove(base, size);
I'm curious how I can't find any other similar example in the kernel.
Please Cc some kmemleak folks.
Perhaps we should be using memblock_mark_nomap() for nomap areas?
Rob
Sorry for this late reply.
Yes, memblock_mark_nomap() can be used here but if I understand
correctly, memblock_mark_nomap() is used to indicate marked parts of
memory should not be covered by the kernel direct mapping and
memblock_remove() here is doing that by removing a given memory from the
"memblock.memory" list to prevent the memory from CPU accessing by the
linear address. I am not 100% sure what will be the side effects of
using memblock_mark_nomap(). Adding folks to help me here on
MEMBLOCK_NOMAP and kmemleak.
I checked and verified with following and I didn't find any errors on my
local setup:
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..f7
[PATCH] dt-bindings: sdhci-omap: Add properties for using external dma
sdhci-omap can support both external dma controller via dmaengine
framework as well as ADMA which standard SD host controller
provides.
Signed-off-by: Chunyan Zhang
Signed-off-by: Faiz Abbas
---
Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
index 72c4dec7e1db..4485dbceb373 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
@@ -14,6 +14,11 @@ Required properties:
"ddr_1_8v-rev11", "ddr_1_8v" or "ddr_3_3v", "hs200_1_8v-rev11",
"hs200_1_8v",
- pinctrl- : Pinctrl states as described in
bindings/pinctrl/pinctrl-bindings.txt
+- dmas:List of DMA specifiers with the controller specific
format as described
+ in the generic DMA client binding. A tx and rx specifier is
required.
+- dma-names: List of DMA request names. These strings correspond 1:1 with the
+ DMA specifiers listed in dmas. The string naming is to be "tx"
+ and "rx" for TX and RX DMA requests, respectively.
Example:
mmc1: mmc@4809c000 {
@@ -22,4 +27,6 @@ Example:
ti,hwmods = "mmc1";
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ dmas = <&sdma 61 &sdma 62>;
+ dma-names = "tx", "rx";
};
--
2.17.1
Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding
On Mon 21 Jan 2019 at 18:44, Sean Wang wrote: On Mon, Jan 21, 2019 at 9:29 AM Loys Ollivier wrote: On Mon 21 Jan 2019 at 17:10, Rob Herring wrote: > On Thu, 17 Jan 2019 17:54:32 +0100, Loys Ollivier wrote: >> Add binding for Mediatek-based GNSS receivers. >> >> Signed-off-by: Loys Ollivier >> --- >> >> v2: >> Renamed bindings from Globaltop/gtop to Mediatek/mtk. >> Moved current-speed as an optional propertie. >> Removed the status line in the example. >> Added "mediatek,mt3339" compatible. >> >> .../devicetree/bindings/gnss/mediatek.txt | 39 >> ++ >> 1 file changed, 39 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt >> > > Reviewed-by: Rob Herring Thanks Rob, If there are no objections by others, I'll stop sending these two patch (1/4 and 2/4) and reference any new patch serie for 3 and 4 as depending on those two. Hi Loys, Thanks for adding the first GPS device driver. It's really nice to see more device drivers added to upstream support. Hi Sean, Glad to know you're supporting this initiative. Do you mind send the series again with Cc linux-media...@lists.infradead.org ? The series already has linux-media...@lists.infradead.org in Cc. Does it need a resend ? Sean -- -L ___ Linux-mediatek mailing list linux-media...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek -- -L
Re: [PATCH] Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()
Hi Myungho, > h4_recv_buf() callers store the return value to socket buffer and > recursively pass the buffer to h4_recv_buf() without protection. So, > ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again > before setting the socket buffer to NULL from previous error. Check if > skb is ERR_PTR in h4_recv_buf(). > > Reported-by: syzbot+017a32f149406df32...@syzkaller.appspotmail.com > Signed-off-by: Myungho Jung > --- > drivers/bluetooth/h4_recv.h | 4 > drivers/bluetooth/hci_h4.c | 4 > 2 files changed, 8 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding
On Mon 21 Jan 2019 at 21:51, Rob Herring wrote: On Mon, Jan 21, 2019 at 11:29 AM Loys Ollivier wrote: On Mon 21 Jan 2019 at 17:10, Rob Herring wrote: > On Thu, 17 Jan 2019 17:54:32 +0100, Loys Ollivier wrote: >> Add binding for Mediatek-based GNSS receivers. >> >> Signed-off-by: Loys Ollivier >> --- >> >> v2: >> Renamed bindings from Globaltop/gtop to Mediatek/mtk. >> Moved current-speed as an optional propertie. >> Removed the status line in the example. >> Added "mediatek,mt3339" compatible. >> >> .../devicetree/bindings/gnss/mediatek.txt | 39 >> ++ >> 1 file changed, 39 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt >> > > Reviewed-by: Rob Herring Thanks Rob, If there are no objections by others, I'll stop sending these two patch (1/4 and 2/4) and reference any new patch serie for 3 and 4 as depending on those two. Generally, you should just resend the whole series unless the maintainer has applied some of the patches. I could apply this but usually the whole series goes in together. Rob OK understood, I'll resend the whole series if needed then. Loys -- -L
Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation
>>> On 22.01.19 at 09:06, wrote: > Don't allow memory to be added above the allowed maximum allocation > limit set by Xen. This reads as if the hypervisor was imposing a limit here, but looking at xen_get_max_pages(), xen_foreach_remap_area(), and xen_count_remap_pages() I take it that it's a restriction enforced by the Xen subsystem in Linux. Furthermore from the cover letter I imply that the observed issue was on a Dom0, yet xen_get_max_pages()'s use of XENMEM_maximum_reservation wouldn't impose any limit there at all (without use of the hypervisor option "dom0_mem=max:..."), would it? Jan
Re: [PATCH v3 2/2] mm, oom: remove 'prefer children over parent' heuristic
On Mon 21-01-19 18:41:28, Shakeel Butt wrote:
> On Mon, Jan 21, 2019 at 1:59 PM Shakeel Butt wrote:
> >
> > From the start of the git history of Linux, the kernel after selecting
> > the worst process to be oom-killed, prefer to kill its child (if the
> > child does not share mm with the parent). Later it was changed to prefer
> > to kill a child who is worst. If the parent is still the worst then the
> > parent will be killed.
> >
> > This heuristic assumes that the children did less work than their parent
> > and by killing one of them, the work lost will be less. However this is
> > very workload dependent. If there is a workload which can benefit from
> > this heuristic, can use oom_score_adj to prefer children to be killed
> > before the parent.
> >
> > The select_bad_process() has already selected the worst process in the
> > system/memcg. There is no need to recheck the badness of its children
> > and hoping to find a worse candidate. That's a lot of unneeded racy
> > work. Also the heuristic is dangerous because it make fork bomb like
> > workloads to recover much later because we constantly pick and kill
> > processes which are not memory hogs. So, let's remove this whole
> > heuristic.
> >
> > Signed-off-by: Shakeel Butt
> > Acked-by: Michal Hocko
>
> Michal, though I have kept your Acked-by but I have made a couple of
> changes in the code. Please let me know if you are ok with the
> changes.
So the only change I can see is that we no longer print the score of the
selected oom victim and that each killed task gets the oom scope prefix.
I cannot think of anybody relying on the former and the later makes
sense to me. So yeah, I am still OK with the resulting code.
> > Cc: Roman Gushchin
> > Cc: Andrew Morton
> > Cc: David Rientjes
> > Cc: Johannes Weiner
> > Cc: Tetsuo Handa
> > Cc: linux...@kvack.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > ---
> > Changelog since v2:
> > - Propagate the message to __oom_kill_process().
> >
> > Changelog since v1:
> > - Improved commit message based on mhocko's comment.
> > - Replaced 'p' with 'victim'.
> > - Removed extra pr_err message.
> >
> > ---
> > mm/oom_kill.c | 78 ---
> > 1 file changed, 18 insertions(+), 60 deletions(-)
> >
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 1a007dae1e8f..c90184fd48a3 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -843,7 +843,7 @@ static bool task_will_free_mem(struct task_struct *task)
> > return ret;
> > }
> >
> > -static void __oom_kill_process(struct task_struct *victim)
> > +static void __oom_kill_process(struct task_struct *victim, const char
> > *message)
> > {
> > struct task_struct *p;
> > struct mm_struct *mm;
> > @@ -874,8 +874,9 @@ static void __oom_kill_process(struct task_struct
> > *victim)
> > */
> > do_send_sig_info(SIGKILL, SEND_SIG_PRIV, victim, PIDTYPE_TGID);
> > mark_oom_victim(victim);
> > - pr_err("Killed process %d (%s) total-vm:%lukB, anon-rss:%lukB,
> > file-rss:%lukB, shmem-rss:%lukB\n",
> > - task_pid_nr(victim), victim->comm, K(victim->mm->total_vm),
> > + pr_err("%s: Killed process %d (%s) total-vm:%lukB, anon-rss:%lukB,
> > file-rss:%lukB, shmem-rss:%lukB\n",
> > + message, task_pid_nr(victim), victim->comm,
> > + K(victim->mm->total_vm),
> > K(get_mm_counter(victim->mm, MM_ANONPAGES)),
> > K(get_mm_counter(victim->mm, MM_FILEPAGES)),
> > K(get_mm_counter(victim->mm, MM_SHMEMPAGES)));
> > @@ -932,24 +933,19 @@ static void __oom_kill_process(struct task_struct
> > *victim)
> > * Kill provided task unless it's secured by setting
> > * oom_score_adj to OOM_SCORE_ADJ_MIN.
> > */
> > -static int oom_kill_memcg_member(struct task_struct *task, void *unused)
> > +static int oom_kill_memcg_member(struct task_struct *task, void *message)
> > {
> > if (task->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {
> > get_task_struct(task);
> > - __oom_kill_process(task);
> > + __oom_kill_process(task, message);
> > }
> > return 0;
> > }
> >
> > static void oom_kill_process(struct oom_control *oc, const char *message)
> > {
> > - struct task_struct *p = oc->chosen;
> > - unsigned int points = oc->chosen_points;
> > - struct task_struct *victim = p;
> > - struct task_struct *child;
> > - struct task_struct *t;
> > + struct task_struct *victim = oc->chosen;
> > struct mem_cgroup *oom_group;
> > - unsigned int victim_points = 0;
> > static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
> > DEFAULT_RATELIMIT_BURST);
> >
> > @@ -958,57 +954,18 @@ static void oom_kill_process(struct oom_control *oc,
> > const char *message)
> > * its children or threads, just give it access to
Re: [PATCH RFC 06/24] userfaultfd: wp: support write protection for userfault vma range
On Mon, Jan 21, 2019 at 12:20:35PM +0200, Mike Rapoport wrote:
> On Mon, Jan 21, 2019 at 03:57:04PM +0800, Peter Xu wrote:
> > From: Shaohua Li
> >
> > Add API to enable/disable writeprotect a vma range. Unlike mprotect,
> > this doesn't split/merge vmas.
> >
> > Cc: Andrea Arcangeli
> > Cc: Pavel Emelyanov
> > Cc: Rik van Riel
> > Cc: Kirill A. Shutemov
> > Cc: Mel Gorman
> > Cc: Hugh Dickins
> > Cc: Johannes Weiner
> > Signed-off-by: Shaohua Li
> > Signed-off-by: Andrea Arcangeli
> > Signed-off-by: Peter Xu
> > ---
> > include/linux/userfaultfd_k.h | 2 ++
> > mm/userfaultfd.c | 52 +++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> > index 38f748e7186e..e82f3156f4e9 100644
> > --- a/include/linux/userfaultfd_k.h
> > +++ b/include/linux/userfaultfd_k.h
> > @@ -37,6 +37,8 @@ extern ssize_t mfill_zeropage(struct mm_struct *dst_mm,
> > unsigned long dst_start,
> > unsigned long len,
> > bool *mmap_changing);
> > +extern int mwriteprotect_range(struct mm_struct *dst_mm,
> > + unsigned long start, unsigned long len, bool enable_wp);
> >
> > /* mm helpers */
> > static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct
> > *vma,
> > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > index 458acda96f20..c38903f501c7 100644
> > --- a/mm/userfaultfd.c
> > +++ b/mm/userfaultfd.c
> > @@ -615,3 +615,55 @@ ssize_t mfill_zeropage(struct mm_struct *dst_mm,
> > unsigned long start,
> > {
> > return __mcopy_atomic(dst_mm, start, 0, len, true, mmap_changing);
> > }
> > +
> > +int mwriteprotect_range(struct mm_struct *dst_mm, unsigned long start,
> > + unsigned long len, bool enable_wp)
> > +{
> > + struct vm_area_struct *dst_vma;
> > + pgprot_t newprot;
> > + int err;
> > +
> > + /*
> > +* Sanitize the command parameters:
> > +*/
> > + BUG_ON(start & ~PAGE_MASK);
> > + BUG_ON(len & ~PAGE_MASK);
> > +
> > + /* Does the address range wrap, or is the span zero-sized? */
> > + BUG_ON(start + len <= start);
> > +
> > + down_read(&dst_mm->mmap_sem);
> > +
> > + /*
> > +* Make sure the vma is not shared, that the dst range is
> > +* both valid and fully within a single existing vma.
> > +*/
> > + err = -EINVAL;
>
> In non-cooperative mode, there can be a race between VM layout changes and
> mcopy_atomic [1]. I believe the same races are possible here, so can we
> please make err = -ENOENT for consistency with mcopy?
Sure.
>
> > + dst_vma = find_vma(dst_mm, start);
> > + if (!dst_vma || (dst_vma->vm_flags & VM_SHARED))
> > + goto out_unlock;
> > + if (start < dst_vma->vm_start ||
> > + start + len > dst_vma->vm_end)
> > + goto out_unlock;
> > +
> > + if (!dst_vma->vm_userfaultfd_ctx.ctx)
> > + goto out_unlock;
> > + if (!userfaultfd_wp(dst_vma))
> > + goto out_unlock;
> > +
> > + if (!vma_is_anonymous(dst_vma))
> > + goto out_unlock;
>
> The sanity checks here seem to repeat those in mcopy_atomic(). I'd suggest
> splitting them out to a helper function.
It's a good suggestion. Thanks!
>
> > + if (enable_wp)
> > + newprot = vm_get_page_prot(dst_vma->vm_flags & ~(VM_WRITE));
> > + else
> > + newprot = vm_get_page_prot(dst_vma->vm_flags);
> > +
> > + change_protection(dst_vma, start, start + len, newprot,
> > + !enable_wp, 0);
> > +
> > + err = 0;
> > +out_unlock:
> > + up_read(&dst_mm->mmap_sem);
> > + return err;
> > +}
> > --
> > 2.17.1
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=27d02568f529e908399514dfbee8ee43bdfd5299
>
> --
> Sincerely yours,
> Mike.
>
--
Peter Xu
Re: [PATCH v4] sched/wake_q: Reduce reference counting for special users
On Mon, Jan 21, 2019 at 08:02:18AM -0800, Davidlohr Bueso wrote: > Hi - considering that the wake_q patches were picked up for tip/urgent, can > this one make it in as well? Ah, here it is. Yes, got it now. I was actually wondering what happened, but couldn't find it in a hurry. All sorted now.
RE: [PATCH v8 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
Hello Mark, Can you please apply below patch in SPI tree? Patch has been reviewed by Boris and Frieder. -- Regards Yogesh Gaur > -Original Message- > From: Yogesh Narayan Gaur > Sent: Tuesday, January 15, 2019 5:30 PM > To: linux-...@lists.infradead.org; bbrezil...@kernel.org; > marek.va...@gmail.com; broo...@kernel.org; linux-...@vger.kernel.org; > devicet...@vger.kernel.org > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > frieder.schre...@kontron.de; linux-kernel@vger.kernel.org; Yogesh Narayan > Gaur > Subject: [PATCH v8 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller > > - Add driver for NXP FlexSPI host controller > > (0) What is the FlexSPI controller? > FlexSPI is a flexsible SPI host controller which supports two SPI channels > and up > to 4 external devices. Each channel supports Single/Dual/Quad/Octal mode > data transfer (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an > interface to > external devices, maximum 4, each with up to 8 bidirectional data lines. > > It uses new SPI memory interface of the SPI framework to issue flash memory > operations to up to four connected flash devices (2 buses with 2 CS each). > > (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility on NXP > LX2160ARDB and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A i.e. A0 > and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses one > flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512ab, [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Signed-off-by: Yogesh Narayan Gaur > Reviewed-by: Frieder Schrempf > Reviewed-by: Boris Brezillon > > --- > Changes for v8: > - Typo review comments changes > - Fix logic of read data for case when read size is less than 8 bytes. > - Add correct email address of Boris > - Add r-o-b tag of Frieder and Boris > Changes for v7: > - Add func pointer for '.get_name' for struct spi_controller_mem_ops > - Add input address range check as per controller memory mapped space > - Update _fill_txfifo/_read_rxfifo funcs as per Frieder review comments > Changes > for v6: > - Rebase on top of v5.0-rc1 > - Updated as per Frieder review comments and perform code cleanup > - Updated _fill_txfifo/_read_rxfifo func write/read logic Changes for v5: > - Rebase on top of v4.20-rc2 > - Modified fspi_readl_poll_tout() as per review comments > - Arrange header file in alphabetical order > - Removed usage of read()/write() function callback pointer > - Add support for 1 and 2 byte address length > - Change Frieder e-mail to new e-mail address Changes for v4: > - Incorporate Boris review comments > * Use readl_poll_timeout() instead of busy looping. > * Re-define register masking as per comment. > * Drop fspi_devtype enum. > Changes for v3: > - Added endianness flag in platform specific structure instead of DTS. > - Modified nxp_fspi_read_ahb(), removed remapping code. > - Added Boris and Frieder as Author and provided reference of spi-fsl-qspi.c > Changes for v2: > - Incorporated Boris review comments. > - Remove dependency of driver over connected flash device size. > - Modified the logic to select requested CS. > - Remove SPI-Octal Macros. > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile |1 + > drivers/spi/spi-nxp-fspi.c | 1105 > 3 files changed, 1116 insertions(+) > create mode 100644 drivers/spi/spi-nxp-fspi.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > dc67eda1788a..fc4cc7a65c33 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -279,6 +279,16 @@ config SPI_FSL_QUADSPI > This controller does not support generic SPI messages. It only > supports the high-level SPI memory interface. > > +config SPI_NXP_FLEXSPI > + tristate "NXP Flex SPI controller" > + depends on ARCH_LAYERSCAPE || HAS_IOMEM > + help > + This enables support for the Flex SPI controller in master mode. > + Up to four slave devices can be connected on two buses with two > + chipselects each. > + This controller does not support generic SPI messages and only > + supports the high-level SPI memory interface. > + > config SPI_GPIO > tristate "GPIO-based bitbanging SPI Master" > depends on GPIOLIB || COMPILE_TEST > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index > 2a857cb9aa81..5c5af4676279 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -64,6 +64,7 @@ obj-$(CONFIG_SPI_MXIC) += spi-mxic.o > obj-$(CONFIG_SPI_MXS)+= spi-mxs.o > obj-$(CONFIG_SPI_NPCM_PSPI) += spi-npcm-pspi.o > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > +obj-$(CONFIG_SPI_
Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem
On Tue, Jan 22, 2019 at 5:33 PM Boris Brezillon wrote:
>
> On Tue, 22 Jan 2019 09:08:30 +0100
> Miquel Raynal wrote:
>
> > Hi Masahiro,
> >
> > Masahiro Yamada wrote on Tue, 22 Jan
> > 2019 17:00:54 +0900:
> >
> > > On Tue, Jan 22, 2019 at 4:50 PM Miquel Raynal
> > > wrote:
> > > >
> > > > Hi Masahiro,
> > > >
> > > > Masahiro Yamada wrote on Tue, 22 Jan
> > > > 2019 16:42:55 +0900:
> > > >
> > > > > Although drivers do not directly get access to the private data of
> > > > > instruction patterns, let's use unnamed union field to be consistent
> > > > > with nand_op_instr.
> > > > >
> > > >
> > > > Actually this is how we wrote it the first time. Then we got robots
> > > > reporting that anonymous unions where not allowed with older (still
> > > > supported) GCC versions and I had to do this:
> > > >
> > > >
> > > > commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce
> > > > Author: Miquel Raynal
> > > > Date: Fri Jan 19 19:11:27 2018 +0100
> > > >
> > > > mtd: nand: Fix build issues due to an anonymous union
> > > >
> > > > GCC-4.4.4 raises errors when assigning a parameter in an anonymous
> > > > union, leading to this kind of failure:
> > > >
> > > > drivers/mtd/nand/marvell_nand.c:1936:
> > > > warning: missing braces around initializer
> > > > warning: (near initialization for '(anonymous)[1].')
> > > > error: unknown field 'data' specified in initializer
> > > > error: unknown field 'addr' specified in initializer
> > > >
> > > > Work around the situation by naming these unions.
> > > >
> > > > Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
> > > > Reported-by: Andrew Morton
> > > > Signed-off-by: Miquel Raynal
> > > > Tested-by: Andrew Morton
> > > > Signed-off-by: Boris Brezillon
> > > >
> > >
> > >
> > > Hmm, how come Andrew's compiler was fine with the following?
> > >
> > > struct nand_flash_dev {
> > > char *name;
> > > union {
> > > struct {
> > > uint8_t mfr_id;
> > > uint8_t dev_id;
> > > };
> > > uint8_t id[NAND_MAX_ID_LEN];
> > > };
> > > unsigned int pagesize;
> > > ...
> > > };
> > >
> >
> > It is probably not :)
>
> It was compile fine. I don't know all the subtleties, but maybe it's
> because ->id[] is a base type and not a struct.
>
> >
> > >
> > >
> > > The current minimum version is GCC 4.6
> > > (commit cafa0010cd51fb7)
> > > but I am not sure if this restriction is remaining.
> > >
> >
> > That's right, can you please test if this limitation is still
> > ongoing wit GCC 4.6?
>
> I have a more important question: why should we go bad back to unnamed
> unions? Why is that a problem to have a named union? Sure, we initially
> started with an unnamed ones because it made lines shorter, but now that
> we switched to named unions I don't see the point of going back and
> patching all drivers again (at the risk of seeing this problem appear
> again when compiled with an old compiler version).
I did not know commit c1a72e2dbb4.
We can drop the union name if and only if we are "100% sure" about the safety.
I cannot prove it.
Generally, 0day bot helps us.
Last time, nobody noticed the build error until Andrew reported it.
So, we cannot count on the 0day bot.
Less praise for this work.
Lots of criticism once I break it.
So, I have no reason to take the risk.
--
Best Regards
Masahiro Yamada
[PATCH] pwm: Add MediaTek MT8183 display PWM driver support
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = &mt2701_pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = &mt8183_pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.20.1
Re: [PATCH] drivers/perf: handle multiple CPUs with single interrupts
On 21.01.2019 18:23, Mark Rutland wrote:
> Hi Stefan,
>
> On Mon, Jan 21, 2019 at 03:41:11PM +0100, Stefan Agner wrote:
>> Currently, if only a single interrupt is available, the code assigns
>> this single interrupt to the first CPU. All other CPUs are left
>> unsupported. This allows to use perf events only on processes using
>> the first CPU. This is not obvious to the user.
>>
>> Instead, disable interrupts but support all CPUs. This allows to use
>> the PMU on all CPUs for all events other than sampling events which do
>> require interrupt support.
>
> Even for non-sampling events we use the overflow interrupt to ensure
> that we don't lose count across overflows, and without that interrupt,
> we cannot guarantee that the results are accurate.
>
> For example:
>
> Program counter to 0
> Start program
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> Stop program
> Counter reads as 5
>
>
> ... which we cannot distinguish from:
>
> Program counter to 0
> Start program
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> < counter overflows, no interrupt >
> Stop program
> Counter reads as 5
>
> ... and thus cannot provide any reasonable confidence in results.
Oh ok I see, this is not what we want at all!
Currently we register that one IRQ for CPU0. So what happens today is:
Program counter to 0
Start program
< program scheduled on CPU0 >
< counter overflows, interrupt >
< program scheduled on CPU1 >
< counter overflows, no interrupt >
< counter overflows, no interrupt >
Stop program
Counter reads as 5
Which is off too...
I could also reproduce this by manually moving the process between
CPU0/1...
We probably should not probe the driver at all then? It seems rather
unwise to provide users PMU data which might be plain wrong.
>
> In theory, we could use a hrtimer to periodically refresh the events to
> prevent this, but this would need to be set at some very high frequency
> to account for the fastest potential counter, and would significantly
> degrade performance.
>
> I don't think that's going to be reliable, and given that, I don't think
> that we can support muxed IRQs in this way.
Is it possible to get the overflow interrupts as well as read the PMU
counters for another CPU?
If not, I assume the interrupt bounce mechanism from ux500 is the only
way?
--
Stefan
>
> Thanks,
> Mark.
>
>>
>> Signed-off-by: Stefan Agner
>> ---
>> This has been observed and tested on a i.MX 6DualLite, but is probably
>> valid for i.MX 6Quad as well.
>>
>> It seems that ux500 once had support for single IRQ on a SMP system,
>> however this got removed with:
>> Commit 2b05f6ae1ee5 ("ARM: ux500: remove PMU IRQ bouncer")
>>
>> I noticed that with this patch I get an error when trying to use perf stat:
>> # perf top
>> Error:
>> cycles: PMU Hardware doesn't support sampling/overflow-interrupts. Try
>> 'perf stat'
>>
>> Without this patch perf top seems to work, but it seems not to use any
>> sampling events (?):
>> # perf top
>> PerfTop:7215 irqs/sec kernel:100.0% exact: 0.0% [4000Hz
>> cpu-clock:pppH], (all, 2 CPUs)
>>
>>
>> Also starting perf top and explicitly selecting cpu-clock seems to work
>> and show the same data as before this change.
>> # perf top -e cpu-clock:pppH
>> PerfTop:7214 irqs/sec kernel:100.0% exact: 0.0% [4000Hz
>> cpu-clock:pppH], (all, 2 CPUs)
>>
>> It seems that perf top falls back to cpu-clock in the old case, but not
>> once sampling events are not supported...
>>
>> --
>> Stefan
>>
>>
>> drivers/perf/arm_pmu_platform.c | 19 +++
>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/perf/arm_pmu_platform.c
>> b/drivers/perf/arm_pmu_platform.c
>> index 933bd8410fc2..80b991417b6e 100644
>> --- a/drivers/perf/arm_pmu_platform.c
>> +++ b/drivers/perf/arm_pmu_platform.c
>> @@ -105,23 +105,26 @@ static int pmu_parse_irqs(struct arm_pmu *pmu)
>> return num_irqs;
>> }
>>
>> +if (num_irqs == 1) {
>> +int irq = platform_get_irq(pdev, 0);
>> +if (irq && irq_is_percpu_devid(irq))
>> +return pmu_parse_percpu_irq(pmu, irq);
>> +}
>> +
>> /*
>> * In this case we have no idea which CPUs are covered by the PMU.
>> * To match our prior behaviour, we assume all CPUs in this case.
>> + * Multiple CPUs with a single PMU irq are currently not handled.
>> + * Rather than supporting only the first CPU, support all CPUs but
>> + * without interrupt capability.
>> */
>> -if (num_irqs == 0) {
>> -pr_warn("no irqs for PMU, sampling events not supported\n");
>> +if (num_irqs == 0 |
Re: [PATCH 2/8] dt-bindings: arm: atmel: add new sam9x60 reset controller binding
Hi Rob, On 22/01/2019 at 02:07, Rob Herring wrote: > On Wed, Jan 16, 2019 at 10:57:38AM +0100, Nicolas Ferre wrote: >> Update the Reset Controller's binding to add new SoC compatibility string. >> >> Signed-off-by: Nicolas Ferre >> --- >> Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt >> b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt >> index 36952cc39993..badce6ef3ab3 100644 >> --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt >> +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt >> @@ -22,6 +22,7 @@ Its subnodes can be: >> RSTC Reset Controller required properties: >> - compatible: Should be "atmel,-rstc". >> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7" >> + it also can be "microchip,sam9x60-rstc" > > How is this related to at91sam9260-rstc? at91sam9260 and sam9x60 are completely different products (they share the same core though...). I know the naming could be misleading but it is like it is... > The 'x' is a wildcard? We generally avoid wildcards. Here, the 'x' is definitively not a wildcard nor a kind of "family" name, it's included in the (upcoming) single product's name. I hope it clarifies. Best regards, Nicolas >> - reg: Should contain registers location and length >> - clocks: phandle to input clock. >> >> -- >> 2.17.1 >> > -- Nicolas Ferre
Re: [PATCH RFC 00/24] userfaultfd: write protection support
On 22.01.19 04:18, Peter Xu wrote: > On Mon, Jan 21, 2019 at 03:33:21PM +0100, David Hildenbrand wrote: > > [...] > >> Does this series fix the "false positives" case I experienced on early >> prototypes of uffd-wp? (getting notified about a write access although >> it was not a write access?) > > Hi, David, > > Yes it should solve it. Terrific, as my use case for uffd-wp really rely on not having false positives these are good news :) ... however it will take a while until I actually have time to look back into it (too much stuff on my table). Just for reference (we talked about this offline once): My plan is to use this for virtio-mem in QEMU. Memory that a virtio-mem device provides to a guest can either be plugged or unplugged. When unplugging, memory will be MADVISE_DONTNEED'ed and uffd-wp'ed. The guest can still read memory (e.g. for dumping) but writing to it is considered bad (as the guest could this way consume more memory as intended). So I can detect malicious guests without too much overhead this way. False positives would mean that I would detect guests as malicious although they are not. So it really would be harmful. Thanks! > > The early prototype in Andrea's tree hasn't yet applied the new > PTE/swap bits for uffd-wp hence it was not able to avoid those fause > positives. This series has applied all those ideas (which actually > come from Andrea as well) so the protection information will be > persisent per PTE rather than per VMA and it will be kept even through > swapping and page migrations. > > Thanks, > -- Thanks, David / dhildenb
RE: [PATCH v8 2/5] dt-bindings: spi: add binding file for NXP FlexSPI controller
Hi Rob / Shawn,
Can you please apply patches [1] [2].
--
Regards,
Yogesh Gaur
[1] https://patchwork.ozlabs.org/patch/1025136/
[2] https://patchwork.ozlabs.org/patch/1025137/
> -Original Message-
> From: Yogesh Narayan Gaur
> Sent: Tuesday, January 15, 2019 5:30 PM
> To: linux-...@lists.infradead.org; bbrezil...@kernel.org;
> marek.va...@gmail.com; broo...@kernel.org; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org
> Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux-
> arm-ker...@lists.infradead.org; computersforpe...@gmail.com;
> frieder.schre...@kontron.de; linux-kernel@vger.kernel.org; Yogesh Narayan
> Gaur
> Subject: [PATCH v8 2/5] dt-bindings: spi: add binding file for NXP FlexSPI
> controller
>
> Add binding file for NXP FlexSPI controller
>
> Signed-off-by: Yogesh Narayan Gaur
> Reviewed-by: Rob Herring
> ---
> Changes for v8:
> - None
> Changes for v7:
> - None
> Changes for v6:
> - None
> Changes for v5:
> - None
> Changes for v4:
> - Incorporated Rob review comments.
> Changes for v3:
> - Removed node property 'big-endian'.
> Changes for v2:
> - Incorporated Rob review comments.
>
> .../devicetree/bindings/spi/spi-nxp-fspi.txt | 39 +++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> new file mode 100644
> index ..2cd67eb727d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> @@ -0,0 +1,39 @@
> +* NXP Flex Serial Peripheral Interface (FSPI)
> +
> +Required properties:
> + - compatible : Should be "nxp,lx2160a-fspi"
> + - reg :First contains the register location and length,
> + Second contains the memory mapping address and length
> + - reg-names : Should contain the resource reg names:
> + - fspi_base: configuration register address space
> + - fspi_mmap: memory mapped address space
> + - interrupts : Should contain the interrupt for the device
> +
> +Required SPI slave node properties:
> + - reg :There are two buses (A and B) with two chip selects each.
> + This encodes to which bus and CS the flash is connected:
> + - <0>: Bus A, CS 0
> + - <1>: Bus A, CS 1
> + - <2>: Bus B, CS 0
> + - <3>: Bus B, CS 1
> +
> +Example showing the usage of two SPI NOR slave devices on bus A:
> +
> +fspi0: spi@20c {
> + compatible = "nxp,lx2160a-fspi";
> + reg = <0x0 0x20c 0x0 0x1>, <0x0 0x2000 0x0
> 0x1000>;
> + reg-names = "fspi_base", "fspi_mmap";
> + interrupts = <0 25 0x4>; /* Level high type */
> + clocks = <&clockgen 4 3>, <&clockgen 4 3>;
> + clock-names = "fspi_en", "fspi";
> +
> + mt35xu512aba0: flash@0 {
> + reg = <0>;
> +
> + };
> +
> + mt35xu512aba1: flash@1 {
> + reg = <1>;
> +
> + };
> +};
> --
> 2.17.1
[PATCH v5 5/5] clk: samsung: exynos5433: add imem clocks
Add imem clocks for exynos5433. This will enable to use crypto Slim
Security SubSystem (in short SlimSSS) IP block.
Acked-by: Chanwoo Choi
Signed-off-by: Kamil Konieczny
---
drivers/clk/samsung/clk-exynos5433.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 24c3360db65b..dae1c96de933 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -5467,6 +5467,35 @@ static const struct samsung_cmu_info cam1_cmu_info
__initconst = {
.clk_name = "aclk_cam1_400",
};
+/*
+ * Register offset definitions for CMU_IMEM
+ */
+#define ENABLE_ACLK_IMEM_SLIMSSS 0x080c
+#define ENABLE_PCLK_IMEM_SLIMSSS 0x0908
+
+static const unsigned long imem_clk_regs[] __initconst = {
+ ENABLE_ACLK_IMEM_SLIMSSS,
+ ENABLE_PCLK_IMEM_SLIMSSS,
+};
+
+static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
+ /* ENABLE_ACLK_IMEM_SLIMSSS */
+ GATE(CLK_ACLK_SLIMSSS, "aclk_slimsss", "aclk_imem_sssx_266",
+ ENABLE_ACLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
+
+ /* ENABLE_PCLK_IMEM_SLIMSSS */
+ GATE(CLK_PCLK_SLIMSSS, "pclk_slimsss", "aclk_imem_200",
+ ENABLE_PCLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
+};
+
+static const struct samsung_cmu_info imem_cmu_info __initconst = {
+ .gate_clks = imem_gate_clks,
+ .nr_gate_clks = ARRAY_SIZE(imem_gate_clks),
+ .nr_clk_ids = IMEM_NR_CLK,
+ .clk_regs = imem_clk_regs,
+ .nr_clk_regs= ARRAY_SIZE(imem_clk_regs),
+ .clk_name = "aclk_imem_200",
+};
struct exynos5433_cmu_data {
struct samsung_clk_reg_dump *clk_save;
@@ -5654,6 +5683,9 @@ static const struct of_device_id
exynos5433_cmu_of_match[] = {
}, {
.compatible = "samsung,exynos5433-cmu-mscl",
.data = &mscl_cmu_info,
+ }, {
+ .compatible = "samsung,exynos5433-cmu-imem",
+ .data = &imem_cmu_info,
}, {
},
};
--
2.20.0
[PATCH V2] pwm: Add MediaTek MT8183 display PWM driver support
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = &mt2701_pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = &mt8183_pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.12.5
Re: [PATCH] clk: sunxi-ng: v3s: Fix TCON reset de-assert bit
On Tue, Jan 22, 2019 at 09:16:19AM +0100, Paul Kocialkowski wrote: > According to the datasheet and the reference code from Allwinner, the > bit used to de-assert the TCON reset is bit 4, not bit 3. > > Fix it in the V3s CCU driver. > > Signed-off-by: Paul Kocialkowski Applied, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH] kcov: convert kcov.refcount to refcount_t
On Mon, Jan 21, 2019 at 11:05:03AM -0500, Alan Stern wrote:
> On Mon, 21 Jan 2019, Peter Zijlstra wrote:
> > Any additional ordering; like the one you have above; are not strictly
> > required for the proper functioning of the refcount. Rather, you rely on
> > additional ordering and will need to provide this explicitly:
> >
> >
> > if (refcount_dec_and_text(&x->rc)) {
> > /*
> > * Comment that explains what we order against
> > */
> > smp_mb__after_atomic();
> > BUG_ON(!x->done*);
> > free(x);
> > }
> >
> >
> > Also; these patches explicitly mention that refcount_t is weaker,
> > specifically to make people aware of this difference.
> >
> > A full smp_mb() (or two) would also be much more expensive on a number
> > of platforms and in the vast majority of the cases it is not required.
>
> How about adding smp_rmb() into refcount_dec_and_test()? That would
> give acq+rel semantics, which seems to be what people will expect. And
> it wouldn't be nearly as expensive as a full smp_mb().
Yes, that's a very good suggestion.
I suppose we can add smp_acquire__after_ctrl_dep() on the true branch.
Then it reall does become rel_acq.
A wee something like so (I couldn't find an arm64 refcount, even though
I have distinct memories of talk about it).
This isn't compiled, and obviously needs comment/documentation updates
to go along with it.
---
arch/x86/include/asm/refcount.h | 9 -
lib/refcount.c | 7 ++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h
index dbaed55c1c24..6f7a1eb345b4 100644
--- a/arch/x86/include/asm/refcount.h
+++ b/arch/x86/include/asm/refcount.h
@@ -74,9 +74,16 @@ bool refcount_sub_and_test(unsigned int i, refcount_t *r)
static __always_inline __must_check bool refcount_dec_and_test(refcount_t *r)
{
- return GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
+ bool ret = GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
REFCOUNT_CHECK_LT_ZERO,
r->refs.counter, e, "cx");
+
+ if (ret) {
+ smp_acquire__after_ctrl_dep();
+ return true;
+ }
+
+ return false;
}
static __always_inline __must_check
diff --git a/lib/refcount.c b/lib/refcount.c
index ebcf8cd49e05..8276ad349d48 100644
--- a/lib/refcount.c
+++ b/lib/refcount.c
@@ -190,7 +190,12 @@ bool refcount_sub_and_test_checked(unsigned int i,
refcount_t *r)
} while (!atomic_try_cmpxchg_release(&r->refs, &val, new));
- return !new;
+ if (!new) {
+ smp_acquire__after_ctrl_dep();
+ return true;
+ }
+
+ return false;
}
EXPORT_SYMBOL(refcount_sub_and_test_checked);
[PATCH v2 1/1] arm64: Add workaround for Fujitsu A64FX erratum 010001
On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1),
memory accesses may cause undefined fault (Data abort,
DFSC=0b11) due to the CPU Errata (Fujitsu #010001).
This patch introduces the workaround to the problem.
The workaround is to change the fault handler for Data abort
DFSC=0b11 to ignore this undefined fault, which will only
affect the Fujitsu-A64FX.
Signed-off-by: Lei Zhang
Tested-by: Lei Zhang
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 13 +
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/cputype.h | 4
arch/arm64/kernel/cpu_errata.c | 8
arch/arm64/mm/fault.c | 24 +++-
6 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 1f09d04..26d64e9 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -80,3 +80,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
+| Fujitsu| A64FX | E#010001| FUJITSU_ERRATUM_010001
|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a4168d3..9c09b2b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -643,6 +643,19 @@ config QCOM_FALKOR_ERRATUM_E1041
If unsure, say Y.
+config FUJITSU_ERRATUM_010001
+ bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
+ default y
+ help
+ This option adds workaround for Fujitsu-A64FX erratum E#010001.
+ On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), memory
accesses
+ may cause undefined fault (Data abort, DFSC=0b11).
+ The workaround is to replace the fault handler for Data abort
DFSC=0b11
+ with a new one to ignore this undefined fault, which will only affect
+ the Fujitsu-A64FX.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 82e9099..3a0b375 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -60,7 +60,8 @@
#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 39
#define ARM64_HAS_GENERIC_AUTH_ARCH40
#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
+#define ARM64_WORKAROUND_FUJITSU_A64FX_011 42
-#define ARM64_NCAPS42
+#define ARM64_NCAPS43
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 951ed1a..70203f9 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -76,6 +76,7 @@
#define ARM_CPU_IMP_BRCM 0x42
#define ARM_CPU_IMP_QCOM 0x51
#define ARM_CPU_IMP_NVIDIA 0x4E
+#define ARM_CPU_IMP_FUJITSU0x46
#define ARM_CPU_PART_AEM_V80xD0F
#define ARM_CPU_PART_FOUNDATION0xD00
@@ -104,6 +105,8 @@
#define NVIDIA_CPU_PART_DENVER 0x003
#define NVIDIA_CPU_PART_CARMEL 0x004
+#define FUJITSU_CPU_PART_A64FX 0x001
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
ARM_CPU_PART_CORTEX_A57)
#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
ARM_CPU_PART_CORTEX_A72)
@@ -122,6 +125,7 @@
#define MIDR_QCOM_KRYO MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_KRYO)
#define MIDR_NVIDIA_DENVER MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA,
NVIDIA_CPU_PART_DENVER)
#define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA,
NVIDIA_CPU_PART_CARMEL)
+#define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU,
FUJITSU_CPU_PART_A64FX)
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 9950bb0..fc0737f 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -739,6 +739,14 @@ static bool has_ssbd_mitigation(const struct
arm64_cpu_capabilities *entry,
ERRATA_MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 2, 0),
},
#endif
+#ifdef CONFIG_FUJITSU_ERRATUM_010001
+ {
+ .desc = "Fujitsu erratum 010001",
+ .capability = ARM64_WORKAROUND_FUJITSU_A64FX_011,
+ ERRATA_MIDR_RANGE(MIDR_FUJITSU_A64FX, 0, 0, 1, 0),
+ },
+#endif
+
{
}
};
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index efb7b2c..37e4f18 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -666,6 +666,28 @@ static int do_sea(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
return 0;
}
+static int do_bad_unkn
[PATCH v2 0/1] arm64: Add workaround for Fujitsu A64FX erratum 010001
On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), memory accesses may cause undefined fault (Data abort, DFSC=0b11). This problem will be fixed by next version of Fujitsu-A64FX. I would like to post a workaround to avoid this problem on existing version. The workaround is to replace the fault handler for Data abort DFSC=0b11 with a new one to ignore this undefined fault, which will only affect the Fujitsu-A64FX. The detail for this problem. > * Under what conditions can the fault occur? e.g. is this in place of > some other fault, or completely spurious? This fault can occur completely spurious under a specific hardware condition and instructions order. > * Does this only occur for data abort? i.e. not instruction aborts? Yes. This fault only occurs for data abort. > * How often does this fault occur? In my test, this fault occurs once every several times in the OS boot sequence, and after the completion of OS boot, this fault have never occurred. In my opinion, this fault rarely occurs after the completion of OS boot. > * Does this only apply to Stage-1, or can the same faults be taken at > Stage-2? This fault can be taken only at Stage-1. > I'm a bit surprised by the single retry. Is there any guarantee that a > thread will eventually stop delivering this fault code? I guarantee that a thread will stop delivering this fault code by the this patch. The hardware condition which cause this fault is reset at exception entry, therefore execution of at least one instruction is guaranteed by this single retry. Changes since [v1] As Mark's review: * Adopted errata framework. I have confirmed as followings: * Fujitsu A64FX - The problem doesn't happen. * QEMU - No problems to boot. I fully appreciate that if someone can test this patch on different chips to verity no harmful effect on other chips. If there is no problem on other chips, please merge this patch. The patch based on linux-5.0-rc2. Zhang Lei (1): arm64: Add workaround for Fujitsu A64FX erratum 010001. Documentation/arm64/silicon-errata.txt | 1 + arch/arm64/Kconfig | 13 + arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/cputype.h | 4 arch/arm64/kernel/cpu_errata.c | 8 arch/arm64/mm/fault.c | 24 +++- 6 files changed, 51 insertions(+), 2 deletions(-) -- 1.8.3.1
Re: [PATCH v3 1/9] platform/chrome: Remove cros_ec dependency in lpc_mec
Missatge de Nick Crews del dia ds., 19 de gen.
2019 a les 1:17:
>
> From: Duncan Laurie
>
> In order to allow this code to be re-used, remove the dependency
> on the rest of the cros_ec code from the cros_ec_lpc_mec functions.
>
> Instead of using a hardcoded register base address of 0x800 have
> this be passed in to cros_ec_lpc_mec_init(). The existing cros_ec
> use case now passes in the 0x800 base address this way.
>
> There are some error checks that happen in cros_ec_lpc_mec_in_range()
> that probably shouldn't be there, as they are checking kernel-space
> callers and not user-space input. However, we'll just do the refactor in
> this patch, and in a future patch might remove this error checking and
> fix all the instances of code that calls this.
>
> There's a similar problem in cros_ec_lpc_read_bytes(), where we return a
> checksum, but on error just return 0. This should probably be changed so
> that it returns int, but we don't want to have to mess with all the
> calling code for this fix. Maybe we'll come back through later and fix
> this.
>
> Signed-off-by: Duncan Laurie
> Signed-off-by: Nick Crews
> ---
>
> Changes in v3:
> - Change <= to >= in mec_in_range()
> - Add " - EC_HOST_CMD_REGION0" to offset arg for io_bytes_mec()
>
> Changes in v2:
> - Fixed kernel-doc comments
> - Fixed include of linux/mfd/cros_ec_lpc_mec.h
> - cros_ec_lpc_mec_in_range() returns -EINVAL on error
> - Added parens around macro variables
>
> drivers/platform/chrome/cros_ec_lpc_mec.c | 52 +++
> drivers/platform/chrome/cros_ec_lpc_mec.h | 43 ++-
> drivers/platform/chrome/cros_ec_lpc_reg.c | 47 +++-
> 3 files changed, 83 insertions(+), 59 deletions(-)
>
For my own reference:
Acked-for-chrome-platform-by: Enric Balletbo i Serra
> diff --git a/drivers/platform/chrome/cros_ec_lpc_mec.c
> b/drivers/platform/chrome/cros_ec_lpc_mec.c
> index c4edfa83e493..782e238a8d4e 100644
> --- a/drivers/platform/chrome/cros_ec_lpc_mec.c
> +++ b/drivers/platform/chrome/cros_ec_lpc_mec.c
> @@ -23,7 +23,6 @@
>
> #include
> #include
> -#include
> #include
> #include
>
> @@ -34,6 +33,7 @@
> * EC mutex because memmap data may be accessed without it being held.
> */
> static struct mutex io_mutex;
> +static u16 mec_emi_base, mec_emi_end;
>
> /*
> * cros_ec_lpc_mec_emi_write_address
> @@ -46,10 +46,37 @@ static struct mutex io_mutex;
> static void cros_ec_lpc_mec_emi_write_address(u16 addr,
> enum cros_ec_lpc_mec_emi_access_mode access_type)
> {
> - /* Address relative to start of EMI range */
> - addr -= MEC_EMI_RANGE_START;
> - outb((addr & 0xfc) | access_type, MEC_EMI_EC_ADDRESS_B0);
> - outb((addr >> 8) & 0x7f, MEC_EMI_EC_ADDRESS_B1);
> + outb((addr & 0xfc) | access_type,
> MEC_EMI_EC_ADDRESS_B0(mec_emi_base));
> + outb((addr >> 8) & 0x7f, MEC_EMI_EC_ADDRESS_B1(mec_emi_base));
> +}
> +
> +/**
> + * cros_ec_lpc_mec_in_range() - Determine if addresses are in MEC EMI range.
> + *
> + * @offset: Address offset
> + * @length: Number of bytes to check
> + *
> + * Return: 1 if in range, 0 if not, and -EINVAL on failure
> + * such as the mec range not being initialized
> + */
> +int cros_ec_lpc_mec_in_range(unsigned int offset, unsigned int length)
> +{
> + if (length == 0)
> + return -EINVAL;
> +
> + if (WARN_ON(mec_emi_base == 0 || mec_emi_end == 0))
> + return -EINVAL;
> +
> + if (offset >= mec_emi_base && offset < mec_emi_end) {
> + if (WARN_ON(offset + length - 1 >= mec_emi_end))
> + return -EINVAL;
> + return 1;
> + }
> +
> + if (WARN_ON(offset + length > mec_emi_base && offset < mec_emi_end))
> + return -EINVAL;
> +
> + return 0;
> }
>
> /*
> @@ -71,6 +98,11 @@ u8 cros_ec_lpc_io_bytes_mec(enum cros_ec_lpc_mec_io_type
> io_type,
> u8 sum = 0;
> enum cros_ec_lpc_mec_emi_access_mode access, new_access;
>
> + /* Return checksum of 0 if window is not initialized */
> + WARN_ON(mec_emi_base == 0 || mec_emi_end == 0);
> + if (mec_emi_base == 0 || mec_emi_end == 0)
> + return 0;
> +
> /*
> * Long access cannot be used on misaligned data since reading B0
> loads
> * the data register and writing B3 flushes.
> @@ -86,9 +118,9 @@ u8 cros_ec_lpc_io_bytes_mec(enum cros_ec_lpc_mec_io_type
> io_type,
> cros_ec_lpc_mec_emi_write_address(offset, access);
>
> /* Skip bytes in case of misaligned offset */
> - io_addr = MEC_EMI_EC_DATA_B0 + (offset & 0x3);
> + io_addr = MEC_EMI_EC_DATA_B0(mec_emi_base) + (offset & 0x3);
> while (i < length) {
> - while (io_addr <= MEC_EMI_EC_DATA_B3) {
> + while (io_addr <= MEC_EMI_EC_DATA_B3(mec_emi_base)) {
> if (io_type == MEC_IO_READ)
> buf[i] = inb(io_a
Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
On Tue, Jan 22, 2019 at 12:03:33PM +0530, Alok Chauhan wrote: > Get the interconnect paths for I2C based Serial Engine device > and vote accordingly based on maximum supported I2C frequency. > > Signed-off-by: Alok Chauhan Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 4/8] net/macb: bindings doc/trivial: fix documentation for sama5d3 10/100 interface
Hi Rob,
On 22/01/2019 at 02:10, Rob Herring wrote:
> On Wed, Jan 16, 2019 at 10:57:40AM +0100, Nicolas Ferre wrote:
>> This removes a line left while adding the correct compatibility string for
>> sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string.
>>
>> Signed-off-by: Nicolas Ferre
>> ---
>> Documentation/devicetree/bindings/net/macb.txt | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/macb.txt
>> b/Documentation/devicetree/bindings/net/macb.txt
>> index 3e17ac1d5d58..f5c414b10e27 100644
>> --- a/Documentation/devicetree/bindings/net/macb.txt
>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>> @@ -3,8 +3,7 @@
>> Required properties:
>> - compatible: Should be "cdns,[-]{macb|gem}"
>> Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
>> - Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
>> - available on sama5d3 SoCs.
>> + Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
>
> Where is "atmel,sama5d3-macb"?
It's actually a couple of line below: line 13 of the resulting macb.txt
file. It was already in the file when I removed the leftovers.
Do you advice to try to better sort entries in this file? Is there a
common pattern?
Best regards,
Nicolas
>> Use "cdns,np4-macb" for NP4 SoC devices.
>> Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic
>> form: "cdns,macb".
>> Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices
>> based on
>> --
>> 2.17.1
>>
>
--
Nicolas Ferre
Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation
On 22/01/2019 09:52, Jan Beulich wrote: On 22.01.19 at 09:06, wrote: >> Don't allow memory to be added above the allowed maximum allocation >> limit set by Xen. > > This reads as if the hypervisor was imposing a limit here, but looking at > xen_get_max_pages(), xen_foreach_remap_area(), and > xen_count_remap_pages() I take it that it's a restriction enforced by > the Xen subsystem in Linux. Furthermore from the cover letter I imply > that the observed issue was on a Dom0, yet xen_get_max_pages()'s > use of XENMEM_maximum_reservation wouldn't impose any limit there > at all (without use of the hypervisor option "dom0_mem=max:..."), > would it? Oh yes, you are right, of course! I need to check the current reservation and adjust the allowed limit in case of ballooning and/or memory hotplug. Thanks for noticing that! Juergen
RE: [PATCH 2/5] sched: convert signal_struct.sigcnt to refcount_t
> On 01/18, Elena Reshetova wrote: > > > > For the signal_struct.sigcnt it might make a difference > > in following places: > > - put_signal_struct(): decrement in refcount_dec_and_test() only > >provides RELEASE ordering and control dependency on success > >vs. fully ordered atomic counterpart > > this is fine. > > Reviewed-by: Oleg Nesterov Thank you Oleg! Will you be able to take this and the other scheduler patch to whatever tree/path it should normally go to get eventually integrated? Best Regards, Elena.
Re: [PATCH] dmaengine: at_xdmac: Fix wrongfull report of a channel as in use
On Thu, Jan 17, 2019 at 05:10:38PM +0100, Codrin Ciubotariu - M19940 wrote:
> From: Codrin Ciubotariu
>
> atchan->status is used for two things:
> - pass channel interrupts status from interrupt handler to tasklet;
> - channel information like whether it is cyclic or paused;
>
> Since these operations have nothing in common, this patch adds a
> different struct member to keep the interrupts status.
>
> Fixes a bug in which a channel is wrongfully reported as in use when
> trying to obtain a new descriptior for a previously used cyclic channel.
>
> Signed-off-by: Codrin Ciubotariu
Acked-by: Ludovic Desroches
As Vinod suggested, you may change the commit message to emphasize
that the bug comes from the fact that a single variable is used to store
different information.
The Fixes: tag should be added too.
Regards
Ludovic
> ---
> drivers/dma/at_xdmac.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index 4e557684f792..fe69dccfa0c0 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -203,6 +203,7 @@ struct at_xdmac_chan {
> u32 save_cim;
> u32 save_cnda;
> u32 save_cndc;
> + u32 irq_status;
> unsigned long status;
> struct tasklet_struct tasklet;
> struct dma_slave_config sconfig;
> @@ -1580,8 +1581,8 @@ static void at_xdmac_tasklet(unsigned long data)
> struct at_xdmac_desc*desc;
> u32 error_mask;
>
> - dev_dbg(chan2dev(&atchan->chan), "%s: status=0x%08lx\n",
> - __func__, atchan->status);
> + dev_dbg(chan2dev(&atchan->chan), "%s: status=0x%08x\n",
> + __func__, atchan->irq_status);
>
> error_mask = AT_XDMAC_CIS_RBEIS
>| AT_XDMAC_CIS_WBEIS
> @@ -1589,15 +1590,15 @@ static void at_xdmac_tasklet(unsigned long data)
>
> if (at_xdmac_chan_is_cyclic(atchan)) {
> at_xdmac_handle_cyclic(atchan);
> - } else if ((atchan->status & AT_XDMAC_CIS_LIS)
> -|| (atchan->status & error_mask)) {
> + } else if ((atchan->irq_status & AT_XDMAC_CIS_LIS)
> +|| (atchan->irq_status & error_mask)) {
> struct dma_async_tx_descriptor *txd;
>
> - if (atchan->status & AT_XDMAC_CIS_RBEIS)
> + if (atchan->irq_status & AT_XDMAC_CIS_RBEIS)
> dev_err(chan2dev(&atchan->chan), "read bus error!!!");
> - if (atchan->status & AT_XDMAC_CIS_WBEIS)
> + if (atchan->irq_status & AT_XDMAC_CIS_WBEIS)
> dev_err(chan2dev(&atchan->chan), "write bus error!!!");
> - if (atchan->status & AT_XDMAC_CIS_ROIS)
> + if (atchan->irq_status & AT_XDMAC_CIS_ROIS)
> dev_err(chan2dev(&atchan->chan), "request overflow
> error!!!");
>
> spin_lock(&atchan->lock);
> @@ -1652,7 +1653,7 @@ static irqreturn_t at_xdmac_interrupt(int irq, void
> *dev_id)
> atchan = &atxdmac->chan[i];
> chan_imr = at_xdmac_chan_read(atchan, AT_XDMAC_CIM);
> chan_status = at_xdmac_chan_read(atchan, AT_XDMAC_CIS);
> - atchan->status = chan_status & chan_imr;
> + atchan->irq_status = chan_status & chan_imr;
> dev_vdbg(atxdmac->dma.dev,
>"%s: chan%d: imr=0x%x, status=0x%x\n",
>__func__, i, chan_imr, chan_status);
> @@ -1666,7 +1667,7 @@ static irqreturn_t at_xdmac_interrupt(int irq, void
> *dev_id)
>at_xdmac_chan_read(atchan, AT_XDMAC_CDA),
>at_xdmac_chan_read(atchan, AT_XDMAC_CUBC));
>
> - if (atchan->status & (AT_XDMAC_CIS_RBEIS |
> AT_XDMAC_CIS_WBEIS))
> + if (atchan->irq_status & (AT_XDMAC_CIS_RBEIS |
> AT_XDMAC_CIS_WBEIS))
> at_xdmac_write(atxdmac, AT_XDMAC_GD,
> atchan->mask);
>
> tasklet_schedule(&atchan->tasklet);
> --
> 2.17.1
>
Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
On 2019-01-22 07:33, Alok Chauhan wrote: > Get the interconnect paths for I2C based Serial Engine device > and vote accordingly based on maximum supported I2C frequency. > > Signed-off-by: Alok Chauhan > --- > drivers/i2c/busses/i2c-qcom-geni.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c > b/drivers/i2c/busses/i2c-qcom-geni.c > index db075bc..e8fe63a 100644 > --- a/drivers/i2c/busses/i2c-qcom-geni.c > +++ b/drivers/i2c/busses/i2c-qcom-geni.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include Please keep the includes sorted. Probably applies for the other patches in the series as well? Cheers, Peter
Re: [PATCH] pinctrl: remove unused 'pinconf-config' debugfs interface
Hi Vladimir, I love your patch! Yet something to improve: [auto build test ERROR on pinctrl/devel] [also build test ERROR on v5.0-rc2 next-20190116] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Vladimir-Zapolskiy/pinctrl-remove-unused-pinconf-config-debugfs-interface/20190122-044655 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel config: i386-randconfig-x0-01221345 (attached as .config) compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): In file included from drivers/pinctrl/cirrus/pinctrl-madera-core.c:25:0: >> drivers/pinctrl/cirrus/../pinctrl-utils.h:36:8: warning: 'enum >> pinctrl_map_type' declared inside parameter list enum pinctrl_map_type type); ^ >> drivers/pinctrl/cirrus/../pinctrl-utils.h:36:8: warning: its scope is only >> this definition or declaration, which is probably not what you want drivers/pinctrl/cirrus/pinctrl-madera-core.c: In function 'madera_pin_probe': >> drivers/pinctrl/cirrus/pinctrl-madera-core.c:1044:9: error: implicit >> declaration of function 'pinctrl_register_mappings' >> [-Werror=implicit-function-declaration] ret = pinctrl_register_mappings(pdata->gpio_configs, ^ cc1: some warnings being treated as errors vim +36 drivers/pinctrl/cirrus/../pinctrl-utils.h 1eb207a9e Laxman Dewangan 2013-08-06 24 1eb207a9e Laxman Dewangan 2013-08-06 25 int pinctrl_utils_reserve_map(struct pinctrl_dev *pctldev, 1eb207a9e Laxman Dewangan 2013-08-06 26struct pinctrl_map **map, unsigned *reserved_maps, 1eb207a9e Laxman Dewangan 2013-08-06 27unsigned *num_maps, unsigned reserve); 1eb207a9e Laxman Dewangan 2013-08-06 28 int pinctrl_utils_add_map_mux(struct pinctrl_dev *pctldev, 1eb207a9e Laxman Dewangan 2013-08-06 29struct pinctrl_map **map, unsigned *reserved_maps, 1eb207a9e Laxman Dewangan 2013-08-06 30unsigned *num_maps, const char *group, 1eb207a9e Laxman Dewangan 2013-08-06 31const char *function); 1eb207a9e Laxman Dewangan 2013-08-06 32 int pinctrl_utils_add_map_configs(struct pinctrl_dev *pctldev, 1eb207a9e Laxman Dewangan 2013-08-06 33struct pinctrl_map **map, unsigned *reserved_maps, 1eb207a9e Laxman Dewangan 2013-08-06 34unsigned *num_maps, const char *group, 1eb207a9e Laxman Dewangan 2013-08-06 35unsigned long *configs, unsigned num_configs, 1eb207a9e Laxman Dewangan 2013-08-06 @36enum pinctrl_map_type type); 1eb207a9e Laxman Dewangan 2013-08-06 37 int pinctrl_utils_add_config(struct pinctrl_dev *pctldev, 1eb207a9e Laxman Dewangan 2013-08-06 38unsigned long **configs, unsigned *num_configs, 1eb207a9e Laxman Dewangan 2013-08-06 39unsigned long config); d32f7fd3b Irina Tirdea2016-03-31 40 void pinctrl_utils_free_map(struct pinctrl_dev *pctldev, 1eb207a9e Laxman Dewangan 2013-08-06 41struct pinctrl_map *map, unsigned num_maps); 1eb207a9e Laxman Dewangan 2013-08-06 42 :: The code at line 36 was first introduced by commit :: 1eb207a9ecaafb980704d8bc055a9a0269f62f8e pinctrl: add utility functions for add map/configs :: TO: Laxman Dewangan :: CC: Linus Walleij --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH V2] pwm: Add MediaTek MT8183 display PWM driver support
On Tue, Jan 22, 2019 at 05:02:43PM +0800, Jitao Shi wrote: > Use the mtk_pwm_data struction to define different registers > and add MT8183 specific register operations, such as MT8183 > doesn't have commit register, needs to disable double buffer > before writing register, and needs to select commit mode > and use PWM_PERIOD/PWM_HIGH_WIDTH. > > Signed-off-by: Jitao Shi There is no difference compared to (implicit) v1 sent a few minutes earlier, right? There was another patch sent with the same Subject last week, so I assume the mail from today without "v2" in the Subject was a mistake? > --- Adding a paragraph below the tripple dash that points out what was changed compared to the previous submission is a good idea to help reviewers to more easily see what was changed. I guess you only adapted the commit log as a reaction to Matthias Burgger's review? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v8 2/5] dt-bindings: spi: add binding file for NXP FlexSPI controller
On Tue, 22 Jan 2019 09:00:14 + Yogesh Narayan Gaur wrote: > Hi Rob / Shawn, > > Can you please apply patches [1] [2]. No, DT bindings should go through Mark's tree. Just wait a bit please.
Re: [PATCH] drm/sun4i: hdmi: Fix usage of TMDS clock
On Tue, Jan 22, 2019 at 09:32:32AM +0200, Priit Laes wrote:
> From: Priit Laes
>
> Although TMDS clock is required for HDMI to properly function,
> nobody called clk_prepare_enable(). This fixes reference counting
> issues and makes sure clock is running when it needs to be running.
>
> Due to TDMS clock being parent clock for DDC clock, TDMS clock
> was turned on/off for each EDID probe, causing spurious failures
> for certain HDMI/DVI screens.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>
> Signed-off-by: Priit Laes
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 061d2e0d9011..25f4d676fd82 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -92,6 +92,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
> val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> +
> + clk_disable_unprepare(hdmi->tmds_clk);
> }
>
> static void sun4i_hdmi_enable(struct drm_encoder *encoder)
> @@ -112,6 +114,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
> val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
>
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> +
> + clk_prepare_enable(hdmi->tmds_clk);
We'll probably need to enable that clock to send the infoframes as
well. I moved it earlier (and that allows the enable and disable
function to be symetric as well).
Thanks for figuring this out!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] doc:process: remove note from 'stable api nonsense'
On Monday, January 21, 2019 9:37:08 AM CET Greg KH wrote: > On Mon, Jan 21, 2019 at 09:14:00AM +0100, Federico Vaga wrote: > > On Monday, January 21, 2019 2:43:38 AM CET Jonathan Corbet wrote: > > > On Fri, 18 Jan 2019 22:58:04 +0100 > > > > > > Federico Vaga wrote: > > > > The link referred by the note can't be retrieved: this patch just > > > > remove that old note. > > > > > > > > Signed-off-by: Federico Vaga > > > > --- > > > > > > > > Documentation/process/stable-api-nonsense.rst | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > diff --git a/Documentation/process/stable-api-nonsense.rst > > > > b/Documentation/process/stable-api-nonsense.rst index > > > > 24f5aeecee91..57d95a49c096 100644 > > > > --- a/Documentation/process/stable-api-nonsense.rst > > > > +++ b/Documentation/process/stable-api-nonsense.rst > > > > @@ -171,8 +171,7 @@ is also a rough job. > > > > > > > > Simple, get your kernel driver into the main kernel tree (remember we > > > > are talking about GPL released drivers here, if your code doesn't > > > > fall > > > > > > > > -under this category, good luck, you are on your own here, you leech > > > > -.) If your > > > > +under this category, good luck, you are on your own here, you leech). > > > > If > > > > your> > > > > > > > > driver is in the tree, and a kernel interface changes, it will be > > > > fixed > > > > up by the person who did the kernel change in the first place. This > > > > ensures that your driver is always buildable, and works over time, > > > > with > > > > > > I've applied this. I do wonder if the "you leech" should maybe come out > > > too, though. I don't think that parasitic worms are a protected class > > > under the CoC, but they might still suffer emotionally from being > > > compared to the purveyors of proprietary modules... > > > > I agree, do you want me to change the patch? > > I would leave it as-is for now please. When this was written, there was > a lot of discussion about closed source modules, and how the companies > that created them were leeches on our development community. No one > disagreed with that statement, and a number of companies privately > agreed with us. > > That still has not changed. > > So I would like to see this remain. I agree on the message, but I disagree on the usage of "you leech". My 2 Cents I do not like political correctness statements, but in this case the document is talking to other developers - who typically do not take decisions about license - and comparing them to a leech: isn't it too much? Alternatives without direct comparison to leech. Here, I just played with punctuation to create some emphasis around "You are on your own here". -8<- Simple, get your kernel driver into the main kernel tree. Remember we are talking about GPL released drivers here, if your code doesn’t fall under this category, good luck. You are on your own here. -8<- And here I just made the reference indirect -8<- (remember we are talking about GPL released drivers here, if your code doesn’t fall under this category, good luck, you are on your own here, leeching has its negative sides) -8<- I will not insist more, it is just a minor discussion about the rights of a poor worm :) > > thanks, > > greg k-h -- Federico Vaga http://www.federicovaga.it/
Re: [PATCH v9 15/22] m68k: Dispatch nvram_ops calls to Atari or Mac functions
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote: > A multi-platform kernel binary has to decide at run-time how to dispatch > the arch_nvram_ops calls. Add a platform-independent arch_nvram_ops > struct for this, to replace the atari-specific one. > > Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs. > > Acked-by: Geert Uytterhoeven > Tested-by: Stan Johnson > Signed-off-by: Finn Thain > --- > Changed since v8: > - Adopted nvram_read_bytes() and nvram_write_bytes() where possible. This patch fails to apply to my tree, what did you make it against? I tried against 5.0-rc1 :( Can you rebase this series against the char-misc-next branch of my char-misc.git tree and resend so that I can apply the whole series? thanks, greg k-h
RE: [PATCH v8 2/5] dt-bindings: spi: add binding file for NXP FlexSPI controller
Hi Boris, > -Original Message- > From: Boris Brezillon [mailto:bbrezil...@kernel.org] > Sent: Tuesday, January 22, 2019 2:47 PM > To: Yogesh Narayan Gaur > Cc: r...@kernel.org; shawn...@kernel.org; mark.rutl...@arm.com; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > frieder.schre...@kontron.de; linux-...@vger.kernel.org; > marek.va...@gmail.com; broo...@kernel.org; linux-...@lists.infradead.org; > computersforpe...@gmail.com; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v8 2/5] dt-bindings: spi: add binding file for NXP FlexSPI > controller > > On Tue, 22 Jan 2019 09:00:14 + > Yogesh Narayan Gaur wrote: > > > Hi Rob / Shawn, > > > > Can you please apply patches [1] [2]. > > No, DT bindings should go through Mark's tree. Just wait a bit please. Ok, thanks. -- Regards Yogesh Gaur
[PATCH v2] 8250_pci.c: Update NI specific devices class to multi serial
On, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
>> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
>> The reason of doing this is because all NI multi port serial cards
>> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
>> serial_pci_is_class_communication test added in the commit 7d8905d06405
>> ("serial: 8250_pci: Enable device after we check black list").
>>
>> Signed-off-by: Guan Yung Tseng
>> ---
>> drivers/tty/serial/8250/8250_pci.c | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c
>> b/drivers/tty/serial/8250/8250_pci.c
>> index 4986b4a..0949db1 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
>> return 0;
>> }
>>
>> +static int pci_ni_probe(struct pci_dev *dev)
>> +{
>> +dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
>> +(dev->class & 0xff);
>
> As Christoph said, this looks really odd. This field comes from the
> PCI structure on the device, it should not be modified by the kernel.
>
> Unless the device is broken and needs to be fixed up in the kernel?
>
> Also, you have sent 2 different patches here for this type of issue, are
> both needed? If so, please resend both of them as a patch series, with
> more explainations in this one as to why you are modifying this field.
>
> I've dropped all pending patches from you from my queue now.
>
Hi Christoph and Greg,
Sorry for the confusion sending 2 different patches to solve the same
issue. I should have wait for your response before sending antoher
patch to solve the similar issue.
For some historical reason, NI serial devices use
PCI_CLASS_COMMUNICATION_OTHER class code. Yes, I understand that
the class code should read from config space instead modified from
kernel. But these devices are shipped to the market for many years.
That's why I am trying to fix the problem in the kernel.
I will send another simple patch again to fix the problem.
Re: [PATCH v9 15/22] m68k: Dispatch nvram_ops calls to Atari or Mac functions
On Tue, Jan 22, 2019 at 10:19:17AM +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote: > > A multi-platform kernel binary has to decide at run-time how to dispatch > > the arch_nvram_ops calls. Add a platform-independent arch_nvram_ops > > struct for this, to replace the atari-specific one. > > > > Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs. > > > > Acked-by: Geert Uytterhoeven > > Tested-by: Stan Johnson > > Signed-off-by: Finn Thain > > --- > > Changed since v8: > > - Adopted nvram_read_bytes() and nvram_write_bytes() where possible. > > This patch fails to apply to my tree, what did you make it against? > > I tried against 5.0-rc1 :( > > Can you rebase this series against the char-misc-next branch of my > char-misc.git tree and resend so that I can apply the whole series? Oops, nope, my fault, I missed some patches in this series, nevermind... greg k-h
Re: [PATCH] nvram: annotate implicit fall through
On Mon, Jan 14, 2019 at 09:44:15PM +0100, Mathieu Malaterre wrote:
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> this place in the code produced a warning (W=1).
>
> This commit remove the following warning:
>
> drivers/char/generic_nvram.c:83:3: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>
> Signed-off-by: Mathieu Malaterre
> Acked-by: Gustavo A. R. Silva
> ---
> drivers/char/generic_nvram.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
> index ff5394f47587..53123c110f7b 100644
> --- a/drivers/char/generic_nvram.c
> +++ b/drivers/char/generic_nvram.c
> @@ -81,6 +81,7 @@ static int nvram_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> #ifdef CONFIG_PPC_PMAC
> case OBSOLETE_PMAC_NVRAM_GET_OFFSET:
> printk(KERN_WARNING "nvram: Using obsolete
> PMAC_NVRAM_GET_OFFSET ioctl\n");
> + /* fall through */
> case IOC_NVRAM_GET_OFFSET: {
> int part, offset;
>
This file is now gone from my tree, sorry.
greg k-h
[PATCH v2 2/7] drm/komeda: Add d71 layer
From: "james qian wang (Arm Technology China)"
1. Add detailed layer/layer_state definitions
2. Add d71_layer_init to report layer features and capabilities according
to D71 layer block.
3. Add d71_layer_updat/disable
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_utils.h| 17 ++
.../arm/display/komeda/d71/d71_component.c| 162 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 10 +-
3 files changed, 185 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index b7bf8db39a64..e97df5fbc9ea 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -25,4 +25,21 @@
num_tries; \
})
+/* the restriction of range is [start, end] */
+struct malidp_range {
+ u32 start;
+ u32 end;
+};
+
+static inline void set_range(struct malidp_range *rg, u32 start, u32 end)
+{
+ rg->start = start;
+ rg->end = end;
+}
+
+static inline bool in_range(struct malidp_range *rg, u32 v)
+{
+ return (v >= rg->start) && (v <= rg->end);
+}
+
#endif /* _MALIDP_UTILS_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 18a36dd71567..0a602e875f5e 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -7,11 +7,171 @@
#include "d71_dev.h"
#include "komeda_kms.h"
#include "malidp_io.h"
+#include "komeda_framebuffer.h"
+
+static void get_resources_id(u32 hw_id, u32 *pipe_id, u32 *comp_id)
+{
+ u32 id = BLOCK_INFO_BLK_ID(hw_id);
+ u32 pipe = id;
+
+ switch (BLOCK_INFO_BLK_TYPE(hw_id)) {
+ case D71_BLK_TYPE_LPU_WB_LAYER:
+ id = KOMEDA_COMPONENT_WB_LAYER;
+ break;
+ case D71_BLK_TYPE_CU_SPLITTER:
+ id = KOMEDA_COMPONENT_SPLITTER;
+ break;
+ case D71_BLK_TYPE_CU_SCALER:
+ pipe = id / D71_PIPELINE_MAX_SCALERS;
+ id %= D71_PIPELINE_MAX_SCALERS;
+ id += KOMEDA_COMPONENT_SCALER0;
+ break;
+ case D71_BLK_TYPE_CU:
+ id += KOMEDA_COMPONENT_COMPIZ0;
+ break;
+ case D71_BLK_TYPE_LPU_LAYER:
+ pipe = id / D71_PIPELINE_MAX_LAYERS;
+ id %= D71_PIPELINE_MAX_LAYERS;
+ id += KOMEDA_COMPONENT_LAYER0;
+ break;
+ case D71_BLK_TYPE_DOU_IPS:
+ id += KOMEDA_COMPONENT_IPS0;
+ break;
+ case D71_BLK_TYPE_CU_MERGER:
+ id = KOMEDA_COMPONENT_MERGER;
+ break;
+ case D71_BLK_TYPE_DOU:
+ id = KOMEDA_COMPONENT_TIMING_CTRLR;
+ break;
+ default:
+ id = 0x;
+ }
+
+ if (comp_id)
+ *comp_id = id;
+
+ if (pipe_id)
+ *pipe_id = pipe;
+}
+
+static u32 get_valid_inputs(struct block_header *blk)
+{
+ u32 valid_inputs = 0, comp_id;
+ int i;
+
+ for (i = 0; i < PIPELINE_INFO_N_VALID_INPUTS(blk->pipeline_info); i++) {
+ get_resources_id(blk->input_ids[i], NULL, &comp_id);
+ if (comp_id == 0x)
+ continue;
+ valid_inputs |= BIT(comp_id);
+ }
+
+ return valid_inputs;
+}
+
+static u32 to_rot_ctrl(u32 rot)
+{
+ u32 lr_ctrl = 0;
+
+ switch (rot & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_0:
+ lr_ctrl |= L_ROT(L_ROT_R0);
+ break;
+ case DRM_MODE_ROTATE_90:
+ lr_ctrl |= L_ROT(L_ROT_R90);
+ break;
+ case DRM_MODE_ROTATE_180:
+ lr_ctrl |= L_ROT(L_ROT_R180);
+ break;
+ case DRM_MODE_ROTATE_270:
+ lr_ctrl |= L_ROT(L_ROT_R270);
+ break;
+ }
+
+ if (rot & DRM_MODE_REFLECT_X)
+ lr_ctrl |= L_HFLIP;
+ if (rot & DRM_MODE_REFLECT_Y)
+ lr_ctrl |= L_VFLIP;
+
+ return lr_ctrl;
+}
+
+static void d71_layer_disable(struct komeda_component *c)
+{
+ malidp_write32_mask(c->reg, BLK_CONTROL, L_EN, 0);
+}
+
+static void d71_layer_update(struct komeda_component *c,
+struct komeda_component_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(state);
+ struct drm_plane_state *plane_st = state->plane->state;
+ struct drm_framebuffer *fb = plane_st->fb;
+ struct komeda_fb *kfb = to_kfb(fb);
+ u32 __iomem *reg = c->reg;
+ u32 ctrl_mask = L_EN | L_ROT(L_ROT_R270) | L_HFLIP | L_VFLIP | L_TBU_EN;
+ u32 ctrl = L_EN | to_rot_ctrl(st->rot);
+ int i;
+
+ for (i = 0; i < fb->format->num_planes; i++) {
+ malidp_write32(reg,
+
Re: [PATCH v9 00/22] Re-use nvram module
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> /dev/nvram misc device. This module is used only by 32-bit PowerPC
> platforms.
>
> The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
> /dev/nvram misc device. This module is now used only by x86 and m68k
> thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
>
> The "generic" module cannot be used by x86 or m68k platforms because it
> cannot co-exist with the "CMOS" module. One reason for that is the
> CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
> that automatically loading the appropriate module would be impossible
> because only one module can provide the char-major-10-144 alias.
>
> A multi-platform kernel binary needs a single, generic module. With this
> patch series, drivers/char/nvram.c becomes more generic and some of the
> arch-specific code gets moved under arch/. The nvram module is then
> usable by all m68k, powerpc and x86 platforms.
>
> This allows for removal of drivers/char/generic_nvram.c as well as a
> duplicate in arch/powerpc/kernel/nvram_64.c. By reducing the number of
> /dev/nvram char misc device implementations, the number of bugs and
> inconsistencies is also reduced.
>
> This approach reduces inconsistencies between PPC32 and PPC64 and also
> between PPC_PMAC and MAC. A uniform API has benefits for userspace.
>
> For example, some error codes for some ioctl calls become consistent
> across PowerPC platforms. The uniform API can potentially benefit any
> bootloader that works across the various platforms having XPRAM
> (e.g. Emile).
>
> This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
> 64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
> pSeries or CHRP.
>
> I think there are two possible merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively,
> the m68k maintainer could take patches 1 thru 16 (though some of these
> have nothing to do with m68k) and after those patches reach mainline
> the powerpc maintainer could take 17 thru 22.
I just took the whole series, thanks for doing this, looks good.
greg k-h
[PATCH v2 1/7] drm/komeda: Add d71_enum_resources and d71_cleanup
From: "james qian wang (Arm Technology China)"
D71 consists of a number of Register Blocks, every Block controls a
specific HW function, every block has a common block_header to represent
its type and pipeline information.
GCU (Global Control Unit) is the first Block which describe the global
information of D71 HW, Like number of block contained and the number of
pipeline supported.
So the d71_enum_resources parsed GCU and create pipeline according
the GCU configuration, and then iterate and detect the blocks that
indicated by the GCU and block_header.
And this change also added two struct d71_dev/d71_pipeline to extend
komeda_dev/komeda_pipeline to add some d71 only members.
v2:
- Return the specific errno not -1.
- Use DRM_DEBUG as default debug msg printer.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_utils.h| 12 +
drivers/gpu/drm/arm/display/komeda/Makefile | 3 +-
.../arm/display/komeda/d71/d71_component.c| 120
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 138 -
.../gpu/drm/arm/display/komeda/d71/d71_dev.h | 50 ++
.../gpu/drm/arm/display/komeda/d71/d71_regs.h | 530 ++
.../drm/arm/display/komeda/komeda_pipeline.c | 16 +-
7 files changed, 852 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index 63cc47cefcf8..b7bf8db39a64 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -13,4 +13,16 @@
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
+#define dp_wait_cond(__cond, __tries, __min_range, __max_range)\
+({ \
+ int num_tries = __tries;\
+ while (!__cond && (num_tries > 0)) {\
+ usleep_range(__min_range, __max_range); \
+ if (__cond) \
+ break; \
+ num_tries--;\
+ } \
+ num_tries; \
+})
+
#endif /* _MALIDP_UTILS_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 1b875e5dc0f6..d593125236ae 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -16,6 +16,7 @@ komeda-y := \
komeda_private_obj.o
komeda-y += \
- d71/d71_dev.o
+ d71/d71_dev.o \
+ d71/d71_component.o
obj-$(CONFIG_DRM_KOMEDA) += komeda.o
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
new file mode 100644
index ..18a36dd71567
--- /dev/null
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
+ * Author: James.Qian.Wang
+ *
+ */
+#include "d71_dev.h"
+#include "komeda_kms.h"
+#include "malidp_io.h"
+
+static int d71_layer_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_Layer.\n");
+
+ return 0;
+}
+
+static int d71_wb_layer_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_Wb_Layer.\n");
+
+ return 0;
+}
+
+static int d71_compiz_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_compiz.\n");
+
+ return 0;
+}
+
+static int d71_improc_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_improc.\n");
+
+ return 0;
+}
+
+static int d71_timing_ctrlr_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_timing_ctrlr.\n");
+
+ return 0;
+}
+
+int d71_probe_block(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ struct d71_pipeline *pipe;
+ int blk_id = BLOCK_INFO_BLK_ID(blk->block_info);
+
+ int err = 0;
+
+ switch (BLOCK_INFO_BLK_TYPE(blk->block_info)) {
+ case D71_BLK_TYPE_GCU:
+ break;
+
+ case D71_BLK_TYPE_LPU:
+ pipe = d71->pipes[blk_id];
+ pipe->lpu_addr = reg;
+ break;
+
+ case D71_BLK_TYPE_LPU_LAYER:
+ err = d71_layer_
[PATCH v2 0/7] D71 pipeline/component descovery and initialization
This is the 2nd patchset for komeda-driver. These patches focus on CHIP(D71) Layer for pipeline/component descovery and initialization. All basic and essential display component: layer, compiz, improc, timing-ctrlr and irq handling have been added, other component support: scaler, wb_layer, merger, splitter will be added in the future. v2: - Rebase. - Use DRM_DEBUG as default msg printer - Return the specific errno not -1. james qian wang (Arm Technology China) (7): drm/komeda: Add d71_enum_resources and d71_cleanup drm/komeda: Add d71 layer drm/komeda: Add d71 compiz component drm/komeda: Add D71 improc and timing_ctrlr drm/komeda: Add komeda_assemble_pipelines drm/komeda: Add irq handling drm/komeda: Add debugfs node "register" for register dump .../drm/arm/display/include/malidp_utils.h| 29 + drivers/gpu/drm/arm/display/komeda/Makefile | 3 +- .../arm/display/komeda/d71/d71_component.c| 682 ++ .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 375 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.h | 50 ++ .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 530 ++ .../gpu/drm/arm/display/komeda/komeda_crtc.c | 18 + .../gpu/drm/arm/display/komeda/komeda_dev.c | 64 ++ .../gpu/drm/arm/display/komeda/komeda_dev.h | 51 ++ .../gpu/drm/arm/display/komeda/komeda_kms.c | 37 +- .../gpu/drm/arm/display/komeda/komeda_kms.h | 5 + .../drm/arm/display/komeda/komeda_pipeline.c | 111 ++- .../drm/arm/display/komeda/komeda_pipeline.h | 48 +- 13 files changed, 1973 insertions(+), 30 deletions(-) create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_component.c create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h -- 2.17.1
[PATCH v2 7/7] drm/komeda: Add debugfs node "register" for register dump
From: "james qian wang (Arm Technology China)"
Add a debugfs node "register" and entry function dump_register to
dev/pipeline/component to register dump, then user can read
"/sys/kernel/debug/komeda/register" to get the register values via these
chip function.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 205 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 52 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 5 +
.../drm/arm/display/komeda/komeda_pipeline.c | 20 ++
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +
5 files changed, 285 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 095779964518..eb8f16e089e7 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -69,6 +69,42 @@ static u32 get_valid_inputs(struct block_header *blk)
return valid_inputs;
}
+static void get_values_from_reg(void __iomem *reg, u32 offset,
+ u32 count, u32 *val)
+{
+ u32 i, addr;
+
+ for (i = 0; i < count; i++) {
+ addr = offset + (i << 2);
+ /* 0xA4 is WO register */
+ if (addr != 0xA4)
+ val[i] = malidp_read32(reg, addr);
+ else
+ val[i] = 0xDEADDEAD;
+ }
+}
+
+static void dump_block_header(struct seq_file *sf, void __iomem *reg)
+{
+ struct block_header hdr;
+ u32 i, n_input, n_output;
+
+ d71_read_block_header(reg, &hdr);
+ seq_printf(sf, "BLOCK_INFO:\t\t0x%X\n", hdr.block_info);
+ seq_printf(sf, "PIPELINE_INFO:\t\t0x%X\n", hdr.pipeline_info);
+
+ n_output = PIPELINE_INFO_N_OUTPUTS(hdr.pipeline_info);
+ n_input = PIPELINE_INFO_N_VALID_INPUTS(hdr.pipeline_info);
+
+ for (i = 0; i < n_input; i++)
+ seq_printf(sf, "VALID_INPUT_ID%u:\t0x%X\n",
+ i, hdr.input_ids[i]);
+
+ for (i = 0; i < n_output; i++)
+ seq_printf(sf, "OUTPUT_ID%u:\t\t0x%X\n",
+ i, hdr.output_ids[i]);
+}
+
static u32 to_rot_ctrl(u32 rot)
{
u32 lr_ctrl = 0;
@@ -141,9 +177,76 @@ static void d71_layer_update(struct komeda_component *c,
malidp_write32_mask(reg, BLK_CONTROL, ctrl_mask, ctrl);
}
+static void d71_layer_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v[15], i;
+ bool rich, rgb2rgb;
+ char *prefix;
+
+ get_values_from_reg(c->reg, LAYER_INFO, 1, &v[14]);
+ if (v[14] & 0x1) {
+ rich = true;
+ prefix = "LR_";
+ } else {
+ rich = false;
+ prefix = "LS_";
+ }
+
+ rgb2rgb = !!(v[14] & L_INFO_CM);
+
+ dump_block_header(sf, c->reg);
+
+ seq_printf(sf, "%sLAYER_INFO:\t\t0x%X\n", prefix, v[14]);
+
+ get_values_from_reg(c->reg, 0xD0, 1, v);
+ seq_printf(sf, "%sCONTROL:\t\t0x%X\n", prefix, v[0]);
+ if (rich) {
+ get_values_from_reg(c->reg, 0xD4, 1, v);
+ seq_printf(sf, "LR_RICH_CONTROL:\t0x%X\n", v[0]);
+ }
+ get_values_from_reg(c->reg, 0xD8, 4, v);
+ seq_printf(sf, "%sFORMAT:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sIT_COEFFTAB:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sIN_SIZE:\t\t0x%X\n", prefix, v[2]);
+ seq_printf(sf, "%sPALPHA:\t\t0x%X\n", prefix, v[3]);
+
+ get_values_from_reg(c->reg, 0x100, 3, v);
+ seq_printf(sf, "%sP0_PTR_LOW:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sP0_PTR_HIGH:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sP0_STRIDE:\t\t0x%X\n", prefix, v[2]);
+
+ get_values_from_reg(c->reg, 0x110, 2, v);
+ seq_printf(sf, "%sP1_PTR_LOW:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sP1_PTR_HIGH:\t\t0x%X\n", prefix, v[1]);
+ if (rich) {
+ get_values_from_reg(c->reg, 0x118, 1, v);
+ seq_printf(sf, "LR_P1_STRIDE:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0x120, 2, v);
+ seq_printf(sf, "LR_P2_PTR_LOW:\t\t0x%X\n", v[0]);
+ seq_printf(sf, "LR_P2_PTR_HIGH:\t\t0x%X\n", v[1]);
+
+ get_values_from_reg(c->reg, 0x130, 12, v);
+ for (i = 0; i < 12; i++)
+ seq_printf(sf, "LR_YUV_RGB_COEFF%u:\t0x%X\n", i, v[i]);
+ }
+
+ if (rgb2rgb) {
+ get_values_from_reg(c->reg, LAYER_RGB_RGB_COEFF0, 12, v);
+ for (i = 0; i < 12; i++)
+ seq_printf(sf, "LS_RGB_RGB_COEFF%u:\t0x%X\n", i, v[i]);
+ }
+
+ get_values_from_reg(c->reg, 0x160, 3, v);
+ seq_printf(sf, "%sAD_CONTROL:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sAD_H_CROP:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sAD_V_CROP:\t\t0x%X\n", prefix, v[2]);
+}
[PATCH v2 5/7] drm/komeda: Add komeda_assemble_pipelines
From: "james qian wang (Arm Technology China)"
komeda_accemble_pipelines is for:
1. Verifing the component->supported_inputs according to the
pipeline->avail_components.
2. Generating component->supported_outputs.
v2: Lower the debug message of komeda_component_dump to DRM_DEBUG.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_dev.c | 6 ++
.../drm/arm/display/komeda/komeda_pipeline.c | 75 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 2 +-
3 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 0fe6954fbbf4..a1160e2f07ec 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -143,6 +143,12 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto err_cleanup;
}
+ err = komeda_assemble_pipelines(mdev);
+ if (err) {
+ DRM_ERROR("assemble display pipelines failed.\n");
+ goto err_cleanup;
+ }
+
return mdev;
err_cleanup:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index f755280caa3e..c2e469164244 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -198,3 +198,78 @@ void komeda_component_destroy(struct komeda_dev *mdev,
{
devm_kfree(mdev->dev, c);
}
+
+static void komeda_component_dump(struct komeda_component *c)
+{
+ if (!c)
+ return;
+
+ DRM_DEBUG(" %s: ID %d-0x%08lx.\n",
+ c->name, c->id, BIT(c->id));
+ DRM_DEBUG(" max_active_inputs:%d, supported_inputs:
0x%08x.\n",
+ c->max_active_inputs, c->supported_inputs);
+ DRM_DEBUG(" max_active_outputs:%d, supported_outputs:
0x%08x.\n",
+ c->max_active_outputs, c->supported_outputs);
+}
+
+static void komeda_pipeline_dump(struct komeda_pipeline *pipe)
+{
+ struct komeda_component *c;
+ int id;
+
+ DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s\n",
+pipe->id, pipe->n_layers, pipe->n_scalers,
+pipe->of_output_dev ? pipe->of_output_dev->full_name : "none");
+
+ dp_for_each_set_bit(id, pipe->avail_comps) {
+ c = komeda_pipeline_get_component(pipe, id);
+
+ komeda_component_dump(c);
+ }
+}
+
+static void komeda_component_verify_inputs(struct komeda_component *c)
+{
+ struct komeda_pipeline *pipe = c->pipeline;
+ struct komeda_component *input;
+ int id;
+
+ dp_for_each_set_bit(id, c->supported_inputs) {
+ input = komeda_pipeline_get_component(pipe, id);
+ if (!input) {
+ c->supported_inputs &= ~(BIT(id));
+ DRM_WARN("Can not find input(ID-%d) for component:
%s.\n",
+id, c->name);
+ continue;
+ }
+
+ input->supported_outputs |= BIT(c->id);
+ }
+}
+
+static void komeda_pipeline_assemble(struct komeda_pipeline *pipe)
+{
+ struct komeda_component *c;
+ int id;
+
+ dp_for_each_set_bit(id, pipe->avail_comps) {
+ c = komeda_pipeline_get_component(pipe, id);
+
+ komeda_component_verify_inputs(c);
+ }
+}
+
+int komeda_assemble_pipelines(struct komeda_dev *mdev)
+{
+ struct komeda_pipeline *pipe;
+ int i;
+
+ for (i = 0; i < mdev->n_pipelines; i++) {
+ pipe = mdev->pipelines[i];
+
+ komeda_pipeline_assemble(pipe);
+ komeda_pipeline_dump(pipe);
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 943aa52189d4..f9b7f517a484 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -363,7 +363,7 @@ komeda_pipeline_add(struct komeda_dev *mdev, size_t size,
struct komeda_pipeline_funcs *funcs);
void komeda_pipeline_destroy(struct komeda_dev *mdev,
struct komeda_pipeline *pipe);
-
+int komeda_assemble_pipelines(struct komeda_dev *mdev);
struct komeda_component *
komeda_pipeline_get_component(struct komeda_pipeline *pipe, int id);
--
2.17.1
[PATCH v2 3/7] drm/komeda: Add d71 compiz component
From: "james qian wang (Arm Technology China)"
Implement d71_compiz_init and add compiz component to komeda-CORE
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 92 ++-
.../drm/arm/display/komeda/komeda_pipeline.h | 26 --
2 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 0a602e875f5e..401053ef0a53 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -96,6 +96,13 @@ static u32 to_rot_ctrl(u32 rot)
return lr_ctrl;
}
+static inline u32 to_d71_input_id(struct komeda_component_output *output)
+{
+ struct komeda_component *comp = output->component;
+
+ return comp ? (comp->hw_id + output->output_port) : 0;
+}
+
static void d71_layer_disable(struct komeda_component *c)
{
malidp_write32_mask(c->reg, BLK_CONTROL, L_EN, 0);
@@ -184,10 +191,93 @@ static int d71_wb_layer_init(struct d71_dev *d71,
return 0;
}
+static void d71_component_disable(struct komeda_component *c)
+{
+ u32 __iomem *reg = c->reg;
+ u32 i;
+
+ malidp_write32(reg, BLK_CONTROL, 0);
+
+ for (i = 0; i < c->max_active_inputs; i++)
+ malidp_write32(reg, BLK_INPUT_ID0 + (i << 2), 0);
+}
+
+static void compiz_enable_input(u32 __iomem *id_reg,
+ u32 __iomem *cfg_reg,
+ u32 input_hw_id,
+ struct komeda_compiz_input_cfg *cin)
+{
+ u32 ctrl = CU_INPUT_CTRL_EN;
+ u8 blend = cin->pixel_blend_mode;
+
+ if (blend == DRM_MODE_BLEND_PIXEL_NONE)
+ ctrl |= CU_INPUT_CTRL_PAD;
+ else if (blend == DRM_MODE_BLEND_PREMULTI)
+ ctrl |= CU_INPUT_CTRL_PMUL;
+
+ ctrl |= CU_INPUT_CTRL_ALPHA(cin->layer_alpha);
+
+ malidp_write32(id_reg, BLK_INPUT_ID0, input_hw_id);
+
+ malidp_write32(cfg_reg, CU_INPUT0_SIZE,
+ HV_SIZE(cin->hsize, cin->vsize));
+ malidp_write32(cfg_reg, CU_INPUT0_OFFSET,
+ HV_OFFSET(cin->hoffset, cin->voffset));
+ malidp_write32(cfg_reg, CU_INPUT0_CONTROL, ctrl);
+}
+
+static void d71_compiz_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_compiz_state *st = to_compiz_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 __iomem *id_reg, *cfg_reg;
+ u32 index, input_hw_id;
+
+ for_each_changed_input(state, index) {
+ id_reg = reg + index;
+ cfg_reg = reg + index * CU_PER_INPUT_REGS;
+ input_hw_id = to_d71_input_id(&state->inputs[index]);
+ if (state->active_inputs & BIT(index)) {
+ compiz_enable_input(id_reg, cfg_reg,
+ input_hw_id, &st->cins[index]);
+ } else {
+ malidp_write32(id_reg, BLK_INPUT_ID0, 0);
+ malidp_write32(cfg_reg, CU_INPUT0_CONTROL, 0);
+ }
+ }
+
+ malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+}
+
+struct komeda_component_funcs d71_compiz_funcs = {
+ .update = d71_compiz_update,
+ .disable= d71_component_disable,
+};
+
static int d71_compiz_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_compiz.\n");
+ struct komeda_component *c;
+ struct komeda_compiz *compiz;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*compiz),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_compiz_funcs,
+CU_NUM_INPUT_IDS, get_valid_inputs(blk),
+CU_NUM_OUTPUT_IDS, reg,
+"CU%d", pipe_id);
+ if (IS_ERR(c))
+ return PTR_ERR(c);
+
+ compiz = to_compiz(c);
+
+ set_range(&compiz->hsize, D71_MIN_LINE_SIZE, d71->max_line_size);
+ set_range(&compiz->vsize, D71_MIN_VERTICAL_SIZE, d71->max_vsize);
return 0;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 03525330efe8..d75cc81ae9c0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -204,6 +204,10 @@ static inline u16 component_changed_inputs(struct
komeda_component_state *st)
return component_disabling_inputs(st) | st->changed_active_inputs;
}
+#define for_each_changed_input(st, i)
[PATCH v2 6/7] drm/komeda: Add irq handling
From: "james qian wang (Arm Technology China)"
1. Added irq_handler/irq_enable/irq_disable to komeda_dev_func, then the
Komeda-CORE can control the HW irq via these chip function.
2. Install irq and register irq_handler to system by DRM, so once the IRQ
coming, the handling sequence is:
komeda_kms_irq_handler(int irq, void *data)
/* step 1. call into the CHIP to recognize event */
mdev->funcs->irq_handler(mdev, &evts);
/* step 2. notify the crtc to handle the events */
for (i = 0; i < kms->n_crtcs; i++)
komeda_crtc_handle_event(&kms->crtcs[i], &evts);
v2:
- Move get IRQ number into this change.
- Enable irq before drm_dev_register.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 237 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 18 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 6 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 46
.../gpu/drm/arm/display/komeda/komeda_kms.c | 37 ++-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
6 files changed, 345 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index b87ffae62dbe..afc13d3b3afc 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -7,6 +7,240 @@
#include "d71_dev.h"
#include "malidp_io.h"
+static u64 get_lpu_event(struct d71_pipeline *d71_pipeline)
+{
+ u32 __iomem *reg = d71_pipeline->lpu_addr;
+ u32 status, raw_status;
+ u64 evts = 0ULL;
+
+ raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
+ if (raw_status & LPU_IRQ_IBSY)
+ evts |= KOMEDA_EVENT_IBSY;
+ if (raw_status & LPU_IRQ_EOW)
+ evts |= KOMEDA_EVENT_EOW;
+
+ if (raw_status & (LPU_IRQ_ERR | LPU_IRQ_IBSY)) {
+ u32 restore = 0, tbu_status;
+ /* Check error of LPU status */
+ status = malidp_read32(reg, BLK_STATUS);
+ if (status & LPU_STATUS_AXIE) {
+ restore |= LPU_STATUS_AXIE;
+ evts |= KOMEDA_ERR_AXIE;
+ }
+ if (status & LPU_STATUS_ACE0) {
+ restore |= LPU_STATUS_ACE0;
+ evts |= KOMEDA_ERR_ACE0;
+ }
+ if (status & LPU_STATUS_ACE1) {
+ restore |= LPU_STATUS_ACE1;
+ evts |= KOMEDA_ERR_ACE1;
+ }
+ if (status & LPU_STATUS_ACE2) {
+ restore |= LPU_STATUS_ACE2;
+ evts |= KOMEDA_ERR_ACE2;
+ }
+ if (status & LPU_STATUS_ACE3) {
+ restore |= LPU_STATUS_ACE3;
+ evts |= KOMEDA_ERR_ACE3;
+ }
+ if (restore != 0)
+ malidp_write32_mask(reg, BLK_STATUS, restore, 0);
+
+ restore = 0;
+ /* Check errors of TBU status */
+ tbu_status = malidp_read32(reg, LPU_TBU_STATUS);
+ if (tbu_status & LPU_TBU_STATUS_TCF) {
+ restore |= LPU_TBU_STATUS_TCF;
+ evts |= KOMEDA_ERR_TCF;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TTNG) {
+ restore |= LPU_TBU_STATUS_TTNG;
+ evts |= KOMEDA_ERR_TTNG;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TITR) {
+ restore |= LPU_TBU_STATUS_TITR;
+ evts |= KOMEDA_ERR_TITR;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TEMR) {
+ restore |= LPU_TBU_STATUS_TEMR;
+ evts |= KOMEDA_ERR_TEMR;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TTF) {
+ restore |= LPU_TBU_STATUS_TTF;
+ evts |= KOMEDA_ERR_TTF;
+ }
+ if (restore != 0)
+ malidp_write32_mask(reg, LPU_TBU_STATUS, restore, 0);
+ }
+
+ malidp_write32(reg, BLK_IRQ_CLEAR, raw_status);
+ return evts;
+}
+
+static u64 get_cu_event(struct d71_pipeline *d71_pipeline)
+{
+ u32 __iomem *reg = d71_pipeline->cu_addr;
+ u32 status, raw_status;
+ u64 evts = 0ULL;
+
+ raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
+ if (raw_status & CU_IRQ_OVR)
+ evts |= KOMEDA_EVENT_OVR;
+
+ if (raw_status & (CU_IRQ_ERR | CU_IRQ_OVR)) {
+ status = malidp_read32(reg, BLK_STATUS) & 0x7FFF;
+ if (status & CU_STATUS_CPE)
+ evts |= KOMEDA_ERR_CPE;
+ if (status & CU_STATUS_ZME)
+ evts |= KOMEDA_ERR_ZME;
+ if (status & CU_STATUS_CFGE)
+ evts |= KOMEDA_ERR_CF
patch "ihex: Share code between ihex_validate_fw() and ihex_next_binrec()" added to driver-core-testing
This is a note to let you know that I've just added the patch titled
ihex: Share code between ihex_validate_fw() and ihex_next_binrec()
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 8092e79204e7884f4bee3584ecfe6cf4a124d129 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:37 -0800
Subject: ihex: Share code between ihex_validate_fw() and ihex_next_binrec()
Convert both ihex_validate_fw() and ihex_next_binrec() to use a helper
function to calculate next record offest. This way we only have one
place implementing next record offset calculation logic. No functional
change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 75c194391869..9c701521176b 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -23,29 +23,34 @@ struct ihex_binrec {
/* Find the next record, taking into account the 4-byte alignment */
static inline const struct ihex_binrec *
-ihex_next_binrec(const struct ihex_binrec *rec)
+__ihex_next_binrec(const struct ihex_binrec *rec)
{
int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
rec = (void *)&rec->data[next];
+ return rec;
+}
+
+static inline const struct ihex_binrec *
+ihex_next_binrec(const struct ihex_binrec *rec)
+{
+ rec = __ihex_next_binrec(rec);
+
return be16_to_cpu(rec->len) ? rec : NULL;
}
/* Check that ihex_next_binrec() won't take us off the end of the image... */
static inline int ihex_validate_fw(const struct firmware *fw)
{
- const struct ihex_binrec *rec;
- size_t ofs = 0;
+ const struct ihex_binrec *end, *rec;
- while (ofs <= fw->size - sizeof(*rec)) {
- rec = (void *)&fw->data[ofs];
+ rec = (const void *)fw->data;
+ end = (const void *)&fw->data[fw->size - sizeof(*end)];
+ for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
if (!be16_to_cpu(rec->len))
return 0;
-
- /* Point to next record... */
- ofs += (sizeof(*rec) + be16_to_cpu(rec->len) + 3) & ~3;
}
return -EINVAL;
}
--
2.20.1
patch "tools/firmware/ihex2fw: Simplify next record offset calculation" added to driver-core-testing
This is a note to let you know that I've just added the patch titled
tools/firmware/ihex2fw: Simplify next record offset calculation
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 2ef8179bb7a6817de3fc9407ab55aa357f2d1e4d Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:40 -0800
Subject: tools/firmware/ihex2fw: Simplify next record offset calculation
We can convert original expression for 'writelen" to use ALIGN as
follows:
(p->len + 9) & ~3 => (p->len + 6 + 3) & ~3 => ALIGN(p->len + 6, 4)
Now, subsituting "p->len + 6" with "p->len + sizeof(p->addr) +
sizeof(p->len)" we end up with the same expression as used by kernel
couterpart in linux/ihex.h:
ALIGN(p->len + sizeof(p->addr) + sizeof(p->len), 4)
That is a full size of the record, aligned to 4 bytes. No functional
change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
tools/firmware/ihex2fw.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index b58dd061e978..e081cef730d8 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -24,6 +24,10 @@
#include
+#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
+#define __ALIGN_KERNEL(x, a) __ALIGN_KERNEL_MASK(x, (typeof(x))(a) -
1)
+#define ALIGN(x, a)__ALIGN_KERNEL((x), (a))
+
struct ihex_binrec {
struct ihex_binrec *next; /* not part of the real data structure */
uint32_t addr;
@@ -259,13 +263,18 @@ static void file_record(struct ihex_binrec *record)
*p = record;
}
+static uint16_t ihex_binrec_size(struct ihex_binrec *p)
+{
+ return p->len + sizeof(p->addr) + sizeof(p->len);
+}
+
static int output_records(int outfd)
{
unsigned char zeroes[6] = {0, 0, 0, 0, 0, 0};
struct ihex_binrec *p = records;
while (p) {
- uint16_t writelen = (p->len + 9) & ~3;
+ uint16_t writelen = ALIGN(ihex_binrec_size(p), 4);
p->addr = htonl(p->addr);
p->len = htons(p->len);
--
2.20.1
patch "ihex: Check if zero-length record is at the end of the blob" added to driver-core-testing
This is a note to let you know that I've just added the patch titled
ihex: Check if zero-length record is at the end of the blob
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 5158c36ec9d0b3343f58987cec7ebfd866331fd0 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:38 -0800
Subject: ihex: Check if zero-length record is at the end of the blob
When verifying the validity of IHEX file we need to make sure that
zero-length record we found is located at the end of the file. Not
doing that could result in an invalid file with a bogus zero-length in
the middle short-circuiting the check and being reported as valid.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9c701521176b..9130f307a420 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -49,7 +49,7 @@ static inline int ihex_validate_fw(const struct firmware *fw)
for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
- if (!be16_to_cpu(rec->len))
+ if (rec == end && !be16_to_cpu(rec->len))
return 0;
}
return -EINVAL;
--
2.20.1
patch "tools/firmware/ihex2fw: Replace explicit alignment with ALIGN" added to driver-core-testing
This is a note to let you know that I've just added the patch titled
tools/firmware/ihex2fw: Replace explicit alignment with ALIGN
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 925f8d4aad5ca1bf18987a3cdcb0e176bcf1 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:41 -0800
Subject: tools/firmware/ihex2fw: Replace explicit alignment with ALIGN
(X + 3) & ~3 is the same as ALIGN(X, 4), so replace all of the
instances of the formwer in the code with the latter. While at it,
introduce a helper variable 'record_size' to avoid duplicating length
calculatin code. No functional change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
tools/firmware/ihex2fw.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index e081cef730d8..8925b60e51f5 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -135,6 +135,7 @@ int main(int argc, char **argv)
static int process_ihex(uint8_t *data, ssize_t size)
{
struct ihex_binrec *record;
+ size_t record_size;
uint32_t offset = 0;
uint32_t data32;
uint8_t type, crc = 0, crcbyte = 0;
@@ -161,12 +162,13 @@ static int process_ihex(uint8_t *data, ssize_t size)
len <<= 8;
len += hex(data + i, &crc); i += 2;
}
- record = malloc((sizeof (*record) + len + 3) & ~3);
+ record_size = ALIGN(sizeof(*record) + len, 4);
+ record = malloc(record_size);
if (!record) {
fprintf(stderr, "out of memory for records\n");
return -ENOMEM;
}
- memset(record, 0, (sizeof(*record) + len + 3) & ~3);
+ memset(record, 0, record_size);
record->len = len;
/* now check if we have enough data to read everything */
--
2.20.1
[PATCH v2 4/7] drm/komeda: Add D71 improc and timing_ctrlr
From: "james qian wang (Arm Technology China)"
Add and initialize improc and timing_ctrlr according to D71 capablitites
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 111 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 +
.../drm/arm/display/komeda/komeda_pipeline.h | 7 ++
3 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 401053ef0a53..095779964518 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -282,18 +282,125 @@ static int d71_compiz_init(struct d71_dev *d71,
return 0;
}
+static void d71_improc_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_improc_state *st = to_improc_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 index, input_hw_id;
+
+ for_each_changed_input(state, index) {
+ input_hw_id = state->active_inputs & BIT(index) ?
+ to_d71_input_id(&state->inputs[index]) : 0;
+ malidp_write32(reg, BLK_INPUT_ID0 + index * 4, input_hw_id);
+ }
+
+ malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+}
+
+struct komeda_component_funcs d71_improc_funcs = {
+ .update = d71_improc_update,
+ .disable= d71_component_disable,
+};
+
static int d71_improc_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_improc.\n");
+ struct komeda_component *c;
+ struct komeda_improc *improc;
+ u32 pipe_id, comp_id, value;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*improc),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_improc_funcs, IPS_NUM_INPUT_IDS,
+get_valid_inputs(blk),
+IPS_NUM_OUTPUT_IDS, reg, "DOU%d_IPS", pipe_id);
+ if (IS_ERR(c)) {
+ DRM_ERROR("Failed to add improc component\n");
+ return PTR_ERR(c);
+ }
+
+ improc = to_improc(c);
+ improc->supported_color_depths = BIT(8) | BIT(10);
+ improc->supported_color_formats = DRM_COLOR_FORMAT_RGB444 |
+ DRM_COLOR_FORMAT_YCRCB444 |
+ DRM_COLOR_FORMAT_YCRCB422;
+ value = malidp_read32(reg, BLK_INFO);
+ if (value & IPS_INFO_CHD420)
+ improc->supported_color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+
+ improc->supports_csc = true;
+ improc->supports_gamma = true;
return 0;
}
+static void d71_timing_ctrlr_disable(struct komeda_component *c)
+{
+ malidp_write32_mask(c->reg, BLK_CONTROL, BS_CTRL_EN, 0);
+}
+
+static void d71_timing_ctrlr_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct drm_crtc_state *crtc_st = state->crtc->state;
+ u32 __iomem *reg = c->reg;
+ struct videomode vm;
+ u32 value;
+
+ drm_display_mode_to_videomode(&crtc_st->adjusted_mode, &vm);
+
+ malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(vm.hactive, vm.vactive));
+ malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(vm.hfront_porch,
+ vm.hback_porch));
+ malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vm.vfront_porch,
+ vm.vback_porch));
+
+ value = BS_SYNC_VSW(vm.vsync_len) | BS_SYNC_HSW(vm.hsync_len);
+ value |= vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ? BS_SYNC_VSP : 0;
+ value |= vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ? BS_SYNC_HSP : 0;
+ malidp_write32(reg, BS_SYNC, value);
+
+ malidp_write32(reg, BS_PROG_LINE, D71_DEFAULT_PREPRETCH_LINE - 1);
+ malidp_write32(reg, BS_PREFETCH_LINE, D71_DEFAULT_PREPRETCH_LINE);
+
+ /* configure bs control register */
+ value = BS_CTRL_EN | BS_CTRL_VM;
+
+ malidp_write32(reg, BLK_CONTROL, value);
+}
+
+struct komeda_component_funcs d71_timing_ctrlr_funcs = {
+ .update = d71_timing_ctrlr_update,
+ .disable= d71_timing_ctrlr_disable,
+};
+
static int d71_timing_ctrlr_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_timing_ctrlr.\n");
+ struct komeda_component *c;
+ struct komeda_timing_ctrlr *ctrlr;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_a
patch "ihex: Simplify next record offset calculation" added to driver-core-testing
This is a note to let you know that I've just added the patch titled
ihex: Simplify next record offset calculation
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 9fb4ab4d3dd665a62da9c176a89e7c7feaf5d9e4 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:39 -0800
Subject: ihex: Simplify next record offset calculation
Next record calucaltion can be reduced to a much more tivial ALIGN
operation as follows:
1. Splitting 5 into 2 + 3 we get
next = ((be16_to_cpu(rec->len) + 2 + 3) & ~3) - 2(1)
2. Using ALIGN macro we reduce (1) to:
ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2 (2)
3. Subsituting 'next' in original next record calucation we get:
(void *)&rec->data[ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2] (3)
4. Converting array index to pointer arithmetic we convert (3) into:
(void *)rec + sizeof(*rec) +
ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2(4)
5. Subsituting sizeof(*rec) with its value, 6, and substracting 2,
in (4) we get:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + 2, 4) + 4(5)
6. Since ALIGN(X, 4) + 4 == ALIGN(X + 4, 4), (5) can be converted to:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + 6, 4)(6)
5. Subsituting 6 in (6) to sizeof(*rec) we get:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + sizeof(*rec), 4) (7)
Using expression (7) should make it more clear that next record is
located by adding full size of the current record (payload + auxiliary
data) aligned to 4 bytes, to the location of the current one. No
functional change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9130f307a420..98cb5ce0b0a0 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -21,14 +21,18 @@ struct ihex_binrec {
uint8_t data[0];
} __attribute__((packed));
+static inline uint16_t ihex_binrec_size(const struct ihex_binrec *p)
+{
+ return be16_to_cpu(p->len) + sizeof(*p);
+}
+
/* Find the next record, taking into account the 4-byte alignment */
static inline const struct ihex_binrec *
__ihex_next_binrec(const struct ihex_binrec *rec)
{
- int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
- rec = (void *)&rec->data[next];
+ const void *p = rec;
- return rec;
+ return p + ALIGN(ihex_binrec_size(rec), 4);
}
static inline const struct ihex_binrec *
--
2.20.1
Re: [PATCH v9 1/4] clk: meson: add one based divider support for sclk divider
On Tue, 2019-01-08 at 21:50 +0800, Jianxin Pan wrote:
> When CLK_DIVIDER_ONE_BASED flag is set, the sclk divider will be:
> one based divider (div = val), and zero value gates the clock
>
> Signed-off-by: Jianxin Pan
> ---
> drivers/clk/meson/Makefile | 3 ++-
> drivers/clk/meson/clkc-audio.h | 8 --
> drivers/clk/meson/clkc.h | 10 ++-
> drivers/clk/meson/sclk-div.c | 59 ---
> ---
> 4 files changed, 50 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index a849aa8..acd8694 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -4,7 +4,8 @@
>
> obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o vid-
> pll-div.o
> obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-input.o
> -obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o sclk-div.o
> +obj-$(CONFIG_COMMON_CLK_AMLOGIC) += sclk-div.o
> +obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o
> obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-
> 32k.o
> diff --git a/drivers/clk/meson/clkc-audio.h b/drivers/clk/meson/clkc-audio.h
> index 0a7c157..286ff12 100644
> --- a/drivers/clk/meson/clkc-audio.h
> +++ b/drivers/clk/meson/clkc-audio.h
> @@ -15,14 +15,6 @@ struct meson_clk_triphase_data {
> struct parm ph2;
> };
>
> -struct meson_sclk_div_data {
> - struct parm div;
> - struct parm hi;
> - unsigned int cached_div;
> - struct clk_duty cached_duty;
> -};
> -
> extern const struct clk_ops meson_clk_triphase_ops;
> -extern const struct clk_ops meson_sclk_div_ops;
>
> #endif /* __MESON_CLKC_AUDIO_H */
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 6183b22..00b3320 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -27,6 +27,14 @@ struct parm {
> u8 width;
> };
>
> +struct meson_sclk_div_data {
> + struct parm div;
> + struct parm hi;
> + unsigned int cached_div;
> + struct clk_duty cached_duty;
> + u8 flags;
> +};
> +
> static inline unsigned int meson_parm_read(struct regmap *map, struct parm
> *p)
> {
> unsigned int val;
> @@ -118,10 +126,10 @@ struct clk_regmap _name = {
> \
> extern const struct clk_ops meson_clk_mpll_ops;
> extern const struct clk_ops meson_clk_phase_ops;
> extern const struct clk_ops meson_vid_pll_div_ro_ops;
> +extern const struct clk_ops meson_sclk_div_ops;
>
> struct clk_hw *meson_clk_hw_register_input(struct device *dev,
> const char *of_name,
> const char *clk_name,
> unsigned long flags);
> -
> #endif /* __CLKC_H */
> diff --git a/drivers/clk/meson/sclk-div.c b/drivers/clk/meson/sclk-div.c
> index bc64019..a6c425b 100644
> --- a/drivers/clk/meson/sclk-div.c
> +++ b/drivers/clk/meson/sclk-div.c
> @@ -4,42 +4,60 @@
> * Author: Jerome Brunet
> *
> * Sample clock generator divider:
> - * This HW divider gates with value 0 but is otherwise a zero based
> divider:
> + * This HW divider gates with value 0
> *
> * val >= 1
> - * divider = val + 1
> + * divider = val + 1 if ONE_BASED is not set, otherwise divider = val.
> *
> * The duty cycle may also be set for the LR clock variant. The duty cycle
> * ratio is:
> *
> * hi = [0 - val]
> - * duty_cycle = (1 + hi) / (1 + val)
> + * duty_cycle = (1 + hi) / (1 + val) if ONE_BASED is not set, otherwise:
> + * duty_cycle = hi / (1 + val)
> */
>
> -#include "clkc-audio.h"
> +#include "clkc.h"
>
> -static inline struct meson_sclk_div_data *
> -meson_sclk_div_data(struct clk_regmap *clk)
> +static inline int get_reg(int val, unsigned char flag)
s/get_reg/sclk_get_reg
> {
> - return (struct meson_sclk_div_data *)clk->data;
> + WARN_ON(val < 1);
I don't think this WARN is justified, especially since you are using this
function to set the hi value.
> + if ((flag & CLK_DIVIDER_ONE_BASED) || !val)
I don't like that you make a dependency on the generic divider just for this.
Please make your own flag like MESON_SCLK_ONE_BASED
> + return val;
> + else
> + return val - 1;
> +}
> +
> +static inline int get_value(int reg, unsigned char flag)
s/get_value/sclk_get_divider
> +{
> + if (flag & CLK_DIVIDER_ONE_BASED)
> + return reg;
> + else
> + return reg + 1;
> }
>
> -static int sclk_div_maxval(struct meson_sclk_div_data *sclk)
> +static inline struct meson_sclk_div_data *
> +meson_sclk_div_data(struct clk_regmap *clk)
> {
> - return (1 << sclk->div.width) - 1;
> + return (struct meson_sclk_div_data *)clk->data;
> }
>
> static int sclk_div_maxdiv(struct meson_sclk_div_data *sclk)
> {
> - return sclk_d
Re: PCI: mediatek: Remove MSI inner domain
On Tue, 2019-01-22 at 11:35 +0800, Ryder Lee wrote:
> On Mon, 2019-01-21 at 19:59 +0800, Jianjun Wang wrote:
> > There is no need to create the inner domain as a parent for MSI domian,
> > some feature has been implemented by MSI framework.
> >
> > Remove the inner domain and its irq chip, it will be more closer to the
> > hardware implementation.
> >
> > Signed-off-by: Jianjun Wang
> > ---
> > drivers/pci/controller/pcie-mediatek.c | 82 +++---
> > 1 file changed, 35 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 8d05df56158b..216e6fa8aec0 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -169,7 +169,6 @@ struct mtk_pcie_soc {
> > * @slot: port slot
> > * @irq: GIC irq
> > * @irq_domain: legacy INTx IRQ domain
> > - * @inner_domain: inner IRQ domain
> > * @msi_domain: MSI IRQ domain
> > * @lock: protect the msi_irq_in_use bitmap
> > * @msi_irq_in_use: bit map for assigned MSI IRQ
> > @@ -190,7 +189,6 @@ struct mtk_pcie_port {
> > u32 slot;
> > int irq;
> > struct irq_domain *irq_domain;
> > - struct irq_domain *inner_domain;
> > struct irq_domain *msi_domain;
> > struct mutex lock;
> > DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> > @@ -418,22 +416,25 @@ static void mtk_msi_ack_irq(struct irq_data *data)
> > u32 hwirq = data->hwirq;
> >
> > writel(1 << hwirq, port->base + PCIE_IMSI_STATUS);
> > + writel(MSI_STATUS, port->base + PCIE_INT_STATUS);
> > }
> >
> > -static struct irq_chip mtk_msi_bottom_irq_chip = {
> > - .name = "MTK MSI",
> > +static struct irq_chip mtk_msi_irq_chip = {
> > + .name = "MTK PCIe",
> > .irq_compose_msi_msg= mtk_compose_msi_msg,
> > + .irq_write_msi_msg = pci_msi_domain_write_msg,
> > .irq_set_affinity = mtk_msi_set_affinity,
> > .irq_ack= mtk_msi_ack_irq,
> > + .irq_mask = pci_msi_mask_irq,
> > + .irq_unmask = pci_msi_unmask_irq,
> > };
>
> (...omitted...)
>
> To keep the patch simple, we don't need to adjust the position for
> mtk_msi_irq_chip.
OK, I will fix it in next version, thanks.
>
> > -
> > -static struct irq_chip mtk_msi_irq_chip = {
> > - .name = "MTK PCIe MSI",
> > - .irq_ack= irq_chip_ack_parent,
> > - .irq_mask = pci_msi_mask_irq,
> > - .irq_unmask = pci_msi_unmask_irq,
> > +static struct msi_domain_ops mtk_msi_domain_ops = {
> > + .get_hwirq = mtk_pcie_msi_get_hwirq,
> > + .msi_free = mtk_pcie_msi_free,
> > };
> >
> > static struct msi_domain_info mtk_msi_domain_info = {
> > - .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > - MSI_FLAG_PCI_MSIX),
> > - .chip = &mtk_msi_irq_chip,
> > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> > + MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_PCI_MSIX),
> > + .ops= &mtk_msi_domain_ops,
> > + .chip = &mtk_msi_irq_chip,
> > + .handler= handle_edge_irq,
> > + .handler_name = "MSI",
> > };
> >
>
>
Re: [PATCH v9 4/4] clk: meson: add sub MMC clock controller driver
On Tue, 2019-01-08 at 21:50 +0800, Jianxin Pan wrote:
> From: Yixun Lan
>
> The patch will add a MMC clock controller driver which used by MMC or NAND,
> It provide a mux and divider clock, and three phase clocks - core, tx, tx.
>
> Two clocks are provided as the parent of MMC clock controller from
> upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
>
> To specify which clock the MMC or NAND driver may consume,
> the preprocessor macros in the dt-bindings/clock/amlogic,mmc-clkc.h header
> can be used in the device tree sources.
>
> Signed-off-by: Yixun Lan
> Signed-off-by: Jianxin Pan
> ---
> drivers/clk/meson/Kconfig| 10 ++
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/mmc-clkc.c | 304
> +++
> 3 files changed, 315 insertions(+)
> create mode 100644 drivers/clk/meson/mmc-clkc.c
>
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index efaa70f..3555f9d 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -15,6 +15,16 @@ config COMMON_CLK_MESON_AO
> select COMMON_CLK_REGMAP_MESON
> select RESET_CONTROLLER
>
> +config COMMON_CLK_MMC_MESON
> + tristate "Meson MMC Sub Clock Controller Driver"
> + depends on ARCH_MESON || COMPILE_TEST
> + select MFD_SYSCON
> + select COMMON_CLK_AMLOGIC
> + help
> + Support for the MMC sub clock controller on Amlogic Meson Platform,
> + which include S905 (GXBB, GXL), A113D/X (AXG) devices.
> + Say Y if you want this clock enabled.
> +
> config COMMON_CLK_REGMAP_MESON
> bool
> select REGMAP
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index d59620d..54416a2 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -12,4 +12,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-
> 32k.o
> obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
> obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
> +obj-$(CONFIG_COMMON_CLK_MMC_MESON) += mmc-clkc.o
> obj-$(CONFIG_COMMON_CLK_REGMAP_MESON)+= clk-regmap.o
> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
> new file mode 100644
> index 000..2582a98
> --- /dev/null
> +++ b/drivers/clk/meson/mmc-clkc.c
> @@ -0,0 +1,304 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Amlogic Meson MMC Sub Clock Controller Driver
> + *
> + * Copyright (c) 2017 Baylibre SAS.
> + * Author: Jerome Brunet
> + *
> + * Copyright (c) 2018 Amlogic, inc.
> + * Author: Yixun Lan
> + * Author: Jianxin Pan
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clkc.h"
> +
> +/* clock ID used by internal driver */
> +
> +#define SD_EMMC_CLOCK0
> +#define CLK_DELAY_STEP_PS200
> +#define MUX_CLK_NUM_PARENTS 2
> +#define MMC_MAX_CLKS 4
> +
> +struct mmc_clkc_data {
> + struct meson_clk_phase_delay_data tx;
> + struct meson_clk_phase_delay_data rx;
> +};
> +
> +static struct clk_regmap_mux_data mmc_clkc_mux_data = {
> + .offset = SD_EMMC_CLOCK,
> + .mask = 0x3,
> + .shift = 6,
> +};
> +
> +static const struct meson_sclk_div_data mmc_clkc_div_data = {
> + .div = {
> + .reg_off = SD_EMMC_CLOCK,
> + .width = 6,
> + },
> + .flags = CLK_DIVIDER_ONE_BASED,
> +};
> +
> +static struct meson_clk_phase_data mmc_clkc_core_phase = {
> + .ph = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 8,
> + .width = 2,
> + }
> +};
> +
> +static const struct mmc_clkc_data mmc_clkc_gx_data = {
> + .tx = {
> + .phase = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 10,
> + .width = 2,
> + },
> + .delay = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 16,
> + .width = 4,
> + },
> + .delay_step_ps = CLK_DELAY_STEP_PS,
> + },
> + .rx = {
> + .phase = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 12,
> + .width = 2,
> + },
> + .delay = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 20,
> + .width = 4,
> + },
> + .delay_step_ps = CLK_DELAY_STEP_PS,
> + },
> +};
> +
> +static const struct mmc_clkc_data mmc_clkc_axg_data = {
> + .tx = {
> + .phase = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 10,
> + .width = 2,
> + },
> + .delay = {
> + .reg_off = SD_EMMC_CLOCK,
> + .shift = 16,
> +
Re: [PATCH] firmware: (memconsole) do not count numbers if read fails
On Tue, Dec 25, 2018 at 11:29:11PM -0600, Kangjie Lu wrote:
> When memory_read_from_buffer() fails, the return value is a negative
> error code, thus we shouldn't count it as the number of read bytes.
>
> The fix checks the return value of memory_read_from_buffer, and count
> the number only when it succeeds.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/firmware/google/memconsole-coreboot.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/google/memconsole-coreboot.c
> b/drivers/firmware/google/memconsole-coreboot.c
> index b29e10757bfb..4e8a0ad110c1 100644
> --- a/drivers/firmware/google/memconsole-coreboot.c
> +++ b/drivers/firmware/google/memconsole-coreboot.c
> @@ -55,6 +55,7 @@ static ssize_t memconsole_coreboot_read(char *buf, loff_t
> pos, size_t count)
> } seg[2] = { {0}, {0} };
> size_t done = 0;
> int i;
> + int ret;
>
> if (flags & OVERFLOW) {
> if (cursor > size) /* Shouldn't really happen, but... */
> @@ -66,8 +67,10 @@ static ssize_t memconsole_coreboot_read(char *buf, loff_t
> pos, size_t count)
> }
>
> for (i = 0; i < ARRAY_SIZE(seg) && count > done; i++) {
> - done += memory_read_from_buffer(buf + done, count - done, &pos,
> + ret = memory_read_from_buffer(buf + done, count - done, &pos,
> cbmem_console->body + seg[i].phys, seg[i].len);
> + if (ret >= 0)
> + done += ret;
But if ret < 0, then it's an error, and something should happen, right?
And really, the only way this can fail is if pos is less than 0, which.
And if that happens, you just now stuck us in an endless loop, which is
worse than just ignoring the error value returned :(
thanks,
greg k-h
Re: [PATCH 2/5] sched: convert signal_struct.sigcnt to refcount_t
On Tue, Jan 22, 2019 at 09:11:42AM +, Reshetova, Elena wrote: > Will you be able to take this and the other scheduler > patch to whatever tree/path it should normally go to get eventually > integrated? I've queeud them up.
Re: linux-next: manual merge of the pidfd tree with the y2038 tree
On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner wrote: > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote: > > On 1/21/19 1:23 PM, Christian Brauner wrote: > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote: > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner > > >> wrote: > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote: > > On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell > > wrote: > > >>> > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal() > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our > > >>> branches don't conflict? Any suggestions? > > >> > > >> A conflict can't be avoided, but if you pick system call number 427 > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for > > > > > > That sounds good to me. Since it's only one syscall for the pidfd branch > > > is there anything that speaks against me using 424? Given that the other > > > patchset has 4 new syscalls. :) > > > Jens, any objections? > > > > I'm fine with either one, I'll have to renumber in any case. But it's 3 > > new syscalls (424, 425, 426), not 4. > > > > Arnd, what's the best way to make this switch now, in my tree? Would be > > Yeah, I'd like to know that as well. > > > great if I didn't have to change it again once I make the change. I'd suggest that you each just take the numbers we talked about and add them in your respective git trees, at the end of the current tables. Stephen and Linus can then do a trivial add/add merge between the three trees that does not involve changing any of the lines besides keeping them in the right order. The result should then be == arch/x86/entry/syscalls/syscall_32.tbl 422i386futex_time64sys_futex__ia32_sys_futex 423i386sched_rr_get_interval_time64 sys_sched_rr_get_interval__ia32_sys_sched_rr_get_interval 424i386pidfd_send_signal sys_pidfd_send_signal __ia32_sys_pidfd_send_signal 425i386io_uring_setup sys_io_uring_setup __ia32_compat_sys_io_uring_setup 426i386io_uring_enter sys_io_uring_enter __ia32_sys_io_uring_enter 427i386io_uring_register sys_io_uring_register __ia32_sys_io_uring_register == arch/x86/entry/syscalls/syscall_64.tbl ... 334common rseq__x64_sys_rseq # don't use numbers 387 through 423, add new calls after the last # 'common' entry 424commonpidfd_send_signal __x64_sys_pidfd_send_signal 425commonio_uring_setup __x64_sys_io_uring_setup 426commonio_uring_enter __x64_sys_io_uring_enter 427commonio_uring_register__x64_sys_io_uring_register # # x32-specific system call numbers start at 512 to avoid cache impact # for native 64-bit operation. The __x32_compat_sys stubs are created # on-the-fly for compat_sys_*() compatibility system calls if X86_X32 # is defined. # 512 x32 rt_sigaction__x32_compat_sys_rt_sigaction ... My hope is that in the future, any new system call will get added to all 16 syscall.tbl files at once, but let's maybe not do this for 5.1 yet, since that only causes more conflicts. I can simply follow up with a patch to add pidfd_send_signal and io_uring_* everywhere during the merge window. Arnd
Re: [PATCH v9 3/4] clk: meson: add DT documentation for emmc clock controller
On Tue, 2019-01-08 at 21:50 +0800, Jianxin Pan wrote:
> From: Yixun Lan
>
> Document the MMC sub clock controller driver, the potential consumer
> of this driver is MMC or NAND. Also add four clock bindings IDs which
> provided by this driver.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Yixun Lan
> Signed-off-by: Jianxin Pan
> ---
> .../devicetree/bindings/clock/amlogic,mmc-clkc.txt | 39
> ++
> include/dt-bindings/clock/amlogic,mmc-clkc.h | 17 ++
> 2 files changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-
> clkc.txt
> create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
> b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
> new file mode 100644
> index 000..0f518e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
> @@ -0,0 +1,39 @@
> +* Amlogic MMC Sub Clock Controller Driver
> +
> +The Amlogic MMC clock controller generates and supplies clock to support
> +MMC and NAND controller
> +
> +Required Properties:
> +
> +- compatible: should be:
> + "amlogic,gx-mmc-clkc"
> + "amlogic,axg-mmc-clkc"
nitpick, missing is something to tell that only one is required, not both
for example `should be one of the following`
> +
> +- #clock-cells: should be 1.
> +- clocks: phandles to clocks corresponding to the clock-names property
> +- clock-names: list of parent clock names
> + - "clkin0", "clkin1"
> +
> +- reg: address of emmc sub clock register
> +
> +Example: Clock controller node:
> +
> +sd_mmc_c_clkc: clock-controller@7000 {
> + compatible = "amlogic,axg-mmc-clkc", "syscon";
> + reg = <0x0 0x7000 0x0 0x4>;
> + #clock-cells = <1>;
> +
> + clock-names = "clkin0", "clkin1";
> + clocks = <&clkc CLKID_SD_MMC_C_CLK0>,
> + <&clkc CLKID_FCLK_DIV2>;
> +};
> +
> +sd_emmc_b_clkc: clock-controller@5000 {
> + compatible = "amlogic,axg-mmc-clkc", "syscon";
> + reg = <0x0 0x5000 0x0 0x4>;
> +
> + #clock-cells = <1>;
> + clock-names = "clkin0", "clkin1";
> + clocks = <&clkc CLKID_SD_EMMC_B_CLK0>,
> + <&clkc CLKID_FCLK_DIV2>;
> +};
> diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h b/include/dt-
> bindings/clock/amlogic,mmc-clkc.h
> new file mode 100644
> index 000..34a3c56
> --- /dev/null
> +++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> +/*
> + * Meson MMC sub clock tree IDs
> + *
> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
> + * Author: Yixun Lan
> + */
> +
> +#ifndef __MMC_CLKC_H
> +#define __MMC_CLKC_H
> +
> +#define CLKID_MMC_DIV0
> +#define CLKID_MMC_PHASE_CORE 1
> +#define CLKID_MMC_PHASE_TX 2
> +#define CLKID_MMC_PHASE_RX 3
> +
> +#endif
Re: [PATCH v1] clk: qcom: lpass: Add CLK_IGNORE_UNUSED for lpass clocks
Hello Stephen, On 1/19/2019 12:31 AM, Stephen Boyd wrote: Quoting Taniya Das (2019-01-17 03:19:22) On 1/15/2019 3:55 AM, Stephen Boyd wrote: Quoting Taniya Das (2019-01-13 22:12:39) On 1/8/2019 2:34 AM, Stephen Boyd wrote: As far as I know, I'm not suggesting the use of CLK_IS_CRITICAL here. But removing CLK_IS_CRITICAL and relying on some random bootloader behavior also looks wrong. Can you clarify what's going on? To enable LPASS clocks the requirement is to enable the GCC_LPASS_SWAY clock. 1) If the LPASS drivers are enabled/probed before the clock late init the client would take care to maintain the dependency to enable the GCC_LPASS_SWAY clock before enabling the LPASS clocks. 2) There could be a condition where the LPASS drivers would probe/init later the clock late_init. When the clock_late_init would try to access the LPASS clocks, since we cannot maintain the dependency this access would fail. To avoid this the earlier patch has made the GCC_LPASS_SWAY clock as CRITICAL. 3) Marking the GCC_LPASS_SWAY clock as CRITICAL has a issue, in the case where the LPASS subsystem would be restarted due to some critical failure on LPASS. Toggling the restart register of LPASS would clear the hardware state of this clock and thus the next access of the LPASS clocks would result in failure of the system. 4) To avoid issues happening in (2) and (3) all the LPASS clocks chould be safely marked as CLK_IGNORE_UNUSED. And lpass drivers would take care of the dependency to enable the required clocks. Ok, so why can't we enable/disable the lpass sway clk in the prepare/unprepare phase of the lpass clk driver paths? Or why can't we forcibly enable this lpass sway clk after the reset is deasserted? Which clk controller is the reset part of? GCC or LPASS? It is part of Always On Subsystem. Ok. Is this merged upstream? It still sounds like the LPASS clk driver isn't handling dependencies it has on accessing registers, but maybe we can get away with not handling the dependency still if we make the reset "do the right thing" and turn the clk back on so it stays "critical". This is a reset from hardware and it does not bring back the clock to the previous state and so we can not mark it "critical". I would submit the next series with comments updated. Please let me know in case you have any comments. Can we have the always on subsystem reset code go hit this clk enable bit back on? There is no code, it is a reset from hardware. And also have the LPASS clk driver get this GCC sway clk and enable it during probe? Maybe we need to get some sort of API in the clk provider layer that can tell us that the clk state has changed now and it needs to be restored. I haven't thought about it deeply but that may be the best solution here. Would it be possible to go about with the current patch and then have it updated with the possible solutions. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. --
Re: linux-next: manual merge of the pidfd tree with the y2038 tree
On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote: > On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner > wrote: > > > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote: > > > On 1/21/19 1:23 PM, Christian Brauner wrote: > > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote: > > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner > > > >> wrote: > > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote: > > > On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell > > > wrote: > > > >>> > > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal() > > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our > > > >>> branches don't conflict? Any suggestions? > > > >> > > > >> A conflict can't be avoided, but if you pick system call number 427 > > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for > > > > > > > > That sounds good to me. Since it's only one syscall for the pidfd branch > > > > is there anything that speaks against me using 424? Given that the other > > > > patchset has 4 new syscalls. :) > > > > Jens, any objections? > > > > > > I'm fine with either one, I'll have to renumber in any case. But it's 3 > > > new syscalls (424, 425, 426), not 4. > > > > > > Arnd, what's the best way to make this switch now, in my tree? Would be > > > > Yeah, I'd like to know that as well. > > > > > great if I didn't have to change it again once I make the change. > > I'd suggest that you each just take the numbers we talked about and > add them in your respective git trees, at the end of the current tables. Great! Will do that today before Stephen does a new merge for -next. > > Stephen and Linus can then do a trivial add/add merge between the > three trees that does not involve changing any of the lines besides > keeping them in the right order. The result should then be > > == arch/x86/entry/syscalls/syscall_32.tbl > 422i386futex_time64sys_futex__ia32_sys_futex > 423i386sched_rr_get_interval_time64 > sys_sched_rr_get_interval__ia32_sys_sched_rr_get_interval > 424i386pidfd_send_signal sys_pidfd_send_signal > __ia32_sys_pidfd_send_signal > 425i386io_uring_setup sys_io_uring_setup > __ia32_compat_sys_io_uring_setup > 426i386io_uring_enter sys_io_uring_enter > __ia32_sys_io_uring_enter > 427i386io_uring_register sys_io_uring_register > __ia32_sys_io_uring_register > > == arch/x86/entry/syscalls/syscall_64.tbl > ... > 334common rseq__x64_sys_rseq > # don't use numbers 387 through 423, add new calls after the last > # 'common' entry > 424commonpidfd_send_signal __x64_sys_pidfd_send_signal > 425commonio_uring_setup __x64_sys_io_uring_setup > 426commonio_uring_enter __x64_sys_io_uring_enter > 427commonio_uring_register__x64_sys_io_uring_register > # > # x32-specific system call numbers start at 512 to avoid cache impact > # for native 64-bit operation. The __x32_compat_sys stubs are created > # on-the-fly for compat_sys_*() compatibility system calls if X86_X32 > # is defined. > # > 512 x32 rt_sigaction__x32_compat_sys_rt_sigaction > ... > > My hope is that in the future, any new system call will get added to > all 16 syscall.tbl files at once, but let's maybe not do this for 5.1 > yet, since that only causes more conflicts. I can simply follow up > with a patch to add pidfd_send_signal and io_uring_* everywhere > during the merge window. Sounds good to me. Thanks Arnd! Christian
[PATCH] doc: process: GPL -> GPL-compatible
Drivers under MIT, BSD-17-clause, or uncle-Bob's-newest-take-on-PD are all fine, not just GPL. Signed-off-by: Adam Borowski --- Not reformatting to fill lines, it'll semi-conflict with another patch that's been acked but not yet pushed. Documentation/process/stable-api-nonsense.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/process/stable-api-nonsense.rst b/Documentation/process/stable-api-nonsense.rst index 24f5aeecee91..9b69fb08b65e 100644 --- a/Documentation/process/stable-api-nonsense.rst +++ b/Documentation/process/stable-api-nonsense.rst @@ -170,7 +170,8 @@ nightmare, and trying to keep up with an ever changing kernel interface is also a rough job. Simple, get your kernel driver into the main kernel tree (remember we -are talking about GPL released drivers here, if your code doesn't fall +are talking about drivers released under a GPL-compatible license here, +if your code doesn't fall under this category, good luck, you are on your own here, you leech .) If your driver is in the tree, and a kernel interface changes, it will be fixed -- 2.20.1
RE: [PATCH 2/5] sched: convert signal_struct.sigcnt to refcount_t
> On Tue, Jan 22, 2019 at 09:11:42AM +, Reshetova, Elena wrote: > > Will you be able to take this and the other scheduler > > patch to whatever tree/path it should normally go to get eventually > > integrated? > > I've queeud them up. Thank you! Best Regards, Elena.
Re: [PATCH v4 2/4] can: m_can: Migrate the m_can code to use the framework
Hello,
Am 17.01.19 um 21:05 schrieb Dan Murphy:
> Migrate the m_can code to use the m_can_platform framework
> code.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/net/can/m_can/Kconfig | 12 +
> drivers/net/can/m_can/Makefile | 4 +-
> drivers/net/can/m_can/m_can.c | 764 -
> drivers/net/can/m_can/m_can_platform.h | 2 +-
> 4 files changed, 374 insertions(+), 408 deletions(-)
>
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..b1a9358b7660 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,17 @@
> config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> + Say Y here if you want to support for Bosch M_CAN controller.
> +
> +config CAN_M_CAN_CORE
> + depends on CAN_M_CAN
> + tristate "Bosch M_CAN Core support"
> + ---help---
> + Say Y here if you want to support for Bosch M_CAN controller.
Do you need that extra config? I think "CAN_M_CAN" is just fine.
> +config CAN_M_CAN_PLATFORM
> depends on HAS_IOMEM
> + depends on CAN_M_CAN_CORE
> tristate "Bosch M_CAN devices"
> ---help---
> Say Y here if you want to support for Bosch M_CAN controller.
> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..04f36947ac3b 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -2,4 +2,6 @@
> # Makefile for the Bosch M_CAN controller driver.
> #
>
> -obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_CORE) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
This file is provided in a sub-sequent patched! The code *must* compile
for every single patch applied for bisect'ing. Looking to your first
patch, I just realize that this is also not the case!
I think it makes sense to squash patch 1 and 2.
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index f817b28582e9..6da0ae26138e 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -28,87 +28,14 @@
> #include
> #include
>
> +#include "m_can_platform.h"
> +
> /* napi related */
> #define M_CAN_NAPI_WEIGHT64
>
> /* message ram configuration data length */
> #define MRAM_CFG_LEN 8
>
> -/* registers definition */
> -enum m_can_reg {
> - M_CAN_CREL = 0x0,
> - M_CAN_ENDN = 0x4,
> - M_CAN_CUST = 0x8,
> - M_CAN_DBTP = 0xc,
> - M_CAN_TEST = 0x10,
> - M_CAN_RWD = 0x14,
> - M_CAN_CCCR = 0x18,
> - M_CAN_NBTP = 0x1c,
> - M_CAN_TSCC = 0x20,
> - M_CAN_TSCV = 0x24,
> - M_CAN_TOCC = 0x28,
> - M_CAN_TOCV = 0x2c,
> - M_CAN_ECR = 0x40,
> - M_CAN_PSR = 0x44,
> -/* TDCR Register only available for version >=3.1.x */
> - M_CAN_TDCR = 0x48,
> - M_CAN_IR= 0x50,
> - M_CAN_IE= 0x54,
> - M_CAN_ILS = 0x58,
> - M_CAN_ILE = 0x5c,
> - M_CAN_GFC = 0x80,
> - M_CAN_SIDFC = 0x84,
> - M_CAN_XIDFC = 0x88,
> - M_CAN_XIDAM = 0x90,
> - M_CAN_HPMS = 0x94,
> - M_CAN_NDAT1 = 0x98,
> - M_CAN_NDAT2 = 0x9c,
> - M_CAN_RXF0C = 0xa0,
> - M_CAN_RXF0S = 0xa4,
> - M_CAN_RXF0A = 0xa8,
> - M_CAN_RXBC = 0xac,
> - M_CAN_RXF1C = 0xb0,
> - M_CAN_RXF1S = 0xb4,
> - M_CAN_RXF1A = 0xb8,
> - M_CAN_RXESC = 0xbc,
> - M_CAN_TXBC = 0xc0,
> - M_CAN_TXFQS = 0xc4,
> - M_CAN_TXESC = 0xc8,
> - M_CAN_TXBRP = 0xcc,
> - M_CAN_TXBAR = 0xd0,
> - M_CAN_TXBCR = 0xd4,
> - M_CAN_TXBTO = 0xd8,
> - M_CAN_TXBCF = 0xdc,
> - M_CAN_TXBTIE= 0xe0,
> - M_CAN_TXBCIE= 0xe4,
> - M_CAN_TXEFC = 0xf0,
> - M_CAN_TXEFS = 0xf4,
> - M_CAN_TXEFA = 0xf8,
> -};
> -
> -/* m_can lec values */
> -enum m_can_lec_type {
> - LEC_NO_ERROR = 0,
> - LEC_STUFF_ERROR,
> - LEC_FORM_ERROR,
> - LEC_ACK_ERROR,
> - LEC_BIT1_ERROR,
> - LEC_BIT0_ERROR,
> - LEC_CRC_ERROR,
> - LEC_UNUSED,
> -};
> -
> -enum m_can_mram_cfg {
> - MRAM_SIDF = 0,
> - MRAM_XIDF,
> - MRAM_RXF0,
> - MRAM_RXF1,
> - MRAM_RXB,
> - MRAM_TXE,
> - MRAM_TXB,
> - MRAM_CFG_NUM,
> -};
Patch 1 should have already done that!
> /* Core Release Register (CREL) */
> #define CREL_REL_SHIFT 28
> #define CREL_REL_MASK(0xF << CREL_REL_SHIFT)
> @@ -343,72 +270,81 @@ enum m_can_mram_cfg {
> #define TX_BUF_MM_MASK (0xff << TX_BUF_MM_SHIFT)
>
> /* Tx event FIFO Element */
> -/* E1 */
> #define TX_EVENT_MM_SHIFTTX_BUF_MM_SHIFT
> #define TX_EVENT_MM_MASK (0xff << TX_EVENT_MM_SHIFT)
>
> -/* address offset and element number for each FIFO/Buffer in the
Re: [PATCH v4 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller
Hi Bin,
Sorry to bother you again, I encounter a problem about the extcon
property.
I don't find a common driver describing the usb-connector. Is
there any driver that I can refer to, specially the way to switch MUSB
controller between host and device mode?
If it needs to implement by myself, is it possible to emulate an
usb-connector driver by extcon-usb-gpio, and also use the notifier
mechanism or can you give me some advices?
Hi Rob,
On Mon, 2019-01-21 at 09:14 -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 08:22:26PM +0800, min@mediatek.com wrote:
> > From: Min Guo
> >
> > This adds support for MediaTek musb controller in
> > host, peripheral and otg mode.
> >
> > Signed-off-by: Min Guo
> > ---
> > changes in v4:
> > suggested by Sergei:
> > 1. String alignment
> >
> > changes in v3:
> > 1. no changes
> >
> > changes in v2:
> > suggested by Bin:
> > 1. Modify DRC to DRD
> > suggested by Rob:
> > 2. Drop the "-musb" in compatible
>
> This is not what I said. I gave you the exact text to put.
Sorry to misunderstood your meaning last time, I will modify it in next
patch.
compatible: should be one of "mediatek,mt2701-musb"...,followed by
"mediatek,mtk-musb"
> > 3. Remove phy-names
> > 4. Add space after comma in clock-names
> > ---
> > .../devicetree/bindings/usb/mediatek,musb.txt | 43
> > ++
> > 1 file changed, 43 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
> > b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
> > new file mode 100644
> > index 000..4305770
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
> > @@ -0,0 +1,43 @@
> > +MediaTek musb DRD/OTG controller
> > +---
> > +
> > +Required properties:
> > + - compatible : should be "mediatek,mtk-musb"
> > + - reg : specifies physical base address and size of
> > + the registers
> > + - interrupts : interrupt used by musb controller
> > + - interrupt-names : must be "mc"
> > + - phys: PHY specifier for the OTG phy
> > + - dr_mode : should be one of "host", "peripheral" or "otg",
> > + refer to usb/generic.txt
> > + - clocks : a list of phandle + clock-specifier pairs, one for
> > + each entry in clock-names
> > + - clock-names : must contain "main", "mcu", "univpll"
> > + for clocks of controller
> > +
> > +Optional properties:
> > + - extcon : external connector for VBUS and ID pin changes
> > detection,
> > + needed when supports dual-role mode
>
> Again, do not use extcon in new bindings.
Thanks, ok.
> > + - vbus-supply : reference to the VBUS regulator, needed when supports
> > + dual-role mode
> > + - power-domains : a phandle to USB power domain node to control USB's
> > + MTCMOS
> > +
> > +Example:
> > +
> > +usb2: usb@1120 {
> > + compatible = "mediatek,mt2701-musb",
> > +"mediatek,mtk-musb";
> > + reg = <0 0x1120 0 0x1000>;
> > + interrupts = ;
> > + interrupt-names = "mc";
> > + phys = <&u2port2 PHY_TYPE_USB2>;
> > + vbus-supply = <&usb_vbus>;
> > + extcon = <&extcon_usb>;
> > + dr_mode = "otg";
> > + clocks = <&pericfg CLK_PERI_USB0>,
> > +<&pericfg CLK_PERI_USB0_MCU>,
> > +<&pericfg CLK_PERI_USB_SLV>;
> > + clock-names = "main","mcu","univpll";
> > + power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
> > +};
> > --
> > 1.9.1
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Regards,
Min.
Re: [PATCH v6 05/16] sched/core: uclamp: Update CPU's refcount on clamp changes
On Mon, Jan 21, 2019 at 03:44:12PM +, Patrick Bellasi wrote:
> On 21-Jan 16:33, Peter Zijlstra wrote:
> > On Tue, Jan 15, 2019 at 10:15:02AM +, Patrick Bellasi wrote:
> >
> > > +static inline void
> > > +uclamp_task_update_active(struct task_struct *p, unsigned int clamp_id)
> > > +{
> > > + struct rq_flags rf;
> > > + struct rq *rq;
> > > +
> > > + /*
> > > + * Lock the task and the CPU where the task is (or was) queued.
> > > + *
> > > + * We might lock the (previous) rq of a !RUNNABLE task, but that's the
> > > + * price to pay to safely serialize util_{min,max} updates with
> > > + * enqueues, dequeues and migration operations.
> > > + * This is the same locking schema used by __set_cpus_allowed_ptr().
> > > + */
> > > + rq = task_rq_lock(p, &rf);
> > > +
> > > + /*
> > > + * Setting the clamp bucket is serialized by task_rq_lock().
> > > + * If the task is not yet RUNNABLE and its task_struct is not
> > > + * affecting a valid clamp bucket, the next time it's enqueued,
> > > + * it will already see the updated clamp bucket value.
> > > + */
> > > + if (!p->uclamp[clamp_id].active)
> > > + goto done;
> > > +
> > > + uclamp_cpu_dec_id(p, rq, clamp_id);
> > > + uclamp_cpu_inc_id(p, rq, clamp_id);
> > > +
> > > +done:
> > > + task_rq_unlock(rq, p, &rf);
> > > +}
> >
> > > @@ -1008,11 +1043,11 @@ static int __setscheduler_uclamp(struct
> > > task_struct *p,
> > >
> > > mutex_lock(&uclamp_mutex);
> > > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
> > > - uclamp_bucket_inc(&p->uclamp[UCLAMP_MIN],
> > > + uclamp_bucket_inc(p, &p->uclamp[UCLAMP_MIN],
> > > UCLAMP_MIN, lower_bound);
> > > }
> > > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
> > > - uclamp_bucket_inc(&p->uclamp[UCLAMP_MAX],
> > > + uclamp_bucket_inc(p, &p->uclamp[UCLAMP_MAX],
> > > UCLAMP_MAX, upper_bound);
> > > }
> > > mutex_unlock(&uclamp_mutex);
> >
> >
> > But __sched_setscheduler() actually does the whole dequeue + enqueue
> > thing already ?!? See where it does __setscheduler().
>
> This is slow-path accounting, not fast path.
Sure; but that's still no reason for duplicate or unneeded code.
> There are two refcounting going on here:
>
> 1) mapped buckets:
>
> clamp_value <--(M1)--> bucket_id
>
> 2) RUNNABLE tasks:
>
> bucket_id <--(M2)--> RUNNABLE tasks in a bucket
>
> What we fix here is the refcounting for the buckets mapping. If a task
> does not have a task specific clamp value it does not refcount any
> bucket. The moment we assign a task specific clamp value, we need to
> refcount the task in the bucket corresponding to that clamp value.
>
> This will keep the bucket in use at least as long as the task will
> need that clamp value.
Sure, I get that. What I don't get is why you're adding that (2) here.
Like said, __sched_setscheduler() already does a dequeue/enqueue under
rq->lock, which should already take care of that.
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > I have a patch that I'll send soon to make x32 use its own table. As > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > not special. But let's please not reuse 512..547 for other purposes > on x86 variants -- that way lies even more confusion, IMO. (trimming Cc list, as this is getting a little off-topic most most) Just so I understand: do you mean duplicating the .tbl file, or just the resulting table of entry points? In either way, how will that work with the new io_uring_setup() system call that will have to use the compat entry point? Are you planning to use the same syscall number as x86_64 but point it to the compat function, or do we still need a new syscall number for x32 in the regular range? Arnd
Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
On Mon, Jan 14, 2019 at 4:36 PM Jon Hunter wrote:
> I have noticed that system suspend has started failing consistently on a
> couple Tegra boards over the last few days with the linux-next branch.
> The following error is seen on on entering suspend ...
>
> [ 58.222033] spi_master spi1: could not stop message queue
> [ 58.222038] spi_master spi1: queue stop failed
> [ 58.222048] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -16
> [ 58.222052] PM: Device 7000da00.spi failed to suspend: error -16
> [ 58.222057] PM: Some devices failed to suspend, or early wake event
> detected
>
> Bisecting today's -next points to commit 412e60373245 ("spi: core: avoid
> waking pump thread from spi_sync instead run teardown delayed") and
> reverting this on top of -next fixes the problem. I have not had chance
> to dig any further but wanted to report this issue to see if you have
> any thoughts.
I can confirm this on r8a7791/koelsch:
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.010 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
spi_master spi0: could not stop message queue
spi_master spi0: queue stop failed
dpm_run_callback(): rspi_suspend+0x0/0xc returns -16
PM: Device e6b1.spi failed to suspend: error -16
PM: Some devices failed to suspend, or early wake event detected
In addition, after boot, when the QSPI device is idle (the only activity
was the initial probe), the device is no longer runtime-suspended, as
witnessed by the following change to
/sys/kernel/debug/pm_genpd/pm_genpd_summary:
-/devices/platform/soc/e6b1.spi suspended
+/devices/platform/soc/e6b1.spi active
and by the following change to /sys/kernel/debug/clk/clk_summary:
- qspi 010
9750 0 0 5
-qspi_mod 010
9750 0 0 5
+ qspi 110
9750 0 0 5
+qspi_mod 110
9750 0 0 5
Reverting 412e60373245 also fixes that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[v1] PCI: mediatek: Remove MSI inner domain
There is no need to create the inner domain as a parent for MSI domian,
some feature has been implemented by MSI framework.
Remove the inner domain and its irq chip, it will be more closer to
hardware implementation.
Signed-off-by: Jianjun Wang
---
drivers/pci/controller/pcie-mediatek.c | 86 +++---
1 file changed, 37 insertions(+), 49 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c
b/drivers/pci/controller/pcie-mediatek.c
index 8d05df56158b..f996a9a6331f 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -169,7 +169,6 @@ struct mtk_pcie_soc {
* @slot: port slot
* @irq: GIC irq
* @irq_domain: legacy INTx IRQ domain
- * @inner_domain: inner IRQ domain
* @msi_domain: MSI IRQ domain
* @lock: protect the msi_irq_in_use bitmap
* @msi_irq_in_use: bit map for assigned MSI IRQ
@@ -190,7 +189,6 @@ struct mtk_pcie_port {
u32 slot;
int irq;
struct irq_domain *irq_domain;
- struct irq_domain *inner_domain;
struct irq_domain *msi_domain;
struct mutex lock;
DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
@@ -418,22 +416,15 @@ static void mtk_msi_ack_irq(struct irq_data *data)
u32 hwirq = data->hwirq;
writel(1 << hwirq, port->base + PCIE_IMSI_STATUS);
+ writel(MSI_STATUS, port->base + PCIE_INT_STATUS);
}
-static struct irq_chip mtk_msi_bottom_irq_chip = {
- .name = "MTK MSI",
- .irq_compose_msi_msg= mtk_compose_msi_msg,
- .irq_set_affinity = mtk_msi_set_affinity,
- .irq_ack= mtk_msi_ack_irq,
-};
-
-static int mtk_pcie_irq_domain_alloc(struct irq_domain *domain, unsigned int
virq,
-unsigned int nr_irqs, void *args)
+static irq_hw_number_t mtk_pcie_msi_get_hwirq(struct msi_domain_info *info,
+ msi_alloc_info_t *arg)
{
- struct mtk_pcie_port *port = domain->host_data;
- unsigned long bit;
+ struct mtk_pcie_port *port = info->chip_data;
+ irq_hw_number_t bit;
- WARN_ON(nr_irqs != 1);
mutex_lock(&port->lock);
bit = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
@@ -446,18 +437,14 @@ static int mtk_pcie_irq_domain_alloc(struct irq_domain
*domain, unsigned int vir
mutex_unlock(&port->lock);
- irq_domain_set_info(domain, virq, bit, &mtk_msi_bottom_irq_chip,
- domain->host_data, handle_edge_irq,
- NULL, NULL);
-
- return 0;
+ return bit;
}
-static void mtk_pcie_irq_domain_free(struct irq_domain *domain,
-unsigned int virq, unsigned int nr_irqs)
+static void mtk_pcie_msi_free(struct irq_domain *domain,
+ struct msi_domain_info *info, unsigned int virq)
{
struct irq_data *d = irq_domain_get_irq_data(domain, virq);
- struct mtk_pcie_port *port = irq_data_get_irq_chip_data(d);
+ struct mtk_pcie_port *port = info->chip_data;
mutex_lock(&port->lock);
@@ -468,46 +455,50 @@ static void mtk_pcie_irq_domain_free(struct irq_domain
*domain,
__clear_bit(d->hwirq, port->msi_irq_in_use);
mutex_unlock(&port->lock);
-
- irq_domain_free_irqs_parent(domain, virq, nr_irqs);
}
-static const struct irq_domain_ops msi_domain_ops = {
- .alloc = mtk_pcie_irq_domain_alloc,
- .free = mtk_pcie_irq_domain_free,
+static struct msi_domain_ops mtk_msi_domain_ops = {
+ .get_hwirq = mtk_pcie_msi_get_hwirq,
+ .msi_free = mtk_pcie_msi_free,
};
static struct irq_chip mtk_msi_irq_chip = {
- .name = "MTK PCIe MSI",
- .irq_ack= irq_chip_ack_parent,
- .irq_mask = pci_msi_mask_irq,
- .irq_unmask = pci_msi_unmask_irq,
+ .name = "MTK PCIe",
+ .irq_compose_msi_msg= mtk_compose_msi_msg,
+ .irq_write_msi_msg = pci_msi_domain_write_msg,
+ .irq_set_affinity = mtk_msi_set_affinity,
+ .irq_ack= mtk_msi_ack_irq,
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
};
static struct msi_domain_info mtk_msi_domain_info = {
- .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
- MSI_FLAG_PCI_MSIX),
- .chip = &mtk_msi_irq_chip,
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
+ MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_PCI_MSIX),
+ .ops= &mtk_msi_domain_ops,
+ .chip = &mtk_msi_irq_chip,
+ .handler= handle_edge_irq,
+ .handler_name = "MSI",
};
static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
{
- struct fwnode_handle *fwnode =
of_node_to_fwnode(port->pcie->dev->of_node);
+ struct device *dev =
Re: [PATCH 2/6] misc/pvpanic: Add pvpanic driver framework
On Tue, Jan 22, 2019 at 03:25:07AM +0800, Peng Hao wrote:
> Add pvpanic driver framework.
>
You need a lot more description of what you did here than this, as I can
not understand from this text, what the patch does, or more importantly,
why it is doing this, at all.
> Signed-off-by: Peng Hao
> ---
> drivers/misc/pvpanic/pvpanic.c | 171
> ++---
> 1 file changed, 39 insertions(+), 132 deletions(-)
>
> diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
> index 595ac06..6380540 100644
> --- a/drivers/misc/pvpanic/pvpanic.c
> +++ b/drivers/misc/pvpanic/pvpanic.c
> @@ -8,15 +8,20 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> -#include
> +#include
> #include
> #include
> -#include
> -#include
> #include
> #include
>
> -static void __iomem *base;
> +static struct {
> + struct platform_device *pdev;
> + void __iomem *base;
> + bool is_ioport;
> +} pvpanic_data = {
> + .pdev = NULL,
> + .is_ioport = false,
You do not need to initialize variables to 0 specifically like this.
> +};
>
> #define PVPANIC_PANICKED(1 << 0)
>
> @@ -27,7 +32,7 @@
> static void
> pvpanic_send_event(unsigned int event)
> {
> - iowrite8(event, base);
> + iowrite8(event, pvpanic_data.base);
Why did you convert a single global variable into a single global
structure? Why not, if you really need to pass this value around, do
that at the same time as you will end up touching these same functions
again, right?
thanks,
greg k-h
