lening

2016-07-31 Thread DIAMOND SWISS LOANS CAPITAL 


Goede dag Client,

  
We zijn Diamond Zwitserse leningen CAPITAL het geven van leningen via 
e-mail advertentie. Wij bieden verschillende soorten leningen (korte en lange 
termijn leningen, persoonlijke leningen, leningen aan bedrijven etc.) met 1% 
rente. We geven leningen aan mensen in nood niet, ongeacht hun locatie, 
geslacht, burgerlijke staat, opleiding, status van de taak, maar moet een 
juridische middelen van terugbetaling hebben. Onze leningen variëren tussen 
5.000,00 tot 10.000.000,00 US Dollar of Euro of Pound met een maximale duur van 
15 years.DIAMOND SWISS lening bedrijf is een van de grootste Finance Company in 
de Europese landen, met meer dan $ 2trillion particuliere en zakelijke 
beleggingsportefeuilles Als u geïnteresseerd bent voor meer informatie, vul dan 
onderstaand formulier in en stuur het naar ons e-mail adres: 
diamondswisslo...@europe.com

Heeft u een financiële hulp nodig? Noodzaak van een legitieme krediet voor 
belang? Heeft u een zakelijke lening nodig? Heeft u een lening nodig om een 
huis, auto te kopen, betaal uw facturen en schulden? Heeft u geld nodig om 
problemen op te lossen? Als dat zo vriendelijk een aanvraag voor een lening met 
ons met 1% rente

INFORMATIE NODIG

Jullie namen:

Adres: 
Telefoon: .
Benodigd 
Duur: .
Bezetting: .
Maandelijks Inkomen Level: .
Geslacht: .
Geboortedatum: 
Staat: .
Land: .
Doel: .

Voor meer informatie contact met ons op voor meer informatie. Gelieve 
onmiddellijk te reageren op deze e-mail: diamondswisslo...@europe.com

"We tonen u een betere manier om uw financiële vrijheid"

Met vriendelijke groet,

Mr.Diamond Peters
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: OK

2016-07-31 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Mon Aug  1 04:00:22 CEST 2016
git branch: test
git hash:   292eaf50c7df4ae2ae8aaa9e1ce3f1240a353ee8
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

2016-07-31 Thread Rob Herring 
On Sun, Jul 31, 2016 at 8:23 PM, Wu, Songjun  wrote:
>
>
> On 7/30/2016 05:44, Rob Herring wrote:
>>
>> On Fri, Jul 29, 2016 at 03:54:08PM +0800, Songjun Wu wrote:
>>>
>>> DT binding documentation for ISC driver.
>>>
>>> Signed-off-by: Songjun Wu 
>>> ---
>>>
>>> Changes in v7: None
>>> Changes in v6:
>>> - Add "iscck" and "gck" to clock-names.
>>>
>>> Changes in v5:
>>> - Add clock-output-names.
>>>
>>> Changes in v4:
>>> - Remove the isc clock nodes.
>>>
>>> Changes in v3:
>>> - Remove the 'atmel,sensor-preferred'.
>>> - Modify the isc clock node according to the Rob's remarks.
>>>
>>> Changes in v2:
>>> - Remove the unit address of the endpoint.
>>> - Add the unit address to the clock node.
>>> - Avoid using underscores in node names.
>>> - Drop the "0x" in the unit address of the i2c node.
>>> - Modify the description of 'atmel,sensor-preferred'.
>>> - Add the description for the ISC internal clock.
>>>
>>>  .../devicetree/bindings/media/atmel-isc.txt| 65
>>> ++
>>>  1 file changed, 65 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
>>
>>
>> Please add acks when posting new versions.
>>
>> Rob
>>
> Hi Rob,
>
> Thank you for your reminder.
>
> Should I Add 'Acked-by: Rob Herring ' behind
> 'Signed-off-by: Songjun Wu '?

Before or after is fine.

> Should I resend this patch?

Not just to add acks, but if you send v8, add the acks.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

2016-07-31 Thread Wu, Songjun 



On 7/30/2016 05:44, Rob Herring wrote:

On Fri, Jul 29, 2016 at 03:54:08PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

Changes in v7: None
Changes in v6:
- Add "iscck" and "gck" to clock-names.

Changes in v5:
- Add clock-output-names.

Changes in v4:
- Remove the isc clock nodes.

Changes in v3:
- Remove the 'atmel,sensor-preferred'.
- Modify the isc clock node according to the Rob's remarks.

Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of 'atmel,sensor-preferred'.
- Add the description for the ISC internal clock.

 .../devicetree/bindings/media/atmel-isc.txt| 65 ++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt


Please add acks when posting new versions.

Rob


Hi Rob,

Thank you for your reminder.

Should I Add 'Acked-by: Rob Herring ' behind 
'Signed-off-by: Songjun Wu '?


Should I resend this patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

2016-07-31 Thread Matwey V. Kornilov 
Hello,

I've also just found that the same commit breaks cpufreq on BeagleBone Black :)

So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
frequency, which is unlisted and being set to 720Mhz by cpufreq driver
(as it did whet there was cpufreq driver).

2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've found that the following commit fixes the issue:
>
> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> Author: Viresh Kumar 
> Date:   Fri Apr 22 16:58:42 2016 +0530
>
> cpufreq: omap: Use generic platdev driver
>
> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> device now, reuse that and remove similar code from platform code.
>
>
> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov :
>> Hello,
>>
>> I've just bisected commit, which fixed the issue in v4.7
>>
>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>> Merge: f55532a febce40
>> Author: Rafael J. Wysocki 
>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>
>> Merge back intel_pstate fixes for v4.6.
>>
>> * pm-cpufreq:
>>   intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>   intel_pstate: Do not set utilization update hook too early
>>
>> Unfortunately, intel_pstate branch doesn't have
>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>> I'll try to bisect this branch with the patch manually applied.
>>
>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov :
>>> Hello,
>>>
>>> I've just biseced commit, which introduced this issue
>>>
>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>> Author: Bin Liu 
>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>
>>> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>> return in bottom half"
>>>
>>> I have not checked yet, if it was intentionnaly fixed.
>>>
>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov :
 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 18:06 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>>> >> > Hi,
>>> >> >
>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru 
>>> >> >> > wrote:
>>> >> >> >> Hello,
>>> >> >> >>
>>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my 
>>> >> >> >> AM335x based BeagleBoneBlack SBC.
>>> >> >> >> I am sure that both of them are fine and work properly.
>>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at 
>>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there 
>>> >> >> >> is an issue with frame transfer when high resolution formats 
>>> >> >> >> are used.
>>> >> >> >>
>>> >> >> >> The issue is the following. I use simple v4l2 example tool 
>>> >> >> >> (taken from API docs), which source code is available at 
>>> >> >> >> http://pastebin.com/grcNXxfe
>>> >> >> >>
>>> >> >> >> When I use (see line 488) 640x480 frames
>>> >> >> >>
>>> >> >> >> fmt.fmt.pix.width   = 640;
>>> >> >> >> fmt.fmt.pix.height  = 480;
>>> >> >> >>
>>> >> >> >> then I get "select timeout" and don't get any frames.
>>> >> >> >>
>>> >> >> >> When I use 320x240 frames
>>> >> >> >>
>>> >> >> >> fmt.fmt.pix.width   = 320;
>>> >> >> >> fmt.fmt.pix.height  = 240;
>>> >> >> >>
>>> >> >> >> then about 60% frames are missed. An example outpout of 
>>> >> >> >> ./a.out -f is available at https://yadi.sk/d/aRka8xWPtSc4y
>>> >> >> >> It looks like there are pauses between bulks of frames (frame 
>>> >> >> >> counter and timestamp as returned from v4l2 API):
>>> >> >> >>
>>> >> >> >> 3 3705.142553
>>> >> >> >> 8 3705.342533
>>> >> >> >> 13 3705.542517
>>> >> >> >> 110 3708.776208
>>> >> >> >> 115 3708.976190
>>> >> >> >> 120 3709.176169
>>> >> >> >> 125 3709.376152
>>> >> >> >> 130 3709.576144
>>> >> >> >> 226 3712.807848
>>> >> >> >>
>>> >> >> >> When I use tiny 160x120 frames
>>> >> >> >>
>>> >> >> >> fmt.fmt.pix.width   = 160;
>>> >> >> >> fmt.fmt.pix.height  = 120;
>>> >> >> >>
>>> >> >> >> then more frames are received. See output example at 
>>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>>> >> >> >> That is why I thought that everything

[PATCH] media: rc: nuvoton: ignore spurious interrupt when logical device is being disabled

2016-07-31 Thread Heiner Kallweit 
When removing module nuvoton-cir I get a fifo overrun warning.
It turned out to be caused by a spurious interrupt when the logical CIR
device is being disabled (although no interrupt source bit being set).
Reading the interrupt status register returns 0xff, therefore the fifo
overrun bit is mistakenly interpreted as being set.

Fix this by ignoring interrupts when interrupt source and status register
reads return 0xff.

Signed-off-by: Heiner Kallweit 
---
 drivers/media/rc/nuvoton-cir.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 00215f3..0c69536 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -886,6 +886,15 @@ static irqreturn_t nvt_cir_isr(int irq, void *data)
status = nvt_cir_reg_read(nvt, CIR_IRSTS);
iren = nvt_cir_reg_read(nvt, CIR_IREN);
 
+   /* At least NCT6779D creates a spurious interrupt when the
+* logical device is being disabled.
+*/
+   if (status == 0xff && iren == 0xff) {
+   spin_unlock_irqrestore(>nvt_lock, flags);
+   nvt_dbg_verbose("Spurious interrupt detected");
+   return IRQ_HANDLED;
+   }
+
/* IRQ may be shared with CIR WAKE, therefore check for each
 * status bit whether the related interrupt source is enabled
 */
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v2 2/2] media: platform: pxa_camera: make a standalone v4l2 device

2016-07-31 Thread Robert Jarzmik 
Hi Hans,


Hans Verkuil  writes:
> On 04/02/2016 04:26 PM, Robert Jarzmik wrote:
>> diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
>> b/drivers/media/platform/soc_camera/pxa_camera.c
>> index b8dd878e98d6..30d266bbab55 100644
>> --- a/drivers/media/platform/soc_camera/pxa_camera.c
>> +++ b/drivers/media/platform/soc_camera/pxa_camera.c
>
> When you prepare the final patch series, please put the driver in
> drivers/media/platform/pxa-camera and not in the soc-camera directory.
Sure.
Would you accept the final patch to make the move, so that I keep the
bisectability, ie. that all patches are applied while still in ../soc_camera,
and then the final one making just the move to .../platform ?

>> +if (format->name)
>> +strlcpy(f->description, format->name, sizeof(f->description));
>
> You can drop this since the core fills in the description. That means the
> 'name' field of struct soc_mbus_pixelfmt is not needed either.
Ok, let's try this, for v3.

>> +static int pxac_vidioc_querycap(struct file *file, void *priv,
>> +struct v4l2_capability *cap)
>> +{
>> +strlcpy(cap->bus_info, "platform:pxa-camera", sizeof(cap->bus_info));
>> +strlcpy(cap->driver, PXA_CAM_DRV_NAME, sizeof(cap->driver));
>> +strlcpy(cap->card, pxa_cam_driver_description, sizeof(cap->card));
>> +cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
>> +cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Tiny fix: you can drop the capabilities assignment: the v4l2 core does that
> for you these days.
Well, above kernel v4.7, if I drop the assignement, v4l2-compliance -s finds 2
new errors:
Required ioctls:
fail: v4l2-compliance.cpp(534): dcaps & ~caps
test VIDIOC_QUERYCAP: FAIL

Allow for multiple opens:
test second video open: OK
fail: v4l2-compliance.cpp(534): dcaps & ~caps
test VIDIOC_QUERYCAP: FAIL
test VIDIOC_G/S_PRIORITY: OK

So there is something fishy here if the core provides this data ...

>> +static int pxac_vidioc_enum_input(struct file *file, void *priv,
>> +  struct v4l2_input *i)
>> +{
>> +if (i->index > 0)
>> +return -EINVAL;
>> +
>> +memset(i, 0, sizeof(*i));
>
> The memset can be dropped, it's cleared for you.
OK, for v3.

>> +static void pxac_vb2_queue(struct vb2_buffer *vb)
>> +{
>> +struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
>> +struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
>> +
>> +dev_dbg(pcdev_to_dev(pcdev),
>> + "%s(vb=%p) nb_channels=%d size=%lu active=%p\n",
>> +__func__, vb, pcdev->channels, vb2_get_plane_payload(vb, 0),
>> +pcdev->active);
>> +
>> +list_add_tail(>queue, >capture);
>> +
>> +pxa_dma_add_tail_buf(pcdev, buf);
>> +
>> +if (!pcdev->active)
>> +pxa_camera_start_capture(pcdev);
>
> This is normally done from start_streaming. Are you really sure this is the 
> right
> place? I strongly recommend moving this start_capture call.
Well, it was at least with the previous framework.
Previously this was done here to "hot-queue" a buffer :
 - if a previous capture was still running, the buffer was queued by
   pxa_dma_add_tail_buf(), and no restart of the DMA pump was necessary
 - if the previous capture was finished, a new one was initiated

Now if the new framework takes care of that, I can move the
pxa_camera_start_capture() into start_streaming(), no problem, let me try in the
next patchset. That might take a bit of time because testing both the
"hot-queue" and the "queue but hot-queuing missed" is a bit tricky.

> You may also want to use the struct vb2queue min_buffers_needed field to 
> specify
> the minimum number of buffers that should be queued up before start_streaming 
> can
> be called. Whether that's needed depends on your DMA engine.
I have no minimum required by the pxa dmaengine driver, that's good.

>> +
>> +v4l2_disable_ioctl(vdev, VIDIOC_G_STD);
>> +v4l2_disable_ioctl(vdev, VIDIOC_S_STD);
>> +v4l2_disable_ioctl(vdev, VIDIOC_ENUMSTD);
>
> I don't think this is needed since the tvnorms field of struct video_device 
> == 0,
> signalling that there is no STD support.
OK, for v3.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rcar_vin: add support for V4L2_FIELD_ALTERNATE

2016-07-31 Thread Sergei Shtylyov 
The hardware  can capture both odd and even fields in  the separate buffers,
so  it's possible to support  this field mode. However, if the subdevice
presents data  in this mode,  we prefer to use the hardware deinterlacing...

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'media_tree.git' repo's 'master' branch.
This patch needs to be merged before the following ADV7180 driver patch is
merged: http://www.mail-archive.com/linux-media@vger.kernel.org/msg100410.html

 drivers/media/platform/soc_camera/rcar_vin.c |2 ++
 1 file changed, 2 insertions(+)

Index: media_tree/drivers/media/platform/soc_camera/rcar_vin.c
===
--- media_tree.orig/drivers/media/platform/soc_camera/rcar_vin.c
+++ media_tree/drivers/media/platform/soc_camera/rcar_vin.c
@@ -585,6 +585,7 @@ static int rcar_vin_setup(struct rcar_vi
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
case V4L2_FIELD_NONE:
+   case V4L2_FIELD_ALTERNATE:
if (is_continuous_transfer(priv)) {
vnmc = VNMC_IM_ODD_EVEN;
progressive = true;
@@ -1595,6 +1596,7 @@ static int rcar_vin_set_fmt(struct soc_c
case V4L2_FIELD_INTERLACED_BT:
field = pix->field;
break;
+   case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_INTERLACED:
/* Query for standard if not explicitly mentioned _TB/_BT */
ret = v4l2_subdev_call(sd, video, querystd, );

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media: rc: fix deadlock when module ir_lirc_codec is removed

2016-07-31 Thread Heiner Kallweit 
When removing module ir_lirc_codec I got this deadlock warning.
Fix this by introducing a separate mutex to protect access
to available_protocols instead of using ir_raw_handler_lock
for this purpose.

==
[ INFO: possible circular locking dependency detected ]
4.7.0-next-20160729 #1 Not tainted
---
rmmod/2542 is trying to acquire lock:
 (>lock){+.+.+.}, at: []
ir_raw_handler_unregister+0x77/0xd0 [rc_core]

but task is already holding lock:
 (ir_raw_handler_lock){+.+.+.}, at: []
ir_raw_handler_unregister+0x22/0xd0 [rc_core]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (ir_raw_handler_lock){+.+.+.}:
   [] lock_acquire+0xb2/0x1e0
   [] mutex_lock_nested+0x5f/0x360
   [] ir_raw_get_allowed_protocols+0x13/0x30 [rc_core]
   [] store_protocols+0x2fa/0x480 [rc_core]
   [] dev_attr_store+0x13/0x20
   [] sysfs_kf_write+0x40/0x50
   [] kernfs_fop_write+0x150/0x1e0
   [] __vfs_write+0x23/0x120
   [] vfs_write+0xb0/0x190
   [] SyS_write+0x44/0xa0
   [] entry_SYSCALL_64_fastpath+0x18/0xa8

-> #0 (>lock){+.+.+.}:
   [] __lock_acquire+0x10fc/0x1270
   [] lock_acquire+0xb2/0x1e0
   [] mutex_lock_nested+0x5f/0x360
   [] ir_raw_handler_unregister+0x77/0xd0 [rc_core]
   [] ir_lirc_codec_exit+0x10/0x12 [ir_lirc_codec]
   [] SyS_delete_module+0x168/0x220
   [] entry_SYSCALL_64_fastpath+0x18/0xa8

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(ir_raw_handler_lock);
   lock(>lock);
   lock(ir_raw_handler_lock);
  lock(>lock);

 *** DEADLOCK ***

1 lock held by rmmod/2542:
 #0:  (ir_raw_handler_lock){+.+.+.}, at: []
ir_raw_handler_unregister+0x22/0xd0 [rc_core]

stack backtrace:
CPU: 0 PID: 2542 Comm: rmmod Not tainted 4.7.0-next-20160729 #1
Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
  88006e607cc0 812715f5 8232b230
 8232b230 88006e607d00 810a846e 790107f0
 880079010818 8800790107f0 1efeb9f4f0dd2e6f 88007901
Call Trace:
 [] dump_stack+0x68/0x93
 [] print_circular_bug+0x1be/0x210
 [] __lock_acquire+0x10fc/0x1270
 [] ? debug_lockdep_rcu_enabled+0x1d/0x20
 [] lock_acquire+0xb2/0x1e0
 [] ? ir_raw_handler_unregister+0x77/0xd0 [rc_core]
 [] mutex_lock_nested+0x5f/0x360
 [] ? ir_raw_handler_unregister+0x77/0xd0 [rc_core]
 [] ? trace_hardirqs_on_caller+0xee/0x1b0
 [] ir_raw_handler_unregister+0x77/0xd0 [rc_core]
 [] ir_lirc_codec_exit+0x10/0x12 [ir_lirc_codec]
 [] SyS_delete_module+0x168/0x220
 [] entry_SYSCALL_64_fastpath+0x18/0xa8

Signed-off-by: Heiner Kallweit 
---
 drivers/media/rc/rc-ir-raw.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 144304c..205ecc6 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -26,6 +26,7 @@ static LIST_HEAD(ir_raw_client_list);
 /* Used to handle IR raw handler extensions */
 static DEFINE_MUTEX(ir_raw_handler_lock);
 static LIST_HEAD(ir_raw_handler_list);
+static DEFINE_MUTEX(available_protocols_lock);
 static u64 available_protocols;
 
 static int ir_raw_event_thread(void *data)
@@ -234,9 +235,9 @@ u64
 ir_raw_get_allowed_protocols(void)
 {
u64 protocols;
-   mutex_lock(_raw_handler_lock);
+   mutex_lock(_protocols_lock);
protocols = available_protocols;
-   mutex_unlock(_raw_handler_lock);
+   mutex_unlock(_protocols_lock);
return protocols;
 }
 
@@ -330,7 +331,9 @@ int ir_raw_handler_register(struct ir_raw_handler 
*ir_raw_handler)
if (ir_raw_handler->raw_register)
list_for_each_entry(raw, _raw_client_list, list)
ir_raw_handler->raw_register(raw->dev);
+   mutex_lock(_protocols_lock);
available_protocols |= ir_raw_handler->protocols;
+   mutex_unlock(_protocols_lock);
mutex_unlock(_raw_handler_lock);
 
return 0;
@@ -349,7 +352,9 @@ void ir_raw_handler_unregister(struct ir_raw_handler 
*ir_raw_handler)
if (ir_raw_handler->raw_unregister)
ir_raw_handler->raw_unregister(raw->dev);
}
+   mutex_lock(_protocols_lock);
available_protocols &= ~protocols;
+   mutex_unlock(_protocols_lock);
mutex_unlock(_raw_handler_lock);
 }
 EXPORT_SYMBOL(ir_raw_handler_unregister);
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c: Modify error handling

2016-07-31 Thread Sakari Ailus 
Hi Amitoj,

On Sun, Jul 31, 2016 at 09:28:00AM +0530, Amitoj Kaur Chawla wrote:
> devm_gpiod_get returns an ERR_PTR on error so a null check is
> incorrect and an IS_ERR check is required.
> 
> The Coccinelle semantic patch used to make this change is as follows:
> @@
> expression e;
> statement S;
> @@
> 
>   e = devm_gpiod_get(...);
>  if(
> -   !e
> +   IS_ERR(e)
>)
>   {
>...
> -  return ...;
> +  return PTR_ERR(e);
>   }
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  drivers/media/i2c/adp1653.c | 4 ++--

In this exact case, the issue has been fixed by similar patch in media-tree
master branch. You likely used another branch for preparing this patch.

Nevertheless, thank you for the patch --- this kind of cleanups are always
much appreciated.

commit 806f8ffa8a0fa9a6f0481c5648c27aa51d10fdc6
Author: Vladimir Zapolskiy 
Date:   Mon Mar 7 15:39:32 2016 -0300

[media] media: i2c/adp1653: fix check of devm_gpiod_get() error code

The devm_gpiod_get() function returns either a valid pointer to
struct gpio_desc or ERR_PTR() error value, check for NULL is bogus.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index fb7ed73..9e1731c 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -466,9 +466,9 @@ static int adp1653_of_init(struct i2c_client *client,
of_node_put(child);
 
pd->enable_gpio = devm_gpiod_get(>dev, "enable", GPIOD_OUT_LOW);
-   if (!pd->enable_gpio) {
+   if (IS_ERR(pd->enable_gpio)) {
dev_err(>dev, "Error getting GPIO\n");
-   return -EINVAL;
+   return PTR_ERR(pd->enable_gpio);
}
 
return 0;

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

You have a new message

2016-07-31 Thread Birgit Rausing & family 

Please confirm if you got my email. 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html