Re: usb/media/em28xx: use-after-free in dvb_unregister_frontend

2017-11-22 Thread Matthias Schwarzott 
Am 21.11.2017 um 14:51 schrieb Andrey Konovalov:
> Hi!
> 
Hi Andrey,

> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1).
> 
> em28xx 1-1:9.0: Disconnecting
> tc90522 1-0015: Toshiba TC90522 attached.
> qm1d1c0042 2-0061: Sharp QM1D1C0042 attached.
> dvbdev: DVB: registering new adapter (1-1:9.0)
> em28xx 1-1:9.0: DVB: registering adapter 0 frontend 0 (Toshiba TC90522
> ISDB-S module)...
> dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-S
> module' registered.
> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
> em28xx 1-1:9.0: DVB extension successfully initialized
> em28xx 1-1:9.0: Remote control support is not available for this card.
> em28xx 1-1:9.0: Closing DVB extension
> ==
> BUG: KASAN: use-after-free in dvb_unregister_frontend+0x8f/0xa0
> Read of size 8 at addr 880067853628 by task kworker/0:3/3182
> 
> CPU: 0 PID: 3182 Comm: kworker/0:3 Not tainted 4.14.0-57501-g9284d204d604 #119
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:17
>  dump_stack+0xe1/0x157 lib/dump_stack.c:53
>  print_address_description+0x71/0x234 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x173/0x270 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
>  dvb_unregister_frontend+0x8f/0xa0 drivers/media/dvb-core/dvb_frontend.c:2768
>  em28xx_unregister_dvb drivers/media/usb/em28xx/em28xx-dvb.c:1122
>  em28xx_dvb_fini+0x62d/0x8e0 drivers/media/usb/em28xx/em28xx-dvb.c:2129
>  em28xx_close_extension+0x71/0x220 drivers/media/usb/em28xx/em28xx-core.c:1122
>  em28xx_usb_disconnect+0xd7/0x130 drivers/media/usb/em28xx/em28xx-cards.c:3763
>  usb_unbind_interface+0x1b6/0x950 drivers/usb/core/driver.c:423
>  __device_release_driver drivers/base/dd.c:870
>  device_release_driver_internal+0x563/0x630 drivers/base/dd.c:903
>  device_release_driver+0x1e/0x30 drivers/base/dd.c:928
>  bus_remove_device+0x2fc/0x4b0 drivers/base/bus.c:565
>  device_del+0x39f/0xa70 drivers/base/core.c:1984
>  usb_disable_device+0x223/0x710 drivers/usb/core/message.c:1205
>  usb_disconnect+0x285/0x7f0 drivers/usb/core/hub.c:2205
>  hub_port_connect drivers/usb/core/hub.c:4851
>  hub_port_connect_change drivers/usb/core/hub.c:5106
>  port_event drivers/usb/core/hub.c:5212
>  hub_event_impl+0x10f0/0x3440 drivers/usb/core/hub.c:5324
>  hub_event+0x38/0x50 drivers/usb/core/hub.c:5222
>  process_one_work+0x944/0x15f0 kernel/workqueue.c:2112
>  worker_thread+0xef/0x10d0 kernel/workqueue.c:2246
>  kthread+0x367/0x420 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437
> 

this looks similar to the oops fixed by this patch:

https://patchwork.linuxtv.org/patch/45219/

Could you try if it fixes your case also?

Regards
Matthias

Best android tv box

2017-11-22 Thread Aidan 
Dear Sir/Madam,

Nice to meet you.

This is Aidan from SENROO company,specialized in android tv box and other 
consumer electronics since 2006.

As a manufacturer,we can offer you high quality product at original factory 
price.

For V88 rk3229  1g/8g tv box,17~19 USD /unit

Tx3 mini/X96 mini s905w 2g/16g android 7.1 tv box,27~28 USD/unit.
 
X96 Amlogic s905x 1g/8g tv box,24~25.5 USD/unit,and 30~32 USD/unit for 
2g/16g version.

Latest H96 Amlogic s912 tv box,47~48 USD/unit for 2g/16g version,and 52~55 
USD/unit for 3g/16g version,and 58~60 USD/unit for 3g/32g version.

And we have mini i8 keyboard for android tv box,5~6 USD/unit.

If you want more details or price lists,pls feel free to contact me.

Best Regards

cron job: media_tree daily build: WARNINGS

2017-11-22 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:   Thu Nov 23 05:00:20 CET 2017
media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10
media_build git hash:   097aaf3e4e4bfdeff130db9697dec1befeb3221b
v4l-utils git hash: a8a04d397e929381a2150bee2100fc28ad2cfbec
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: 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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

2017-11-22 Thread Tim Harvey 
On Wed, Nov 15, 2017 at 8:30 PM, Rob Herring  wrote:
> On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote:
>> On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring  wrote:
>> > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
>> >> Add support for the TDA1997x HDMI receivers.
>> >>
>> >> Cc: Hans Verkuil 
>> >> Signed-off-by: Tim Harvey 
>> >> ---
>> >> v3:
>> >>  - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>> >>  - fixed missing break
>> >>  - use only hdmi_infoframe_log for infoframe logging
>> >>  - simplify tda1997x_s_stream error handling
>> >>  - add delayed work proc to handle hotplug enable/disable
>> >>  - fix set_edid (disable HPD before writing, enable after)
>> >>  - remove enabling edid by default
>> >>  - initialize timings
>> >>  - take quant range into account in colorspace conversion
>> >>  - remove vendor/product tracking (we provide this in log_status via 
>> >> infoframes)
>> >>  - add v4l_controls
>> >>  - add more detail to log_status
>> >>  - calculate vhref generator timings
>> >>  - timing detection fixes (rounding errors, hswidth errors)
>> >>  - rename configure_input/configure_conv functions
>> >>
>> >> v2:
>> >>  - implement dv timings enum/cap
>> >>  - remove deprecated g_mbus_config op
>> >>  - fix dv_query_timings
>> >>  - add EDID get/set handling
>> >>  - remove max-pixel-rate support
>> >>  - add audio codec DAI support
>> >>  - change audio bindings
>> >> ---
>> >>  drivers/media/i2c/Kconfig|9 +
>> >>  drivers/media/i2c/Makefile   |1 +
>> >>  drivers/media/i2c/tda1997x.c | 3485 
>> >> ++
>> >>  include/dt-bindings/media/tda1997x.h |   78 +
>> >
>> > This belongs with the binding documentation patch.
>> >
>>
>> Rob,
>>
>> Thanks - missed that. I will move it for v4.
>>
>> Regarding your previous comment to the v2 series:
>> > The rest of the binding looks fine, but I have some reservations about
>> > this. I think this should be common probably. There's been a few
>> > bindings for display recently that deal with the interface format. Maybe
>> > some vendor property is needed here to map a standard interface format
>> > back to pin configuration.
>>
>> I take it this is not an 'Ack' for the bindings?
>>
>> Which did you feel should be made common? I admit I was surprised
>> there wasn't a common binding for audio bus format (i2s|spdif) but if
>> you were referring to the video data that would probably be much more
>> complicated.
>
> The video data. Either you have to try to come up with some way to map
> color components to signals/pins (and even cycles) or you just enumerate
> the formats and keep adding to them when new ones appear. There's h/w
> that allows the former, but in the end you have to interoperate, so
> enumerating the formats is probably enough.
>
>> I was hoping one of the media/driver maintainers would respond to your
>> comment with thoughts as I'm not familiar with a very wide variety of
>> receivers.
>
> I am hoping, too.
>
> Rob

Hans,

Do you have any comment here regarding Rob's hope that there could be
some generic properties created for video port bindings? Anyone else
you know of who should chime in here?

The TDA1997x allows mapping its internal video output bus to its
physical pin in a fairly flexible way. I don't know how unique this is
to other chips.

Regards,

Tim

Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X

2017-11-22 Thread Tim Harvey 
On Tue, Nov 21, 2017 at 11:36 PM, Sakari Ailus  wrote:
> Hi Tim,
>
> On Thu, Nov 09, 2017 at 10:45:33AM -0800, Tim Harvey wrote:
>> Cc: Rob Herring 
>> Signed-off-by: Tim Harvey 
>> ---
>> v3:
>>  - fix typo
>>
>> v2:
>>  - add vendor prefix and remove _ from vidout-portcfg
>>  - remove _ from labels
>>  - remove max-pixel-rate property
>>  - describe and provide example for single output port
>>  - update to new audio port bindings
>> ---
>>  .../devicetree/bindings/media/i2c/tda1997x.txt | 179 
>> +
>>  1 file changed, 179 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
>> b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>> new file mode 100644
>> index 000..dd37f14
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>> @@ -0,0 +1,179 @@
>> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
>> +
>> +The TDA19971/73 are HDMI video receivers.
>> +
>> +The TDA19971 Video port output pins can be used as follows:
>> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
>> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
>> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
>> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] 
>> CbCr[11:2]
>> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] 
>> CbCr[11:0]
>> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
>> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
>> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
>> +
>> +The TDA19973 Video port output pins can be used as follows:
>> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
>> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
>> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] 
>> CbCr[11:0]
>> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
>> +
>> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
>> +for a variety of connection possibilities including swapping pin order 
>> within
>> +pin groups. The video_portcfg device-tree property consists of register 
>> mapping
>> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
>> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
>> +
>> +Required Properties:
>> + - compatible  :
>> +  - "nxp,tda19971" for the TDA19971
>> +  - "nxp,tda19973" for the TDA19973
>> + - reg : I2C slave address
>> + - interrupts  : The interrupt number
>> + - DOVDD-supply: Digital I/O supply
>> + - DVDD-supply : Digital Core supply
>> + - AVDD-supply : Analog supply
>> + - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin 
>> groups.
>> +
>> +Optional Properties:
>> + - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
>> + - nxp,audout-width: width of audio output data bus (1-4).
>> + - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
>> + - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
>> + mclk.
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> Could you add that this port has one endpoint node as well? (Unless you
> support multiple, that is.)

Sure... will clarify as:

The device node must contain one endpoint 'port' child node for its
digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.

>> +
>> +Optional Endpoint Properties:
>> +  The following three properties are defined in video-interfaces.txt and
>> +  are valid for source endpoints only:
>
> Transmitters? Don't you have an endpoint only in the port representing the
> transmitter?

I'm not usre what you mean.

The TDA1997x is an HDMI receiver meaning it receives HDMI and decodes
it to a parallel video bus. HDMI transmitters are the opposite.

Regards,

Tim

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

2017-11-22 Thread Tim Harvey 
On Mon, Nov 20, 2017 at 7:39 AM, Hans Verkuil  wrote:
> Hi Tim,
>
> Some more review comments:
>
> On 11/09/2017 07:45 PM, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.

>> + */
>> +struct color_matrix_coefs {
>> + const char *name;
>> + /* Input offsets */
>> + s16 offint1;
>> + s16 offint2;
>> + s16 offint3;
>> + /* Coeficients */
>> + s16 p11coef;
>> + s16 p12coef;
>> + s16 p13coef;
>> + s16 p21coef;
>> + s16 p22coef;
>> + s16 p23coef;
>> + s16 p31coef;
>> + s16 p32coef;
>> + s16 p33coef;
>> + /* Output offsets */
>> + s16 offout1;
>> + s16 offout2;
>> + s16 offout3;
>> +};
>> +
>> +enum {
>> + ITU709_RGBLIMITED,
>> + ITU709_RGBFULL,
>> + ITU601_RGBLIMITED,
>> + ITU601_RGBFULL,
>> + RGBLIMITED_RGBFULL,
>> + RGBLIMITED_ITU601,
>> + RGBFULL_ITU601,
>
> This can't be right.
>ITU709_RGBLIMITED
> You have these conversions:
>
> ITU709_RGBFULL
> ITU601_RGBFULL
> RGBLIMITED_RGBFULL
> RGBLIMITED_ITU601
> RGBFULL_ITU601
> RGBLIMITED_ITU709
> RGBFULL_ITU709
>
> I.e. on the HDMI receiver side you can receive RGB full/limited or ITU601/709.
> On the output side you have RGB full or ITU601/709.
>
> So something like ITU709_RGBLIMITED makes no sense.
>

I misunderstood the V4L2_CID_DV_RX_RGB_RANGE thinking that it allowed
you to configure the output range. If output to the SoC is only ever
full quant range for RGB then I can drop the
ITU709_RGBLIMITED/ITU601_RGBLIMITED conversions.

However, If the output is YUV how do I know if I need to convert to
ITU709 or ITU601 and what are my conversion matrices for
RGBLIMITED_ITU709/RGBFULL_ITU709?

Sorry for all the questions, the colorspace/colorimetry options
confuse the heck out of me.

>> +};
>> +

>> +
>> +/* parse an infoframe and do some sanity checks on it */
>> +static unsigned int
>> +tda1997x_parse_infoframe(struct tda1997x_state *state, u16 addr)
>> +{
>> + struct v4l2_subdev *sd = >sd;
>> + union hdmi_infoframe frame;
>> + u8 buffer[40];
>> + u8 reg;
>> + int len, err;
>> +
>> + /* read data */
>> + len = io_readn(sd, addr, sizeof(buffer), buffer);
>> + err = hdmi_infoframe_unpack(, buffer);
>> + if (err) {
>> + v4l_err(state->client,
>> + "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
>> + len, addr, buffer[0]);
>> + return err;
>> + }
>> + hdmi_infoframe_log(KERN_INFO, >client->dev, );
>> + switch (frame.any.type) {
>> + /* Audio InfoFrame: see HDMI spec 8.2.2 */
>> + case HDMI_INFOFRAME_TYPE_AUDIO:
>> + /* sample rate */
>> + switch (frame.audio.sample_frequency) {
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_32000:
>> + state->audio_samplerate = 32000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_44100:
>> + state->audio_samplerate = 44100;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_48000:
>> + state->audio_samplerate = 48000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_88200:
>> + state->audio_samplerate = 88200;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_96000:
>> + state->audio_samplerate = 96000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_176400:
>> + state->audio_samplerate = 176400;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_192000:
>> + state->audio_samplerate = 192000;
>> + break;
>> + default:
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM:
>> + break;
>> + }
>> +
>> + /* sample size */
>> + switch (frame.audio.sample_size) {
>> + case HDMI_AUDIO_SAMPLE_SIZE_16:
>> + state->audio_samplesize = 16;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_20:
>> + state->audio_samplesize = 20;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_24:
>> + state->audio_samplesize = 24;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_STREAM:
>> + default:
>> + break;
>> + }
>> +
>> + /* Channel Count */
>> + state->audio_channels = frame.audio.channels;
>> + if (frame.audio.channel_allocation &&
>> + frame.audio.channel_allocation != state->audio_ch_alloc) {
>> + /* use the channel assignment from the infoframe */
>> + state->audio_ch_alloc = frame.audio.channel_allocation;
>> +

[PATCH] davinci: vpif_capture: add NULL check on devm_kzalloc return value

2017-11-22 Thread Gustavo A. R. Silva 
Check return value from call to devm_kzalloc() in order to prevent
a NULL pointer dereference.

This issue was detected with the help of Coccinelle.

Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when 
available")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/davinci/vpif_capture.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index a89367a..3879c7c 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1550,6 +1550,8 @@ vpif_capture_get_pdata(struct platform_device *pdev)
sizeof(*chan->inputs) *
VPIF_CAPTURE_NUM_CHANNELS,
GFP_KERNEL);
+   if (!chan->inputs)
+   return NULL;
 
chan->input_count++;
chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
-- 
2.7.4

Re: [PATCH] au0828: fix use-after-free at USB probing

2017-11-22 Thread Gustavo A. R. Silva 

Hi Andrey,

I have successfully installed and tested syzkaller with QEMU. Can you  
please tell me how to reproduce this bug or share with me the full  
crash report?


Also, can you point me out to the PoC file?

Much appreciated
Thank you!
--
Gustavo A. R. Silva

Quoting Andrey Konovalov :


On Fri, Nov 10, 2017 at 6:35 PM, Gustavo A. R. Silva
 wrote:


Quoting Andrey Konovalov :


On Fri, Nov 10, 2017 at 1:21 AM, Gustavo A. R. Silva
 wrote:


Hi Andrey,

Could you please try this patch?

Thank you


Hi!

Sorry for the delay.

With this patch I still see the same report:

au0828: recv_control_msg() Failed receiving control message, error -71.
au0828: recv_control_msg() Failed receiving control message, error -71.
au0828: recv_control_msg() Failed receiving control message, error -71.
au8522_writereg: writereg error (reg == 0x106, val == 0x0001, ret == -5)
usb 1-1: selecting invalid altsetting 5
au0828: Failure setting usb interface0 to as5
au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
au0828: probe of 1-1:0.0 failed with error -22
usb 1-1: USB disconnect, device number 3
==
BUG: KASAN: use-after-free in __list_del_entry_valid+0xda/0xf3
Read of size 8 at addr 880062a74410 by task kworker/0:1/24

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
4.14.0-rc8-44455-ge2105594a876-dirty #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:17
 dump_stack+0xe1/0x157 lib/dump_stack.c:53
 print_address_description+0x71/0x234 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x173/0x270 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 __list_del_entry_valid+0xda/0xf3 lib/list_debug.c:54
 __list_del_entry ./include/linux/list.h:117
 list_del_init ./include/linux/list.h:159
 device_pm_remove+0x4a/0x1e7 drivers/base/power/main.c:149
 device_del+0x599/0xa70 drivers/base/core.c:1986
 usb_disable_device+0x223/0x710 drivers/usb/core/message.c:1170
 usb_disconnect+0x285/0x7f0 drivers/usb/core/hub.c:2205
 hub_port_connect drivers/usb/core/hub.c:4838
 hub_port_connect_change drivers/usb/core/hub.c:5093
 port_event drivers/usb/core/hub.c:5199
 hub_event_impl+0x10ec/0x3440 drivers/usb/core/hub.c:5311
 hub_event+0x38/0x50 drivers/usb/core/hub.c:5209
 process_one_work+0x925/0x15d0 kernel/workqueue.c:2113
 process_scheduled_works kernel/workqueue.c:2173
 worker_thread+0x72e/0x10d0 kernel/workqueue.c:2249
 kthread+0x346/0x410 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432

The buggy address belongs to the page:
page:ea00018a9d00 count:0 mapcount:-127 mapping:  (null)  
index:0x0

flags: 0x100()
raw: 0100   ff80
raw: 88007fffa690 ea00018e6120 0002 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 880062a74300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 880062a74380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

880062a74400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

 ^
 880062a74480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 880062a74500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
=

Thanks!




Hi Gustavo,

With your patch I get a different crash. Not sure if it's another bug
or the same one manifesting differently.



That's the same one. It seems that the best solution is to remove the kfree
after the mutex_unlock and let the device resources be freed in
au0828_usb_disconnect.

Please try the following patch instead.

I appreciate your help.

Thank you, Andrey.

---
 drivers/media/usb/au0828/au0828-core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index cd363a2..257ae0d 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -629,7 +629,6 @@ static int au0828_usb_probe(struct usb_interface
*interface,
pr_err("%s() au0282_dev_register failed to register on
V4L2\n",
__func__);
mutex_unlock(>lock);
-   kfree(dev);
goto done;
}

--
2.7.4



au0828: recv_control_msg() Failed receiving control message, error -71.
au0828: recv_control_msg() Failed receiving control message, error -71.
au8522_writereg: writereg error (reg == 0x106, val == 0x0001, ret == -5)
usb 1-1: selecting invalid altsetting 5
au0828: Failure setting usb interface0 to as5
au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
au0828: probe of 1-1:0.0 failed with

Re: [PATCH 1/1] s2255drv: f2255usb: firmware version 1.2.8

2017-11-22 Thread Ben Hutchings 
On Fri, 2017-11-03 at 13:33 -0700, Dean Anderson wrote:
> Updates the firmware for the s2255drv driver.
> Adds support for NTSC4.43, horizontal/vertical adjustments and
> Motion JPEG capture mode improvements.
> 
> Signed-off-by: Dean Anderson 
> ---
>  f2255usb.bin | Bin 180776 -> 181312 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-11-22 Thread Yong 
Hi,

On Wed, 22 Nov 2017 10:45:26 +0100
Maxime Ripard  wrote:

> Hi,
> 
> On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > and CSI1 is used for parallel interface. This is not documented in
> > > > datasheet but by testing and guess.
> > > > 
> > > > This patch implement a v4l2 framework driver for it.
> > > > 
> > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > ISP's support are not included in this patch.
> > > > 
> > > > Signed-off-by: Yong Deng 
> > > 
> > > Thanks again for this driver.
> > > 
> > > It seems like at least this iteration is behaving in a weird way with
> > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > > 
> > > Starting a transfer of multiple frames in either of these formats,
> > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > > 
> > > The panic seems to be generated with random data going into parts of
> > > the kernel memory, the pattern being in my case something like
> > > 0x8287868a which is very odd (always around 0x88)
> > > 
> > > It turns out that when you cover the sensor, the values change to
> > > around 0x28, so it really seems like it's pixels that have been copied
> > > there.
> > > 
> > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > me. Do you have the same issue on your side? Have you been able to
> > > test those formats using your hardware?
> > 
> > I had tested the following formats with BT1120 input:
> > V4L2_PIX_FMT_NV12   -> NV12
> > V4L2_PIX_FMT_NV21   -> NV21
> > V4L2_PIX_FMT_NV16   -> NV16
> > V4L2_PIX_FMT_NV61   -> NV61
> > V4L2_PIX_FMT_YUV420 -> YU12
> > V4L2_PIX_FMT_YVU420 -> YV12
> > V4L2_PIX_FMT_YUV422P-> 422P
> > And they all work fine.
> 
> Ok, that's good to know.
> 
> > > Given that they all are planar formats and YUYV and the likes work
> > > just fine, maybe we can leave them aside for now?
> > 
> > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > is bad? It's really weird.
> > 
> > What's your input bus code format, type and width?
> 
> The sensor is an ov5640, so the MBUS code for the bus is
> MEDIA_BUS_FMT_YUYV8_2X8.

Did you test on V3s?
I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.

The Allwinner CSI's DMA is definitely weird. Ondřej Jirman thought
that CSI has an internal queue (Ondřej's commit has explained in detail).
I think CSI just pick up the buffer address before the frame done 
interrupt triggered. 
The patch in attachment can deal with this. You can see if it is
useful to solve your problem.

Thanks,
Yong


sun6i_csi_fix_writing_to_incorrect_buffer.patch
Description: Binary data

[PATCH V2 22/29] [media] atomisp: deprecate pci_get_bus_and_slot()

2017-11-22 Thread Sinan Kaya 
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Getting ready to remove pci_get_bus_and_slot() function. Since ISP always
uses domain 0, hard-code it in the code when calling the replacement
function pci_get_domain_bus_and_slot().

Signed-off-by: Sinan Kaya 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c   | 2 +-
 drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 663aa91..95b9c7a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1233,7 +1233,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->pdev = dev;
isp->dev = >dev;
isp->sw_contex.power_state = ATOM_ISP_POWER_UP;
-   isp->pci_root = pci_get_bus_and_slot(0, 0);
+   isp->pci_root = pci_get_domain_bus_and_slot(0, 0, 0);
if (!isp->pci_root) {
dev_err(>dev, "Unable to find PCI host\n");
return -ENODEV;
diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c 
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index 4631b1d..51dcef57 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -39,7 +39,7 @@ static inline int platform_is(u8 model)
 
 static int intel_mid_msgbus_init(void)
 {
-   pci_root = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+   pci_root = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
if (!pci_root) {
pr_err("%s: Error: msgbus PCI handle NULL\n", __func__);
return -ENODEV;
-- 
1.9.1

dvbv5-scan: Missing NID, TID, and RID in VDR channel output

2017-11-22 Thread Gregor Jasny 
Hello Mauro and list,

since some days my region in Germany finally got DVB-T2 coverage.
Something in the broadcasted tabled makes w_scan only find a subset each
time. dvbv5-scan is somewhat more reliable.  But with the VDR compatible
channel list exported from dvbv5-scan I cannot make VDR produce any EPG.
>From skimming over the VDR code I think this is due to missing NID and TID.

The upper one is from dvbv5-scan, the lower one from w_scan:

>   VPID
> APID   TPID  CA SID  NID   TIDRID
> arte HD:618000:B8 C999 D999 G19128 I999 M999 S1 T16 Y0   :T:27500 :210
> :220,221   :0:0 :770 :0:0 :0
> arte HD;ARD:618000:B8  D0   G19256   S1 T32 Y0 P0:T:27500 :210=36 
> :220=deu@17,221=fra:230  :0 :770 :8468 :15106 :0

Mauro, do you think it would be possible to parse / output NID, TID, and
RID from dvbv5_scan? It would greatly improve usability. Now that w_scan
is unmaintained, dvb5-scan is the only maintained DVB-T2 scanning app:

https://linuxtv.org/wiki/index.php/Frequency_scan#Comparison_of_DVB_frequency_scanning_commandline_utilities

Thanks,
Gregor

[GIT FIXES FOR v4.15] RC repeat and DVB fix

2017-11-22 Thread Sean Young 
Hi Mauro,

Here are two fixes which would be nice to have in v4.15. I am working on
a better rework of the repeat stuff (including moving cec repeats into
rc-core), but it is far too much change for v4.15 or the stable tree.

Thanks,

Sean

The following changes since commit 30b4e122d71cbec2944a5f8b558b88936ee42f10:

  media: rc: sir_ir: detect presence of port (2017-11-15 08:57:34 -0500)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.15e

for you to fetch changes up to 27a7a06b95cd0995b81915606e832fafca2c92ed:

  media: rc: partial revert of "media: rc: per-protocol repeat period" 
(2017-11-22 18:29:33 +)


Laurent Caumont (1):
  media: dvb: i2c transfers over usb cannot be done from stack

Sean Young (1):
  media: rc: partial revert of "media: rc: per-protocol repeat period"

 drivers/media/rc/rc-main.c| 32 +++
 drivers/media/usb/dvb-usb/dibusb-common.c | 16 ++--
 2 files changed, 30 insertions(+), 18 deletions(-)

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

2017-11-22 Thread Dave Stevenson 
On 21 November 2017 at 20:54, Eric Anholt  wrote:
> Rob Herring  writes:
>
>> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt  wrote:
>>> Dave Stevenson  writes:
>>>
 Hi Rob

 On 27 September 2017 at 22:51, Rob Herring  wrote:
> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
>> Hi Stefan
>>
>> On 22 September 2017 at 07:45, Stefan Wahren  
>> wrote:
>> > Hi Dave,
>> >
>> >> Dave Stevenson  hat am 20. September 
>> >> 2017 um 18:07 geschrieben:
>> >>
>> >>
>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> >> (known as Unicam) on BCM283x SoCs.
>> >>
>> >> Signed-off-by: Dave Stevenson 
>> >> ---
>> >>
>> >> Changes since v2
>> >> - Removed all references to Linux drivers.
>> >> - Reworded section about disabling the firmware driver.
>> >> - Renamed clock from "lp_clock" to "lp" in description and example.
>> >> - Referred to video-interfaces.txt and stated requirements on 
>> >> remote-endpoint
>> >>   and data-lanes.
>> >> - Corrected typo in example from csi to csi1.
>> >> - Removed unnecessary #address-cells and #size-cells in example.
>> >> - Removed setting of status from the example.
>> >>
>> >>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
>> >> ++
>> >>  1 file changed, 85 insertions(+)
>> >>  create mode 100644 
>> >> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>> >>
>> >> diff --git 
>> >> a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
>> >> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>> >> new file mode 100644
>> >> index 000..7714fb3
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>> >> @@ -0,0 +1,85 @@
>> >> +Broadcom BCM283x Camera Interface (Unicam)
>> >> +--
>> >> +
>> >> +The Unicam block on BCM283x SoCs is the receiver for either
>> >> +CSI-2 or CCP2 data from image sensors or similar devices.
>> >> +
>> >> +The main platform using this SoC is the Raspberry Pi family of 
>> >> boards.
>> >> +On the Pi the VideoCore firmware can also control this hardware 
>> >> block,
>> >> +and driving it from two different processors will cause issues.
>> >> +To avoid this, the firmware checks the device tree configuration
>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
>> >> +it will stop the firmware accessing the block, and it can then
>> >> +safely be used via the device tree binding.
>> >> +
>> >> +Required properties:
>> >> +===
>> >> +- compatible : must be "brcm,bcm2835-unicam".
>> >> +- reg: physical base address and length of the 
>> >> register sets for the
>> >> +   device.
>> >> +- interrupts : should contain the IRQ line for this Unicam instance.
>> >> +- clocks : list of clock specifiers, corresponding to entries in
>> >> +   clock-names property.
>> >> +- clock-names: must contain an "lp" entry, matching entries 
>> >> in the
>> >> +   clocks property.
>> >> +
>> >> +Unicam supports a single port node. It should contain one 'port' 
>> >> child node
>> >> +with child 'endpoint' node. Please refer to the bindings defined in
>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> >> +
>> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" 
>> >> properties
>> >> +are mandatory.
>> >> +Data lane reordering is not supported so the data lanes must be in 
>> >> order,
>> >> +starting at 1. The number of data lanes should represent the number 
>> >> of
>> >> +usable lanes for the hardware block. That may be limited by either 
>> >> the SoC or
>> >> +how the platform presents the interface, and the lower value must be 
>> >> used.
>> >> +
>> >> +Lane reordering is not supported on the clock lane either, so the 
>> >> optional
>> >> +property "clock-lane" will implicitly be <0>.
>> >> +Similarly lane inversion is not supported, therefore 
>> >> "lane-polarities" will
>> >> +implicitly be <0 0 0 0 0>.
>> >> +Neither of these values will be checked.
>> >> +
>> >> +Example:
>> >> + csi1: csi1@7e801000 {
>> >> + compatible = "brcm,bcm2835-unicam";
>> >> + reg = <0x7e801000 0x800>,
>> >> +   <0x7e802004 0x4>;
>> >
>> > sorry, i didn't noticed this before. I'm afraid this is using a small 
>> > range of the CMI. Are there

[PATCH] dma-buf: Fix ifnullfree.cocci warnings

2017-11-22 Thread Vasyl Gomonovych 
NULL check before some freeing functions is not needed.
drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing 
debugfs_remove_recursive
Generated by: scripts/coccinelle/free/ifnullfree.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/dma-buf/dma-buf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4a038dcf5361..048827b06c03 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void)
 
 static void dma_buf_uninit_debugfs(void)
 {
-   if (dma_buf_debugfs_dir)
-   debugfs_remove_recursive(dma_buf_debugfs_dir);
+   debugfs_remove_recursive(dma_buf_debugfs_dir);
 }
 #else
 static inline int dma_buf_init_debugfs(void)
-- 
1.9.1

Re: [PATCH] c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

2017-11-22 Thread Gustavo A. R. Silva 


On 11/21/2017 02:22 AM, Patrice CHOTARD wrote:

Hi Gustavo

On 11/20/2017 03:00 PM, Gustavo A. R. Silva wrote:

_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.

This issue was detected with the help of Coccinelle.

Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
Signed-off-by: Gustavo A. R. Silva 
---
   drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index 59280ac..23d0ced 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(unsigned long 
ac8sectpfei)
   static void channel_swdemux_tsklet(unsigned long data)
   {
struct channel_info *channel = (struct channel_info *)data;
-   struct c8sectpfei *fei = channel->fei;
+   struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
if (unlikely(!channel || !channel->irec))
return;
   
+	fei = channel->fei;

+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
   


Acked-by: Patrice Chotard 

Thanks


Thank you, Patrice.

--
Gustavo A. R. Silva

Re: [PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()

2017-11-22 Thread Sinan Kaya 
On 11/22/2017 9:05 AM, Sinan Kaya wrote:
> Hi Alex,

I tried to mean Alan. Sorry about that. 

Apparently, I didn't have enough coffee this morning. I shouldn't touch the
code for a few hours.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()

2017-11-22 Thread Sinan Kaya 
Hi Alex,

On 11/22/2017 7:20 AM, Alan Cox wrote:
> On Wed, 2017-11-22 at 00:31 -0500, Sinan Kaya wrote:
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0
>> as
>> where a PCI device is present. This restricts the device drivers to
>> be
>> reused for other domain numbers.
> 
> The ISP v2 will always been in domain 0.
> 

Sorry, I didn't get what you mean. Do you mean that you are OK with the
change (thus, can I get a reviewed by) or do you mean that I should fix
the commit message?

I wrote a generic commit message and applied it to all 30 patches that
are more or less similar. I can certainly tailor the message a little
bit for atomisp since you confirmed domain 0.

> Alan
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: media: coda: sources of coda_regs.h?

2017-11-22 Thread Martin Kepplinger 

Am 22.11.2017 11:40 schrieb Philipp Zabel:

Hi Martin,

On Thu, 2017-11-09 at 23:14 +0100, Martin Kepplinger wrote:

Hi Philipp,

As I'm reading up on the coda driver a little, I can't seem to find 
the
vendor's sources for the coda_regs.h definitions. Could you point me 
to

them?


I don't know for sure what information Javier based the CodaDx6 
register

names on, but I assume that he used the old LGPLed i.MX VPU libraries
that Freescale once distributed. At least that's what I looked at for
the CODA960 additions: The BSP "L3.0.35_12.09.01.01_GA_source.tar.gz"
contained a tarball "pkgs/imx-lib-12.09.01.tar.gz" with a header file
"imx-lib-12.09.01/vpu/vpu_reg.h" inside. I believe the current BSP
versions distributed by NXP do not include this library anymore.


Great! Thanks for the details.

Re: [PATCH] media: coda: fix comparision of decoded frames' indexes

2017-11-22 Thread Philipp Zabel 
Hi Martin,

On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote:
> At this point the driver looks the currently decoded frame's index
> and compares is to VPU-specific state values. Directly before this
> if and else statements the indexes are read (index for decoded and
> for displayed frame).
> 
> Now what is saved in ctx->display_idx is an older value at this point!

Yes. The rotator that copies out the decoded frame runs in parallel with
the decoding of the next frame. So the decoder signals with display_idx
which decoded frame should be presented next, but it is only copied out
into the vb2 buffer during the following run. The same happens with the
VDOA, but manually, in prepare_decode.

That means that at this point display_idx is the index of the previously
decoded internal frame that should be presented next, and ctx-
>display_idx is the index of the internal frame that was just copied
into the externally visible vb2 buffer.

The logic reads someting like this:

if (no frame was decoded) {
if (a frame will be copied out next time) {
adapt sequence number offset;
} else if (no frame was copied out this time) {
hold until further input;
}
}

Basically, it will just wait one more run until it stops the stream,
assuming that there is really nothing useful in the bitstream
ringbuffer.

> During these index checks, the current values apply, so fix this by
> taking display_idx instead of ctx->display_idx.

display_idx is already checked later in the same function.
According to the i.MX6 VPU API document, it can be -2 (never seen) or -3
during sequence start (if there is frame reordering, depending on
whether decoder skip is enabled), and I think I've seen -3 as prescan
failure on i.MX5. -1 means EOS according to that document, that's why we
always hold in that case.

> ctx->display_idx is updated later in the same function.
> 
> Signed-off-by: Martin Kepplinger 
> ---
> 
> Please review this thoroughly, but in case I am wrong here, this is
> at least very strange to read and *should* be accompanied with a
> comment about what's going on with that index value!

Maybe it would be less confusing to move this into the display_idx checks 
below, given that we already hold unconditionally
on display_idx == -1.

> I don't think it matter that much here because at least playing h264
> worked before and works with this change, but I've tested it anyways.

I think this shouldn't happen at all if you feed it a well formed h.264
stream. But if you have a skip because of broken data while there is
still no display frame at the beginning of the stream or after an IDR,
this might be hit.

regards
Philipp

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-11-22 Thread Geert Uytterhoeven 
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro
 wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()

2017-11-22 Thread Alan Cox 
On Wed, 2017-11-22 at 00:31 -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0
> as
> where a PCI device is present. This restricts the device drivers to
> be
> reused for other domain numbers.

The ISP v2 will always been in domain 0.

Alan

Re: media: coda: sources of coda_regs.h?

2017-11-22 Thread Philipp Zabel 
Hi Martin,

On Thu, 2017-11-09 at 23:14 +0100, Martin Kepplinger wrote:
> Hi Philipp,
> 
> As I'm reading up on the coda driver a little, I can't seem to find the
> vendor's sources for the coda_regs.h definitions. Could you point me to
> them?

I don't know for sure what information Javier based the CodaDx6 register
names on, but I assume that he used the old LGPLed i.MX VPU libraries
that Freescale once distributed. At least that's what I looked at for
the CODA960 additions: The BSP "L3.0.35_12.09.01.01_GA_source.tar.gz"
contained a tarball "pkgs/imx-lib-12.09.01.tar.gz" with a header file
"imx-lib-12.09.01/vpu/vpu_reg.h" inside. I believe the current BSP
versions distributed by NXP do not include this library anymore.

regards
Philipp

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-11-22 Thread Maxime Ripard 
Hi,

On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > > 
> > > This patch implement a v4l2 framework driver for it.
> > > 
> > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > ISP's support are not included in this patch.
> > > 
> > > Signed-off-by: Yong Deng 
> > 
> > Thanks again for this driver.
> > 
> > It seems like at least this iteration is behaving in a weird way with
> > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > 
> > Starting a transfer of multiple frames in either of these formats,
> > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > 
> > The panic seems to be generated with random data going into parts of
> > the kernel memory, the pattern being in my case something like
> > 0x8287868a which is very odd (always around 0x88)
> > 
> > It turns out that when you cover the sensor, the values change to
> > around 0x28, so it really seems like it's pixels that have been copied
> > there.
> > 
> > I've looked quickly at the DMA setup, and it seems reasonable to
> > me. Do you have the same issue on your side? Have you been able to
> > test those formats using your hardware?
> 
> I had tested the following formats with BT1120 input:
> V4L2_PIX_FMT_NV12 -> NV12
> V4L2_PIX_FMT_NV21 -> NV21
> V4L2_PIX_FMT_NV16 -> NV16
> V4L2_PIX_FMT_NV61 -> NV61
> V4L2_PIX_FMT_YUV420   -> YU12
> V4L2_PIX_FMT_YVU420   -> YV12
> V4L2_PIX_FMT_YUV422P  -> 422P
> And they all work fine.

Ok, that's good to know.

> > Given that they all are planar formats and YUYV and the likes work
> > just fine, maybe we can leave them aside for now?
> 
> V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> is bad? It's really weird.
> 
> What's your input bus code format, type and width?

The sensor is an ov5640, so the MBUS code for the bus is
MEDIA_BUS_FMT_YUYV8_2X8.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] cec: disable the hardware when unregistered

2017-11-22 Thread Hans Verkuil 
When the device is being unregistered disable the hardware, don't wait
until cec_delete_adapter is called as the hardware may have disappeared by
then. This would be the case for hotplugable devices.

Signed-off-by: Hans Verkuil 
Reported-by: Bård Eirik Winther 
Tested-by: Bård Eirik Winther 
---
 drivers/media/cec/cec-api.c  | 11 ---
 drivers/media/cec/cec-core.c | 15 +--
 include/media/cec.h  | 12 
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..766b16e60c3b 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -45,12 +45,11 @@ static inline struct cec_devnode *cec_devnode_data(struct 
file *filp)
 static unsigned int cec_poll(struct file *filp,
 struct poll_table_struct *poll)
 {
-   struct cec_devnode *devnode = cec_devnode_data(filp);
struct cec_fh *fh = filp->private_data;
struct cec_adapter *adap = fh->adap;
unsigned int res = 0;

-   if (!devnode->registered)
+   if (!cec_is_registered(adap))
return POLLERR | POLLHUP;
mutex_lock(>lock);
if (adap->is_configured &&
@@ -474,13 +473,12 @@ static long cec_s_mode(struct cec_adapter *adap, struct 
cec_fh *fh,

 static long cec_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
-   struct cec_devnode *devnode = cec_devnode_data(filp);
struct cec_fh *fh = filp->private_data;
struct cec_adapter *adap = fh->adap;
bool block = !(filp->f_flags & O_NONBLOCK);
void __user *parg = (void __user *)arg;

-   if (!devnode->registered)
+   if (!cec_is_registered(adap))
return -ENODEV;

switch (cmd) {
@@ -604,9 +602,8 @@ static int cec_release(struct inode *inode, struct file 
*filp)

mutex_lock(>lock);
list_del(>list);
-   if (list_empty(>fhs) &&
-   !adap->needs_hpd &&
-   adap->phys_addr == CEC_PHYS_ADDR_INVALID) {
+   if (cec_is_registered(adap) && list_empty(>fhs) &&
+   !adap->needs_hpd && adap->phys_addr == CEC_PHYS_ADDR_INVALID) {
WARN_ON(adap->ops->adap_enable(adap, false));
}
mutex_unlock(>lock);
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 648136e552d5..a56171d4d072 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -164,8 +164,9 @@ static int __must_check cec_devnode_register(struct 
cec_devnode *devnode,
  * This function can safely be called if the device node has never been
  * registered or has already been unregistered.
  */
-static void cec_devnode_unregister(struct cec_devnode *devnode)
+static void cec_devnode_unregister(struct cec_adapter *adap)
 {
+   struct cec_devnode *devnode = >devnode;
struct cec_fh *fh;

mutex_lock(>lock);
@@ -183,6 +184,11 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
devnode->unregistered = true;
mutex_unlock(>lock);

+   mutex_lock(>lock);
+   __cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+   __cec_s_log_addrs(adap, NULL, false);
+   mutex_unlock(>lock);
+
cdev_device_del(>cdev, >dev);
put_device(>dev);
 }
@@ -196,7 +202,7 @@ static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
 void cec_register_cec_notifier(struct cec_adapter *adap,
   struct cec_notifier *notifier)
 {
-   if (WARN_ON(!adap->devnode.registered))
+   if (WARN_ON(!cec_is_registered(adap)))
return;

adap->notifier = notifier;
@@ -374,7 +380,7 @@ void cec_unregister_adapter(struct cec_adapter *adap)
if (adap->notifier)
cec_notifier_unregister(adap->notifier);
 #endif
-   cec_devnode_unregister(>devnode);
+   cec_devnode_unregister(adap);
 }
 EXPORT_SYMBOL_GPL(cec_unregister_adapter);

@@ -382,9 +388,6 @@ void cec_delete_adapter(struct cec_adapter *adap)
 {
if (IS_ERR_OR_NULL(adap))
return;
-   mutex_lock(>lock);
-   __cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
-   mutex_unlock(>lock);
kthread_stop(adap->kthread);
if (adap->kthread_config)
kthread_stop(adap->kthread_config);
diff --git a/include/media/cec.h b/include/media/cec.h
index df6b3bd31284..c3cb1af3ccc0 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -229,6 +229,18 @@ static inline bool cec_is_sink(const struct cec_adapter 
*adap)
return adap->phys_addr == 0;
 }

+/**
+ * cec_is_registered() - is the CEC adapter registered?
+ *
+ * @adap:  the CEC adapter, may be NULL.
+ *
+ * Return: true if the adapter is registered, false otherwise.
+ */
+static inline bool cec_is_registered(const struct cec_adapter *adap)
+{
+   return adap && adap->devnode.registered;
+}
+