On Tuesday 22 December 2020 16:27:01 CET Greg Kroah-Hartman wrote:
> On Tue, Dec 22, 2020 at 05:10:11PM +0200, Kalle Valo wrote:
> > Jerome Pouiller writes:
> >
> > > +/*
> > > + * Internal helpers.
> > > + *
> > > + * About CONFIG_VMAP_STACK:
> > > + * When CONFIG_VMAP_STACK is enabled, it is not
kref_put() can be outside of mutex_lock(),and use amdgpu_ctx_put()
instead of kref_put().
Signed-off-by: Yejune Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
Hi Ricardo,
On Tue, Dec 22, 2020 at 09:04:19PM +0100, Ricardo Ribalda wrote:
> On Tue, Dec 22, 2020 at 11:30 AM Laurent Pinchart wrote:
> > On Mon, Dec 21, 2020 at 05:48:16PM +0100, Ricardo Ribalda wrote:
> > > Some devices, can only read the privacy_pin if the device is
> >
> > s/devices,/devices
On Tue, Dec 22, 2020 at 09:06:04PM +, Alasdair G Kergon wrote:
> I have not read the background about whatever the new problem is - I'm
> jumping in cold seeing this message - but from the very beginning of
> device-mapper we have strongly recommended that userspace supplies the
> block device
On Tue, Dec 22, 2020 at 06:24:09PM +0100, Hannes Reinecke wrote:
> Ok. The problem from my perspective is that device-mapper needs to
> a) ensure that the arbitrary string passed in with the table definition
> refers to a valid block device
> and
> b) the block device can be opened with O_EXCL, so
On Wed, Dec 23, 2020 at 10:26:23AM +0800, chensong wrote:
> "base" was double input in comment line "I/O port base
> address", remove one of them.
>
> Signed-off-by: chensong
> ---
> drivers/staging/comedi/drivers/dt2815.c | 2 +-
> drivers/staging/comedi/drivers/dt2817.c | 2 +-
> 2 files chang
On Wed, Dec 23, 2020 at 10:24:23AM +0800, chensong wrote:
> Checkpatch.pl reports "warning: struct comedi_lrange should
> normally be const" in some places, which are supposed to
> be removed.
>
> Signed-off-by: chensong
> ---
> drivers/staging/comedi/drivers/das16.c | 4 ++--
> drivers/stagin
Post the regression fix in a standalone patch as Andrew suggested for
-stable branch better back porting. This is rebased on the latest
master branch of mainline kenrel, surely there's almost no change
comparing with v2.
https://lore.kernel.org/linux-mm/20201220082754.6900-1-...@redhat.com/
Tested
VMware observed a performance regression during memmap init on their platform,
and bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock
regions rather that check each PFN") causing it.
Before the commit:
[0.033176] Normal zone: 1445888 pages used for memmap
[0.033176] Nor
On Wed, Dec 23, 2020 at 09:01:33AM +0100, Jérôme Pouiller wrote:
> On Tuesday 22 December 2020 16:27:01 CET Greg Kroah-Hartman wrote:
> > On Tue, Dec 22, 2020 at 05:10:11PM +0200, Kalle Valo wrote:
> > > Jerome Pouiller writes:
> > >
> > > > +/*
> > > > + * Internal helpers.
> > > > + *
> > > > +
On Tue, 22 Dec 2020 09:40:04 +0100, Krzysztof Kozlowski wrote:
> On Tue, Dec 22, 2020 at 07:31:40AM +, Timon Baetz wrote:
> > Register for extcon notification and set charging current depending on
> > the detected cable type. Current values are taken from vendor kernel,
> > where most charger t
On Wed, Dec 23, 2020 at 10:20:44AM +0800, chensong wrote:
> There are a log of "#if 0" or "#if 1" in comedi driver which
> cause warning when running checkpatch.pl, they are supposed to
> be cleaned up before release.
>
> Signed-off-by: chensong
Hi,
This is the friendly patch-bot of Greg Kroah
On Wed, Dec 23, 2020 at 10:13:03AM +0800, Zheng Zengkai wrote:
> Hi everyone,
>
> Friendly ping:
>
> Just want to know why this patch was ignored,
Right now it is the merge window and we can't do anything with any
patches until 5.11-rc1 is out. After that happens, I'll work on
catching up on ol
On 12/23/20 at 10:05am, Baoquan He wrote:
> On 12/22/20 at 05:46pm, Andrew Morton wrote:
> > On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He wrote:
> >
> > > VMware reported the performance regression during memmap_init()
> > > invocation.
> > > And they bisected to commit 73a6e474cb376 ("mm: memm
Hi, all:
Please ignore this change, i will resend a patch V2 later.
Hi Yong,
On Wed, Dec 09, 2020 at 04:00:39PM +0800, Yong Wu wrote:
> In the latest SoC, there are several HW IP require a sepecial iova
> range, mainly CCU and VPU has this requirement. Take CCU as a example,
> CCU require its iova locate in the range(0x4000_ ~ 0x43ff_).
Is this really a d
On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
>
On Wed, Dec 09, 2020 at 04:00:44PM +0800, Yong Wu wrote:
> MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
>
> Signed-off-by: Yong Wu
> Acked-by: Will Deacon
> Reviewed-by: Robin Murphy
> ---
> drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
> drivers/iommu/mtk_iommu.c
On Mon, Dec 21, 2020 at 09:32:30PM -0800, Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> This cast loses the __iomem qualifier from clint_timer_val, which
> triggers an sparse warning.
I'm not a native speaker, but the subject line sounds strange to me.
Shouldn't this be:
"don't cast
On Tue, Dec 22, 2020 at 09:22:19AM -0700, Tycho Andersen wrote:
> On Mon, Dec 21, 2020 at 11:52:00PM +0100, Andreas Schwab wrote:
> > Properly return -ENOSYS for syscall -1 instead of leaving the return value
> > uninitialized. This fixes the strace teststuite.
> >
> > Fixes: 5340627e3fe0 ("riscv
On Wed, Dec 09, 2020 at 04:00:50PM +0800, Yong Wu wrote:
> Add fail handle for iommu_device_sysfs_add and iommu_device_register.
>
> Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register
> interface")
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 13 +++-
On Wed, Dec 23, 2020 at 08:09:55AM +, Timon Baetz wrote:
> On Tue, 22 Dec 2020 09:40:04 +0100, Krzysztof Kozlowski wrote:
(...)
> > > .name = "max8997_pmic",
> > > .type = POWER_SUPPLY_TYPE_BATTERY,
> > > @@ -170,6 +237,33 @@ static int max8997_battery_probe(struct
> >
On Tue, Dec 22, 2020 at 08:22:06AM -0800, Joe Perches wrote:
> Having checkpatch complain about > 80 column lines didn't stop
> patches before, likely it wouldn't stop patches now.
>
> Emitting yet more messages for trivial lines > 80 columns is also
> against the intent of the commit that changed
On Wed, 2020-12-23 at 09:31 +0800, Can Guo wrote:
> I don't see why removing the sysfs nodes during ufshcd_shutdown() is
> a
> concern to customer - we should do whatever is needed to protect LLD
> contexts from user space intervene. What do you think?
The sysfs nodes can be removed only when the
On Wed, Dec 09, 2020 at 04:00:51PM +0800, Yong Wu wrote:
> In the lastest SoC, M4U has its special power domain. thus, If the engine
> begin to work, it should help enable the power for M4U firstly.
> Currently if the engine work, it always enable the power/clocks for
> smi-larbs/smi-common. This p
On Wed, 2020-12-23 at 09:31 +0800, Can Guo wrote:
> First of all, this check is not helping at all, during
> ufshcd_shutdown(),
> both the link and dev can be active for a moment, so this check is
> not
> helping the race condition.
yes, This checkup doesn't fix race, it is to address your remove
Linus,
please pull sound fixes for v5.11-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-fix-5.11-rc1
The topmost commit is 13be30f156fda725b168ac89fc91f78651575307
sound fixes for 5.11-rc1
Hi Laurent
On Wed, Dec 23, 2020 at 9:05 AM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> On Tue, Dec 22, 2020 at 09:04:19PM +0100, Ricardo Ribalda wrote:
> > On Tue, Dec 22, 2020 at 11:30 AM Laurent Pinchart wrote:
> > > On Mon, Dec 21, 2020 at 05:48:16PM +0100, Ricardo Ribalda wrote:
> > > > Some
Can we please make the eBPF code stop referencing this function instead
of papering over this crap? It has no business poking into page cache
internals.
On Wed, Dec 09, 2020 at 04:00:52PM +0800, Yong Wu wrote:
> This patch adds pm runtime callback.
>
> In pm runtime case, all the registers backup/restore and bclk are
> controlled in the pm_runtime callback, then pm_suspend is not needed in
> this case.
>
> runtime PM is disabled when suspend, thu
On Wed, Dec 23, 2020 at 12:31:58PM +0800, sh wrote:
> remove the next_bvec label in __blk_bios_map_sg(), simplify the logic
> of traversal bvec.
What makes you believe that this simplifies anything?
Change since v1:
-move out from mt8192 seri series
Yongqiang Niu (1):
soc: mediatek: cmdq: add address shift in jump
drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.8.1.1.dirty
Add address shift when compose jump instruction
to compatible with 35bit format.
Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform")
Signed-off-by: Yongqiang Niu
Reviewed-by: Nicolas Boichat
---
drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++-
1 file changed, 2 insertions(+)
On Wed, 2020-12-23 at 07:47 +, Avri Altman wrote:
> > > could change the way it does: Keep manual flush disabled by
> > > default and
> > > remove this quirk.
>
> Ack on that.
> I never understood why it was needed in the first place.
> Maybe just remove it, and allow to perform explicit flush
On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
> In the previous SoC, the M4U HW is in the EMI power domain which is
> always on. the latest M4U is in the display power domain which may be
> turned on/off, thus we have to add pm_runtime interface for it.
>
> When the engine work, the eng
For the smp_call_function() optimization, where callbacks can run from
idle context, in commit 806f04e9fd2c ("rcu: Allow for smp_call_function()
running callbacks from idle"), an additional check is added in
rcu_is_cpu_rrupt_from_idle(), for dynticks_nmi_nesting value being 0,
for these smp_call_fu
[...]
>> I was rather saying that for security it's of little use IMHO.
>> Application/VM start up time might be improved by using huge pages (and
>> pre-zeroing these). Free page reporting might be improved by using
>> MADV_FREE instead of MADV_DONTNEED in the hypervisor.
>>
>>> this feature, abo
Support DEVAPC on MediaTek platforms by enabling CONFIG_MTK_DEVAPC.
Signed-off-by: Neal Liu
---
arch/arm64/configs/defconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 17a2df6..a373776 100644
--- a/arch/arm64/configs/d
This series adds DEVAPC (Device Access Permission Control) support on MediaTek
MT6779 SoC platform.
*** BLURB HERE ***
Neal Liu (2):
arm64: dts: mt6779: Support devapc
arm64: configs: Support DEVAPC on MediaTek platforms
arch/arm64/boot/dts/mediatek/mt6779.dtsi | 8
arch/arm64/con
Signed-off-by: Neal Liu
---
arch/arm64/boot/dts/mediatek/mt6779.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
index 370f309..52ecfc7 100644
--- a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
+++
Hi Christoph,
The reason we use dio is because we need to deploy the patch on some
early kernel versions, and we don't pay much attention to the change of
iomap. Anyway, I will study the problem mentioned by Gao Xiang and try
to convert the current patch to iomap.
Thanks,
Jianan
On Wed, D
On Wed, Dec 16, 2020 at 06:36:01PM +0800, Yong Wu wrote:
> In the end of __iommu_map, It alway call iotlb_sync_map.
> This patch moves iotlb_sync_map out from __iommu_map since it is
> unnecessary to call this for each sg segment especially iotlb_sync_map
> is flush tlb all currently.
>
> Signed-o
On 22.12.2020 16:01, Andrew Lunn wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
> > +static void sparx5_board_init(struct sparx5 *sparx5)
> > +{
> > + int idx;
> > +
> > + if (!sparx5->sd_sgpio_remapping)
> > + return;
> >
On Wed, Dec 23, 2020 at 04:48:20PM +0800, Huang Jianan wrote:
> Hi Christoph,
>
> The reason we use dio is because we need to deploy the patch on some early
> kernel versions, and we don't pay much attention to the change of iomap.
No, that is never an excuse for upstream development.
Hi Ricardo,
Thank you for the patch.
On Wed, Dec 23, 2020 at 12:04:39AM +0100, Ricardo Ribalda wrote:
> Provide a code path for events that can be sent without a work-queue,
> this is, that do not belong to an URB and are not handled in the top
> half on an irq-handled.
>
> Signed-off-by: Ricard
This patch is used to construct skb based on page to save memory copy
overhead.
Taking into account the problem of addr unaligned, and the
possibility of frame size greater than page in the future.
Signed-off-by: Xuan Zhuo
---
net/xdp/xsk.c | 68 -
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Dec 16, 2020 at 06:36:06PM +0800, Yong Wu wrote:
> In current iommu_unmap, this code is:
>
> iommu_iotlb_gather_init(&iotlb_gather);
> ret = __iommu_unmap(domain, iova, size, &iotlb_gather);
> iommu_iotlb_sync(domain, &iotlb_gather);
>
> We could gather the whole iova ra
On Wed, Dec 23, 2020 at 02:47:56AM +, Michael Kelley wrote:
> From: Sasha Levin Sent: Tuesday, December 22, 2020 6:22 PM
> >
> > From: "Andrea Parri (Microsoft)"
> >
> > [ Upstream commit 206ad34d52a2f1205c84d08c12fc116aad0eb407 ]
> >
> > Lack of validation could lead to out-of-bound reads
> On Sun, Dec 20, 2020 at 03:05:40PM +0800, Dinghao Liu wrote:
> > When do_ide_setup_pci_device() fails, host allocated
> > by ide_host_alloc() may not have been freed, which
> > leads to memleak.
> >
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/ide/setup-pci.c | 8
> > 1 file cha
Subject: NASA scientists achieve long-distance 'quantum teleportation'
over 27 miles for the first time – paving the way for unhackable
networks that transfer data faster than the speed of light
Good day from Singapore,
I am sharing the below news article:
News Article: NASA scientists achiev
I have not found any user for this struct component.
Signed-off-by: H. Nikolaus Schaller
---
drivers/mmc/host/jz4740_mmc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index a1f92fed2a55b7..b3c636edbb4610 100644
--- a/drivers/mm
I have not found any user for this struct component.
Signed-off-by: H. Nikolaus Schaller
---
include/linux/platform_data/mmc-omap.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/platform_data/mmc-omap.h
b/include/linux/platform_data/mmc-omap.h
index f0b8947
card_detect_irq is not used anymore since v4.1.
Remove it.
H. Nikolaus Schaller (2):
mmc: jz4740: remove unused struct component card_detect_irq
mmc: omap: remove unused struct component card_detect_irq
drivers/mmc/host/jz4740_mmc.c | 1 -
include/linux/platform_data/mmc-omap.h | 3
On Wed, Dec 23, 2020 at 08:54:01AM +, Christoph Hellwig wrote:
> On Wed, Dec 23, 2020 at 04:48:20PM +0800, Huang Jianan wrote:
> > Hi Christoph,
> >
> > The reason we use dio is because we need to deploy the patch on some early
> > kernel versions, and we don't pay much attention to the change
Alexandre Belloni writes:
> On 22/12/2020 16:01:22+0100, Andrew Lunn wrote:
>> > The problem is that the switch core reset also affects (reset) the
>> > SGPIO controller.
>> >
>> > We tried to put this in the reset driver, but it was rejected. If the
>> > reset is done at probe time, the SGPIO d
The identical mapping used until now created issues when mapping
different virtual pages with the same physical address.
To solve this issue, we can use the iova module, to handle the IOVA
allocation.
For simplicity we use an IOVA allocator with byte granularity.
We add two new functions, vdpasim_
On Wed, 2020-12-23 at 09:31 +0800, Can Guo wrote:
> And assume you come up with a better check,
> you want to add the check everywhere? You must have noticed the fix
> to
> the func ufshcd_clk_gate_enable_store() from Jaegeuk Kim.
Do you mean lock spin_lock_irqsave(hba->host->host_lock, flags)?
It
Hello!
On 22.12.2020 14:22, Yoshihiro Shimoda wrote:
Add support for BD9574MWF which is silimar chip with BD9571MWV.
Similar? :-)
Note that BD9574MWF has additional features "RECOV_GPOUT",
"FREQSEL" and "RTC_IN", but supports GPIO function only.
Signed-off-by: Yoshihiro Shimoda
Reviewe
On 22.12.2020 14:22, Yoshihiro Shimoda wrote:
Add support for BD9574MWF which is silimar chip with BD9571MWV.
Similar (again)? :-)
Note that we don't support voltage rails VD{09,18,25,33} by this
driver on BD9574. The VD09 voltage could be read from PMIC but that
is not supported by this
Hi Sergei,
> From: Sergei Shtylyov, Sent: Wednesday, December 23, 2020 6:15 PM
>
> On 22.12.2020 14:22, Yoshihiro Shimoda wrote:
>
> > Add support for BD9574MWF which is silimar chip with BD9571MWV.
>
> Similar (again)? :-)
Thank you for pointed it out! I'll fix this and patch 8/12.
Best
This patch set adds document the devicetree bindings for MediaTek Command-Queue
DMA controller,
and remove redundant queue structure.
hanges since v6:
- fix dt binding format
hanges since v5:
- fix full name
hanges since v4:
- fix yaml & dma-mask code flow
hanges since v3:
- fix dt_binding_che
This patch adds common compatible & platform compatiable.
Signed-off-by: EastL Lee
Reviewed-by: Matthias Brugger
---
drivers/dma/mediatek/mtk-cqdma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
index 1610632..17b3ab9 10
This patch introduces active_vdec to indicate the virtual descriptor
under processing by the CQDMA dmaengine, and simplify the control logic
by removing redundant queue structure, tasklets, and completion
management.
Signed-off-by: EastL Lee
---
drivers/dma/mediatek/mtk-cqdma.c | 382 ++-
This patch add dma mask for capability.
Signed-off-by: EastL Lee
Reviewed-by: Matthias Brugger
---
drivers/dma/mediatek/mtk-cqdma.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
index 905bbcb..1610632 1
On Tue, 2020-12-22 at 21:49 +0800, Ziqi Chen wrote:
> As per specs, e.g, JESD220E chapter 7.2, while powering
> off/on the ufs device, RST_N signal and REF_CLK signal
> should be between VSS(Ground) and VCCQ/VCCQ2.
>
> To flexibly control device reset line, refactor the function
> ufschd_vops_devi
Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6779 SoC or other similar Mediatek SoCs.
Signed-off-by: EastL Lee
---
.../devicetree/bindings/dma/mtk-cqdma.yaml | 104 +
1 file changed, 104 insertions(+)
create mod
In order to use xmon with powerpc 8xx, the serial driver
must provide udbg_putc() and udpb_getc().
Provide them via cpm_put_poll_char() and cpm_get_poll_char().
This requires CONFIG_CONSOLE_POLL.
Signed-off-by: Christophe Leroy
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 40 +
Powerpc 8xx requires CONSOLE_POLL to get udbg_putc() and
udbg_getc() in CPM uart driver.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index b88900f4832f..ae084357994e 100
Since commit 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint"),
8xx has breakpoints so there is no reason to opt breakpoint logic
out of xmon for the 8xx.
Signed-off-by: Christophe Leroy
Fixes: 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint")
---
arch/powerpc/xmon/xmon.c | 4
1 fil
On Tue, Dec 22, 2020 at 4:01 PM Linus Torvalds
wrote:
>
> The more I look at the mprotect code, the less I like it. We seem to
> be much better about the TLB flushes in other places (looking at
> mremap, for example). The mprotect code seems to be very laissez-faire
> about the TLB flushing.
No,
On 12/23/20 3:18 AM, Andrew Morton wrote:
> On Thu, 17 Dec 2020 17:54:13 +0100 Helge Deller wrote:
>
>> To resolve the symbol fuction name for wchan, use the printk format
>> specifier %ps instead of manually looking up the symbol function name
>> via lookup_symbol_name().
>>
>> Signed-off-by: Hel
From: Chen Xiaoguang
Before a CPU switches from running SCHED_NORMAL task to
SCHED_IDLE task, trying to pull SCHED_NORMAL tasks from other
CPU by doing load_balance first.
Signed-off-by: Chen Xiaoguang
Signed-off-by: Chen He
---
kernel/sched/fair.c | 5 +
1 file changed, 5 insertions(+)
+add comments & reviewed-by Hanks
On Wed, 2020-12-23 at 16:44 +0800, Neal Liu wrote:
Support DEVAPC on MT6779 platforms by adding device node.
Reviewed-by: Hanks Chen
> Signed-off-by: Neal Liu
> ---
> arch/arm64/boot/dts/mediatek/mt6779.dtsi |8
> 1 file changed, 8 insertions(+)
There are a log of "#if 0" or "#if 1" in driver which cause
warning when running checkpatch.pl, they are supposed to be
cleaned up before release.
Signed-off-by: Song Chen
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 95 --
drivers/staging/comedi/drivers/dt2801.c
On Tue, Dec 22, 2020 at 04:13:45PM +0100, Martin Kepplinger wrote:
> In order for the touchscreen interrupt line to work, describe it properly.
> Otherwise it can work if defaults are ok, but we cannot be sure.
>
> Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone")
> Sign
Chengsong Ke,
- Ursprüngliche Mail -
> The memory area allocated in ubifs_jnl_write_inode() is not aligned with 8
> bytes:
> ino_start = ino = kmalloc(write_len, GFP_NOFS);
>
> When ino_start passed into write_head -> ubifs_wbuf_write_nolock:
>n = aligned_len >> c->max_write_shift;
>
On Tue, Dec 22, 2020 at 04:13:46PM +0100, Martin Kepplinger wrote:
> According to commit e045f044e84e ("arm64: dts: imx8mq: Move usdhc clocks
> assignment to board DT") add the clocks assignment to imx8mq-librem5.dtsi
> too.
>
> Fixes: e045f044e84e ("arm64: dts: imx8mq: Move usdhc clocks assignmen
From: Suzuki K Poulose
If a graph node is not found for a given node, of_get_next_endpoint()
will emit the following error message :
OF: graph: no port node found in /
If the given component doesn't have any explicit connections (e.g,
ETE) we could simply ignore the graph parsing.
Cc: Mathieu
This series enables future IP trace features Embedded Trace Extension (ETE)
and Trace Buffer Extension (TRBE). This series depends on the ETM system
register instruction support series [0] which is available here [1]. This
series which applies on [1] is avaialble here [2] for quick access.
ETE is
From: Suzuki K Poulose
ETE may not implement the OS lock and instead could rely on
the PE OS Lock for the trace unit access. This is indicated
by the TRCOLSR.OSM == 0b100. Add support for handling the
PE OS lock
Cc: Mathieu Poirier
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
Signed-off-by:
From: Suzuki K Poulose
Add support for handling the system registers for Embedded Trace
Extensions (ETE). ETE shares most of the registers with ETMv4 except
for some and also adds some new registers. Re-arrange the ETMv4x list
to share the common definitions and add the ETE sysreg support.
Cc: M
On Wed, Dec 23, 2020 at 9:57 AM Xuan Zhuo wrote:
>
> This patch is used to construct skb based on page to save memory copy
> overhead.
>
> Taking into account the problem of addr unaligned, and the
> possibility of frame size greater than page in the future.
Thanks Xuan for the patch set. Could y
From: Suzuki K Poulose
When there are multiple sinks on the system, in the absence
of a specified sink, it is quite possible that a default sink
for an ETM could be different from that of another ETM. However
we do not support having multiple sinks for an event yet. This
patch allows the event to
From: Suzuki K Poulose
Add ETE as one of the supported device types we support
with ETM4x driver. The devices are named following the
existing convention as ete.
ETE mandates that the trace resource status register is programmed
before the tracing is turned on. For the moment simply write to
it
From: Suzuki K Poulose
Document the device tree bindings for Embedded Trace Extensions.
ETE can be connected to legacy coresight components and thus
could optionally contain a connection graph as described by
the CoreSight bindings.
Cc: devicet...@vger.kernel.org
Cc: Mathieu Poirier
Cc: Mike Le
While starting off the etm event, just abort and truncate the perf record
if the perf handle as no space left. This avoids configuring both source
and sink devices in case the data cannot be consumed in perf.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Anshuman Khandu
Add support for dedicated sinks that are bound to individual CPUs. (e.g,
TRBE). To allow quicker access to the sink for a given CPU bound source,
keep a percpu array of the sink devices. Also, add support for building
a path to the CPU local sink from the ETM.
This adds a new percpu sink type CORE
This adds TRBE related registers and corresponding feature macros.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Anshuman Khandual
---
Changes in V1:
- Re-arranged TRBE register definitions per existing sorted registers
- Replaced some instances with BIT() and GENMASK
Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
accessible via the system registers. The TRBE supports different addressing
modes including CPU virtual address and buffer modes including the circular
buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1)
This patch documents the device tree binding in use for Arm TRBE.
Cc: devicet...@vger.kernel.org
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Anshuman Khandual
---
Changes in V1:
- TRBE DT entry has been renamed as 'arm, trace-buffer-extension'
Documentation/device
On Wed, Dec 23, 2020 at 01:44:42AM -0800, Linus Torvalds wrote:
> On Tue, Dec 22, 2020 at 4:01 PM Linus Torvalds
> wrote:
> >
> > The more I look at the mprotect code, the less I like it. We seem to
> > be much better about the TLB flushes in other places (looking at
> > mremap, for example). The
Hi Yi,
On 2020/12/23 14:27, Liu Yi L wrote:
iommu_flush_dev_iotlb() is called to invalidate caches on device. It only
loops the devices which are full-attached to the domain. For sub-devices,
this is ineffective. This results in invalid caching entries left on the
device. Fix it by adding loop f
On 2020/12/23 16:53, Christoph Hellwig wrote:
> On Tue, Dec 22, 2020 at 11:39:08PM +0900, Tetsuo Handa wrote:
>> For example, if uaccess_kernel() is "false" due to CONFIG_SET_FS=n,
>> isn't sg_check_file_access() failing to detect kernel context?
>
> sg_check_file_access does exactly the right thi
On Wed, Dec 16, 2020 at 2:13 PM Zheng Yongjun wrote:
>
> The parameter of kfree function is NULL, so kfree code is useless, delete it.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/mtd/ubi/eba.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eb
To remove mfd devices when unload this driver, should use
devm_mfd_add_devices() instead.
Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
Signed-off-by: Yoshihiro Shimoda
Acked-for-MFD-by: Lee Jones
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Matti Vaittinen
---
drivers/mfd
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/regulator/bd9571mwv-regulator.c | 49 +
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/driv
From: Khiem Nguyen
The new PMIC BD9574MWF inherits features from BD9571MWV.
Add the support of new PMIC to existing bd9571mwv driver.
Signed-off-by: Khiem Nguyen
Co-developed-by: Yoshihiro Shimoda
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/mfd/bd9571mwv.c
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/gpio/gpio-bd9571mwv.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-bd9571mwv.c
Add support for BD9574MWF which is similar chip with BD9571MWV.
Note that BD9574MWF has additional features "RECOV_GPOUT",
"FREQSEL" and "RTC_IN", but supports GPIO function only.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/gpio/gpio-bd9571mwv.c | 6 --
1 file
1 - 100 of 799 matches
Mail list logo
