On 01.01.2019 09:42, Murali Krishna Policharla wrote:
> Store newly configured mtu settings in the netdevice after mtu
> configuration is successful to the dsa switch.
>
> Fixes: 2315dc91a5 ("net: make dev_set_mtu() honor notification return code")
> Signed-off-by: Murali Krishna Policharla
> Rev
On Wed, Dec 26, 2018 at 12:56:22PM -0600, Aditya Pakki wrote:
> In bnxt_qplib_map_tc2cos(), bnxt_qplib_rcfw_send_message() can return
> an error value. The fix returns the error from the latter function
> upstream.
>
> Signed-off-by: Aditya Pakki
> ---
> drivers/infiniband/hw/bnxt_re/qplib_sp.c |
On Tue, Jan 01, 2019 at 04:32:40AM +0100, Andreas Färber wrote:
> Am 01.01.19 um 04:26 schrieb Manivannan Sadhasivam:
> > On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote:
> >> On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote:
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
>
Store newly configured mtu settings in the netdevice after mtu
configuration is successful to the dsa switch.
Fixes: 2315dc91a5 ("net: make dev_set_mtu() honor notification return code")
Signed-off-by: Murali Krishna Policharla
Reviewed-by: Florian Fainelli
---
net/core/dev.c | 9 ++---
1 f
There is no method to force an RC to forward requests p2p. RC's are also not
required to support p2p and whether they do or not is implementation specific.
There is also currently no PCIe based standard to determine whether an RC
supports p2p or in what capacity. Also, even if p2p is supported,
Hi Olof, Georgi,
Happy new year! :-)
Quoting Georgi Djakov (2018-12-08 21:15:35)
> Hi Olof,
>
> On 9.12.18 2:33, Olof Johansson wrote:
> > Hi Georgi,
> >
> > On Sat, Dec 8, 2018 at 9:02 AM Georgi Djakov
> > wrote:
> >>
> >> Modern SoCs have multiple processors and various dedicated cores (vid
Running some mmap() workloads to put the system on low memory situation with
swapping and OOM, and then it trigger this BUG(),
void __noreturn do_task_dead(void)
{
/* Causes final put_task_struct in finish_task_switch(): */
set_special_state(TASK_DEAD);
/* Tell freezer to
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
arch/arm/boot/dts/mt2701.dtsi | 1 -
arch/arm/boot/dts/mt7623.dtsi | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dts
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dts
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 14 --
include/so
MediaTek IOMMU should wait for smi larb which need wait for the
power domain(mtk-scpsys.c) and the multimedia ccf who both are
module init. Thus, subsys_initcall for MediaTek IOMMU is not helpful.
Switch to builtin_platform_driver.
Meanwhile, the ".remove" can be removed. Move its content to
".shu
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
Signed-off-by: Yong Wu
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_
Normally, If the smi-larb HW need work, we should enable the smi-common
HW power and clock firstly.
This patch adds device-link between the smi-larb dev and the smi-common
dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
(smi-common-dev) will be called automatically.
Since s
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Rick Chang
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 22
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
---
drivers/gpu/drm/mediatek/mtk_drm_cr
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
MediaTek IOMMU don't have its power-domain. all the consumer connect
with smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should en
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When there is no this patch, if some c
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connec
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
MediaTek IOMMU don't have its powe
DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
automatically on consumer/supplier driver unbind", that means we should
remove whole the device_link when there is no this driver no matter what
the ref_count of the link is.
CC: Greg Kroah-Hartman
Signed-off-by: Yong Wu
---
The ref_cou
In the reboot burning test, if some Multimedia HW has something wrong,
It may keep send the invalid request to IOMMU. In order to avoid
affect the reboot flow, we add the shutdown callback to disable
M4U HW when shutdown.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 6 ++
driver
Switch to SPDX license identifier for MediaTek iommu/smi and their
header files.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
---
drivers/iommu/mtk_iommu.c | 10 +-
drivers/iommu/mtk_iommu.h | 10 +-
drivers/iommu/mtk_iommu_v1.c
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-
||| |...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 file
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In m
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
the ARM Short-descriptor like mt8173, and most of the HW registers
are the same.
Here list main differences between mt8183 and mt8173/mt2712:
1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
2) mt8183 don't have the
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
It's no need to parse it again in SMI driver. Only clean some codes.
This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
and mt8183.
After this patch, the "mediatek,larb-id" only be needed for mt2712
which have 2
The larb-id may be remapped in the smi-common, this means the
larb-id reported in the mtk_iommu_isr isn't the real larb-id,
Take mt8183 as a example:
M4U
|
-
| SMI common |
-0-
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
--
||
gals0-rx
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
range) register while mt2712 have. Move it into the plat_data.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/dri
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while
it is extended to REG_MMU_CTRL which contains _STANDARD_AXI_MODE in
the other SoCs. I move this property to plat_data since both mt8173
and mt8183 use this property.
It is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
driv
The protect memory setting is a little different in the different SoCs.
In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
protect) shift bit is normally 4 while it shift 5 bits only in the
mt8173. This patch delete the complex MACRO and use a common if-else
instead.
Also, use
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
is remapped to high address from 0x1__ to 0x1__, the
bit32 is always enab
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 +++---
drivers/iommu/mtk_iommu.h | 3 +++
2 files changed,
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 --
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by:
Use a struct as the platform special data instead of the enumeration.
This is a prepare patch for adding mt8183 iommu support.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 24
drivers/iommu/mtk_iommu.h | 6 +-
2 files changed
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt81
This patch adds decriptions for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
This patchset mainly adds support for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
Am 01.01.19 um 04:26 schrieb Manivannan Sadhasivam:
> On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote:
>> On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote:
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>> []
>>> @@ -1240,6 +1240,7 @@ ARM/ACTIONS SEMI ARCHITECTURE
>>> M: Andr
Hi Joe,
On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote:
> On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote:
> > Add the linux-actions mailing list for Actions Semi SoC architecture.
>
> Unrelated to adding this L: entry
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
On Dec 31, 2018, at 7:11 PM, Paul Fulghum wrote:
NAK to this patch. It causes lost wakeups in both read and write paths.
The write path does not need changing.
The read path can be fixed by setting current to TASK_RUNNING at the top of the
if (rbuf) block so the warning is not triggered by
Hi Olof,
On Mon, Dec 31, 2018 at 01:13:42PM -0800, Olof Johansson wrote:
> On Tue, Dec 18, 2018 at 08:32:27PM +0530, Manivannan Sadhasivam wrote:
> > Hello Maintainers,
> >
> > This patch series adds initial RDA8810PL SoC and Orange Pi boards (2G IoT
> > and
> > i96) support. RDA8810PL is an ARM
On 12/30/18 12:39 PM, Michael Straube wrote:
Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
is causing hardfreeze whenever the driver tries to connect to my wifi
network. That makes the driver unusable on my system. Reverting the
commit fixes the issue and the driver works pro
The pull request you sent on Mon, 31 Dec 2018 13:46:37 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0922275ef157ba8ac93e7e7857087eb0442d5397
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 31 Dec 2018 13:46:38 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
> tags/armsoc-drivers
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d36377c6eb071e3d0751e9e0e3c19198c58d9a5d
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 31 Dec 2018 13:46:40 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
> tags/armsoc-defconfig
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e1ef035d272ef4dbfdda98e58699698305138856
Thank you!
--
Deet-doot-dot
The pull request you sent on Mon, 31 Dec 2018 13:46:39 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b7badd1d7aa61087010803affa19bb83fb5a0af1
Thank you!
--
Deet-doot-dot, I am a b
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 4:29 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > > wrote:
> > >
> > > > +static ssize_t ppc_nvram_get_size(void)
> > > > +{
> > > > + if
On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote:
> From: Peng Li
>
> Port 0/1 of HiP08 supports 10G and 25G. This patch adds a
> change to configure NIC port speed same as that of optical
> module(SFP/QFSP). Driver gets the optical module speed and
> sets NIC port speed accordingly.
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 12:43 AM Finn Thain
> wrote:
>
> >
> > Is there some benefit, or is that just personal taste?
> >
> > Avoiding changes to call sites avoids code review, but I think 1) the
> > thinkpad_acpi changes have already been reviewed an
Hi Takashi,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f12e840c819bab42621685558a01d3f46ab9a226
commit: d99501b8575dc1248bacf1b58d2241cb4b265d49 ALSA: hda/ca0132 - Call
pci_iounmap() instead of iounmap()
date:
On Tue, Jan 1, 2019 at 12:42 AM Pierre-Louis Bossart
wrote:
>
>
> On 12/31/18 2:35 PM, Sinan Kaya wrote:
> > On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart
> > wrote:
> >>
> >> On 12/31/18 1:35 PM, Sinan Kaya wrote:
> >>> On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote:
> On Mon, D
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 8:25 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > > --- a/drivers/char/nvram.c
> > > > +++ b/drivers/char/nvram.c
> > > > @@ -48,6 +48,10 @@
> > > > #include
> > > > #include
> > > >
> > >
On Mon, 3 Dec 2018, Vineeth Remanan Pillai wrote:
> This patch was initially posted by Kelley(kelley...@gmail.com).
> Reposting the patch with all review comments addressed and with minor
> modifications and optimizations. Tests were rerun and commit message
> updated with new results.
>
> The fu
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> > On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > > Definitely! Same, I won't emit a patch just for this, Paul already queued
> > > it.
> >
> >
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> The English rules for capitalization and lists are baroque and completely
> unsuited to word processors ("If any list item is longer than one line,
> capitalize all the items."), but in this case each item has multiple
> sentences,
A recent enhancement intentionally fails the kernel build if the
compiler does not support retpolines and CONFIG_RETPOLINE is set.
However, the patch that introduced it did not change RETPOLINE macro
references into CONFIG_RETPOLINE ones. As a result, indirect branches
that are used by init functi
On Mon, 31 Dec 2018 06:03:51 +
"Wang, Wei W" wrote:
> On Sunday, December 30, 2018 2:06 PM, Halil Pasic wrote:
> >
> > I guess you are the first one trying to read virtio config from within
> > interrupt
> > context. AFAICT this never worked.
>
> I'm not sure about "never worked". It seems
On 2018-12-20 5:34 p.m., Florian Fainelli wrote:
Add a binding document for the Broadcom STB reset controller, also known
as SW_INIT-style reset controller.
Signed-off-by: Florian Fainelli
---
.../devicetree/bindings/reset/brcm,reset.txt | 27 +++
1 file changed, 27 insert
Am 31.12.18 um 18:50 schrieb Mark Brown:
> On Sun, Dec 30, 2018 at 11:55:46AM +0100, Andreas Färber wrote:
>> Given that observed symptoms were CPU stalls, workqueue hangs and RCU
>> problems, requiring a power-cycle to recover, I wonder whether we are
>> running into some atomic/locking issue with
On Sun, 30 Dec 2018, I wrote:
>
> The rationale for the ops struct was that it offers introspection.
>
> [...] those platforms which need checksum validation always set
> byte-at-a-time methods to NULL.
>
> [...] The NULL methods in the ops struct allow the nvram.c misc device
> to avoid inef
Hi David and Linus,
On Mon, Dec 17, 2018 at 12:02:01PM -0800, Linus Torvalds wrote:
> On Mon, Dec 17, 2018 at 11:51 AM James Bottomley
> wrote:
> >
> > If this is to replace Eric's patch, didn't you want to set token_mask
> > to (1<
> No, let's not add any extra code that is trying to be subtle.
On 2018-12-26 7:39 p.m., Srinath Mannam wrote:
Add ACPI support to bcm ocotp driver
This patch is based on Linux-4.20-rc7.
Signed-off-by: Srinath Mannam
Acked-by: Scott Branden
---
drivers/nvmem/bcm-ocotp.c | 37 -
1 file changed, 20 insertions(+), 1
On Mon, 31 Dec 2018 11:50:18 -0800
Linus Torvalds wrote:
> > OK, I'll modify my script not to make that diff.
>
> For small "fixes" pulls, the diffs are nice, and you actually see the
> details of the fixes. But for big things, the full diff is usually
> only a distraction.
>
> I think the x8
Hello,
syzbot found the following crash on:
HEAD commit:90cadbbf341d Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17127500c0
kernel config: https://syzkaller.appspot.com/x/.config?x=f9a32c9a4aef9af7
da
Hi Linus,
Please consider for pull,
The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd:
Linux 4.20-rc7 (2018-12-16 15:46:55 -0800)
are available in the Git repository at:
git://github.com/openrisc/linux.git tags/for-linus
for you to fetch changes up to 57ce8ba0fd3
Hi,
* Tony Lindgren [181228 22:28]:
> With droid4-pending-mdm-v4.20 branch in the following state:
>
> - UARTs idled
> - LCD blanked (well no drivers yet droid4-sms-read.rb)
> - MUSB and EHCI USB modules unloaded
> - OHCI loaded with all the children in autosuspend via sysfs
> - WLAN connected
>
On 04/12/2018 19:17, Srinath Mannam wrote:
> Hi,
>
> Could you please provide your feedback to this patch series?
Rui or Eduardo can we get either one of you to review the thermal driver
parts of this patch series? Why do we constantly have to chase people to
respond in this specific subsystem
On Sat, 29 Dec 2018 11:24:34 -0800
Linus Torvalds wrote:
> New signing key? And one that you forgot to push out to keyservers?
Sort of...some time ago, I tried to be a good kid and made a separate
signing subkey like Konstantin told me to. Then I couldn't ever get the
nitrokey thing to work and
SoC updates, mostly refactorings and cleanups of old legacy platforms,
but also a few more things:
New SoC support this release:
- NXP/Freescale i.MX7ULP (1x Cortex-A7, Cortex-M4, graphics, etc)
- Allwinner F1C100, older platform with an ARM926-EJS (ARMv5) core
Cleanups of various platforms:
- OM
Misc driver updates for platforms, many of them power related.
- Rockchip adds power domain support for rk3066 and rk3188
- Amlogic adds a power measurement driver
- Allwinner adds SRAM support for three platforms (F1C100, H5, A64 C1)
- Wakeup and ti-sysc (platform bus) fixes for OMAP/DRA7
- Broad
Hi Linus,
Here's the batch of changes for arm-soc for this merge window. It's
arriving later than I had planned for, the holidays messed up schedules
and time availability a lot at my end this year.
As for the material itself, it's pretty straight forward. The only
branch with conflicts is the So
As usual, this is where the bulk of our changes end up landing each
merge window.
The individual updates are too many to enumerate, many many platforms
have seen additions of device descriptions such that they are
functionally more complete (in fact, this is often the bulk of updates
we see).
Ins
Most changes here are to enable new drivers and platforms in the various
configs that affect them. Most of these have been covered and described
in the other branches, we mostly keep defconfig separate to avoid
conflicts between SoC/dt/driver updates that they otherwise would be
grouped with.
One
On 12/31/18 2:35 PM, Sinan Kaya wrote:
On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart
wrote:
On 12/31/18 1:35 PM, Sinan Kaya wrote:
On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote:
On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote:
On Mon, Dec 31, 2018 at 8:47 PM Mark B
On Wed, Dec 12, 2018 at 01:31:21PM +0100, Jens Wiklander wrote:
> Hello arm-soc maintainers,
>
> Please pull this small OP-TEE driver enhancement. A friendly log message
> is added to inform that dynamic shared memory is used when initiazing
> the OP-TEE driver.
>
> Thanks,
> Jens
>
> The follow
On Tue, Dec 18, 2018 at 09:10:03PM +0100, Krzysztof Kozlowski wrote:
> Hi,
>
> On top of previous pull request.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 9deffb5ee78e41e2a5d6c448874a24caec6467d0:
>
> arm64: dts: exynos: Add all CPUs in cooling maps (2018-11-18 15
On Tue, Dec 18, 2018 at 08:32:27PM +0530, Manivannan Sadhasivam wrote:
> Hello Maintainers,
>
> This patch series adds initial RDA8810PL SoC and Orange Pi boards (2G IoT and
> i96) support. RDA8810PL is an ARM Cortex A5 based SoC with Vivante's GC860
> GPU. The SoC has been added as a new ARM sub
On Thu, Dec 13, 2018 at 08:29:06AM +0100, Jens Wiklander wrote:
> On Wed, Dec 12, 2018 at 11:16 PM Olof Johansson wrote:
> >
> > On Wed, Dec 12, 2018 at 01:28:00PM +0100, Jens Wiklander wrote:
> > > Hello arm-soc maintainers,
> > >
> > > Please pull this tee driver fix for a possible double list_d
On Tue, Dec 18, 2018 at 09:10:02PM +0100, Krzysztof Kozlowski wrote:
> Hi,
>
> On top of previous pull request.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 57b13b8b34002ce8f1d822ea05f0a84e5bc3a64a:
>
> ARM: dts: exynos: remove display-port node from Arndale (2018-1
On Thu, Dec 20, 2018 at 01:54:20PM +, Patrice CHOTARD wrote:
> Hi Arnd, Olof, Kevin
>
> Please find STi SoC update for v4.21 round 1:
>
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
>
> Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
>
> are available in the gi
On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote:
> > difference is that on a cold boot, the TPM takes longer to initialize.
>
> Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager
> does
> not solve the problem. So the problem is NOT that the TPM takes longer to
> On Dec 31, 2018, at 12:08 PM, Andy Lutomirski wrote:
>
> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>> It is sometimes beneficial to have a restartable sequence - very few
>> instructions which if they are preempted jump to a predefined point.
>>
>> To provide such functionality on x8
> On Dec 31, 2018, at 12:05 PM, Andy Lutomirski wrote:
>
> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>> During runtime, we collect the targets of indirect branch targets and
>> patch them in. Patching is done asynchronously, by modifying each of the
>> relpoline code-paths separately wh
Hi Yixun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20181224]
[cannot apply to v4.20]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
Hi,
On 12/31/18 9:10 PM, Pierre-Louis Bossart wrote:
On 12/31/18 12:15 PM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 11:24:41 +0100,
Pierre-Louis Bossart wrote:
On 12/31/18 2:11 AM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 00:17:58 +0100,
Pierre-Louis Bossart wrote:
BTW, one thing I'd really
Hello,
syzbot found the following crash on:
HEAD commit:fc2fd5f0f1aa Merge branch 'x86-platform-for-linus' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=172a9e5340
kernel config: https://syzkaller.appspot.com/x/.config?x=9a98287508be3ff9
da
Hi Kangjie,
Thanks for the patch.
On Tue, Dec 25, 2018 at 08:22:36PM -0600, Kangjie Lu wrote:
> devm_gpio_request_one() could fail. The fix checks its status and issues
> an error if it fails.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/pci/controller/dwc/pci-exynos.c | 9 ++---
> 1 file
Greetings,
My name is Mr Ramy Said Abdelkhalek, an Egyptian Citizen and a Financial
BROKER , I wish to know if you are open for private investor's
discussion to invest with you or your company, iam ready to invest or
loan fund with a stipulated capital tune of $1.8 Billion and above into
any co
On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart
wrote:
>
>
> On 12/31/18 1:35 PM, Sinan Kaya wrote:
> > On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote:
> >> On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote:
> >>> On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote:
> I don't
On 12/31/18 1:35 PM, Sinan Kaya wrote:
On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote:
On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote:
On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote:
I don't have the cover letter or anything for this series, what's going
on with dependenci
Hi Yixun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20181224]
[cannot apply to v4.20]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
On 12/31/18 12:15 PM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 11:24:41 +0100,
Pierre-Louis Bossart wrote:
On 12/31/18 2:11 AM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 00:17:58 +0100,
Pierre-Louis Bossart wrote:
BTW, one thing I'd really like to avoid is to rearrange the probe
procedure of t
On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > Definitely! Same, I won't emit a patch just for this, Paul already queued
> > it.
>
> Yeah, not that big a deal :)
>
> Reviewed-by: Joey Pabalinas
But as long as
On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>
> It is sometimes beneficial to have a restartable sequence - very few
> instructions which if they are preempted jump to a predefined point.
>
> To provide such functionality on x86-64, we use an empty REX-prefix
> (opcode 0x40) as an indicatio
On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>
> During runtime, we collect the targets of indirect branch targets and
> patch them in. Patching is done asynchronously, by modifying each of the
> relpoline code-paths separately while diverting code execution to the
> other path during patchi
1 - 100 of 248 matches
Mail list logo
