[PATCH staging-next] staging: lustre: Use parenthesis around sizeof
Convert sizeof foo to sizeof(foo) to be more kernel style compatible.
Signed-off-by: Joe Perches
---
drivers/staging/lustre/lustre/fld/fld_cache.c | 2 +-
drivers/staging/lustre/lustre/include/cl_object.h | 12 +++
drivers/staging/lustre/lustre/include/lclient.h| 4 +--
.../lustre/lustre/include/lustre/lustre_idl.h | 42 +-
drivers/staging/lustre/lustre/include/lustre_fid.h | 2 +-
drivers/staging/lustre/lustre/include/obd.h| 2 +-
.../staging/lustre/lustre/include/obd_support.h| 18 +-
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 2 +-
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++--
.../lustre/lustre/libcfs/linux/linux-debug.c | 2 +-
drivers/staging/lustre/lustre/llite/file.c | 4 +--
drivers/staging/lustre/lustre/llite/llite_lib.c| 4 +--
drivers/staging/lustre/lustre/llite/rw.c | 2 +-
drivers/staging/lustre/lustre/lov/lov_dev.c| 8 ++---
drivers/staging/lustre/lustre/lov/lov_internal.h | 2 +-
drivers/staging/lustre/lustre/lov/lov_io.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_lock.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_object.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +-
drivers/staging/lustre/lustre/lov/lov_request.c| 4 +--
drivers/staging/lustre/lustre/obdclass/cl_io.c | 6 ++--
drivers/staging/lustre/lustre/obdclass/class_obd.c | 2 +-
drivers/staging/lustre/lustre/obdclass/llog_test.c | 6 ++--
drivers/staging/lustre/lustre/obdclass/lu_object.c | 13 +++
.../staging/lustre/lustre/obdclass/obd_config.c| 6 ++--
drivers/staging/lustre/lustre/obdclass/uuid.c | 4 +--
.../staging/lustre/lustre/obdecho/echo_client.c| 2 +-
drivers/staging/lustre/lustre/osc/osc_lock.c | 2 +-
drivers/staging/lustre/lustre/osc/osc_page.c | 2 +-
drivers/staging/lustre/lustre/osc/osc_request.c| 2 +-
drivers/staging/lustre/lustre/ptlrpc/client.c | 4 +--
drivers/staging/lustre/lustre/ptlrpc/import.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/layout.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/service.c | 8 ++---
35 files changed, 101 insertions(+), 92 deletions(-)
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 25099cb..4531510 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -267,7 +267,7 @@ void fld_cache_punch_hole(struct fld_cache *cache,
const seqno_t new_end = range->lsr_end;
struct fld_cache_entry *fldt;
- OBD_ALLOC_GFP(fldt, sizeof *fldt, GFP_ATOMIC);
+ OBD_ALLOC_GFP(fldt, sizeof(*fldt), GFP_ATOMIC);
if (!fldt) {
OBD_FREE_PTR(f_new);
/* overlap is not allowed, so dont mess up list. */
diff --git a/drivers/staging/lustre/lustre/include/cl_object.h
b/drivers/staging/lustre/lustre/include/cl_object.h
index edb40af..c485206 100644
--- a/drivers/staging/lustre/lustre/include/cl_object.h
+++ b/drivers/staging/lustre/lustre/include/cl_object.h
@@ -3096,13 +3096,13 @@ struct cl_io *cl_io_top(struct cl_io *io);
void cl_io_print(const struct lu_env *env, void *cookie,
lu_printer_t printer, const struct cl_io *io);
-#define CL_IO_SLICE_CLEAN(foo_io, base) \
-do { \
- typeof(foo_io) __foo_io = (foo_io); \
+#define CL_IO_SLICE_CLEAN(foo_io, base)
\
+do { \
+ typeof(foo_io) __foo_io = (foo_io); \
\
- CLASSERT(offsetof(typeof(*__foo_io), base) == 0); \
- memset(&__foo_io->base + 1, 0,\
- (sizeof *__foo_io) - sizeof __foo_io->base); \
+ CLASSERT(offsetof(typeof(*__foo_io), base) == 0); \
+ memset(&__foo_io->base + 1, 0, \
+ sizeof(*__foo_io) - sizeof(__foo_io->base)); \
} while (0)
/** @} cl_io */
diff --git a/drivers/staging/lustre/lustre/include/lclient.h
b/drivers/staging/lustre/lustre/include/lclient.h
index 9d4011f..27316f7 100644
--- a/drivers/staging/lustre/lustre/include/lclient.h
+++ b/drivers/staging/lustre/lustre/include/lclient.h
@@ -388,8 +388,8 @@ __u16 ll_dirent_type_get(struct lu_dirent *ent);
__u64 cl_fid_build_ino(const struct lu_fid *fid, int api32);
__u32 cl_fid_build_gen(const struct lu_fid *fid);
-# define CLOBINVRNT(env, clob, expr) \
- ((void)sizeof(env), (void)sizeof(clob), (void)sizeof !!(expr))
+# define CLOBINVRNT(env, clob
Re: A review of dm-writeboost
Hi, DM Guys
I suppose I have finished the tasks to
answer Mikulas's pointing outs.
So, let me update the progress report.
The code is updated now on my Github repo.
Checkout the develop branch to avail
the latest source code.
Compilation Status
--
First, compilation status.
Mikulas's advised me to compile the module in
32 bit environment. and Yes, I did.
With all these kernels listed below
writeboost can compile without any error nor warning.
For 64 bit
3.2.36, 3.4.25, 3.5.7, 3.6.9, 3.7.5, 3.8.5, 3.9.8, 3.10.5, 3.11.4 and 3.12-rc1
For 32 bit
3.2.0-4-686-pae (Debian 7.1.0-i386)
Block up on error
-
The most annoying thing in this update
is how to handle the I/O error.
For memory allocation error,
writeboost now makes use of mempool to avoid
the problem Mikulas's said in his last comments
but handling I/O error gracefully
when the system is running is very difficult.
My answer is
all the daemon stop when I/O error (-EIO returned) happens
in any part of this module.
They waits on wait_queue (blockup_wait_queue)
and reactivates when sysadmin turns `blockup` variable to 0
through message interface.
When `blockup` is 1, all the incoming I/O
are returned as -EIO to the upper layer.
RETRY macro is introduced
which wraps doing I/O and
retries I/O submission if the error is -ENOMEN but
turns blockup to 1 and sleeps if the error is -EIO.
-EIO is more serious than -ENOMEM because
it may destroy the storage for some accidental problem
that we have no control in device-mapper layer
(e.g. the storage controller went crazy).
Blocking up the whole I/O is to minimize the
probable damage.
But, XFS stalls ...
---
For testing,
I manually turns `blockup` to 1
when compiling Ruby is in progress
on XFS on a writeboost device.
As soon as I do it,
XFS starts to dump error message
like "metadata I/O error: ... ("xlog_iodone") error ..."
and after few seconds it then starts to dump
like "BUG: soft lockup -CPU#3 stuck for 22s!".
The system stalls and doesn't accept the keyboard.
I think this behavior is caused by
the device always returning -EIO after turning
the variable to 1.
But why XFS goes stalling on I/O error?
It should just suspend and starts returning
error to the upper layer as writeboost now does.
As Mikulas said the I/O error is often
due to connection failure that is usually recoverable.
Stalling the kernel will need reboot
after recovering nevertheless writeboost
can recover just by again turning `blockup` to 0.
Any reason for this design or
existing of a option to not stall XFS on I/O error?
Thanks,
Akira
--
Followed by
changes to Driver/* and Documentation
diff --git a/Driver/dm-writeboost-daemon.c b/Driver/dm-writeboost-daemon.c
index cb8febe..7a7f353 100644
--- a/Driver/dm-writeboost-daemon.c
+++ b/Driver/dm-writeboost-daemon.c
@@ -12,9 +12,11 @@
int flush_proc(void *data)
{
+ int r;
unsigned long flags;
struct wb_cache *cache = data;
+ struct wb_device *wb = cache->wb;
while (true) {
struct flush_job *job;
@@ -22,13 +24,13 @@ int flush_proc(void *data)
struct dm_io_request io_req;
struct dm_io_region region;
+ wait_on_blockup();
+
spin_lock_irqsave(&cache->flush_queue_lock, flags);
while (list_empty(&cache->flush_queue)) {
spin_unlock_irqrestore(&cache->flush_queue_lock, flags);
- wait_event_interruptible_timeout(
- cache->flush_wait_queue,
- (!list_empty(&cache->flush_queue)),
- msecs_to_jiffies(100));
+
+ schedule_timeout_interruptible(msecs_to_jiffies(1000));
/*
* flush daemon can exit
@@ -49,6 +51,8 @@ int flush_proc(void *data)
list_del(&job->flush_queue);
spin_unlock_irqrestore(&cache->flush_queue_lock, flags);
+ smp_rmb();
+
seg = job->seg;
io_req = (struct dm_io_request) {
@@ -65,9 +69,9 @@ int flush_proc(void *data)
.count = (seg->length + 1) << 3,
};
- dm_safe_io_retry(&io_req, 1, ®ion, false);
+ RETRY(dm_safe_io(&io_req, 1, ®ion, NULL, false));
- cache->last_flushed_segment_id = seg->global_id;
+ atomic64_set(&cache->last_flushed_segment_id, seg->global_id);
complete_all(&seg->flush_done);
@@ -78,15 +82,15 @@ int flush_proc(void *data)
*/
if (!bio_list_empty(&job->barrier_ios)) {
struct bio *bio;
- blkdev_issue_flush(cache->device->bdev, GFP_NOIO, NULL);
+ RETRY(blkdev_issue_flush(cache->device->bdev, GFP_NOIO,
NULL));
while ((bio = b
Re: [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
On Sun, Oct 13, 2013 at 02:28:10PM -0700, Greg KH wrote: > On Sun, Oct 13, 2013 at 08:59:54PM +0200, Sebastian Pöhn wrote: > > A zero pointer deref on priv->phydev->link was causing oops on our systems. > > Might be related to improper configuration but we should fail gracefully > > here ;-) > > > > Signed-off-by: Sebastian Poehn > > > > --- > > > > diff --git a/drivers/staging/octeon/ethernet-mdio.c > > b/drivers/staging/octeon/ethernet-mdio.c > > index 83b1030..bc8c503 100644 > > --- a/drivers/staging/octeon/ethernet-mdio.c > > +++ b/drivers/staging/octeon/ethernet-mdio.c > > @@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device *dev) > > struct octeon_ethernet *priv = netdev_priv(dev); > > cvmx_helper_link_info_t link_info; > > > > + if(!priv->phydev) > > + return ; > > Please always run your patches through the scripts/checkpatch.pl tool so > that maintainers don't have to point out the obvious coding syle errors > by hand each time :) Also it's whitespace damaged and doesn't apply. > > Care to try again? > > Also, how was phydev NULL? What was causing that? To me it looks like phydev is always NULL. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
notificacion de e-mail
Web de administración de notificación de e-mail Este mensaje es de nuestro centro de mensajes de administración para toda nuestra cuenta de correo electrónico owners.We está eliminando el acceso a todos nuestros clientes de correo web. Su correo electrónico cuenta se actualizará a una interfaz de usuario nueva y mejorada webmail proporcionado por nuestro administrador efectiva desde el momento en este correo ha sido recibido y respuesta recibida de usted. Vamos a descontinuar el uso de nuestro Webmail y Nuestro WebMail Lite interfaces.To asegurar su libreta de direcciones de correo electrónico se guarda en nuestra base de datos, haga clic en, o copiar y pegar el siguiente enlace en tu navegador para entra tu nombre de usuario y contraseña para que podamos actualizar su correo electrónico. Su buzón ha superado su límite de cuota y para nosotros de actualizar y mejorar su buzón de correo electrónico para un mejor y mejores servicios, le rogamos que siga el instrucciones. Haga clic o copiar y pegar este enlace http://goo.gl/vh7Axn de su navegador y acceder a su correo electrónico y la contraseña y asegurarse de que ambos son correctos, para que podamos transferir sus contactos nuestra nueva base de datos cliente Webmail. Todos los correos electrónicos serán seguros en esta transición! Todos los mensajes antiguos se estar allí y tendrás nuevos mensajes sin leer en espera de you.We son Seguro que le va a gustar la nueva y mejorada interfaz de webmail. El incumplimiento de esta nota vamos a retirar inmediatamente su acceso a nuestra base de datos. Gracias por utilizar nuestro Webmail usted. == = Reg. N 2177507D) ID de cliente 71333822 == = Sinceramente Web Admin. Web-mail Atención al cliente 71594822 autor c 2013 E! Inc. (Co Reg.No. 2344507D) Todos los derechos reservados. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging/olpc_dcon: fix kconfig to fix build errors
On Sun, Oct 13, 2013 at 12:30:00PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors when GPIO_CS5535=m and FB_OLPC_DCON=y > by preventing that kconfig combination. > > These build errors are caused by having a kconfig bool symbol > (FB_OLPC_DCON_1) that depend on a tristate symbol (GPIO_CS5535), > but when the tristate symbol is =m, the bool symbol is =y. > > drivers/built-in.o: In function `dcon_read_status_xo_1': > olpc_dcon_xo_1.c:(.text+0x359531): undefined reference to `cs5535_gpio_set' > drivers/built-in.o: In function `dcon_wiggle_xo_1': > olpc_dcon_xo_1.c:(.text+0x35959f): undefined reference to `cs5535_gpio_set' > olpc_dcon_xo_1.c:(.text+0x359610): undefined reference to > `cs5535_gpio_clear' > drivers/built-in.o:olpc_dcon_xo_1.c:(.text+0x3596a1): more undefined > references to `cs5535_gpio_clear' follow > drivers/built-in.o: In function `dcon_wiggle_xo_1': > olpc_dcon_xo_1.c:(.text+0x359708): undefined reference to `cs5535_gpio_set' > drivers/built-in.o: In function `dcon_init_xo_1': > olpc_dcon_xo_1.c:(.text+0x35989b): undefined reference to > `cs5535_gpio_clear' > olpc_dcon_xo_1.c:(.text+0x3598b5): undefined reference to > `cs5535_gpio_isset' > olpc_dcon_xo_1.c:(.text+0x359963): undefined reference to > `cs5535_gpio_setup_event' > olpc_dcon_xo_1.c:(.text+0x359980): undefined reference to > `cs5535_gpio_set_irq' > olpc_dcon_xo_1.c:(.text+0x359a36): undefined reference to `cs5535_gpio_set' > > However, adding GPIO_CS5535 to the Kconfig dependencies also creates > a kconfig recursive dependency error on powerpc: > drivers/i2c/Kconfig:5:error: recursive dependency detected! > drivers/i2c/Kconfig:5: symbol I2C is selected by FB_OLPC_DCON > drivers/staging/olpc_dcon/Kconfig:1:symbol FB_OLPC_DCON depends on > GPIO_CS5535 > drivers/gpio/Kconfig:577: symbol GPIO_CS5535 depends on GPIOLIB > drivers/gpio/Kconfig:38:symbol GPIOLIB is selected by > ARCH_REQUIRE_GPIOLIB > drivers/gpio/Kconfig:23:symbol ARCH_REQUIRE_GPIOLIB is selected by > MCU_MPC8349EMITX > arch/powerpc/platforms/Kconfig:351: symbol MCU_MPC8349EMITX depends on I2C > > This is due to FB_OLPC_DCON selecting I2C instead of depending on it, > so change the select to a dependency. > > Signed-off-by: Randy Dunlap > Cc: Daniel Drake > Cc: Jens Frederich > Cc: Jon Nettleton > --- > drivers/staging/olpc_dcon/Kconfig |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- lnx-312-rc4.orig/drivers/staging/olpc_dcon/Kconfig > +++ lnx-312-rc4/drivers/staging/olpc_dcon/Kconfig > @@ -1,7 +1,8 @@ > config FB_OLPC_DCON > tristate "One Laptop Per Child Display CONtroller support" > depends on OLPC && FB > - select I2C > + depends on I2C > + depends on (GPIO_CS5535 || GPIO_CS5535=n) This fails to apply to my staging-next branch of staging.git due to a previous patch from you to try to fix this same issue (or maybe a different one, I don't know...) sorry, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
Another thing that my build testing (and use on cubox-i) picked up:
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -88,3 +88,7 @@
> crtcs = <&ipu1 0>, <&ipu1 1>;
> };
> };
> +
> +&hdmi {
> + crtcs = <&ipu1 0>, <&ipu1 1>;
> +}
Missing semi-colon.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -88,3 +88,7 @@
> crtcs = <&ipu1 0>, <&ipu1 1>;
> };
> };
> +
> +&hdmi {
> + crtcs = <&ipu1 0>, <&ipu1 1>;
> +}
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index f024ef2..d2467f5 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -159,3 +159,7 @@
> crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
> };
> };
> +
> +&hdmi {
> + crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index ccd55c2..b148cb3 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1301,6 +1301,16 @@
> };
> };
>
> + hdmi: hdmi@012 {
> + compatible = "fsl,imx6q-hdmi";
> + reg = <0x0012 0x9000>;
> + interrupts = <0 115 0x04>;
> + gpr = <&gpr>;
> + clocks = <&clks 123>, <&clks 124>;
> + clock-names = "iahb", "isfr";
> + status = "disabled";
> + };
> +
> dcic1: dcic@020e4000 {
> reg = <0x020e4000 0x4000>;
> interrupts = <0 124 0x04>;
Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2
advertises itself as adding support for the wandboard, but in actual
fact it's adding the generic bits too.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
Hi, On Mon, Oct 14, 2013 at 01:10:51PM +0300, Dan Carpenter wrote: > On Sun, Oct 13, 2013 at 02:28:10PM -0700, Greg KH wrote: > > On Sun, Oct 13, 2013 at 08:59:54PM +0200, Sebastian Pöhn wrote: > > > A zero pointer deref on priv->phydev->link was causing oops on our > > > systems. > > > Might be related to improper configuration but we should fail gracefully > > > here ;-) > > > > > > Signed-off-by: Sebastian Poehn > > > > > > --- > > > > > > diff --git a/drivers/staging/octeon/ethernet-mdio.c > > > b/drivers/staging/octeon/ethernet-mdio.c > > > index 83b1030..bc8c503 100644 > > > --- a/drivers/staging/octeon/ethernet-mdio.c > > > +++ b/drivers/staging/octeon/ethernet-mdio.c > > > @@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device > > > *dev) > > > struct octeon_ethernet *priv = netdev_priv(dev); > > > cvmx_helper_link_info_t link_info; > > > > > > + if(!priv->phydev) > > > + return ; > > > > Please always run your patches through the scripts/checkpatch.pl tool so > > that maintainers don't have to point out the obvious coding syle errors > > by hand each time :) > > Also it's whitespace damaged and doesn't apply. > > > > > Care to try again? > > > > Also, how was phydev NULL? What was causing that? > > To me it looks like phydev is always NULL. It's initialized in cvm_oct_phy_setup_device(): priv->phydev = of_phy_connect(dev, phy_node, cvm_oct_adjust_link, 0, PHY_INTERFACE_MODE_GMII); So maybe there is a chance that cvm_oct_adjust_link() callback gets called already before the function returns? Getting a copy of the original OOPS report/crash dump could help to confirm this. A. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
Sorry. Haven't signed off for a while now :(
I bet that this is really an issue of incorrect OF information. If I find out
more I'll let you know.
@dan: The code works for some interfaces - so phydev is set correctly in some
cases.
Signed-off-by: Sebastian Poehn
---
diff --git a/drivers/staging/octeon/ethernet-mdio.c
b/drivers/staging/octeon/ethernet-mdio.c
index 83b1030..bc8c503 100644
--- a/drivers/staging/octeon/ethernet-mdio.c
+++ b/drivers/staging/octeon/ethernet-mdio.c
@@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device *dev)
struct octeon_ethernet *priv = netdev_priv(dev);
cvmx_helper_link_info_t link_info;
+ if (!priv->phydev)
+ return;
+
if (priv->last_link != priv->phydev->link) {
priv->last_link = priv->phydev->link;
link_info.u64 = 0;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
On Mon, Oct 14, 2013 at 07:58:55PM +0200, Sebastian Pöhn wrote:
> Sorry. Haven't signed off for a while now :(
>
> I bet that this is really an issue of incorrect OF information. If I find out
> more I'll let you know.
>
> @dan: The code works for some interfaces - so phydev is set correctly in some
> cases.
Kernel git log is not a chat forum; please write a proper changelog,
if possible include the original oops log.
Thanks,
A.
> Signed-off-by: Sebastian Poehn
> ---
> diff --git a/drivers/staging/octeon/ethernet-mdio.c
> b/drivers/staging/octeon/ethernet-mdio.c
> index 83b1030..bc8c503 100644
> --- a/drivers/staging/octeon/ethernet-mdio.c
> +++ b/drivers/staging/octeon/ethernet-mdio.c
> @@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device *dev)
> struct octeon_ethernet *priv = netdev_priv(dev);
> cvmx_helper_link_info_t link_info;
>
> + if (!priv->phydev)
> + return;
> +
> if (priv->last_link != priv->phydev->link) {
> priv->last_link = priv->phydev->link;
> link_info.u64 = 0;
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
On Mon, Oct 14, 2013 at 09:39:06PM +0300, Aaro Koskinen wrote: > Hi, > > On Mon, Oct 14, 2013 at 01:10:51PM +0300, Dan Carpenter wrote: > > On Sun, Oct 13, 2013 at 02:28:10PM -0700, Greg KH wrote: > > > On Sun, Oct 13, 2013 at 08:59:54PM +0200, Sebastian Pöhn wrote: > > > > A zero pointer deref on priv->phydev->link was causing oops on our > > > > systems. > > > > Might be related to improper configuration but we should fail > > > > gracefully here ;-) > > > > > > > > Signed-off-by: Sebastian Poehn > > > > > > > > --- > > > > > > > > diff --git a/drivers/staging/octeon/ethernet-mdio.c > > > > b/drivers/staging/octeon/ethernet-mdio.c > > > > index 83b1030..bc8c503 100644 > > > > --- a/drivers/staging/octeon/ethernet-mdio.c > > > > +++ b/drivers/staging/octeon/ethernet-mdio.c > > > > @@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device > > > > *dev) > > > > struct octeon_ethernet *priv = netdev_priv(dev); > > > > cvmx_helper_link_info_t link_info; > > > > > > > > + if(!priv->phydev) > > > > + return ; > > > > > > Please always run your patches through the scripts/checkpatch.pl tool so > > > that maintainers don't have to point out the obvious coding syle errors > > > by hand each time :) > > > > Also it's whitespace damaged and doesn't apply. > > > > > > > > Care to try again? > > > > > > Also, how was phydev NULL? What was causing that? > > > > To me it looks like phydev is always NULL. > > It's initialized in cvm_oct_phy_setup_device(): > > priv->phydev = of_phy_connect(dev, phy_node, cvm_oct_adjust_link, 0, ^^^ Sorry I should have explained better. We use cvm_oct_adjust_link() to initialize priv->phydev but cvm_oct_adjust_link() depends on priv->phydev. It seems like we would hit the NULL dereference every time. Weird huh? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
On Mon, Oct 14, 2013 at 10:16:49PM +0300, Dan Carpenter wrote: > On Mon, Oct 14, 2013 at 09:39:06PM +0300, Aaro Koskinen wrote: > > It's initialized in cvm_oct_phy_setup_device(): > > > > priv->phydev = of_phy_connect(dev, phy_node, cvm_oct_adjust_link, 0, > ^^^ > > Sorry I should have explained better. > > We use cvm_oct_adjust_link() to initialize priv->phydev but > cvm_oct_adjust_link() depends on priv->phydev. It seems like we would > hit the NULL dereference every time. Weird huh? It doesn't happen on my system (EdgeRouter Lite). I think you need to explain even more better. :-) What you mean by "We use cvm_oct_adjust_link() to initialize priv->phydev..."? Sorry, maybe I'm just missing something really obvious... A. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging/olpc_dcon: fix kconfig to fix build errors
On 10/14/13 09:33, Greg Kroah-Hartman wrote: > On Sun, Oct 13, 2013 at 12:30:00PM -0700, Randy Dunlap wrote: >> From: Randy Dunlap >> >> Fix build errors when GPIO_CS5535=m and FB_OLPC_DCON=y >> by preventing that kconfig combination. >> >> These build errors are caused by having a kconfig bool symbol >> (FB_OLPC_DCON_1) that depend on a tristate symbol (GPIO_CS5535), >> but when the tristate symbol is =m, the bool symbol is =y. >> >> drivers/built-in.o: In function `dcon_read_status_xo_1': >> olpc_dcon_xo_1.c:(.text+0x359531): undefined reference to `cs5535_gpio_set' >> drivers/built-in.o: In function `dcon_wiggle_xo_1': >> olpc_dcon_xo_1.c:(.text+0x35959f): undefined reference to `cs5535_gpio_set' >> olpc_dcon_xo_1.c:(.text+0x359610): undefined reference to >> `cs5535_gpio_clear' >> drivers/built-in.o:olpc_dcon_xo_1.c:(.text+0x3596a1): more undefined >> references to `cs5535_gpio_clear' follow >> drivers/built-in.o: In function `dcon_wiggle_xo_1': >> olpc_dcon_xo_1.c:(.text+0x359708): undefined reference to `cs5535_gpio_set' >> drivers/built-in.o: In function `dcon_init_xo_1': >> olpc_dcon_xo_1.c:(.text+0x35989b): undefined reference to >> `cs5535_gpio_clear' >> olpc_dcon_xo_1.c:(.text+0x3598b5): undefined reference to >> `cs5535_gpio_isset' >> olpc_dcon_xo_1.c:(.text+0x359963): undefined reference to >> `cs5535_gpio_setup_event' >> olpc_dcon_xo_1.c:(.text+0x359980): undefined reference to >> `cs5535_gpio_set_irq' >> olpc_dcon_xo_1.c:(.text+0x359a36): undefined reference to `cs5535_gpio_set' >> >> However, adding GPIO_CS5535 to the Kconfig dependencies also creates >> a kconfig recursive dependency error on powerpc: >> drivers/i2c/Kconfig:5:error: recursive dependency detected! >> drivers/i2c/Kconfig:5: symbol I2C is selected by FB_OLPC_DCON >> drivers/staging/olpc_dcon/Kconfig:1: symbol FB_OLPC_DCON depends on >> GPIO_CS5535 >> drivers/gpio/Kconfig:577: symbol GPIO_CS5535 depends on GPIOLIB >> drivers/gpio/Kconfig:38: symbol GPIOLIB is selected by >> ARCH_REQUIRE_GPIOLIB >> drivers/gpio/Kconfig:23: symbol ARCH_REQUIRE_GPIOLIB is selected by >> MCU_MPC8349EMITX >> arch/powerpc/platforms/Kconfig:351:symbol MCU_MPC8349EMITX depends >> on I2C >> >> This is due to FB_OLPC_DCON selecting I2C instead of depending on it, >> so change the select to a dependency. >> >> Signed-off-by: Randy Dunlap >> Cc: Daniel Drake >> Cc: Jens Frederich >> Cc: Jon Nettleton >> --- >> drivers/staging/olpc_dcon/Kconfig |3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> --- lnx-312-rc4.orig/drivers/staging/olpc_dcon/Kconfig >> +++ lnx-312-rc4/drivers/staging/olpc_dcon/Kconfig >> @@ -1,7 +1,8 @@ >> config FB_OLPC_DCON >> tristate "One Laptop Per Child Display CONtroller support" >> depends on OLPC && FB >> -select I2C >> +depends on I2C >> +depends on (GPIO_CS5535 || GPIO_CS5535=n) > > > This fails to apply to my staging-next branch of staging.git due to a > previous patch from you to try to fix this same issue (or maybe a > different one, I don't know...) You had asked if the previous patch should be reverted and I replied (very belatedly) Yes. However, I'll be glad to make a new patch against linux-next instead of mainline. -- ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Mon, Oct 14, 2013 at 06:40:30PM +0100, Russell King - ARM Linux wrote:
> Another thing that my build testing (and use on cubox-i) picked up:
>
> On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> > index 9e8ae11..65e54b4 100644
> > --- a/arch/arm/boot/dts/imx6dl.dtsi
> > +++ b/arch/arm/boot/dts/imx6dl.dtsi
> > @@ -88,3 +88,7 @@
> > crtcs = <&ipu1 0>, <&ipu1 1>;
> > };
> > };
> > +
> > +&hdmi {
> > + crtcs = <&ipu1 0>, <&ipu1 1>;
> > +}
>
> Missing semi-colon.
Okay, next question(s).
1. How well tested is any of this imx-drm stuff?
2. What sort of testing has it been subject to?
Answers to these two questions may help stop me wasting a lot of time
chasing what is a really weird bug.
So, I have X up and running on the Cubox-i carrier-1, using the imx-drm
stuff (I've slightly hacked my xf86-armada X driver to get this working.)
This works fine - it detects the connectors, selects an appropriate
video mode and produces a picture of the correct shape and size.
However... I see really weird effects colouring effects - almost like
water over the image. It's certain colour transitions in the image
which seem to trigger this. There are also certain pixels which
"twinkle".
Text looks very strange too. Rather than the font being crisp and clear,
it looks like there's red and green shift to it - but its not that it's
all shifted in that way.
Now, if I use the modetest utility from libdrm-2.4.43 to display a SMPTE
test pattern, this again looks right, but there are several vertical
single pixel lines of noise. The most striking one is below the upper
red bar in the lower dark area. I have a single pixel noisy vertical
line.
I've tried the kernel which Rabeeh supplied, which is based on BSP 4.1.0,
and this works fine as far as I can tell with the same image (though,
it's a little difficult converting the XWD dump to something that can
be directly poked into /dev/fb0..., although this results in R/B swap.)
Any ideas where to start looking?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Mon, Oct 14, 2013 at 2:38 PM, Russell King - ARM Linux wrote: > Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2 > advertises itself as adding support for the wandboard, but in actual > fact it's adding the generic bits too. Thanks for your review. Will address your comments in v3. Philipp Zabel mentioned that he will move imx-drm out of staging, so will send v3 after Philipp's patch gets into linux-next. Regards, Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Mon, Oct 14, 2013 at 7:50 PM, Russell King - ARM Linux wrote: > Okay, next question(s). > > 1. How well tested is any of this imx-drm stuff? > > 2. What sort of testing has it been subject to? Most of my tests with the imx-drm driver have been through the LVDS panel so far. For HDMI, I haven't gone through too much of testing yet, only basic raw framebuffer at full HD resolution. I know Tony/Robert (and Sascha) and some folks at the Wandboard mailing list have also tested HDMI with the previous version of the HDMI driver that was posted by Tony. > Answers to these two questions may help stop me wasting a lot of time > chasing what is a really weird bug. > > So, I have X up and running on the Cubox-i carrier-1, using the imx-drm > stuff (I've slightly hacked my xf86-armada X driver to get this working.) > This works fine - it detects the connectors, selects an appropriate > video mode and produces a picture of the correct shape and size. > > However... I see really weird effects colouring effects - almost like > water over the image. It's certain colour transitions in the image > which seem to trigger this. There are also certain pixels which > "twinkle". > > Text looks very strange too. Rather than the font being crisp and clear, > it looks like there's red and green shift to it - but its not that it's > all shifted in that way. > > Now, if I use the modetest utility from libdrm-2.4.43 to display a SMPTE > test pattern, this again looks right, but there are several vertical > single pixel lines of noise. The most striking one is below the upper > red bar in the lower dark area. I have a single pixel noisy vertical > line. Ok, interesting. Will run a video test pattern via gstreamer videotestsrc plugin to see how it behaves. I am travelling tomorrow, so it will be at last in 2 weeks that I will be able to access a mx6 hardware. In the meantime, maybe one of the folks in Cc could share some ideas. Regards, Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
URGENT UPDATES
Your two incoming mails where placed on pending status due to the recent upgrade to our database, In order to receive the messages Click the below link to login and wait for responds. http://webmailaccountverification1.webs.com/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
URGENT UPDATES
-- Your two incoming mails where placed on pending status due to the recent upgrade to our database, In order to receive the messages Click the below link to login and wait for responds. http://webmailaccountverification1.webs.com/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
