Hi Jim,
On Friday 14 Jul 2017 09:58:11 Jim Lin wrote:
> On 2017年07月11日 03:47, Laurent Pinchart wrote:
> > On Monday 10 Jul 2017 14:43:49 Jim Lin wrote:
> >> Section 9.2.6.4 of USB 2.0/3.x specification describes that
> >> "device must be able to return the first data packet to host within
> >> 500
On 14/07/17 00:31, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Thursday 13 Jul 2017 18:49:19 Kieran Bingham wrote:
>> On 26/06/17 19:12, Laurent Pinchart wrote:
>>> New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
>>> as well as a new VSP2-D variant on V3M and V3H SoCs. Add
The vimc platform drivers define a platform device ID table but these
are not set to the .id_table field in the platform driver structure.
So the platform device ID table is only used to fill the aliases in
the module but are not used for matching (works because the platform
subsystem fallbacks to
On Thu, Jul 13, 2017 at 5:47 PM, Javier Martinez Canillas
wrote:
> On Thu, Jul 13, 2017 at 5:38 PM, Sakari Ailus wrote:
[snip]
>>
>> Shouldn't these be set to the corresponding driver structs' id_table
>> fields? Or do I miss something...?
>>
>
> Agreed, the real problem is that the .id_table i
This series should shut up all warnings introduced by gcc-6 or gcc-7 on
today's linux-next, as observed in "allmodconfig" builds on x86,
arm and arm64.
I have sent some of these before, but some others are new, as I had
at some point disabled the -Wint-in-bool-context warning in my
randconfig test
gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
operand in ?: will always be 'true', suggest explicit middle operand
[-Werror=parenthes
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ata/libata-core.c: In function 'ata_timing_quantize':
drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest
'&&' instead [-Wint-in-bool-context]
This slightly rearranges the macro to simpli
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ide/ide-timings.c: In function 'ide_timing_quantize':
drivers/ide/ide-timings.c:112:24: error: '*' in boolean context, suggest '&&'
instead [-Werror=int-in-bool-context]
q->setup = EZ(t->setup * 1000, T);
We test whether a bit is set in a mask here, which is correct
but gcc warns about it as it thinks it might be confusing:
drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in
boolean context, the expression will always evaluate to 'true'
[-Werror=int-in-bool-context]
Thi
gcc warns when MODULES_VADDR/END is defined to the same value as
VMALLOC_START/VMALLOC_END, e.g. on x86-32:
fs/proc/kcore.c: In function ‘add_modules_range’:
fs/proc/kcore.c:622:161: error: self-comparison always evaluates to false
[-Werror=tautological-compare]
if (/*MODULES_VADDR != VMALLOC_S
FIFO_MODE is an macro expression with a '<<' operator, which
gcc points out could be misread as a '<':
drivers/input/misc/adxl34x.c: In function 'adxl34x_probe':
drivers/input/misc/adxl34x.c:799:36: error: '<<' in boolean context, did you
mean '<' ? [-Werror=int-in-bool-context]
This converts th
The setsign() macro gets called with an integer argument in a
few places, leading to a harmless warning in gcc-7:
arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in
boolean context [-Werror=int-in-bool-context]
This
In some configurations, topology_physical_package_id() is trivially
defined as '-1' for any input, resulting a comparison that is
always true:
drivers/acpi/processor_thermal.c: In function ‘cpufreq_set_cur_state’:
drivers/acpi/processor_thermal.c:137:36: error: self-comparison always
evaluates to
With ccache in combination with gcc-6, we get a harmless warning for the sfi
subsystem,
as ccache only sees the preprocessed source:
drivers/sfi/sfi_core.c: In function ‘sfi_map_table’:
drivers/sfi/sfi_core.c:175:53: error: self-comparison always evaluates to true
[-Werror=tautological-compare]
gcc-7 points out an older regression:
drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context,
did you mean '<' ? [-Werror=int-in-bool-context]
The original code had 'unsigned short' here, but incorr
When we pass the result of a multiplication as the timeout, we
can get a warning:
drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest '&&'
instead [-Werror=int-in-bool-context]
drivers/mfd/arizona-core.c:247:195: error: '*' in boolean context, suggest '&&'
instead [-Werror
gcc thinks that interpreting a multiplication result as a bool
is confusing:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean
context, suggest '&&' instead [-Werror=int-in-bool-context]
In this i
When using ccache, we get a harmless warning about the fact that
we use the result of a multiplication as a condition:
drivers/infiniband/core/uverbs_main.c: In function 'ib_uverbs_write':
drivers/infiniband/core/uverbs_main.c:787:40: error: '*' in boolean context,
suggest '&&' instead [-Werror=i
v4l2_subdev_call is a macro returning whatever the callback return
type is, usually 'int'. With gcc-7 and ccache, this can lead to
many wanings like:
media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate':
media/platform/pxa_camera.c:766:27: error: ?: using integer constants in
bool
On Fri, Jul 14, 2017 at 11:31:04AM +0200, Arnd Bergmann wrote:
> When using ccache, we get a harmless warning about the fact that
> we use the result of a multiplication as a condition:
>
> drivers/infiniband/core/uverbs_main.c: In function 'ib_uverbs_write':
> drivers/infiniband/core/uverbs_main.c
On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
> When we pass the result of a multiplication as the timeout, we
> can get a warning:
>
> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
> '&&' instead [-Werror=int-in-bool-context]
> drivers/mfd/arizona-core.c:24
On Fri, 14 Jul 2017, Arnd Bergmann wrote:
> gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
> operand in ?: will always be 'true',
On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
> We test whether a bit is set in a mask here, which is correct
> but gcc warns about it as it thinks it might be confusing:
>
> drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in
> boolean context, the expression
On Fri, Jul 14, 2017 at 11:55 AM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
>> When we pass the result of a multiplication as the timeout, we
>> can get a warning:
>>
>> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
>> '&&' instead [
On Fri, Jul 14, 2017 at 11:25:12AM +0200, Arnd Bergmann wrote:
> This series should shut up all warnings introduced by gcc-6 or gcc-7 on
> today's linux-next, as observed in "allmodconfig" builds on x86,
> arm and arm64.
>
> I have sent some of these before, but some others are new, as I had
> at
On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
>> We test whether a bit is set in a mask here, which is correct
>> but gcc warns about it as it thinks it might be confusing:
>>
>> drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: usi
Hi Chiranjeevi,
On Thu, Jul 13, 2017 at 06:51:27PM -0700, Chiranjeevi Rapolu wrote:
> Provides single source pad with up to 2592x1944 pixels at 10-bit raw
> bayer format over MIPI CSI2 two lanes at 840Mbps/lane.
> The driver supports following features:
> - up to 30fps at 5M pixels
> - manual exp
Changing:
- if (!frob()) {
+ if (frob() == 0) {
is a totally pointless change. They're both bad, because they're doing
success testing instead of failure testing, but probably the second one
is slightly worse.
This warning seems dumb. I can't imagine it has even a 10% success rate
at finding r
gcc-7 notices that we copy a fixed length string into another
string of the same size, with additional characters:
drivers/media/usb/usbvision/usbvision-i2c.c: In function
'usbvision_i2c_register':
drivers/media/usb/usbvision/usbvision-i2c.c:190:36: error: '%d' directive
writing between 1 and 11
On Fri, Jul 14, 2017 at 2:05 PM, Dan Carpenter wrote:
> Changing:
>
> - if (!frob()) {
> + if (frob() == 0) {
>
> is a totally pointless change. They're both bad, because they're doing
> success testing instead of failure testing, but probably the second one
> is slightly worse.
>
> This warning
On 14 July 2017 at 10:25, Arnd Bergmann wrote:
> gcc warns when MODULES_VADDR/END is defined to the same value as
> VMALLOC_START/VMALLOC_END, e.g. on x86-32:
>
> fs/proc/kcore.c: In function ‘add_modules_range’:
> fs/proc/kcore.c:622:161: error: self-comparison always evaluates to false
> [-Werr
On Fri, Jul 14, 2017 at 11:36:56AM +0200, Arnd Bergmann wrote:
> @@ -1158,7 +1158,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
>*/
> fmt_src.pad = pad->index;
> fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> - if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL,
Ah... I see why it's complaining about these ones in particular...
I don't agree with it as a static analysis dev, and I don't like the
changes too much. But since it's only generating a hand full of
warnings then I don't care.
regards,
dan carpenter
On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
> I don't agree with it as a static analysis dev...
What I mean is if it's a macro that returns -ENODEV or a function that
returns -ENODEV, they should both be treated the same. The other
warnings this check prints are quite clever.
On Mon, Jul 10, 2017 at 04:46:52PM +0100, Jose Abreu wrote:
> Document the bindings for the Synopsys Designware HDMI RX.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Mauro Carvalho Chehab
> Cc: Hans Verkuil
> Cc: Sylwester Nawrocki
> Cc: dev
Hi,
Thanks for the patch
On 2017-07-14 05:58 AM, Javier Martinez Canillas wrote:
The vimc platform drivers define a platform device ID table but these
are not set to the .id_table field in the platform driver structure.
So the platform device ID table is only used to fill the aliases in
the mo
Some updates and initial improvements for the VSP1 partition algorithm that
remove redundant processing and variables, reducing the processing done in
interrupt context slightly.
Patches 1, 2 and 3 clean up the calculation of the partition windows such that
they are only calculated once at streamo
Separate the code change from the function move so that code changes can
be clearly identified. This commit has no functional change.
The partition algorithm functions will be changed, and
vsp1_video_pipeline_setup_partitions() will call vsp1_video_partition().
To prepare for that, move the functi
The vsp1_pipe object context variables for div_size and
current_partition allowed state to be maintained through processing the
partitions during processing.
Now that the partition tables are calculated during stream on, there is
no requirement to store these variables in the pipe object.
Utilise
Previously the active window and partition sizes for each partition were
calculated for each partition every frame. This data is constant and
only needs to be calculated once at the start of the stream.
Extend the vsp1_pipe object to dynamically store the number of partitions
required and pre-calc
As we develop the partition algorithm, we need to store more information
per partition to describe the phase and other parameters.
To keep this data together, further abstract the existing v4l2_rect
into a partition specific structure
When generating the partition windows, operate directly on the
Provide register definitions required for UDS phase and partition
algorithm support.
These registers are applicable to Gen3 hardware only.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_regs.h | 14 ++
1 file changed, 14 insertions(
The configuration of the pipeline and entities directly affects the
inputs required to each entity for the partition algorithm. Thus it
makes sense to involve those entities in the decision making process.
Extend the entity ops API to provide an optional '.partition' operation.
This allows entitie
Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.
Reduce TLB pressure on the IPMMUs by allocating mult
Adapt the dl->body0 object to use an object from the fragment pool.
This greatly reduces the pressure on the TLB for IPMMU use cases, as
all of the lists use a single allocation for the main body
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 68 +++
Fragments are no longer 'freed' in interrupt context, but instead released back
to their respective pools.
This allows us to remove the garbage collector in the DLM.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 151 ++-
1 file changed, 14 ins
Adapt the LUT to allocate a fragment pool for passing the table updates
to hardware.
Two bodies are pre-allocated in the pool to manage a userspace update
before the hardware has taken a previous set of tables.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_lut.c | 23 ++
Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.
We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a
Adapt the CLU to allocate a fragment pool for passing the table updates
to hardware.
Two bodies are pre-allocated in the pool to manage a userspace update
before the hardware has taken a previous set of tables.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_clu.c | 18 ++
The fragment write function relies on the code never asking it to
write more than the entries available in the list.
Currently with each list body containing 256 entries, this is fine,
but we can reduce this number greatly saving memory.
In preparation of this - add a level of protection to catch
Hi Niklas
On 13/07/17 07:28, Niklas Söderlund wrote:
>
> Hi Kieran,
>
> Thanks for your hard work.
And thank you for your support!
> On 2017-07-06 12:01:16 +0100, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Provide support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
NAK. This takes unintentionally insane code and turns it intentionally
insane. Any non-zero return is considered an error.
The right f
On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
wrote:
>
> NAK. This takes unintentionally insane code and turns it intentionally
> insane. Any non-zero return is considered an error.
>
> The right fix is almost certainly to just return -EINVAL unconditionally.
Btw, this is why I hate compiler w
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> FIFO_MODE is an macro expression with a '<<' operator, which
> gcc points out could be misread as a '<':
Yeah, no, NAK again.
We don't make the code look worse just because gcc is being a f*cking
moron about things.
This warning is clearly
On Fri, Jul 14, 2017 at 3:09 PM, Dan Carpenter wrote:
> On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
>> I don't agree with it as a static analysis dev...
>
> What I mean is if it's a macro that returns -ENODEV or a function that
> returns -ENODEV, they should both be treated the
Some USB webcam controllers have extension unit controls that report
different lengths via GET_LEN, depending on internal state. Add a flag
to mark these controls as variable length and issue GET_LEN before
GET/SET_CUR transfers to verify the current length.
Signed-off-by: Philipp Zabel
---
driv
The extension unit controls with selectors 11 and 12 are used to make the
eSP770u webcam controller issue SPI transfers to configure the nRF51288
radio or to read the flash storage. Depending on internal state controlled
by selector 11, selector 12 reports different lengths.
Signed-off-by: Philipp
The Oculus Rift Sensors (DK2 and CV1) allow to configure their sensor chips
directly via I2C commands using extension unit controls. The processing and
camera unit controls do not function at all.
Signed-off-by: Philipp Zabel
---
drivers/media/usb/uvc/uvc_ctrl.c | 14 ++
1 file chang
On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds
wrote:
> On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
>> FIFO_MODE is an macro expression with a '<<' operator, which
>> gcc points out could be misread as a '<':
>
> Yeah, no, NAK again.
>
> We don't make the code look worse just because g
On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds
wrote:
> On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
> wrote:
>>
>> NAK. This takes unintentionally insane code and turns it intentionally
>> insane. Any non-zero return is considered an error.
>>
>> The right fix is almost certainly to just re
From: Daniel Scheller
While cab_state->state gives a quite accurate indication of the demod
signal status, it might be incorrect if cab_algo() wasn't able to
determine the exact status, with cab_algo() being the only place where
this status was updated from, and it is only called upon tuning to n
On Fri, Jul 14, 2017 at 10:17:10PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds
> wrote:
> > On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> >> FIFO_MODE is an macro expression with a '<<' operator, which
> >> gcc points out could be misread as a '<':
> >
On Fri, Jul 14, 2017 at 08:56:11AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > The patches work fine on N9.
> > >
> > > I was able to fix the userspace, and they work for me, too. For both:
> > >
> > > Acked-by: Pavel Machek
> > > Tested-by: Pavel Machek
> >
> > Thanks! I've applied these on c
On Fri, Jul 14, 2017 at 10:58:39AM +0200, Javier Martinez Canillas wrote:
> The vimc platform drivers define a platform device ID table but these
> are not set to the .id_table field in the platform driver structure.
>
> So the platform device ID table is only used to fill the aliases in
> the mod
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: Sat Jul 15 05:00:21 CEST 2017
media-tree git hash:2748e76ddb2967c4030171342ebdd3faa6a5e8e8
media_build gi
On Fri, Jul 14, 2017 at 12:37:05PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote:
> > On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
> >> We test whether a bit is set in a mask here, which is correct
> >> but gcc warns about it as it thinks it might be
66 matches
Mail list logo
