[PATCH] staging: vc04_services: remove unused functions

Looking at the history these calls were introduced in 71bad7f08641
(staging: add bcm2708 vchiq driver, 2013-07-02) and they were not
being used at all.

Discovered using sparse and fixes the following output:

drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c:816:1: warning: symbol 'vchi_readbuf_uint32' was not declared. Should it be static?
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c:827:1: warning: symbol 'vchi_writebuf_uint32' was not declared. Should it be static?
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c:841:1: warning: symbol 'vchi_readbuf_uint16' was not declared. Should it be static?
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c:852:1: warning: symbol 'vchi_writebuf_uint16' was not declared. Should it be static?

Signed-off-by: Alexander Alemayhu <redacted>
---
 .../vc04_services/interface/vchiq_arm/vchiq_shim.c | 48 ----------------------
 1 file changed, 48 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 48984abc3854..cd0c332210ca 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c

@@ -808,54 +808,6 @@ int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T handle, short *peer_ve
 }
 EXPORT_SYMBOL(vchi_get_peer_version);
 
-/* ----------------------------------------------------------------------
- * read a uint32_t from buffer.
- * network format is defined to be little endian
- * -------------------------------------------------------------------- */
-uint32_t
-vchi_readbuf_uint32(const void *_ptr)
-{
-	const unsigned char *ptr = _ptr;
-	return ptr[0] | (ptr[1] << 8) | (ptr[2] << 16) | (ptr[3] << 24);
-}
-
-/* ----------------------------------------------------------------------
- * write a uint32_t to buffer.
- * network format is defined to be little endian
- * -------------------------------------------------------------------- */
-void
-vchi_writebuf_uint32(void *_ptr, uint32_t value)
-{
-	unsigned char *ptr = _ptr;
-	ptr[0] = (unsigned char)((value >> 0)  & 0xFF);
-	ptr[1] = (unsigned char)((value >> 8)  & 0xFF);
-	ptr[2] = (unsigned char)((value >> 16) & 0xFF);
-	ptr[3] = (unsigned char)((value >> 24) & 0xFF);
-}
-
-/* ----------------------------------------------------------------------
- * read a uint16_t from buffer.
- * network format is defined to be little endian
- * -------------------------------------------------------------------- */
-uint16_t
-vchi_readbuf_uint16(const void *_ptr)
-{
-	const unsigned char *ptr = _ptr;
-	return ptr[0] | (ptr[1] << 8);
-}
-
-/* ----------------------------------------------------------------------
- * write a uint16_t into the buffer.
- * network format is defined to be little endian
- * -------------------------------------------------------------------- */
-void
-vchi_writebuf_uint16(void *_ptr, uint16_t value)
-{
-	unsigned char *ptr = _ptr;
-	ptr[0] = (value >> 0)  & 0xFF;
-	ptr[1] = (value >> 8)  & 0xFF;
-}
-
 /***********************************************************
  * Name: vchi_service_use
  *

-- 
2.11.1

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

regards,
dan carpenter

On Tue, Feb 07, 2017 at 03:09:44PM +0300, Dan Carpenter wrote:

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

OK.

Thanks.

-- 
Mit freundlichen Gr??en

Alexander Alemayhu

Dan Carpenter [off-list ref] writes:

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

Checking the downstream tree, these are actually dead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170207/67939700/attachment.sig>

On Tue, Feb 07, 2017 at 01:13:34PM -0800, Eric Anholt wrote:

Dan Carpenter [off-list ref] writes:

quoted

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

Checking the downstream tree, these are actually dead.

Ahh...  Thanks.  In that case, of course, fine let's remove them.

regards,
dan carpenter

On Wed, 2017-02-08 at 01:19 +0300, Dan Carpenter wrote:

On Tue, Feb 07, 2017 at 01:13:34PM -0800, Eric Anholt wrote:

quoted

Dan Carpenter [off-list ref] writes:

quoted

There is a bunch of vc04_services that we're still looking to
merge in
the near future.??Please hold off deleting these until we are
further
along on that.

Checking the downstream tree, these are actually dead.

Ahh...??Thanks.??In that case, of course, fine let's remove them.

regards,
dan carpenter

I made a table awhile ago as to which entry points are being used by
what.  Most of the entry points are indeed only being used by those
other drivers which exist mostly to support a debugging tool called
vcdbg(which I didn't find that useful).

The other drivers are small drivers, but I'm not sure bringing them
here makes much sense either especially since they are mostly to
support that debugging tool.  Which complicates things because probably
half the driver could be otherwise deleted instantly.

I attached a list of driver exports and which drivers are using them.



-------------- next part --------------
interface/vchiq_arm/vchiq_connected.c:EXPORT_SYMBOL(vchiq_add_connected_callback)   -- 	Github(vc_cma/vc_cma.c & vc_sm/vmcs_sm.c)
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_initialise)		    --  Github(vc_cma/vc_cma.c)
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_shutdown)		    --  Github(vc_cma/vc_cma.c)
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_connect)		    --  Github(vc_cma/vc_cma.c)
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_add_service)		    --  Internal Only
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_open_service)		    --  Github(vc_cma/vc_cma.c)
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_queue_bulk_transmit)	    --  Internal Only
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_queue_bulk_receive)	    --  Internal Only
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_bulk_transmit)		    --  Internal Only
interface/vchiq_arm/vchiq_kern_lib.c:EXPORT_SYMBOL(vchiq_bulk_receive)		    --  Internal Only
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_msg_peek)			    --  Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_msg_remove)			    --  Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_msg_queue)			    --  bcm2835/mmal-vchiq.c, bcm2835-audio/bcm2835-vchiq.c, Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_bulk_queue_receive)		    --  bcm2835/mmal-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_bulk_queue_transmit)	    --  bcm2835-audio/bcm2835-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_msg_dequeue)		    --  bcm2835-audio/bcm2835-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_held_msg_release) 		    --  bcm2835/mmal-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_msg_hold)			    --  bcm2835/mmal-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_initialise)			    --  bcm2835/mmal-vchiq.c, bcm2835-audio/bcm2835-vchiq.c, Github(vc_sm/vmcs_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_connect)			    --  bcm2835/mmal-vchiq.c, Github(vc_sm/vmcs_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_disconnect) 		    --  Internal Only
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_open)		    --  bcm2835/mmal-vchiq.c, Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_create)		    --  Internal Only
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_close)		    --  Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_destroy)                --  Internal Only
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_set_option)		    --  Internal Only
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_get_peer_version)		    --  bcm2835-audio/bcm2835-vchiq.c
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_use)		    --  bcm2835/mmal-vchiq.c, bcm2835-audio/bcm2835-vchiq.c, Github(vc_sm/vc_vchi_sm.c)
interface/vchiq_arm/vchiq_shim.c:EXPORT_SYMBOL(vchi_service_release)		    --  bcm2835/mmal-vchiq.c, bcm2835-audio/bcm2835-vchiq.c

On Tuesday, February 7, 2017 3:09:44 PM CET Dan Carpenter wrote:

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

More generally speaking, I'd like to see all the 
-Wmissing-declarations/-Wmissing-prototypes warnings addressed
in the kernel and turn on that warning by default.

If there are parts of vc04_services that are intentionally
left in place but currently unused, adding a declaration in the
header file with a comment should be sufficient to prevent it
from getting deleted or seeing bogus warnings.

	Arnd

On Wed, Feb 08, 2017 at 11:42:21AM +0100, Arnd Bergmann wrote:

On Tuesday, February 7, 2017 3:09:44 PM CET Dan Carpenter wrote:

quoted

There is a bunch of vc04_services that we're still looking to merge in
the near future.  Please hold off deleting these until we are further
along on that.

More generally speaking, I'd like to see all the 
-Wmissing-declarations/-Wmissing-prototypes warnings addressed
in the kernel and turn on that warning by default.

If there are parts of vc04_services that are intentionally
left in place but currently unused, adding a declaration in the
header file with a comment should be sufficient to prevent it
from getting deleted or seeing bogus warnings.

Yeah.  That's true.  There really isn't a good reason to have these
warnings.

regards,
dan carpenter