Greg Kroah-Hartman <gre...@linuxfoundation.org> writes:

> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls.  This ends up removing a number of lines of code that are not
> needed.
>
> Cc: Eric Anholt <e...@anholt.net>
> Cc: Stefan Wahren <stefan.wah...@i2se.com>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Dan Carpenter <dan.carpen...@oracle.com>
> Cc: Arnd Bergmann <a...@arndb.de>
> Cc: Keerthi Reddy <keerthigd4...@gmail.com>
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> ---
>  .../interface/vchiq_arm/vchiq_arm.c           | 13 +---
>  .../interface/vchiq_arm/vchiq_debugfs.c       | 72 +++----------------
>  .../interface/vchiq_arm/vchiq_debugfs.h       |  4 +-
>  3 files changed, 15 insertions(+), 74 deletions(-)
>

> diff --git 
> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c 
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> index 766b4fe5f32c..103fec955e2c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c

> @@ -314,31 +284,13 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T 
> instance)
>       debugfs_remove_recursive(node->dentry);
>  }
>  
> -int vchiq_debugfs_init(void)
> +void vchiq_debugfs_init(void)
>  {
> -     BUG_ON(debugfs_info.vchiq_cfg_dir != NULL);
> -
>       debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
> -     if (debugfs_info.vchiq_cfg_dir == NULL)
> -             goto fail;
> -

I think now that we allow successful probe with this value NULL, module
remove could vchiq_debugfs_deinit() -> vchiq_debugfs_top() -> BUG_ON().
I think the right solution would be to just drop that BUG_ON().  With
that change (and probably just garbage-collecting that function), this
will be enthusiastically:

Reviewed-by: Eric Anholt <e...@anholt.net>

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to