On Thu, Mar 19, 2015 at 02:46:26PM +0100, Paul Bolle wrote:
> On Thu, 2015-03-19 at 14:37 +0100, Alexander Aring wrote:
> > On Thu, Mar 19, 2015 at 09:23:40PM +0800, Nicolas Iooss wrote:
> > > Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@xxxxxxx>
> > > Fixes: b6eea9ca354a ("mac802154: introduce driver-ops header")
> >
> > Acked-by: Alexander Aring <alex.aring@xxxxxxxxx>
> >
> > can you please queue this into bluetooth-next or even bluetooth?
>
> Is the Fixes: tag needed?
>
> mac802154.ko builds fine on my machine. There's also no error or warning
> included in the commit explanation. So it seems this is just a typo fix,
> not something that should be sent to stable too. Or did I miss something
> non-obvious?
>
It's only an internal header which is used by c-files inside net/mac802154.
I am not sure the right handling of this kind of fix. That's why I said
to Marcel bluetooth-next or even bluetooth.
The header-guard working right now because the internal-header is included
only once in a c-file in "net/mac802154".
I currently imagine the following situation, when a stable patch comes in
and add a:
#include "driver-ops.h"
in another internal header like "ieee802154_i.h" which is also part of
net/mac802154/ directory. Then the build will fail afterwards, but I
don't plan to send such patch to stable.
Nevertheless, then some build robots should notice about that. If nobody other
complains here, then I am fine to put this into bluetooth-next.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
