Get rid of using ops->info.type defined on DVB drivers,
as it doesn't apply anymore.
Currently, one driver (cxd2820) supports more than one different
info.type, as it can be used for DVB-T/T2 and DVB-C. There are more
drivers like that to come. So, the same frontend will have
different DVBv3 types, depending on the current delivery system.
This breaks the existing logic at dvb_frontend, that assumes that
just one delivery system DVBv3 type is supported by all delsys.
In order to easy the DVBv3->DVBv5 conversion, an ancillary function
that maps DVBv3 delivery systems into DVBv5 were added.
Also, on all places, except for the event logic, the DVBv5 cache
will be used to check parameters, instead of the DVBv5 copy.
This patch simplifies the cache sync logic, and warrants that the
cache will be in a clear state at DVB frontend register. This way,
ops->info.type will be filled to reflect the first delivery system,
providing backward compatibility support for it.
For example, in the cases like cxd2820, where the delivery systems
are defined as:
.delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A },
A pure DVBv3 will be able to use both DVB-T and DVB-T2, as, at
DVB cache clear, the ops->info.type will be equal to FE_OFDM.
However, DVB-C won't be visible. A quick workaround would be to
do a DVBv5 call to set the delivery system to SYS_DVBC_ANNEX_A.
After such call, ops->info.type will be equal to FE_QAM, and a
DVBv3 application will see the frontend as a DVB-C one.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change is there in order to prepare the code to avoid calling
dvb_frontend_ioctl_legacy() from FE_SET_PROPERTY.
A call to dvb_frontend_ioctl_legacy() would require to update the
DVBv3 cache without need, mangling calls for newer delivery system
without any reason.
No functional changes here.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to DVB-T2, several new possible values for bandwidth were added.
As the DVBv3 struct were updated to handle them, the core needs to
handle all of them, as a DVBv3 application might try to use it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By default, initialize the frontend current delivery system with
the first one. This warrants that a DVBv3 application will be able
to tune to it, after the removal of ops->init.type filling at
the drivers.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts commit 93b2ec0128.
The call to "schedule_work()" in rtc_initialize_alarm() happens too
early, and can cause oopses at bootup
Neil Brown explains why we do it:
"If you set an alarm in the future, then shutdown and boot again after
that time, then you will end up with a timer_queue node which is in
the past.
When this happens the queue gets stuck. That entry-in-the-past won't
get removed until and interrupt happens and an interrupt won't happen
because the RTC only triggers an interrupt when the alarm is "now".
So you'll find that e.g. "hwclock" will always tell you that
'select' timed out.
So we force the interrupt work to happen at the start just in case."
and has a patch that convert it to do things in-process rather than with
the worker thread, but right now it's too late to play around with this,
so we just revert the patch that caused problems for now.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Requested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Requested-by: John Stultz <john.stultz@linaro.org>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit c0afabd3d5.
It causes failures on Toshiba laptops - instead of disabling the alarm,
it actually seems to enable it on the affected laptops, resulting in
(for example) the laptop powering on automatically five minutes after
shutdown.
There's a patch for it that appears to work for at least some people,
but it's too late to play around with this, so revert for now and try
again in the next merge window.
See for example
http://bugs.debian.org/652869
Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500)
Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr> (Toshiba Portege R830)
Cc: Jonathan Nieder <jrnieder@gmail.com>
Requested-by: John Stultz <john.stultz@linaro.org>
Cc: stable@kernel.org # for the versions that applied this
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If 'iw connect' command is fired when driver is already busy in
serving 'iw scan' command, ssid specific scan operation for connect
is skipped. In this case cmd wait queue handler gets called with no
command in queue (i.e. adapter->cmd_queued = NULL).
This patch adds a NULL check in mwifiex_wait_queue_complete()
routine to fix crash observed during simultaneous scan and assoc
operations.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes the regression, introduced by
commit 17030f48e3
From: Rafał Miłecki <zajec5@gmail.com>
Date: Thu, 11 Aug 2011 17:16:27 +0200
Subject: [PATCH] b43: support new RX header, noticed to be used in 598.314+ fw
in PIO case.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If one only selects mx23-based boards, compile fails:
drivers/net/ethernet/freescale/fec.c:410:2: error: 'FEC_HASH_TABLE_HIGH' undeclared (first use in this function)
drivers/net/ethernet/freescale/fec.c:411:2: error: 'FEC_HASH_TABLE_LOW' undeclared (first use in this function)
This is because fec.h uses CONFIG_SOC_IMX28 to determine the register
layout of the core which makes sense since the MX23 does not have a fec.
However, Kconfig uses the broader ARCH_MXS symbol and this way even
makes the fec-driver default for MX23. Adapt Kconfig to use the more
precise SOC_IMX28 as well.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
netfilter: ctnetlink: fix timeout calculation
ipvs: try also real server with port 0 in backup server
skge: restore rx multicast filter on resume and after config changes
mlx4_en: nullify cq->vector field when closing completion queue
The current gspca core code has a regression where it no longer properly
falls back to lower alt settings when there is not enough bandwidth.
This causes many iso based usb-1 cameras to not work when plugged into a
usb2 hub or a sandybridge chipset motherboard!
This patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A few drivers don't have .delsys. Add it, in order to allow
future patches for dvb_frontend.c to not use info.type.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just like set_frontend, use the dvb cache properties for get_frontend.
This is more consistent, as both functions are now symetric. Also,
at the places get_frontend is called, it makes sense to update the
cache.
Most of this patch were generated by this small perl script:
while (<>) { $file .= $_; }
if ($file =~ m/\.get_frontend\s*=\s*([\d\w_]+)/) {
my $get = $1;
$file =~ s/($get)(\s*\([^\,\)]+)\,\s*struct\s+dtv_frontend_properties\s*\*\s*([_\d\w]+)\)\s*\{/\1\2)\n{\n\tstruct dtv_frontend_properties *\3 = &fe->dtv_property_cache;/g;
}
print $file;
Of course, the changes at dvb_frontend.[ch] were made by hand,
as well as the changes on a few other places, where get_frontend()
is called internally inside the driver.
On some places, get_frontend() were just a void function. Those
occurrences were removed, as the DVB core handles such cases.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On several places inside dvb_frontend, only the DVBv3 parameters
were updated. Change it to be sure that, on all places, the DVBv5
parameters will be changed instead.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that all frontends are implementing DVBv5, don't export the
DVBv3 specific stuff to the drivers. Only the core should be
aware of that, as it will keep providing DVBv3 backward compatibility.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that everybody is talking DVBv5 API dialect, using this
DVBv3 macro internally is not ok.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This callback is not used anywhere. Maybe it were used in the
past to optimize the custom algo, but, as it is not used anymore,
let's just remove it.
If later needed, some patch may re-add it with a proper
implementation.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just like the other DVB algorithms, drivers should use the DVBv5
way to retrieve parameters: via the cache struct.
Actually, several drivers were partially using the DVBv3 struct
and partially using the DVBv5 way, with is confusing and may
lead into troubles.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As all parameters are passed via DVBv5 to the frontends, there's
no need to pass them again via fops. Also, most drivers weren't using
it anyway. So, instead, just pass a parameter to indicate if the
hardware algorithm wants the driver to re-tune or not.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the past, dvb_frontent_parameters were passed inside the
struct where get_tuner_settings should store their result.
This is not needed anymore, as all parameters needed are stored
already at the fe property cache. So, use it, where needed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that the DVB ops struct contains the supported delivery
systems, use it, instead of adding a get_property() callback
just due to that.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Actually, this driver needs to fill/use the ISDB-T proprieties.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's no need to initialize unused fields with zero, as Kernel does
it automatically.
Removing the initialization makes the code cleaner.
This also allows the removal of the unused pll_set callback.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver only uses the DVBv5 struct. All it needs is to remove
the non-used params var, and to add the ISDB-T to the delivery
systems.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dib9000 is almost ok, with regards to the usage of DVBv5 parameters.
It has just a few stuff using the old way, at set_frontend.
Replace them by the DVBv5 way, and add the delivery system.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is one of the first drivers using DVBv5. It relies only
on DVBv5 way, but still it contains some stub for unused
methods. Remove them, add the delivery system and do some
trivial cleanups.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is one of the cases where the frontend changes is required:
while this device lies to applications that it is a DVB-T, it is,
in fact, a frontend for CTTB delivery system. So, the information
provided for a DVBv3 application should be different than the one
provided to a DVBv5 application.
So, fill delsys with the CTTB delivery system, and use the new
way. there aren't many changes here, as everything on this driver
is on auto mode, probably because of the lack of a proper API
for this delivery system.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Creates a DVBv5 get_frontend call, renaming the DVBv3 one to
get_frontend_legacy(), while not all frontends are converted.
After the conversion for all drivers, get_frontend_legacy()
will be removed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Passing DVBv3 parameters to set_frontend is not fun, as the
core doesn't have any way to know if the driver is using the
v3 or v5 parameters. So, rename the callback and add a new
one to allow distinguish between a mixed v3/v5 paramenter call
from a pure v5 call.
After having all frontends to use the new way, the legacy
call can be removed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The dvb were originally written for DVB-T/C/S and ATSC. So,
the original frontend struct has fields to describe only those three
standards.
While 2nd gen standards are similar to these, new standards
like DSS, ISDB and CTTB don't fit on any of the above types.
While there's a way for the drivers to explicitly change whatever
default DELSYS were filled inside the core, still a fake value is
needed there, and a "compat" code to allow DVBv3 applications to
work with those delivery systems is needed. This is good for a
short term solution, while applications aren't using DVBv5 directly.
However, at long term, this is bad, as the compat code runs even
if the application is using DVBv5. Also, the compat code is not
perfect, and only works when the frontend is capable of auto-detecting
the parameters that aren't visible by the faked delivery systems.
So, let the frontend fill the supported delivery systems at the
device properties directly.
The future plan is that the drivers will stop filling ops->info.type,
filling, instead, ops->delsys. This will allow multi-frontend
devices like drx-k to use just one frontend structure for all supported
delivery systems.
Of course, the core will keep using it, in order to keep allowing
DVBv3 calls.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a big patch, yet trivial: now that all tuners use the DVBv5
way to pass parameters (e. g. via fe->dtv_property_cache), the
extra parameter can be removed from set_params() call.
After this change, very few DVBv3 specific stuff are left at the
tuners.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The calc_regs() callback is used by a few frontends (mt352, nxt200x,
digitv and zl10353). On all places it is called, the parameters are
set by DVBv5 way. So, just use the DVBv5 struct and remove the
extra parameter.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Despite its name, tuner-simple has a complex logic to set freqs ;)
Basically, it can be called by two different ways: via set_params()
or via calc_regs() callbacks. Both are bound to the DVBv3 API.
Also, set_params internally calls calc_regs().
In order to get rid of DVBv3 params at set_params(), it shouldn't
call calc_regs() anymore. The code duplication is very small,
as most of the code there is just to check for invalid parameters.
With regards to calc_regs(), it should still trust on bandwidth and
frequency parameters passed via DVBv3, until a later patch fixes
it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This standard is not properly documented, but its settings are at
the tda18271dd driver, and are somewhat obvious, as they follow
the same logic as DVB-T 7MHz.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a bug on mxl5005s logic: when the bandwidth changes, but using
the same delivery system, the code discard the set_params()
reconfiguration request.
This was happening because, in the previous coding, the bandwidth
calculus were after the check for delivery system changes.
The previous patch changed the logic to estimate the bandwidth to
happend together with the changes at the delivery system.
So, with a one-statement change, it is possible to make the tuner to
reconfigure, in order to adjust to bandwidth changes. this will
likely fix issues on countries that use 7MHz/8MHz DVB-T channels.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was "set".
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
While here, convert set_params to use the DVBv5 way to pass
parameters to tuners.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was "set".
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
While here, convert set_params to use the DVBv5 way to pass
parameters to tuners.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was "set".
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
While here, convert set_params to use the DVBv5 way to pass
parameters to tuners.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of just estimating the bandwidth for DVB-C annex A/C,
also fill it at the core for ATSC and DVB-C annex B. This
simplifies the logic inside the tuners, as all non-satellite
tuners can just use c->bandwidth_hz for all supported
delivery systems.
It could make sense to latter use it also for satellite
systems, as several DVB-S drivers have their own calculus.
However, on DVB-S2 the bw estimation is a little more complex,
and the existing drivers have some optimized calculus for
bandwidth. So, let's not touch on it for now.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
SYS_DVBC_ANNEX_AC is an alias for SYS_DVBC_ANNEX_A. However,
the first one is incorrect, as not all devices support both.
So, replace its occurrences by the proper value (either
SYS_DVBC_ANNEX_A or both SYS_DVBC_ANNEX_A and SYS_DVBC_ANNEX_C).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restore skge hardware registers for multicast filtering to their
appropriate values after system resume and after hardware restarts
that are done when changing certain settings.
Signed-off-by: Florian Zumbiehl <florz@florz.de>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Caused loss of connectivity when changing ring size.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://www.linux-watchdog.org/linux-watchdog:
watchdog: iTCO_wdt.c - problems with newer hardware due to SMI clearing (part 2)
watchdog: hpwdt: Changes to handle NX secure bit in 32bit path
watchdog: sp805: Fix section mismatch in ID table.
watchdog: move coh901327 state holders
dvb_register calls videobuf_dvb_register_bus, but if that returns
a failure the module will be unloaded without clearing the
value of core->gate_ctrl which will cause an oops in macros
called from video_open in cx88-video.c
Signed-off-by: David Fries <David@Fries.net>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Istvan Varga <istvan_v@mailbox.hu>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Stop dual frontend attach in warm state with single devices.
Since this is a no reconnect device this occurs only after a warm system
reboot.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Re: [git:v4l-dvb/for_v3.3] [media] it9135: add support for IT9135 9005 devices
On Sun, 2011-12-11 at 11:55 +0100, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] it9135: add support for IT9135 9005 devices
> Author: Malcolm Priestley <tvboxspy@gmail.com>
> Date: Wed Nov 30 17:16:09 2011 -0300
>
> Support add for IT9135 9005 devices
>
> With this patch IT9135 devices now move to using
> dvb-usb-it9135-01.fw firmware
> IT9137 remain on previous firmware.
Hi Mauro,
I have made a small mistake on this patch.
I forgot to increase number of num_device_descs to 4.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are some issues and miss-behaves at the dvb fe thread:
1) dvb_shutdown_timeout should be dvb_shutdown_timeout * HZ
instead of (dvb_shutdown_timeout * HZ + 1);
2) add a memory barrier to warrant that all CPU's will consider the
new value for release_jiffies;
3) wake up dvb thread also when fepriv->exit == DVB_FE_NO_EXIT.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The attached patch fixes the automute logic of saa7134.
It avoids the white noise on the pulseaudio startup.
(pulseaudio reads the saa7134 alsa device on startup)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Message-Id: <1322820073-19347-4-git-send-email-xi.wang@gmail.com>
The error handling with (ret < 0) didn't work where ret is a u32.
Use int instead. To be consistent we also change the functions to
return an int.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Message-Id: <1322820073-19347-3-git-send-email-xi.wang@gmail.com>
The error handling with (ret < 0) didn't work where ret is a u32.
Use int instead. To be consistent we also change the functions to
return an int.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Message-Id: <1322820073-19347-2-git-send-email-xi.wang@gmail.com>
The error handling with (ret < 0) didn't work where ret is a u32.
Use int instead. To be consistent we also change the functions to
return an int.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new iso bandwidth calculation code accidentally has broken support
for bulk mode cameras. This has broken the following drivers:
finepix, jeilinj, ovfx2, ov534, ov534_9, se401, sq905, sq905c, sq930x,
stv0680, vicam.
Thix patch fixes this. Fix tested with: se401, sq905, sq905c, stv0680 &
vicam cams.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems that a cut-and-past error were added by the last patch:
drivers/media/video/videobuf2-core.c: In function ‘vb2_qbuf’:
drivers/media/video/videobuf2-core.c:1099:14: warning: comparison between ‘enum v4l2_buf_type’ and ‘enum v4l2_memory’ [-Wenum-compare]
On all places V4L2_MEMORY_USERPTR is used, it is associated with
q->memory, and not b->type. So, the fix seems obvious.
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for user pointer memory buffers to vmalloc
videobuf2 allocator.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is a result of review of mem_priv entry usage in videobuf2 core.
It fixes all all potential places where it was not checked against NULL or
zeroed after freeing as well as a few style issues.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
To get direct access to userspace memory pages vb2 allocator needs to
gather read access on mmap semaphore in the current process.
The same semaphore is taken before calling mmap operation, while
both mmap and qbuf are called by the driver or v4l2 core with
driver's lock held. To avoid a AB-BA deadlock (mmap_sem then
driver's lock in mmap and driver's lock then mmap_sem in qbuf)
the videobuf2 core release driver's lock, takes mmap_sem and then
takes again driver's lock. get_userptr methods are now called with
all needed locks already taken to avoid further lock magic inside
memory allocator's code.
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Heuristic that checks if the memory pointer has been changed lacked a check
if the pointer was actually provided by the userspace, what allowed one to
queue a NULL pointer which was accepted without further checking. This
patch fixes this issue.
Reported-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
fix the following build warning:
lgdt330x.c: In function "lgdt330x_set_parameters":
lgdt330x.c:346:6: warning: variable "err" set but not used
[-Wunused-but-set-variable]
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
initialize *ucblocks to zero & fix the following build warning:
lgdt330x.c: In function "lgdt330x_read_ucblocks":
lgdt330x.c:288:6: warning: variable "err" set but not used
[-Wunused-but-set-variable]
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
PCTV290E: Attach a single frontend, rather than a frontend each per
delivery system, whereby a multistandard frontend can advertise all
associated delivery systems.
Signed-off-by: Manu Abraham <abraham.manu@gmail.com>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Override default delivery system information provided by FE_GET_INFO,
so that applications can enumerate delivery systems provided by the
frontend.
Signed-off-by: Manu Abraham <abraham.manu@gmail.com>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Hartmut <e9hack@googlemail.com>:
> A break is missing before the default statement. Delivery systems for DVB-C result always
> in an error.
Reported-by: Hartmut <e9hack@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rewrite whole af9013 demod driver in order to decrease I2C I/O.
We need to decrease I2C load since AF9015 (I2C adapter / USB-bridge used)
seems to have some problems under heavy I2C traffic.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
AF9015 firmware does not like if it gets interrupted by I2C adapter
request on some critical phases. During normal operation I2C adapter
is used only 2nd demodulator and tuner on dual tuner devices.
Override demodulator callbacks and use mutex for limit access to
those "critical" paths to keep AF9015 happy.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set v4l2_subdev flags for a host driver to create a sub-device
node for the driver so the subdev can be directly configured
by applications. Add the subdev open() handler.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set V4L2_SUBDEV_FL_HAS_DEVNODE flag for the host driver to create
the sensor device node.
Acked-by: HeungJun Kim <riverful.kim@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mauro Carvalho Chehab