Am 11.12.18 um 04:57 schrieb Manivannan Sadhasivam:
> Since Spreadtrum is now merged into Unisoc Communications, let's use the
> newly created linux-unisoc mailing list for all discussions around the
> Spreadtrum SoCs.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Andreas Färber
Since Spreadtrum is now merged into Unisoc Communications, let's use the
newly created linux-unisoc mailing list for all discussions around the
Spreadtrum SoCs.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
G'day Anson,
Just pulled up the datasheet for this chip.
The absolute max for Vdda is speced as Vddd +/-0.5
With a note that Vdda should be externally shorted to Vddd.
On 11/12/2018 11:43 am, Anson Huang wrote:
Hi, Phil
Best Regards!
Anson Huang
-Original Message-
From: Phil Reid
> chouryzhou@, can you confirm that this implementation works for your
> android-in-container use-case?
>
> -Todd
>
We are running Android Pie in container now. If it works for later Android
release, it will works for us.
- choury
Hi, Phil
Best Regards!
Anson Huang
> -Original Message-
> From: Phil Reid [mailto:pr...@electromag.com.au]
> Sent: 2018年12月11日 11:36
> To: Anson Huang ; ji...@kernel.org;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> robh...@kernel.org; mark.rutl...@arm.com;
From: Yulei Zhang
Early this year we spot there may be two issues in kernel
kfifo.
One is reported by Xiao Guangrong to linux kernel.
https://lkml.org/lkml/2018/5/11/58
In current kfifo implementation there are missing memory
barrier in the read side, so that without proper barrier
between
On 11/12/2018 11:24 am, Anson Huang wrote:
The light sensor's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the light sensor
isl29023's power supply is controlled by a GPIO fixed regulator,
need to make sure the regulator is enabled before any
The accelerometer's power supply could be controlled by regulator
on some platforms, add optional property "vdd/vddio" power supply
to let device tree to pass phandles to the regulators to driver.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4
1
The accelerometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mma8451's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mma8451,
this patch adds optional
Hi Tony
> Here are two fixes that allow me to have multiple endpoints defined in
> the dts file for audio-graph-card. To do that, we need to fix up few
> issues as the graph binding Documentation/devicetree/bindings/graph.txt
> allows multiple endpoints per port. This allows configuring TDM
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/hwmon/k10temp.c
between commit:
c552e29fdd63 ("hwmon: (k10temp) Add Hygon Dhyana support")
from the hwmon-staging tree and commit:
210ba1201ff9 ("hwmon/k10temp: Add support for AMD family 17h, model 30h CPUs")
The magnetometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mag3110's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mag3110,
this patch adds optional vdd/vddio
The light sensor's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the light sensor
isl29023's power supply is controlled by a GPIO fixed regulator,
need to make sure the regulator is enabled before any operation of
sensor, this patch adds optional
According to datasheet, the isl29018 has "vddd/vdda" power
supply, and isl29023/isl29035 ONLY has "vdd" power supply,
update the power supply name with "vdd" and "vdda" according
to datasheet to cover all devices and avoid confusion.
Signed-off-by: Anson Huang
---
Hi Josef,
On Mon, Dec 10, 2018 at 01:25:08PM -0500, Josef Bacik wrote:
> On Mon, Dec 10, 2018 at 11:35:10AM -0500, Dennis Zhou wrote:
> > The blk-iolatency controller measures the time from rq_qos_throttle() to
> > rq_qos_done_bio() and attributes this time to the first bio that needs
> > to
On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
>
> Hi all-
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
>
> 1. It's not entirely clear that it has users. As far as I know, it's
> supported on Gentoo and
gcc warning this:
drivers/net/ieee802154/ca8210.c:730:10: warning:
comparison is always false due to limited range of data type [-Wtype-limits]
'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
This patch change the type of 'len' to unsigned int to avoid this,also fix
the
On 2018/12/11 上午9:34, Michael S. Tsirkin wrote:
On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote:
When we try to do rx busy polling in tx path in commit 441abde4cd84
("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex
after tx vq mutex is held. This may lead deadlock
Hi Joey,
On Mon, Dec 10, 2018 at 02:31:53PM +0800, joeyli wrote:
> Hi Chen Yu and ACPI experts,
>
> On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote:
> > According to current implementation of acpi_pad driver,
> > it does not make sense to spawn any power saving threads
> > on the cpus
On 2018/12/11 上午3:47, David Miller wrote:
From: Jason Wang
Date: Mon, 10 Dec 2018 17:44:50 +0800
This series tries to fix various issues of vhost:
- Patch 1 adds a missing write barrier between used idx updating and
logging.
- Patch 2-3 brings back the protection of device IOTLB through
On Mon, Dec 10, 2018 at 09:47:59PM +0100, Arnd Bergmann wrote:
> The i.MX7D configuration was reworked, but that change did
> not get propagated into the newly added i.MX7ULP, which now
> produces a Kconfig warning:
>
> WARNING: unmet direct dependencies detected for HAVE_ARM_ARCH_TIMER
>
> Hi Lukasz,
>
> On 2018년 12월 05일 20:05, Lukasz Luba wrote:
> > This patch adds implementation for global suspend/resume for
> > devfreq framework. System suspend will next use these functions.
> >
> > Suggested-by: Tobias Jakobi
> > Suggested-by: Chanwoo Choi
> > Signed-off-by: Lukasz Luba
>
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Tuesday, December 11, 2018 10:19 AM
> To: linux-kernel@vger.kernel.org
> Cc: xuyandong ; sta...@vger.kernel.org; Yinghai
> Lu ; Jesse Barnes ; Bjorn
> Helgaas ; linux-...@vger.kernel.org
> Subject: [PATCH]
Mark,
On Mon, Dec 10, 2018 at 5:00 PM Mark Brown wrote:
>
> On Tue, Dec 11, 2018 at 12:52:21AM +, Mark Brown wrote:
> > On Mon, Dec 10, 2018 at 08:32:32AM -0800, Doug Anderson wrote:
>
> > > Can you clarify? See below where it's applying cleanly to "for-next" for
> > > me:
>
> > I tried a
On Thu, Dec 06, 2018 at 08:45:09AM +0200, Leon Romanovsky wrote:
> On Thu, Dec 06, 2018 at 03:19:51PM +1100, David Gibson wrote:
> > Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when
> > unbound from their regular driver and attached to vfio-pci in order to pass
> > them
On December 10, 2018 5:40:33 PM PST, Linus Torvalds
wrote:
>On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski
>wrote:
>>
>> I'm seriously considering sending a patch to remove x32 support from
>> upstream Linux. Here are some problems with it:
>
>I talked to Arnd (I think - we were talking about
commit 1f82de10d6 ("PCI/x86: don't assume prefetchable ranges are
64bit") added probing of bridge support for 64 bit memory
each time bridge is re-enumerated.
Unfortunately this probing is destructive if any device behind
the bridge is in use at this time.
There's no real need to re-probe the
Quoting Rob Herring :
On Mon, Nov 26, 2018 at 10:06 PM tom burkart wrote:
Quoting Rob Herring :
> On Thu, Nov 22, 2018 at 3:49 AM Tom Burkart wrote:
>>
>> This patch implements the device tree changes required for the pps
>> echo functionality for pps-gpio, that sysfs claims is available
On Mon, Dec 10, 2018 at 10:03:03PM +0100, Wolfram Sang wrote:
> Rejecting transfers should be handled by the core. Also, this will
> ensure proper locking which was forgotten in this open coded version
> and make sure resume mark is set after enabling clocks (not before).
>
> Signed-off-by:
On 12/10/2018 1:58 PM, Arnd Bergmann wrote:
WARNING: vmlinux.o(.text+0x27530): Section mismatch in reference from the
function am43xx_suspend_init() to the function .init.text:am43xx_map_scu()
The function am43xx_suspend_init() references
the function __init am43xx_map_scu().
This is often
The mm-of-the-moment snapshot 2018-12-10-18-09 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
> The refactoring is needed for the new client in devfreq: suspend.
> To avoid code duplication, move it to the new local function
> devfreq_set_target.
>
> Suggested-by: Tobias Jakobi
> Suggested-by: Chanwoo Choi
> Reviewed-by: Chanwoo Choi
> Signed-off-by: Lukasz Luba
> ---
Acked-by:
We currently use only the first endpoint even if multiple endpoints
are configured for a port.
We should follow what's specified in the device graph binding
document Documentation/devicetree/bindings/graph.txt in paragraph
"Organisation of ports and endpoints":
"If a single port is connected to
Hi all,
Here are two fixes that allow me to have multiple endpoints defined in
the dts file for audio-graph-card. To do that, we need to fix up few
issues as the graph binding Documentation/devicetree/bindings/graph.txt
allows multiple endpoints per port. This allows configuring TDM codecs
for
Commit b6f3fc005a2c ("ASoC: simple-card-utils: fixup
asoc_simple_card_get_dai_id() counting") changed endpoint parsing for
asoc_simple_card_get_dai_id(), but it seems the old code is correct.
This code should follow the generic binding documentation for
Documentation/devicetree/bindings/graph.txt
As we know, The framebased format can be used to support a lot of
formats other than YUV and MJPEG, for example: H264 or H265.
And Nowadays, the H264 and H265 is used more and more compared to the
MJPEG, so there is a need to support such usecase, although the new UVC
1.5 and the UVC1.1 extensions
Hi Miquel,
On 2018/12/10 22:50, Miquel Raynal wrote:
Hi Liang,
Liang Yang wrote on Mon, 10 Dec 2018 20:12:39
+0800:
On 2018/12/10 19:38, Boris Brezillon wrote:
On Mon, 10 Dec 2018 19:23:46 +0800
Liang Yang wrote:
+ mtd->ecc_stats.failed++;
+
Based on patch commit 401c636a0eeb ("kernel/hung_task.c:
show all hung tasks before panic"), we could get the
call stack of hung task.
However, if the console loglevel is not high, we still
can not see the useful panic information in practice,
and in most cases users don't set console loglevel to
On 2018/12/11 4:04, David Miller wrote:
> From: YueHaibing
> Date: Mon, 10 Dec 2018 19:34:43 +0800
>
>> Fix follwing gcc warning:
>>
>> drivers/net/ieee802154/ca8210.c:730:10: warning:
>> comparison is always false due to limited range of data type [-Wtype-limits]
>>
>> the variable 'len' is of
On Mon, Dec 10, 2018 at 05:14:36PM +0100, Zaslonko Mikhail wrote:
>Hello,
>
>On 10.12.2018 16:10, Wei Yang wrote:
>> On Mon, Dec 10, 2018 at 02:07:12PM +0100, Mikhail Zaslonko wrote:
>>> If memory end is not aligned with the sparse memory section boundary, the
>>> mapping of such a section is only
On Mon, Dec 10, 2018 at 3:58 PM Pavel Machek wrote:
>
> On Thu 2018-11-29 11:11:50, Linus Torvalds wrote:
> >
> > It might be better to use an empty REX prefix on x86-64 or something like
> > that.
>
> It might be easiest to use plain old NOP, no? :-).
No. The whole point would be that the
> Hi Lukasz,
>
> On 2018년 12월 05일 20:05, Lukasz Luba wrote:
> > The patch prepares devfreq device for handling suspend/resume
> > functionality. The new fields will store needed information during this
> > process. Devfreq framework handles opp-suspend DT entry and there is no
> > need of
Hi, Rob
Best Regards!
Anson Huang
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2018年12月11日 7:24
> To: Anson Huang
> Cc: ji...@kernel.org; knaac...@gmx.de; l...@metafoo.de;
> pme...@pmeerw.net; mark.rutl...@arm.com; linux-...@vger.kernel.org;
>
On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
I talked to Arnd (I think - we were talking about all the crazy ABI's,
but maybe it was with somebody else) about
Ping ?
Thanks
Jianchao
On 12/10/18 11:01 AM, Jianchao Wang wrote:
> Hi Jens
>
> Please consider this patchset for 4.21.
>
> It refactors the code of issue request directly to unify the interface
> and make the code clearer and more readable.
>
> The 1st patch refactors the code of issue
On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote:
> When we try to do rx busy polling in tx path in commit 441abde4cd84
> ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex
> after tx vq mutex is held. This may lead deadlock so we try to lock vq
> one by one in commit
On Mon, Dec 10, 2018 at 11:14:41PM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on net/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Jason-Wang/Fix-various-issue-of-vhost/
From: Arnd Bergmann
Date: Mon, 10 Dec 2018 22:17:20 +0100
> This is one of only two files that initialize a semaphore to a negative
> value. We don't really need the two semaphores here at all, but can do
> the same thing in more conventional and more effient way, by using a
> single waitqueue
I'm working on some code that detects at build time if there's a
COMPAT_SYSCALL_DEFINE() that is not referenced in the x86 syscall
tables. It catches three offenders: rt_sigsuspend(),
rt_sigprocmask(), and sendfile64().
For rt_sigsuspend() and rt_sigprocmask(), the only potential
difference
Hi all-
I'm seriously considering sending a patch to remove x32 support from
upstream Linux. Here are some problems with it:
1. It's not entirely clear that it has users. As far as I know, it's
supported on Gentoo and Debian, and the Debian popcon graph for x32
has been falling off
The patch
gpio: Enable nonexclusive gpiods from DT nodes
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
> -Original Message-
> From: Tetsuo Handa [mailto:penguin-ker...@i-love.sakura.ne.jp]
> Sent: Monday, December 10, 2018 5:59 PM
> To: Sergey Senozhatsky ; Liu,
> Chuansheng
> Cc: a...@linux-foundation.org; pmla...@suse.com;
> sergey.senozhat...@gmail.com; rost...@goodmis.org;
The patch
regulator: tps65090: Hand over GPIO to regulator core
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
gpio: Add devm_gpiod_unhinge()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
regulator: da9211: Hand over GPIO to regulator core
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
gpio: Export gpiod_get_from_of_node()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
mtd: atmel-quadspi: disallow building on ebsa110
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
gpio: devres: Handle nonexclusive GPIOs
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: fixed: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: lp8788-ldo: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: max8952: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: s5m8767: Hand over GPIO to regulator core
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: max77686: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: max8973: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: lm363x: Let core handle GPIO descriptor
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: core: Track dangling GPIO descriptors
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: s2mps11: Hand over GPIO to regulator core
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
Hi,
On Sun, Dec 09, 2018 at 01:13:18PM +0100, Pavel Machek wrote:
> Poweroff does not seem to work on Motorola droid 4 -- it reboots. It
> seems to be problem "forever", 4.18 and 4.20-rc5 seem to be
> affected. It is bad, because when your battery is low, you get into
> reboot loop and discharge
The patch
ASoC: sdm845: add rt5663 codec select
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: simple-card-utils: fix build warning without CONFIG_OF
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
Memory-only nodes will often have affinity to a compute node that can
initiate memory access. Platforms may have various ways to express that
locality. The nodes that initiate memory requests closest to a memory
target node may be considered to have 'primary' access.
In preparation for these
Here is the second version for adding heterogeneous memory attributes to
the existing node sysfs representation.
Background:
Platforms may provide multiple types of cpu attached system memory. The
memory ranges for each type may have different characteristics that
applications may wish to know
System memory may have side caches to help improve access speed. While
the system provided cache is transparent to the software accessing
these memory ranges, applications can optimize their own access based
on cache attributes.
Provide a new API for the kernel to register these memory side
Register memory side cache attributes with the memory's node if HMAT
provides the side cache information table.
Signed-off-by: Keith Busch
---
drivers/acpi/hmat.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/acpi/hmat.c b/drivers/acpi/hmat.c
Add the entries for primary cpu and memory node attributes.
Signed-off-by: Keith Busch
---
Documentation/ABI/stable/sysfs-devices-node | 34 -
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/stable/sysfs-devices-node
Systems may provide different memory types and export this information
in the ACPI Heterogeneous Memory Attribute Table (HMAT). Parse these
tables provided by the platform and report the memory access and caching
attributes.
Signed-off-by: Keith Busch
---
drivers/acpi/Kconfig | 8 +++
Heterogeneous memory systems provide memory nodes with different latency
and bandwidth performance attributes. Create an interface for the kernel
to register the attributes for the primary memory initiators under the
memory node. If the system provides this information, applications can
then query
Save the best performance access attributes and register these with the
memory's node if HMAT provides the locality table.
Signed-off-by: Keith Busch
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/hmat.c | 34 ++
2 files changed, 35 insertions(+)
diff --git
If the HMAT Subsystem Address Range provides a valid processor proximity
domain for a memory domain, or a processor domain with the highest
performing access, register the node as one of the initiator's primary
memory targets so this relationship will be visible under the node's
sysfs directory.
Platforms may provide system memory where some physical address ranges
perform differently than others, or is side cached by the system.
Add documentation describing a high level overview of such systems and the
performance and caching attributes the kernel provides for applications
wishing to
Add the attributes for the system memory side caches.
Signed-off-by: Keith Busch
---
Documentation/ABI/stable/sysfs-devices-node | 34 +
1 file changed, 34 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-devices-node
Parsing entries in an ACPI table had assumed a generic header structure
that is most common. There is no standard ACPI header, though, so less
common types would need custom parsers if they want go through their
sub-table entry list.
Create the infrastructure for adding different table types so
Add descriptions for primary memory initiator performance access
attributes.
Signed-off-by: Keith Busch
---
Documentation/ABI/stable/sysfs-devices-node | 28
1 file changed, 28 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-devices-node
On Mon, Dec 10, 2018 at 3:32 PM Weiyi Lu wrote:
>
> Add MT8183 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/clk/mediatek/Kconfig | 75 ++
> drivers/clk/mediatek/Makefile | 12 +
>
On Tue, Dec 11, 2018 at 12:52:21AM +, Mark Brown wrote:
> On Mon, Dec 10, 2018 at 08:32:32AM -0800, Doug Anderson wrote:
> > Can you clarify? See below where it's applying cleanly to "for-next" for
> > me:
> I tried a git am on my for-4.21 and for-next branches and it didn't work
> on
On Mon, Dec 10, 2018 at 08:32:32AM -0800, Doug Anderson wrote:
> On Mon, Dec 10, 2018 at 7:43 AM Mark Brown wrote:
> > On Thu, Dec 06, 2018 at 02:23:18PM -0800, Douglas Anderson wrote:
> > > At the end of regulator_resolve_supply() we have historically turned
> > > on our supply in some cases.
On Mon, Dec 10, 2018 at 05:26:22PM +0100, Thierry Reding wrote:
> On Mon, Dec 10, 2018 at 02:25:59PM +, Mark Brown wrote:
> > This has been broken for a considerable time now with no response from
> > Ben - is there some other path we can use to get the fix merged?
> I suppose we could go
On Mon, Dec 10, 2018 at 3:56 PM Arnd Bergmann wrote:
>
> The new a200 GPU MMU support fails to build on arm64 because
> of a conflicting macro name:
>
> drivers/gpu/drm/msm/msm_gpummu.c:17: error: "VA_START" redefined [-Werror]
> #define VA_START SZ_16M
>
> In file included from
Clang warns when one enumerated type is implicitly converted to another:
drivers/soc/ti/knav_dma.c:601:20: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
chan->direction =
Hello,
syzbot found the following crash on:
HEAD commit:3f06bda61398 kmsan: remove excessive KMSAN wrappers from a..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=13ca6b0540
kernel config:
Hi Mathieu,
On Mon, Dec 10, 2018 at 04:04:45PM -0700, Mathieu Poirier wrote:
> On Mon, Dec 10, 2018 at 04:53:00PM +0800, Leo Yan wrote:
> > If decoder outputs EO_TRACE element, it means the end of the trace
> > buffer; this is a discontinuity and in this case the end of trace data
> > needs to be
On Mon, Dec 10, 2018 at 06:56:18AM +, He, Bo wrote:
> Hi,
>We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to
> detect the preempt rcu hang, hope we can get more useful logs tomorrow.
>I also enclosed the config and the debug patches for you review.
I instead
On 12/5/18 9:53 AM, Jeffrey Hugo wrote:
On 11/29/2018 4:28 PM, Atish Patra wrote:
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT
Hi
> When CONFIG_OF is disabled, of_graph_parse_endpoint() does not
> initialize 'info', and gcc can see that:
>
> sound/soc/generic/simple-card-utils.c: In function
> 'asoc_simple_card_parse_graph_dai':
> sound/soc/generic/simple-card-utils.c:284:13: error: 'info.port' may be used
>
On Tue, Dec 11, 2018 at 10:46:26AM +1030, Joel Stanley wrote:
> On Tue, 11 Dec 2018 at 10:40, Andrew Jeffery wrote:
> >
> >
> >
> > On Tue, 11 Dec 2018, at 10:35, Nathan Chancellor wrote:
> > > Clang does not support this option:
> > >
> > > warning: unknown warning option '-Woverride-init'; did
On Tue, 11 Dec 2018 at 10:40, Andrew Jeffery wrote:
>
>
>
> On Tue, 11 Dec 2018, at 10:35, Nathan Chancellor wrote:
> > Clang does not support this option:
> >
> > warning: unknown warning option '-Woverride-init'; did you mean
> > '-Woverride-module'? [-Wunknown-warning-option]
> > 1 warning
Hi!
> > >> OK, - and now we are looking forward to *your* ideas how to solve this.
> > >
> > > After four days playing games around git bisect - real winner is
> > > debian gcc-8.2.0-9. Upgrade it to 8.2.0-10 or use 7.3.0-30 version for
> > > same kernel + config - does not exhibit ext4
On 12/7/18 5:45 AM, Morten Rasmussen wrote:
Hi,
On Thu, Nov 29, 2018 at 03:28:16PM -0800, Atish Patra wrote:
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU
On Mon 10 Dec 03:17 PST 2018, Srinivas Kandagatla wrote:
> On 07/12/18 18:23, Mark Rutland wrote:
> > On Fri, Dec 07, 2018 at 04:35:08PM +, Srinivas Kandagatla wrote:
> > > diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
> > >
On Tue, Aug 21, 2018 at 12:38 AM Yi Zhang wrote:
>
> On 2018-08-20 at 12:50:31 -0700, Dave Jiang wrote:
> >
> >
> > On 08/20/2018 10:53 AM, Verma, Vishal L wrote:
> > >
> > > On Mon, 2018-08-13 at 20:02 +0800, Zhang Yi wrote:
> > >> This patch prevents a user mapping an illegal vma range that is
101 - 200 of 1203 matches
Mail list logo
