From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. Remove the node from the
cache.
Add paranoia checks in of_find_node_by_phandle() as a second level
of
On Fri, Dec 14, 2018 at 9:40 AM Taniya Das wrote:
>
> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> SoCs. This is required for managing the cpu frequency transitions which are
> controlled by the hardware engine.
>
> Signed-off-by: Taniya Das
Tested-by: Amit Kucheria
From: Frank Rowand
The phandle cache contains struct device_node pointers. The refcount
of the pointers was not incremented while in the cache, allowing use
after free error after kfree() of the node. Add the proper increment
and decrement of the use count.
Fixes: 0b3ce78e90fc ("of: cache
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. This bug exposed the foloowing
phandle cache refcount bug.
The refcount of phandle_cache entries is not
On Fri, Dec 14, 2018 at 9:40 AM Taniya Das wrote:
>
> The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
> for changing the frequency of CPUs. The driver implements the cpufreq
> driver interface for this hardware engine.
>
> Signed-off-by: Saravana Kannan
> Signed-off-by:
On Sun, Dec 16, 2018 at 03:18:52PM +0100, Paul Cercueil wrote:
> Hi,
>
> Le ven. 14 déc. 2018 à 15:26, Uwe Kleine-König
> a écrit :
> > Hello,
> >
> > On Fri, Dec 14, 2018 at 02:50:20PM +0100, Linus Walleij wrote:
> > > On Thu, Dec 13, 2018 at 9:42 PM Uwe Kleine-König
> > > wrote:
> > > >
On Thu, 2018-12-13 at 11:39 +0800, Ryder Lee wrote:
> Hi,
>
> On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> > MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> >
> > The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> > in arm64 but bogus
In gic_iterate_rdists, ret will never be 0 when `ret ? -ENODEV : 0` at
the end of function, so let's directly return -ENODEV.
Signed-off-by: Peng Fan
---
drivers/irqchip/irq-gic-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c
Hi Han,
On 14.12.18 18:05, Han Xu wrote:
>
>
>> -Original Message-
>> From: Schrempf Frieder
>> Sent: Tuesday, December 4, 2018 8:15 AM
>> To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
>> s...@vger.kernel.org; Marek Vasut
>> Cc: dw...@infradead.org;
The patch prefix should be "staging: iio: adc: ad7280a:". Do
git log --oneline drivers/staging/iio/adc/ad7280a.c and copy what
other people do.
On Mon, Dec 17, 2018 at 04:43:33AM +0300, Sergey Efimochkin wrote:
> staging:iio:adc: fix codestyle
Only to do one thing per patch. We need a better
Hello Paul,
On Sun, Dec 16, 2018 at 02:36:03PM +0100, Paul Cercueil wrote:
> Le jeu. 13 déc. 2018 à 21:32, Uwe Kleine-König
> a écrit :
> > On Thu, Dec 13, 2018 at 02:58:31PM +0100, Paul Cercueil wrote:
> > > Hi,
> > >
> > > Le jeu. 13 déc. 2018 à 10:18, Uwe Kleine-König
> > > a écrit :
> >
On Sun, Dec 16, 2018 at 9:03 PM Baruch Siach wrote:
>
> Hi Andrey,
>
> Andrey Smirnov writes:
> > The driver now supports i.MX8MQ, so update bindings accordingly.
> >
> > Cc: p.za...@pengutronix.de
> > Cc: Fabio Estevam
> > Cc: cphe...@gmail.com
> > Cc: l.st...@pengutronix.de
> > Cc: Leonard
Hey Dominique,
sorry for the delay, I've been quite busy these days.
The patches looks good to me and should indeed speed up the code a bit.
I quickly tested them against Syzkaller tuned for the 9p subsystem and
everything seems fine.
And by the way, which refcount races?
Cheers,
Tomas
On
Hey Dominique,
sorry for the delay, I've been quite busy these days.
The patches looks good to me and should indeed speed up the code a bit.
I quickly tested them against Syzkaller tuned for the 9p subsystem and
everything seems fine.
And by the way, which refcount races?
Cheers,
Tomas
On
Hello Marcin,
On Mon, 17 Dec 2018 00:25:58 +0100, Marcin Wojtas wrote:
> Thanks. Indeed, the patch is valid as a fix for current version of SW
> BM. However, because this concept is broken, I will rework it and
> submit patch/patches some time early 2019.
I know some people are working on XDP
On 17.12.18 08:24, Alexey Khoroshilov wrote:
Hi Oleksij,
By chance I took a look at another implementations:
arch/arm/mach-ep93xx/clock.c#L266
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (!clk)
return -EINVAL;
...
arch/c6x/platforms/pll.c#L48
Hi,
> On Dec 12, 2018, at 22:25, Benjamin Tissoires
> wrote:
>
> Hi,
>
> sorry for the late reply. I was always meaning to fix this the proper
> way but couldn't dedicate a full day of work to go to the bottom of
> elan_i2c.
>
> Meanwhile, I am thinking at simply having a blacklist of
Hi Oleksij,
By chance I took a look at another implementations:
arch/arm/mach-ep93xx/clock.c#L266
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (!clk)
return -EINVAL;
...
arch/c6x/platforms/pll.c#L48
int clk_enable(struct clk *clk)
{
On Sat, 15 Dec 2018 at 01:22, Sowjanya Komatineni
wrote:
>
> This patch adds HW Command Queue for supported Tegra SDMMC
> controllers.
>
> Tegra SDHCI with Quirk SDHCI_QUIRK2_BROKEN_64_BIT_DMA disables the
> use of 64_BIT DMA to disable 64-bit addressing mode access to the
> system memory and
On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740
> kernel
syzbot has found a reproducer for the following crash on:
HEAD commit:0a602458c72c kmsan: random: another take at unpoisoning CR..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=129e103540
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:6531e115b7ab Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10c68f6d40
kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
Hello,
Here is a short series about fixing kprobe blacklist checking on
arm64.
I found that some blacklist checking code were mis-placed in
arch_prepare_kprobe() and arch_within_kprobe_blacklist().
Some sub-function (instruction-level) accept/decline check
should be done in arch_prepare_kprobe()
Move extable address check into arch_prepare_kprobe() from
arch_within_kprobe_blacklist().
Please do not blacklisting instructions on exception_table,
since it is a kind of architectural unsupported instruction.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |7
Remove unneeded RODATA check from arch_prepare_kprobe().
Since check_kprobe_address_safe() already ensured that
the probe address is in kernel text, we don't need to
check whether the address in RODATA or not. That must
be always false.
Signed-off-by: Masami Hiramatsu
---
Move exception/irqentry text address check in blacklist,
since those are symbol based rejection.
If we prohibit probing on the symbols in exception_text,
those should be blacklisted.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |6 ++
1 file changed, 2
Hi,
Gentle ping...
Are there any comments about changes since v2?
v2: https://www.spinics.net/lists/netdev/msg536926.html
Thank you,
On Mon, 3 Dec 2018 17:22:29 +0900 wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always
In rx_alloc_pkts(), there is no need to schedule a different tasklet for
refill and it will cause some extra overhead. this patch remove it.
Suggested-by: Neil Horman
Signed-off-by: Xue Chaojing
---
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 23 +---
On 05-12-18, 11:18, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applied all 4, thanks
--
~Vinod
On 10-12-18, 21:55, Arnd Bergmann wrote:
> The newly added driver lacks a MODULE_LICENSE tag, which now produces
> a warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-qdma.o
>
> Add the license according to the SPDX specifier.
Applied, thanks
--
~Vinod
Hello,
syzbot found the following crash on:
HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740
kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140
Hello,
syzbot found the following crash on:
HEAD commit:c151acc6e9ff l2tp: Add protocol field decompression
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1231955d40
kernel config: https://syzkaller.appspot.com/x/.config?x=d9655b05acfc97ff
dashboard
Hello,
syzbot found the following crash on:
HEAD commit:8203e2d844d3 net: clear skb->tstamp in forwarding paths
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=17d37c1b40
kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
dashboard
On 11-12-18, 14:43, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Some places in the kernel check the iommu_group pointer in
> 'struct device' in order to find ot whether a device is
^^
Typo
--
~Vinod
On 11-12-18, 14:43, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Use Use device_iommu_mapped() to check if the device is
> already mapped by an IOMMU.
Acked-by: Vinod Koul
--
~Vinod
A sysfs driven USB authorisation change can trigger a usb_set_configuration
while a hub_event worker thread is running. This can result in a USB device
being disabled just after it was configured and bringing down all the
devices and impacting hardware and user processes that were established on
From: Stefan M Schaeckeler
Add support for the Aspeed AST2500 SoC EDAC driver.
Signed-off-by: Stefan M Schaeckeler
---
MAINTAINERS | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
drivers/edac/Kconfig | 7 +
drivers/edac/Makefile| 1 +
From: Stefan M Schaeckeler
Add support for the Aspeed AST2500 SoC EDAC driver.
Signed-off-by: Stefan M Schaeckeler
---
.../bindings/edac/aspeed-sdram-edac.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644
We only have uvcg_dbg, uvcg_info, and uvcg_err, so add uvcg_warn macro
to print gadget device name and function name along with format.
Signed-off-by: Paul Elder
---
drivers/usb/gadget/function/uvc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/function/uvc.h
Currently, for uvc class-specific control IN and OUT requests, in the
setup handler a UVC_EVENT_SETUP with the setup control is enqueued to
userspace. In response to this, the uvc function driver expects
userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request
data.
In the case of
From: Stefan M Schaeckeler
Add support for the Aspeed AST2500 SoC EDAC driver.
Note, I only have access to AST2500 hardware and documentation. The AST2500
documentation explicitly states that the sdram controller is not backward
compatible with AST2400 and hence this driver is not supporting
This patch series adds a mechanism to allow asynchronously validating
the data stage of a control OUT request, and for stalling or suceeding
the request accordingly. This mechanism is implemented for MUSB, and is
used by UVC. At the same time, UVC packages the setup stage and data
stage data
V4L2_EVENT_PRIVATE_START is used in g_uvc.h but is defined in
videodev2.h, which is not included and causes a compiler warning:
linux/usb/g_uvc.h:15:28: error: ‘V4L2_EVENT_PRIVATE_START’ undeclared here (not
in a function)
#define UVC_EVENT_FIRST (V4L2_EVENT_PRIVATE_START + 0)
Include
We now have a mechanism to signal the UDC driver to reply to a control
OUT request with STALL or ACK, and we have packaged the setup stage data
and the data stage data of a control OUT request into a single
UVC_EVENT_DATA for userspace to consume. The ioctl UVCIOC_SEND_RESPONSE
in the case of a
A usb gadget function driver may or may not want to delay the status
stage of a control OUT request. An instance it might want to is to
asynchronously validate the data of a class-specific request.
A function driver that wants an explicit status stage should set the
newly added explicit_status
Since "usb: gadget: uvc: enqueue uvc_request_data in setup handler
for control OUT requests" it is no longer necessary for userspace to
call ioctl UVCIOC_SEND_RESPONSE in response to receiving a
UVC_EVENT_SETUP from the uvc function driver for a control OUT request.
This change means that for
Implement the mechanism for optional explicit status stage for the MUSB
driver. This allows a function driver to specify what to reply for the
status stage. The functionality for an implicit status stage is
retained.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
v1 Acked-by: Bin
On 12/14/2018 5:56 PM, Lee Jones wrote:
On Fri, 14 Dec 2018, Lee Jones wrote:
On Thu, 06 Dec 2018, Christian Hohnstaedt wrote:
Free allocated IRQ if reading the device ID fails.
The patch is fine. However, in future please submit patches using the
format set (by precedent) by the
Hi Alexey,
On Sun, Dec 16, 2018 at 02:01:44AM +0300, Alexey Khoroshilov wrote:
> Handling of devm_clk_get() suggests that the driver should support
> lack of priv->clk. But imx_mu_probe() fails on clk_prepare_enable(NULL)
> in that case.
>
> The patch removes the try to enable absent clk and
Hi,
>
>On 12/12/18 12:22 PM, Felipe Balbi wrote:
>>
>> Hi
>>
>> Pawel Laszczak writes:
> + cdns->phy = devm_phy_get(dev, "cdns3,usbphy");
> + if (IS_ERR(cdns->phy)) {
> + ret = PTR_ERR(cdns->phy);
> + if (ret == -ENOSYS || ret == -ENODEV) {
Are you sure
Hi Johan,
On Sun, Dec 16, 2018 at 12:03 AM Johan Jonker wrote:
>
> A MK808 TV stick with rk3066 processor boots normal with logo and console.
> After the boot the monitor remains black.
> This patch fixes a vblank timeout crash by adding qos_hdmi and
> HCLK_HDMI to the pmu node.
> The HCLK_HDMI
Hi all,
After merging the mfd tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mfd/tps65218.c: In function 'tps65218_probe':
drivers/mfd/tps65218.c:247:3: error: label 'err_irq' used but not defined
goto err_irq;
^~~~
Caused by commit
05ba643fa2ce
On Thu, Dec 13, 2018 at 4:16 PM Will Deacon wrote:
>
> On Thu, Dec 13, 2018 at 02:35:07PM +0530, Vivek Gautam wrote:
> > Qcom's implementation of arm,mmu-500 works well with current
> > arm-smmu driver implementation. Adding a soc specific compatible
> > along with arm,mmu-500 makes the bindings
On 13-12-18, 20:21, Fabrizio Castro wrote:
> This patch adds bindings for the r8a774c0 (RZ/G2E).
Applied, thanks
--
~Vinod
On 13-12-18, 20:17, Fabrizio Castro wrote:
> Renesas' RZ/G2E (R8A774C0) SoC has DMA controllers compatible
> with this driver, therefore document RZ/G2E specific bindings.
Applied, thanks
--
~Vinod
The accelerometer's power supply could be controllable on some
platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
are controlled by a GPIO fixed regulator, need to make sure the
regulators are enabled before any communication with mma8451, this
patch adds vdd/vddio regulator
The accelerometer's power supplies could be controllable on some
platforms, add 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 file changed, 4
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/vmx.c
between commit:
a97673a1c43d ("x86: Fix various typos in comments")
from the tip tree and commit:
a821bab2d1ee ("KVM: VMX: Move VMX specific files to a "vmx" subdirectory")
from the kvm tree.
I
clcsock can be released while kernel_accept() references it in TCP
listen worker. Also, clcsock needs to wake up before released if TCP
fallback is used and the clcsock is blocked by accept. Add a lock to
safely release clcsock and call kernel_sock_shutdown() to wake up
clcsock from accept in
Hi Myungho,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.20-rc7 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 12/16/18 6:17 AM, Masahiro Yamada wrote:
> This commit removes redundant generic-y defines in
> arch/arc/include/asm/Kbuild.
>
> It is redundant to define generic-y when arch-specific implementation
> exists in arch/$(ARCH)/include/asm/*.h
>
> Remove the following generic-y:
>
>
Add Freescale MAG3110 dt-bindings and remove it from trivial-devices
dt-bingding doc.
Signed-off-by: Anson Huang
---
.../bindings/iio/magnetometer/mag3110.txt | 27 ++
.../devicetree/bindings/trivial-devices.txt| 1 -
2 files changed, 27 insertions(+), 1
The magnetometer's power supplies could be controllable on some platforms,
such as i.MX6Q-SABRESD board, the mag3110's power supplies are controlled
by a GPIO fixed regulator, need to make sure the regulators are enabled
before any communication with mag3110, this patch adds vdd/vddio regulator
+++ Edgecombe, Rick P [12/12/18 23:05 +]:
On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > +++ Rick
Hi Andrey,
Andrey Smirnov writes:
> The driver now supports i.MX8MQ, so update bindings accordingly.
>
> Cc: p.za...@pengutronix.de
> Cc: Fabio Estevam
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez
> Cc: "A.s. Dong"
> Cc: Richard Zhu
> Cc: Rob Herring
> Cc:
> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: Monday, December 17, 2018 10:38 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andrey Smirnov ; p.za...@pengutronix.de;
> Fabio Estevam ; cphe...@gmail.com;
> l.st...@pengutronix.de; Leonard Crestez ;
On Mon, Dec 17, 2018 at 03:15:42AM +, He, Bo wrote:
> for double confirm the issue is not reproduce after 90 hours, we tried only
> add the enclosed patch on the easy reproduced build, the issue is not
> reproduced after 63 hours in the whole weekend on 16 boards.
> so current conclusion is
Actually I'm pretty sure kernel calls proc_mount()
Here is the call stack
[0.003450] [] proc_mount+0x2c/0x98
[0.003459] [] mount_fs+0x164/0x190
[0.003465] [] vfs_kern_mount+0x74/0x168
[0.003469] [] kern_mount_data+0x18/0x30
[0.003474] [] pid_ns_prepare_proc+0x24/0x40
[
Hi,
On Sat, Dec 15, 2018 at 6:14 PM Torsten Duwe wrote:
>
> On Fri, 14 Dec 2018 21:45:03 +0530
> Amit Daniel Kachhap wrote:
>
> > Sorry I didn't mention my environment. I am using 4.20-rc3 and it has
> > all the above 8 extra patches
> > mentioned by you.
>
> So that should be fine.
ok thanks.
>
On Sun, 2018-12-16 at 19:53 -0800, Guenter Roeck wrote:
> On 12/16/18 7:39 PM, Ryder Lee wrote:
> > Hi Matthias,
> >
> > On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote:
> >>
> >> On 07/11/2018 08:10, Ryder Lee wrote:
> >>> This updates dt-binding documentation for MT7629 SoC
> >>>
>
The Broadcom Bluetooth controllers can take up to two external clocks:
an external frequency reference, substituting the main crystal, and a
LPO clock at 32.768 kHz substituting the internal LPO clock.
In particular, the external LPO clock must be used when the controller
does not have NVRAM
The Broadcom Bluetooth controllers support a secondary LPO clock at
32.768 kHz. This external clock provides low power timing, and also
a way to detect the frequency of the main reference clock. On many
designs without NVRAM and a non-default reference clock, this must
be used or the controller
Hi everyone,
This is v3 of my Broadcom-based Bluetooth controllers on Allwinner SoC-
based SBCs series. v2 was sent on 11/15, with a follow up ping on 11/28.
No response from either Bluetooth maintainer. Would the maintainers
acknowledge or provide feedback so we can move forward? WiFi for the
From: Maxime Ripard
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and
transceiver. It is found in the AMPAK AP6210 WiFi+BT package.
Signed-off-by: Maxime Ripard
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/btbcm.c | 6 ++
The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none
is given. This address was found when enabling Bluetooth on a bunch of
boards with the AMPAK AP6210 module, all sharing the same address. It
also contains the sequence 4343A0, which is suspicious as that is also
the name the chip
This patch adds the Bluetooth node, and the underlying UART node if it's
missing, to the board device tree file for several boards. The LPO clock
is also added to the WiFi side's power sequencing node if it's missing,
to correctly represent the shared connections. There is also a PCM
connection
The datasheets for BCM20702 and BCM43438 both have power up time
sequence graphs, however they are slightly different. Both chips
also have an internal power-on-reset, which holds the chip in reset
for a short time after the regulators are enabled.
For the BCM20702, the time period from when the
The BCM20702A1 is a Bluetooth 4.0 chip from Broadcom. It is found in the
Ampak AP6210 WiFi+BT module, identified from the read verbose config info
command response. However the Bluetooth firmware provided by vendors uses
the name BCM20710. This patch elects to use the chip ID returned by the
chip
The BCM4330 is a 802.11 a/b/g/n WiFi + Bluetooth 4.0 chip from Broadcom.
It is found in the Ampak AP6330 WiFi+BT module. The partiular one I have
identifies as BCM4330B1 for Bluetooth and BCM4330/4 for WiFi.
It is unclear if the AP6330 module uses this revision of the BCM4330, or
if there are
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO.
The former provides overall power for the chip, while the latter powers
the I/O pins and buffers.
Model these two as regulator supplies, and let the driver manage them
in the same way as it does the clock supply.
Tested-by:
Originally the device tree binding only specified one clock reference,
with the name "extclk". The driver simply retrieves the clock without
bothering to specify a name.
Since we added a second clock to the binding, we need to fetch the
clocks by name now. First we try the new name "txco", then
The driver currently checks the clk pointer for an error condition, as
returned by clk_get, before every invocation of the clk consumer API.
This is redundant if the goal is simply to ignore the errors, thereby
making the clk optional. The clk consumer API already checks if the
pointer is NULL or
The AP6212 is based on the Broadcom BCM43430 or BCM43438. The WiFi side
identifies as BCM43430, while the Bluetooth side identifies as BCM43438.
The Bluetooth side is connected to UART1 in a 4 wire configuration. Same
as the WiFi side, due to being the same chip and package, DLDO2 provides
On some systems that actually have the bluetooth controller wired up
with an extra clock signal, it's possible the bluetooth controller
probes before the clock provider. clk_get would return a defer probe
error, which was not handled by this driver.
Handle this properly, so that these systems can
The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller.
This patch adds a compatible string match to the serdev driver for the
Bluetooth part of the chip.
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO.
The former provides overall power for the chip, while the latter powers
the I/O pins and buffers.
This patch adds properties for the two so we can describe the power
supply relationships.
Reviewed-by: Rob Herring
Tested-by:
On Mon, 2018-12-17 at 11:15 +0800, Chuanjia Liu wrote:
> On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote:
> > On Thu, Dec 13, 2018 at 1:36 AM wrote:
> > >
> > > From: Chuanjia Liu
> > >
> > > This patch add gpio vritual number select,avoid virtual gpio set SMT.
> >
> > s/gpio/GPIO/
> >
This bug can be reproduced this way on x86_64.
* make sure none of libelf-dev, libelf-devel or elfutils-libelf-devel installed.
# make distclean
* generate a default .config where CONFIG_UNWINDER_ORC is enabled by default.
# make menuconfig (exit -> save)
# grep CONFIG_UNWINDER_ORC .config
On 12/16/18 7:39 PM, Ryder Lee wrote:
Hi Matthias,
On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote:
On 07/11/2018 08:10, Ryder Lee wrote:
This updates dt-binding documentation for MT7629 SoC
Signed-off-by: Ryder Lee
Acked-by: Matthias Brugger
---
On Sun, Dec 16, 2018 at 05:38:13PM +0800, Hou Tao wrote:
> Hi,
>
> On 2018/12/15 22:38, Matthew Wilcox wrote:
> > On Tue, Dec 04, 2018 at 10:08:40AM +0800, Hou Tao wrote:
> >> There is no need to disable __GFP_FS in ->readpage:
> >> * It's a read-only fs, so there will be no dirty/writeback page
Good Day,
Hope you are doing great Today.I have a proposed BUSINESS DEAL that will
benefit both parties. This is legitimate,legal and your personality will not be
compromised.Please Reply to me ONLY if you are interested and consider your
self capable for details.
Sincerely,
Peter OWEN
Hi Matthias,
On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote:
>
> On 07/11/2018 08:10, Ryder Lee wrote:
> > This updates dt-binding documentation for MT7629 SoC
> >
> > Signed-off-by: Ryder Lee
>
> Acked-by: Matthias Brugger
>
> > ---
> >
The light sensor's power supply could be controllable 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 vcc
On Fri, 2018-12-14 at 03:51 +0800, Sean Wang wrote:
> And the subject should be also corrected with prefix starting with
> "pinctrl: mediatek:", typo fixup, and having a better subject close to
> the content.
I will change it in next patch.
> On Thu, Dec 13, 2018 at 1:36 AM wrote:
> >
> > From:
for double confirm the issue is not reproduce after 90 hours, we tried only add
the enclosed patch on the easy reproduced build, the issue is not reproduced
after 63 hours in the whole weekend on 16 boards.
so current conclusion is the debug patch has extreme effect on the rcu issue.
Compared
On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote:
> On Thu, Dec 13, 2018 at 1:36 AM wrote:
> >
> > From: Chuanjia Liu
> >
> > This patch add gpio vritual number select,avoid virtual gpio set SMT.
>
> s/gpio/GPIO/
> s/vritual/virtual/
>
> Virtual GPIOs you said here that means these pins only
On 14/12/2018 10:29 PM, Thierry Reding wrote:
> On Fri, Dec 07, 2018 at 06:10:05PM +0800, Wei Ni wrote:
>> Add optional property "nvidia,thermtrips".
>> If present, these trips will be used as HW shutdown trips,
>> and critical trips will be used as SW shutdown trips.
>>
>> Signed-off-by: Wei
On 12/16/18 6:48 PM, Kyle Tso wrote:
Current matching rules ensure that the voltage range of selected Source
Capability is entirely within the range defined in one of the Sink
Capabilities. This is reasonable but not practical because Sink may not
support wide range of voltage when sinking power
On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit wrote:
>
> > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada
> > wrote:
> >
> > Revert the following 9 commits:
> >
> > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
> >work around GCC inlining bugs")
> >
> >This was
On 12/15/18 6:49 PM, Dmitry V. Levin wrote:
> According to the documentation in include/uapi/asm-generic/ioctl.h,
> _IOW means userspace is writing and kernel is reading, and
> _IOR means userspace is reading and kernel is writing.
>
> In case of these two ioctls, kernel is writing and userspace
1 - 100 of 348 matches
Mail list logo
