hi matthias,
thanks for your suggestion.
On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote:
El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit:
>Refactor rockchip_sound_probe, parse dai links from dts instead of
>hard coding them.
Mark doesn't seem to be overly con
hi shawn,
On 08/16/2017 05:00 PM, Shawn Lin wrote:
Hi Jeffy,
On 2017/8/16 15:52, Jeffy Chen wrote:
Add support for PCIE_WAKE pin in rockchip pcie driver.
Signed-off-by: Jeffy Chen
---
drivers/pci/host/pcie-rockchip.c | 58
1 file changed, 58
Hi Matthias,
On 08/17/2017 07:50 AM, Matthias Kaehlcke wrote:
El Thu, Aug 17, 2017 at 06:55:20AM +0800 jeffy ha dit:
hi matthias,
thanks for your suggestion.
On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote:
El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit:
Refactor
Hi Shawn,
On 08/16/2017 04:35 PM, Shawn Lin wrote:
Hi Jeffy
On 2017/8/16 15:52, Jeffy Chen wrote:
Add an optional interrupt for PCIE_WAKE pin.
Signed-off-by: Jeffy Chen
---
Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 11
+++
1 file changed, 7 insertions(+), 4
et_status_flags before request irq would lose trigger
type setting.
things work well after reverted that commit, so i will send my patch
soon, and ask irq people about it :)
On 08/17/2017 01:49 AM, Brian Norris wrote:
Hi,
On Wed, Aug 16, 2017 at 03:52:22PM +0800, Jeffy Chen wrote:
Add suppor
Hi guys,
I hit an problem when testing a level triggered irq with:
irq = platform_get_irq_byname(pdev, "wake");
...<-- irq trigger type is correct
irq_set_status_flags(irq, IRQ_NOAUTOEN);
...<-- irq trigger type become zero
request_threaded_irq(irq, ...)
the trigger type lost(irqd_get_trigger_t
Hi Marc,
Thanks for your reply.
On 08/17/2017 09:34 PM, Marc Zyngier wrote:
On 17/08/17 13:46, jeffy wrote:
Hi guys,
I hit an problem when testing a level triggered irq with:
irq = platform_get_irq_byname(pdev, "wake");
...<-- irq trigger type is correct
irq_set_sta
Hi Mark,
thanks for your reply
On 08/18/2017 01:11 AM, Mark Brown wrote:
On Thu, Aug 17, 2017 at 12:44:10PM +0800, Jeffy Chen wrote:
This property is no longer used.
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified
Hi Mark,
On 08/18/2017 01:11 AM, Mark Brown wrote:
On Thu, Aug 17, 2017 at 12:44:09PM +0800, Jeffy Chen wrote:
Currently we are using devm_snd_soc_register_component, which would
use legacy dai name.
Switch to snd_soc_register_codec to use dai driver name.
This is the wrong direction to
Hi Shawn,
On 08/18/2017 03:23 PM, Shawn Lin wrote:
@@ -1524,6 +1532,9 @@ static int rockchip_pcie_remove(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
+dev_pm_clear_wake_irq(dev);
+device_init_wakeup(dev
Hi guys,
On 04/05/2017 09:20 AM, jeffy wrote:
Hi dmitry,
On 04/04/2017 06:41 AM, Dmitry Torokhov wrote:
On Mon, Apr 03, 2017 at 01:53:53PM -0700, Brian Norris wrote:
+ others
On Mon, Apr 03, 2017 at 11:43:36AM -0700, Dmitry Torokhov wrote:
On Sun, Apr 02, 2017 at 08:07:39AM +0800, Jeffy
Hi Krzysztof,
thanx for noting that, will add it to next version :)
On 06/21/2017 11:36 PM, Krzysztof Kozlowski wrote:
On Wed, Jun 21, 2017 at 11:33:29PM +0800, jeffy wrote:
Hi Krzysztof,
thanx for your comment.
On 06/21/2017 06:45 PM, Krzysztof Kozlowski wrote:
On Wed, Jun 21, 2017 at 12
Hi Brian,
On 10/17/2017 07:57 AM, Brian Norris wrote:
This is going to be a*lot* of churn throughout the tree, if we expect
all resource consumers to do this. I think we'd want some kind of
agreement from the PM maintainers and (larger) subsystem owners before
going down this route...
And in t
Hi sean,
On 05/25/2017 11:30 PM, Sean Paul wrote:
On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
The system would crash when trying to alloc zero sized gem buffer:
[6.712435] Unable to handle kernel NULL pointer dereference at virtual address
0010 <--ZERO_SIZE_
Hi Thomas,
On 05/26/2017 09:20 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Jeffy Chen wrote:
If irq is already disabled and masked, we would hit a unbalanced irq
shutdown/disable/mask when freeing it.
Errr? What exactly is unbalanced? None of the called functions has any
counter or
Hi Thomas,
On 05/27/2017 04:30 PM, Thomas Gleixner wrote:
On Sat, 27 May 2017, Jeffy Chen wrote:
If a irq is already disabled & masked, free_irq may cause a unbalanced
irq shutdown/disable/mask, for example:
No, it's not. irq_shutdown/disable/mask are low level access functions
whi
Hi guys,
On 10/24/2017 04:09 PM, Ard Biesheuvel wrote:
The following patch appears to fix the issue as well:
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
b/arch/arm/boot/compressed/vmlinux.lds.S
index 7a4c59154361..0e0f504e256e 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/ar
tform_pci_set_wakeup().
does this make sense?
On 10/24/2017 12:06 PM, jeffy wrote:
Hi Brian,
On 10/24/2017 07:02 AM, Brian Norris wrote:
+ PM folks
Hi Jeffy,
It's probably good if you send the whole thing to linux-pm@ in the
future, if you're really trying to implement generic PCI/PM for
Hi Rob,
On 10/27/2017 04:02 AM, Rob Herring wrote:
Why do you need this patch? You're moving the wakeup handling from the
PCI device to the bridge. The bridge device is not PCI interrupts, but
a platform device so this function doesn't matter.
because it's possible we have multiple PCI device
Hi Sinan,
Thanks for your reply.
On 10/26/2017 11:16 PM, Sinan Kaya wrote:
If the intention is to push this to pci directory, this code needs to be made
platform agnostic by splitting into two pieces.
I think you can make this code common by abstracting the IRQ number and
have some generic cod
Hi Brian,
On 10/27/2017 10:33 AM, Brian Norris wrote:
On Thu, Oct 26, 2017 at 09:28:34PM +0800, Jeffy Chen wrote:
Add optional interrupts for PCIe WAKE# pin and PCI interrupt pin.
Signed-off-by: Jeffy Chen
---
Changes in v8:
Add optional "pci", and rewrite commit message.
Cha
Hi Brian,
On 10/27/2017 01:40 PM, Brian Norris wrote:
Another odd thing about this series is that the interrupt doesn't
actually show up in /proc/interrupts, /sys/kernel/debug/gpio, or
similar, seemingly because the wakeirq is requested/released every time
we suspend/resume. So it's really not t
Hi guys,
On 10/18/2017 03:05 AM, Mark Brown wrote:
On Tue, Oct 17, 2017 at 11:53:01AM -0700, Brian Norris wrote:
On Tue, Oct 17, 2017 at 07:46:03PM +0100, Mark Brown wrote:
I would expect we can get a long way in the DT by doing a pass over the
tree and adding links between device nodes in c
Hi Greg,
Thanks for your reply.
On 10/18/2017 02:19 PM, Greg Kroah-Hartman wrote:
On Wed, Oct 18, 2017 at 01:49:26PM +0800, Jeffy Chen wrote:
>There are cases we call device_del() without detaching it from the
>driver(e.g. spi core del children devices).
Why would you do that? Sho
Hi Greg,
On 10/18/2017 03:33 PM, Greg Kroah-Hartman wrote:
The SPI core should have some internal housekeeping to do there as well,
right? Is this the only bus that gets this "wrong"?
hmm, i checked i2c code, it has the same issue:
void i2c_unregister_device(struct i2c_client *client)
{
Hi Rafael,
Thanks for your reply.
On 10/18/2017 06:04 PM, Rafael J. Wysocki wrote:
But device_del() calls bus_remove_device() which in turn calls
device_release_driver(), so this looks like an ordering issue to me.
uh, right, didn't notice that, it indeed to be a ordering issue...
it turns o
Hi Rafael,
On 10/18/2017 07:11 PM, jeffy wrote:
my board has these devices:
spi master device->spi child device->spi based pwm->pwm_bl
and i add a device link to the pwm and pwm_bl, and got a warning about
the pwm not unbound:
sorry, it happens when i try to unbind the spi child de
Hi Rafael,
On 10/19/2017 07:36 AM, Rafael J. Wysocki wrote:
Why don't you write something like the following:
"The current ordering of code in device_del() triggers a WARN_ON()
in device_links_purge(), because of an unexpected link status.
The device_links_unbind_consumers() call in device_rel
Hi Sean,
Thanks for your review.
On 10/18/2017 02:10 AM, Sean Paul wrote:
On Tue, Oct 17, 2017 at 06:16:20PM +0800, Jeffy Chen wrote:
>Add missing clk_disable_unprepare() in bind()'s error handling path.
This also isn't disabled in unbind(), is that intentional?
i wasn'
Hi guys,
On 10/18/2017 09:29 PM, Bjorn Helgaas wrote:
>
>I guess it could work to look into pci_create_root_bus(), and
>do something like the following?
>
>if (IS_ENABLED(CONFIG_OF) && parent && parent->of_node)
>... do OF parsing for generic features like WAKE# ...
That's exact
Hi Rafael,
On 10/19/2017 10:56 PM, Rafael J. Wysocki wrote:
Signed-off-by: Rafael J. Wysocki
It has not been signed off by me, so you should not have added the line
above.
Signed-off-by: Jeffy Chen
For the patch itself and the changelog *except* for the S-o-b line:
Reviewed-by: Rafael
Hi Brian,
On 10/27/2017 01:55 PM, Brian Norris wrote:
One reason this series is failing for me: the above is failing with
-EINVAL -- it seems like no one set the 'can_wakeup' flag for the
Marvell Wifi card I'm using. It seems like we probably*should* be
calling device_set_wakeup_capable() from
Hi Tony,
thanks for your Acked-by. but i'm moving the dedicated wakeirq setup to
the setup(), so that the irq would be tracked in the /proc/interrupts.
please help to check the new v10 patches, thanks :)
On 10/26/2017 10:42 PM, Tony Lindgren wrote:
* Jeffy Chen [171026 06:31]:
Ad
Hi Rob,
On 10/27/2017 10:38 PM, Rob Herring wrote:
+ prop = of_find_property(dn, "interrupt-names", NULL);
>+ for (name = of_prop_next_string(prop, NULL); name;
>+name = of_prop_next_string(prop, name), index++) {
>+ if (!strcmp(name, "pc
Hi Rafael,
thanks for your reply.
On 10/28/2017 05:07 PM, Rafael J. Wysocki wrote:
Overall, I don't quite like the direction this is going into, but I need to
have a deeper look. Which may take some time, so please bear with me.
ok, i'll wait for your comments, thanks :)
Thanks,
Rafael
Hi brian,
On 01/24/2017 10:31 AM, Brian Norris wrote:
Hi Jeffy,
On Fri, Jan 20, 2017 at 09:52:08PM +0800, Jeffy Chen wrote:
[ 39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
at [] hidp_session_thread+0x110/0x568 [hidp]
...
[ 40.159664] Call trace:
[ 40.162122
Hi Rob,
On 03/22/2017 10:55 PM, Rob Herring wrote:
On Wed, Mar 22, 2017 at 9:39 AM, Rob Herring wrote:
On Tue, Mar 21, 2017 at 9:25 PM, Jeffy Chen wrote:
Currently we only free the allocated resource struct when error.
This would cause memory leak after pci_free_resource_list.
Signed-off
Hi brian,
On 03/21/2017 10:21 AM, Brian Norris wrote:
On Tue, Mar 21, 2017 at 09:25:16AM +0800, Shawn Lin wrote:
On 2017/3/21 6:49, Brian Norris wrote:
This list is local to the probe() function. We should free it up in both
the success case and the error case, but currently we're only freeing
Hi Rob & Dmitry,
On 03/24/2017 06:58 AM, Dmitry Torokhov wrote:
On Thu, Mar 23, 2017 at 3:07 PM, Rob Herring wrote:
On Thu, Mar 23, 2017 at 3:12 AM, Jeffy Chen wrote:
Currently we only free the allocated resource struct when error.
This would cause memory leak after pci_free_resource_
Hi Andrzej,
On 03/14/2017 08:05 PM, Andrzej Hajda wrote:
Hi Jeffy,
On 14.03.2017 11:45, Jeffy Chen wrote:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic, follow exynos drm
Hi Heiko,
On 03/16/2017 01:00 AM, Heiko Stuebner wrote:
Am Mittwoch, 15. März 2017, 18:20:47 CET schrieb Jeffy Chen:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic, follow
Hi Heiko,
On 03/16/2017 04:20 PM, Heiko Stuebner wrote:
Hi Jeffy,
Am Donnerstag, 16. März 2017, 10:05:56 CET schrieb Jeffy Chen:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic
Hi Sean,
On 03/14/2017 05:06 AM, Sean Paul wrote:
On Wed, Mar 08, 2017 at 01:58:14PM +0800, Jeffy Chen wrote:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic, follow exynos drm
Hi Kalle,
On 02/24/2017 07:01 PM, Kalle Valo wrote:
Jeffy Chen writes:
Currrently we are disabling this wake irq after receiving it. If this
happens before we finish suspend and the pm event check is disabled,
the system will continue suspending, and this irq would not work again.
We may
Hi brian,
On 02/11/2017 09:40 AM, Brian Norris wrote:
Hi,
On Tue, Jan 24, 2017 at 12:07:49PM +0800, Jeffy Chen wrote:
It looks like bnep_session has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE);
if
Hi brian,
On 02/11/2017 09:43 AM, Brian Norris wrote:
Hi,
On Tue, Jan 24, 2017 at 12:07:50PM +0800, Jeffy Chen wrote:
It looks like cmtp_session has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE);
if
Hi brian,
On 02/11/2017 09:26 AM, Brian Norris wrote:
Hi Jeffy,
I'm really not an expert on bluetooth or HIDP, but I can't bring myself
to say that this is correct. I still think you have a problem.
On Tue, Jan 24, 2017 at 12:07:51PM +0800, Jeffy Chen wrote:
It looks like hidp_sess
Hi Dmitry,
On 02/14/2017 05:27 AM, Dmitry Torokhov wrote:
Hi Jeffy,
On Sun, Feb 12, 2017 at 8:12 PM, Jeffy Chen wrote:
It looks like hidp_session_thread has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE
Hi Arnd,
Tested-by: Jeffy Chen
Thanx for fixing this :)
On 03/29/2017 12:37 AM, Guenter Roeck wrote:
On Tue, Mar 28, 2017 at 3:16 AM, Arnd Bergmann wrote:
A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
the rockchip drm driver will fail to link:
drivers/gpu/drm
Hi dmitry,
On 04/04/2017 06:41 AM, Dmitry Torokhov wrote:
On Mon, Apr 03, 2017 at 01:53:53PM -0700, Brian Norris wrote:
+ others
On Mon, Apr 03, 2017 at 11:43:36AM -0700, Dmitry Torokhov wrote:
On Sun, Apr 02, 2017 at 08:07:39AM +0800, Jeffy Chen wrote:
Report wakeup events when process
Hi Daniel,
On 04/03/2017 03:41 PM, Daniel Vetter wrote:
On Sat, Apr 01, 2017 at 07:35:28PM +0800, Jeffy Chen wrote:
Signed-off-by: Jeffy Chen
---
Changes in v2: None
Wut? How is this even possible? If you haven't registered the driver yet,
there's no way for userspace to call
Hi Bjorn,
On 04/05/2017 03:18 AM, Bjorn Helgaas wrote:
On Thu, Mar 23, 2017 at 5:58 PM, Dmitry Torokhov wrote:
On Thu, Mar 23, 2017 at 3:07 PM, Rob Herring wrote:
On Thu, Mar 23, 2017 at 3:12 AM, Jeffy Chen wrote:
Currently we only free the allocated resource struct when error.
This would
Hi Sean,
On 04/05/2017 03:44 AM, Sean Paul wrote:
On Sat, Apr 01, 2017 at 07:35:26PM +0800, Jeffy Chen wrote:
We should not cleanup iommu before cleanup other resources.
Reorder unload sequence, follow exynos drm.
This doesn't match the cleanup sequence in rockchip_drm_bind. Also make
Hi Sean,
On 04/05/2017 03:42 AM, Sean Paul wrote:
On Sat, Apr 01, 2017 at 07:35:25PM +0800, Jeffy Chen wrote:
Hi Jeffy,
Could you please add commit messages describing *why* you're making the change?
It might be obvious to you (and maybe me), but others will benefit from better
descrip
Hi Daniel,
On 04/03/2017 03:58 PM, Daniel Vetter wrote:
On Sat, Apr 1, 2017 at 1:35 PM, Jeffy Chen wrote:
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a5d83cb..5dbf011 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
Hi Joe,
On 04/06/2017 12:06 AM, Joe Perches wrote:
On Wed, 2017-04-05 at 19:30 +0800, Jeffy Chen wrote:
Currently we are searching "./:$ENV{HOME}/:.scripts/" for ignore file,
but would always get "./.get_maintainer.ignore" only.
That's the point.
It allows you to ha
Hi Sean,
On 04/06/2017 12:28 AM, Sean Paul wrote:
On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:
After unbinding drm, the userspace may still has a chance to access
gem buf.
Add a sanity check for a NULL dev_private to prevent that from
happening.
I still don't understan
Hi Joe,
On 04/06/2017 10:39 AM, Joe Perches wrote:
On Thu, 2017-04-06 at 10:01 +0800, Jeffy Chen wrote:
The mail account "Yakir Yang " is no longer
valid.
Does this person still want to be involved with the kernel?
If so, perhaps a .mailmap entry would be more appropriate.
i don&
Hi Daniel,
On 04/06/2017 04:26 PM, Daniel Vetter wrote:
On Wed, Apr 05, 2017 at 12:28:40PM -0400, Sean Paul wrote:
On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:
After unbinding drm, the userspace may still has a chance to access
gem buf.
Add a sanity check for a NULL
Hi Andrzej,
On 04/06/2017 03:11 PM, Andrzej Hajda wrote:
On 05.04.2017 10:29, Jeffy Chen wrote:
The dp aux is registered when binding analogix dp.
Signed-off-by: Jeffy Chen
Reviewed-by: Andrzej Hajda
Btw, if you are working already in this area you can check also to
analogix_dp bind and
Hi Andrzej,
On 04/06/2017 03:19 PM, Andrzej Hajda wrote:
On 05.04.2017 10:29, Jeffy Chen wrote:
Normally we do this in drm_mode_config_cleanup. But analogix dp's
connector is allocated in bind, and freed after unbind. So we need
to destroy it in unbind to avoid further access.
Signed-o
Hi Sean,
On 04/06/2017 08:26 PM, Sean Paul wrote:
On Thu, Apr 06, 2017 at 10:47:59AM +0800, jeffy wrote:
Hi Sean,
On 04/06/2017 12:28 AM, Sean Paul wrote:
On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:
After unbinding drm, the userspace may still has a chance to access
gem buf
Hi Daniel,
On 04/07/2017 02:30 PM, Daniel Vetter wrote:
On Thu, Apr 6, 2017 at 1:09 PM, jeffy wrote:
On 04/06/2017 04:26 PM, Daniel Vetter wrote:
On Wed, Apr 05, 2017 at 12:28:40PM -0400, Sean Paul wrote:
On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:
After unbinding drm
Hi Daniel,
On 04/07/2017 03:16 PM, Daniel Vetter wrote:
On Thu, Apr 06, 2017 at 08:31:25PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.
Add a sanity check here to prevent that from happening.
Signed-off
Hi Sean,
On 04/11/2017 04:31 AM, Sean Paul wrote:
On Mon, Apr 10, 2017 at 06:00:45PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may trigger fb release after cleanup mode config.
Add a sanity check to prevent that.
Signed-off-by: Jeffy Chen
Hi Sean,
On 04/11/2017 03:26 AM, Sean Paul wrote:
On Mon, Apr 10, 2017 at 06:00:43PM +0800, Jeffy Chen wrote:
Hi Jeffy,
Thanks for sending this up again.
Verified on rk3399 chromebook kevin, no more crashes during unbind/bind drm.
I'm assuming this is on the chromeos-4.4 kernel?
Hi Daniel,
On 04/12/2017 02:33 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:41AM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.
We're using an unplugged state to prevent something like tha
Hi Daniel,
On 04/12/2017 02:36 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:42AM +0800, Jeffy Chen wrote:
We are freeing all framebuffers in drm_mode_config_cleanup without
sync the drm_file's fbs list.
So if someone try to unbind drm before release drm dev fd, the fbs
list
Hi Daniel,
missed some questions...
On 04/12/2017 04:17 PM, jeffy wrote:
Hi Daniel,
On 04/12/2017 02:33 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 11:31:41AM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm
Hi Dmitry,
On 04/02/2017 01:14 AM, Dmitry Torokhov wrote:
On Sat, Apr 01, 2017 at 10:12:37AM -0700, Dmitry Torokhov wrote:
Hi Jeffy,
On Thu, Mar 30, 2017 at 05:50:49PM +0800, Jeffy Chen wrote:
Report wakeup events when process events.
Signed-off-by: Jeffy Chen
---
drivers/input/keyboard
Hi Sean,
On 04/12/2017 11:03 PM, Sean Paul wrote:
On Wed, Apr 12, 2017 at 04:56:21PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so
Hi Rob,
On 06/27/2017 12:40 AM, Dmitry Torokhov wrote:
On Mon, Jun 26, 2017 at 11:00:11AM -0500, Rob Herring wrote:
On Wed, Jun 21, 2017 at 06:01:49PM +0800, Jeffy Chen wrote:
Update document devicetree bindings to support "wakeup-source" property.
Signed-off-by: Jeffy Chen
---
Hi brian,
thanx for your comments.
On 06/27/2017 06:17 AM, Brian Norris wrote:
Hi Jeffy,
On Mon, Jun 26, 2017 at 11:10:06AM +0800, Jeffy Chen wrote:
The cros_ec requires CS line to be active after last message. But the CS
would be toggled when powering off/on rockchip spi, which breaks ec
_session_thread
Tested-by: Rohit Vaswani
-Rohit
-Original Message-----
From: jeffy [mailto:jeffy.c...@rock-chips.com]
Sent: Friday, June 23, 2017 05:39
To: Rohit Vaswani; linux-blueto...@vger.kernel.org
Cc: Brian Norris; Douglas Anderson; Johan Hedberg; Peter Hurley; Johan Hedberg;
net...@
Hi Stephen,
On 06/28/2017 11:43 AM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
static int hidp_session_wake_function(wait_queue_t *wait
Hi doug,
thanx for your comments.
On 06/28/2017 03:27 AM, Doug Anderson wrote:
Hi,
On Mon, Jun 26, 2017 at 7:20 PM, Jeffy Chen wrote:
The rockchip spi would stop driving pins when runtime suspended, which
might break slave's xfer(for example cros_ec).
Since we have pullups on those
Hi Bjorn,
On 05/18/2017 05:08 AM, Bjorn Helgaas wrote:
On Wed, Apr 05, 2017 at 10:28:22AM +0800, Jeffy Chen wrote:
Currently we only free the allocated resource struct when error.
This would cause memory leak after pci_free_resource_list.
I think I see the problem here. The release path is
c_len + 1);
...
if (version->name_len) version->name[version->name_len] = '\0';
<-- crashed here, since the name_len would always be zero, so
version->name would be nullptr.
On 07/12/2017 02:18 PM, Jeffy Chen wrote:
DRM_IOCTL_VERSION is supposed to updat
Hi brian,
On 06/30/2017 06:05 AM, Brian Norris wrote:
On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote:
Currently the rockchip pinctrl driver would try to enable/disable the
gpio bank clk when enable/disable an irq.
So when the irq core trying to shutdown an already disabled irq, it
Hi Oliver,
Thanx for your comments, and sorry for reply late.
On 07/04/2017 07:38 PM, Oliver Neukum wrote:
Am Freitag, den 23.06.2017, 11:46 +0800 schrieb jeffy:
---
drivers/bluetooth/btusb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b
Hi brian,
On 07/06/2017 02:08 AM, Brian Norris wrote:
On Mon, Jul 03, 2017 at 03:54:30PM +0800, Jeffy Chen wrote:
We inited wakeup info at the beginning of mwifiex_add_card, so we need
to uninit it in the error handling.
It's much the same as what we did in:
36908c4 mwifiex: uninit w
Hi Oliver,
Thanks for your reply.
On 07/17/2017 11:26 PM, Oliver Neukum wrote:
Am Mittwoch, den 12.07.2017, 10:27 +0800 schrieb jeffy:
Hi Oliver,
Thanx for your comments, and sorry for reply late.
If you do that you have to change submit_tx_urb() to be called under a
spinlock.
sorry, why
Hi Greg,
On 07/18/2017 01:08 PM, Greg KH wrote:
On Tue, Jul 18, 2017 at 12:29:59PM +0800, Jeffy Chen wrote:
The earlycon would be alive outside the init code in these cases:
1/ we have keep_bootcon in cmdline.
2/ we don't have a real console to switch to.
So remove the __init marking to
Hi Oliver,
On 07/18/2017 03:30 PM, Oliver Neukum wrote:
Am Dienstag, den 18.07.2017, 08:44 +0200 schrieb Marcel Holtmann:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0d533b2..a22a08b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3260,19
Hi Oliver,
On 07/18/2017 04:41 PM, Oliver Neukum wrote:
Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy:
I am afraid not. We cannot silently drop one part of a transmission.
I am afraid that the correct algorithm, if we encounter an error at
that stage, is to abort the operation and
Hi Oliver,
On 07/18/2017 05:41 PM, Oliver Neukum wrote:
Am Dienstag, den 18.07.2017, 17:36 +0800 schrieb jeffy:
Hi Oliver,
On 07/18/2017 04:41 PM, Oliver Neukum wrote:
Am Dienstag, den 18.07.2017, 16:08 +0800 schrieb jeffy:
I am afraid not. We cannot silently drop one part of a
eters
[2.026327] mali ff9a.gpu: Failed to get voltage for frequency 0:
-34
Update devfreq stats when governor started to avoid that.
Signed-off-by: Jeffy Chen
How are you calling suspend/resume routins in the mali drivers?
i was porting mali driver from here:
https://chromium.googlesourc
Hi Oliver,
On 07/18/2017 08:29 PM, Oliver Neukum wrote:
Am Dienstag, den 18.07.2017, 17:56 +0800 schrieb jeffy:
Hi Oliver,
I think that as soon as one URB fails, you should not even try
to submit any other deferred URBs. You are taking one out from
the middle of a sequence. That cannot be
ignore it.
On 07/18/2017 07:27 PM, jeffy wrote:
hi Ham,
Thanks for your reply.
On 07/18/2017 06:35 PM, MyungJoo Ham wrote:
If governor suspends soon after started, it may not have the chance to
update devfreq stats, which leaves devfreq stats' current frequence be
zero.
So when the the
Hi Oliver,
On 07/20/2017 05:11 PM, Oliver Neukum wrote:
>+ if (err < 0) {
>+ if (err != -EPERM && err != -ENODEV)
>+ BT_ERR("%s urb %p submission failed (%d)",
>+ data->hdev->name, urb, -err);
>+
Hi shawn,
On 08/10/2017 04:21 PM, Shawn Lin wrote:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the function of __free_irq, it says
"It's a shared IRQ -- the driver ought to be prepared for
an IRQ ev
Hi shawn,
On 08/10/2017 05:14 PM, Shawn Lin wrote:
Hi Jeffy
On 2017/8/10 16:39, jeffy wrote:
Hi shawn,
On 08/10/2017 04:21 PM, Shawn Lin wrote:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the
Hi Heiko,
On 08/10/2017 05:27 PM, Heiko Stuebner wrote:
Hi Shawn,
Am Donnerstag, 10. August 2017, 16:21:13 CEST schrieb Shawn Lin:
>With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
>would still access the irq handler registed as a shard irq.
>Per the comment within the function of __
Hi Mark,
On 08/10/2017 10:56 PM, Mark Brown wrote:
On Thu, Aug 10, 2017 at 12:54:58PM +0800, Jeffy Chen wrote:
Add a new rockchip,codec-names property, so that the driver can parse
the codecs by name.
Why? You're already referencing the CODECs by phandle and these names
are not part o
Hi Heiko,
thanks for your reply.
On 08/30/2017 09:30 PM, Heiko Stübner wrote:
>- compatible = "realtek,rt5514";
>+ compatible = "realtek,rt5514", "realtek,rt5514-i2c";
the rt5514-i2c and -spi compatibles should be documented in the binding-txt
of the chip, but I haven't fou
Hi Donglin,
On 08/22/2017 05:08 PM, Donglin Peng wrote:
> card->dev = &pdev->dev;
> platform_set_drvdata(pdev, card);
There is no need to call platform_set_drvdata, because
devm_snd_soc_register_card will do it.
right, will remove it in next version, thanks:)
Hi Mark,
On 08/22/2017 06:32 PM, Mark Brown wrote:
On Tue, Aug 22, 2017 at 03:57:20PM +0800, Jeffy Chen wrote:
This property is no longer used.
I would still rather keep the existing property documented (the binding
does need to be fixed) than remove it. It's better practice and it&
Hi guys,
On 08/22/2017 10:26 PM, Takashi Iwai wrote:
On Tue, 22 Aug 2017 16:21:11 +0200,
Mark Brown wrote:
On Tue, Aug 22, 2017 at 10:15:32PM +0800, Donglin Peng wrote:
On Tue, Aug 22, 2017 at 10:02 PM, Mark Brown wrote:
We should be already verifying that drivers have a name, we assume o
hi Mark,
On 08/23/2017 12:17 AM, Mark Brown wrote:
On Tue, Aug 22, 2017 at 10:45:12PM +0800, Jeffy Chen wrote:
- return dai;
+ if (!dlc->dai_name)
+ return dai;
+ if (!strcmp(dai->nam
Hi Tony,
On 08/23/2017 01:26 AM, Tony Lindgren wrote:
OK, let's fix any wakeriq ordering issues to make it more
usable. Sounds like in your case the wakeirq needs to be enabled
late and disabled early, while in my test cases I can keep it
enabled basically any time.
yes, in my case it's a leve
1 - 100 of 780 matches
Mail list logo
