Hi, Yongqiang:
Yongqiang Niu 於 2020年12月12日 週六 下午12:12寫道：
>
> This patch add component OVL_2L2
Break drm part and soc part into different patches.
Regards,
Chun-Kuang.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> include/linux/soc/mediatek/mtk-
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 8 Dec 2020 19:33:46 -0800 you wrote:
> According to the X.25 documentation, there was a plan to implement
> X.25-over-802.2-LLC. It never finished but left various code stubs in the
> X.25 code. At this time it is
A widget's "dirty" list_head, much like its "list" list_head, eventually
chains back to a list_head on the snd_soc_card itself. This means that
the list can stick around even after the widget (or all widgets) have
been freed. Currently, however, widgets that are in the dirty list when
freed remain
On 2020-12-12 11:20 a.m., Tyler Hicks wrote:
On 2020-12-12 10:02:47, Tushar Sugandhi wrote:
A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get
On 2020-12-12 11:20 a.m., Tyler Hicks wrote:
On 2020-12-12 10:02:48, Tushar Sugandhi wrote:
System administrators should be able to limit which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
condition to choose specific kernel subsystems is needed.
On Sun, Dec 13, 2020 at 02:55:33AM +0300, Dmitry Baryshkov wrote:
> On shutdown the driver core calls the bus' shutdown callback also for
> unbound devices. A driver's shutdown callback however is only called for
> devices bound to this driver. Commit 9c30921fe799 ("driver core:
> platform: use bus
On Fri, 2020-12-11 at 09:46 -0800, James Bottomley wrote:
> On Fri, 2020-12-11 at 06:01 -0500, Mimi Zohar wrote:
> > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > > Hi Sasha,
> > > >
> > > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levi
allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201212
i386 randconfig-a004
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi/core
head: 54649911f31b6e7c2a79a1426ca98259139e4c35
commit: 4dbe44fb538c59a4adae5abfa9ded2f310250315 [9/12] efi: capsule: clean
scatter-gather entries from the D-cache
config: ia64-randconfig-r011-20201213 (attached as .conf
On 2020/12/10 16:24, Manivannan Sadhasivam wrote:
> This commit documents the LED triggers used commonly in the SoCs. Not
> all triggers are documented as some of them are very application specific.
> Most of the triggers documented here are currently used in devicetrees
> of many SoCs.
>
> Whi
This small series tries to make DSA behave a bit more sanely when
bridged with "foreign" (non-DSA) interfaces. When a station A connected
to a DSA switch port needs to talk to another station B connected to a
non-DSA port through the Linux bridge, DSA must explicitly add a route
for station B towar
Currently the bridge emits atomic switchdev notifications for
dynamically learnt FDB entries. Monitoring these notifications works
wonders for switchdev drivers that want to keep their hardware FDB in
sync with the bridge's FDB.
For example station A wants to talk to station B in the diagram below
Right now, the following would happen for a switch driver that does not
implement .port_fdb_add or .port_fdb_del.
dsa_slave_switchdev_event returns NOTIFY_OK and schedules:
-> dsa_slave_switchdev_event_work
-> dsa_port_fdb_add
-> dsa_port_notify(DSA_NOTIFIER_FDB_ADD)
-> dsa_switc
Some DSA switches (and not only) cannot learn source MAC addresses from
packets injected from the CPU. They only perform hardware address
learning from inbound traffic.
This can be problematic when we have a bridge spanning some DSA switch
ports and some non-DSA ports (which we'll call "foreign in
Given the following setup:
ip link add br0 type bridge
ip link set eno0 master br0
ip link set swp0 master br0
ip link set swp1 master br0
ip link set swp2 master br0
ip link set swp3 master br0
Currently, packets received on a DSA slave interface (such as swp0)
which should be routed by the soft
Currently DSA doesn't add FDB entries on the CPU port, because it only
does so through switchdev, which is associated with a net_device, and
there are none of those for the CPU port.
But actually FDB addresses on the CPU port have some use cases of their
own, if the switchdev operations are initia
We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
events even for interfaces where dsa_slave_dev_check returns false, so
we need that check inside the switch-case statement for SWITCHDEV_FDB_*.
This movement also avoids a useless allocation / free of switchdev_work
on the untreate
On 2020/12/13 10:39, Leizhen (ThunderTown) wrote:
>
>
> On 2020/12/10 16:24, Manivannan Sadhasivam wrote:
>> This commit documents the LED triggers used commonly in the SoCs. Not
>> all triggers are documented as some of them are very application specific.
>> Most of the triggers documented he
Hello,
syzbot found the following issue on:
HEAD commit:14240d4c Add linux-next specific files for 20201210
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=137b0f9b50
kernel config: https://syzkaller.appspot.com/x/.config?x=6dbe20fdaa5aaebe
dashboard
On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Right now, the following would happen for a switch driver that does not
> implement .port_fdb_add or .port_fdb_del.
>
> dsa_slave_switchdev_event returns NOTIFY_OK and schedules:
> -> dsa_slave_switchdev_event_work
>-> dsa_port_fdb_add
>
On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
> events even for interfaces where dsa_slave_dev_check returns false, so
> we need that check inside the switch-case statement for SWITCHDEV_FDB_*.
>
> This movement also avoids a
On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Currently DSA doesn't add FDB entries on the CPU port, because it only
> does so through switchdev, which is associated with a net_device, and
> there are none of those for the CPU port.
>
> But actually FDB addresses on the CPU port have some use
From: Lai Jiangshan
In kvm_mmu_notifier_invalidate_range_start(), tlbs_dirty is used as:
need_tlb_flush |= kvm->tlbs_dirty;
with need_tlb_flush's type being int and tlbs_dirty's type being long.
It means that tlbs_dirty is always used as int and the higher 32 bits
is useless. We can just
On Fri, 2020-12-11 at 10:17 +0800, Ian Kent wrote:
> On Fri, 2020-12-11 at 10:01 +0800, Ian Kent wrote:
> > > For the patches, there is a mutex_lock in kn->attr_mutex, as
> > > Tejun
> > > mentioned here
> > > (https://lore.kernel.org/lkml/x8fe0cmu+aq1g...@mtj.duckdns.org/),
> > > maybe a global
On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Given the following setup:
>
> ip link add br0 type bridge
> ip link set eno0 master br0
> ip link set swp0 master br0
> ip link set swp1 master br0
> ip link set swp2 master br0
> ip link set swp3 master br0
>
> Currently, packets received on a
On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Some DSA switches (and not only) cannot learn source MAC addresses from
> packets injected from the CPU. They only perform hardware address
> learning from inbound traffic.
>
> This can be problematic when we have a bridge spanning some DSA switch
Hi Linus,
This time there have been quite a few changes in auxdisplay thanks to
a refactor by Lars Poeschel to share code in order to introduce a new driver.
I am sending these earlier than usual. Please also note I am using
a different email address than usual, too.
Cheers,
Miguel
The followin
On Sat, Dec 12, 2020 at 10:54:35AM +0300, Dmitry Osipenko wrote:
> Hello,
>
> 12.12.2020 05:43, Dmitry Torokhov пишет:
> > Hi Dmitry,
> >
> > On Mon, Dec 07, 2020 at 12:22:14AM +0300, Dmitry Osipenko wrote:
> >> Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example,
> >> have a
On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck wrote:
>
> This patch results in:
>
> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of
> 'request_irq' declared with attribute 'warn_unused_result'
>
> when
Quoting Nicolas Saenz Julienne (2020-12-11 08:47:52)
> Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> interface when unbinding the device.
>
> Signed-off-by: Nicolas Saenz Julienne
> Reviewed-by: Florian Fainelli
> ---
Acked-by: Stephen Boyd
On 10/26/20 12:37 PM, Kuppuswamy Sathyanarayanan wrote:
Currently if report_error_detected() or report_mmio_enabled()
functions requests PCI_ERS_RESULT_NEED_RESET, current
pcie_do_recovery() implementation does not do the requested
explicit device reset, but instead just calls the
report_slot_
Quoting Nicolas Saenz Julienne (2020-12-11 08:47:50)
> When unbinding the firmware device we need to make sure it has no
> consumers left. Otherwise we'd leave them with a firmware handle
> pointing at freed memory.
>
> Keep a reference count of all consumers and introduce rpi_firmware_put()
> whi
Quoting Geert Uytterhoeven (2020-12-10 01:32:01)
> diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c
> b/arch/arm/boot/compressed/fdt_check_mem_start.c
> new file mode 100644
> index ..e58c3a79c8a31ec4
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
We don't need to force this to be trigger high here, as the firmware
properly configures the irq flags already. Drop it to save a line.
Cc: Douglas Anderson
Cc: Rajendra Nayak
Cc: Mukesh Kumar Savaliya
Cc: Akash Asthana
Signed-off-by: Stephen Boyd
---
drivers/spi/spi-qcom-qspi.c | 3 +--
1 f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers/core
branch HEAD: a3356a079da268cd35460d9bfe052c74383e179b ntp: Fix build error
elapsed time: 720m
configs tested: 155
configs skipped: 3
The following configs have been built successfully.
More configs may be tes
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
branch HEAD: dc780fed5a1be01ece7e0d5588337340a642183c Merge branch 'core/entry'
elapsed time: 720m
configs tested: 151
configs skipped: 3
The following configs have been built successfully.
More configs may be test
background:
I was trying to debug a MIPS build error, but it wasn't MIPS-specific,
so I did this, using the MIPS .config file:
make ARCH=i386 O=xx32 olddefconfig
Little to my knowledge, this came up with
CONFIG_PHYSICAL_START=0x8100
Then I built the i386 kernel, and got this message:
ld: ke
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq/core
branch HEAD: 559db8c7e6ed1f24baf7264a6966ee4f051c6446 Merge tag 'irqchip-5.11'
of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
elapsed time: 725m
configs tested: 123
configs skip
301 - 338 of 338 matches
Mail list logo
