lening
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
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
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
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
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 was fine in May when >>> >> >> >> used tiny xawtv window to check kernel OOPS presence (see >>> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for >>> >> >> >> reference) >>> >> >> >> >
[PATCH] media: rc: nuvoton: ignore spurious interrupt when logical device is being disabled
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->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
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(&buf->queue, &pcdev->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
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, &std); -- 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
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: (&dev->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 (&dev->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(&dev->lock); lock(ir_raw_handler_lock); lock(&dev->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(&ir_raw_handler_lock); + mutex_lock(&available_protocols_lock); protocols = available_protocols; - mutex_unlock(&ir_raw_handler_lock); + mutex_unlock(&available_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, &ir_raw_client_list, list) ir_raw_handler->raw_register(raw->dev); + mutex_lock(&available_protocols_lock); available_protocols |= ir_raw_handler->protocols; + mutex_unlock(&available_protocols_lock); mutex_unlock(&ir_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(&available_protocols_lock); available_protocols &= ~protocols; + mutex_unlock(&available_protocols_lock); mutex_unlock(&ir_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 a
Re: [PATCH] i2c: Modify error handling
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(&client->dev, "enable", GPIOD_OUT_LOW); - if (!pd->enable_gpio) { + if (IS_ERR(pd->enable_gpio)) { dev_err(&client->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
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