Re: [ 70/71] cw1200: Dont perform SPI transfers in interrupt context
On Sun, Sep 29, 2013 at 12:28:22PM -0700, Greg Kroah-Hartman wrote: > 3.11-stable review patch. If anyone has any objections, please let me know. If it's not too late, please drop this patch. Sorry aobut the delay in responding, I was travelling internationally and had very sporadic connectivity. The patch was reverted in this patch: c4fb19d21b003ec99ec490ba2cb60baffabc73f3 And superceded by this one: 87421cb6010a2f6494938fbe0a95e1b096b3b7af (Out of Linus's upstream tree) - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgphtftcdISE4.pgp Description: PGP signature
Re: [ 70/71] cw1200: Dont perform SPI transfers in interrupt context
On Wed, Oct 02, 2013 at 02:26:09PM -0700, Greg Kroah-Hartman wrote: > Thanks, I've now applied both of these, which should resolve the issue, > right? Yup, for now. Things are vastly better, but tester's still reporting some oddities. It's rather difficult do do remote debugging in this situation, as I'm sure you know. Thanks for getting the patches into -stable! - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpyarUStPvqL.pgp Description: PGP signature
[PATCH] [firmware_class] Fix compile with no builtin firmware
When compiling the firmware loader, the builtin firmware functions were
erroneously compiled as they were wrapped with CONFIG_FW_LOADER instead
of CONFIG_FIRMWARE_IN_KERNEL. This is normally harmless, except when
there was actually no firmware to compile into the kernel, causing the
build to fail with a linking error:
drivers/built-in.o: In function `release_firmware':
(.text+0x192e2): undefined reference to `__end_builtin_fw'
drivers/built-in.o: In function `release_firmware':
(.text+0x19304): undefined reference to `__end_builtin_fw'
drivers/built-in.o: In function `_request_firmware':
firmware_class.c:(.text+0x1986c): undefined reference to `__end_builtin_fw'
firmware_class.c:(.text+0x19886): undefined reference to `__end_builtin_fw'
firmware_class.c:(.text+0x19a98): undefined reference to `__end_builtin_fw'
drivers/built-in.o: In function `release_firmware':
(.text+0x192dc): undefined reference to `__start_builtin_fw'
drivers/built-in.o: In function `_request_firmware':
firmware_class.c:(.text+0x19860): undefined reference to `__start_builtin_fw'
firmware_class.c:(.text+0x19a8a): undefined reference to `__start_builtin_fw'
This trivial patch fixes this oversight.
Signed-off-by: Solomon Peachy
CC: sta...@vger.kernel.org
---
drivers/base/firmware_class.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..3474e7f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -38,7 +38,7 @@ MODULE_LICENSE("GPL");
/* Builtin firmware support */
-#ifdef CONFIG_FW_LOADER
+#ifdef CONFIG_FIRMWARE_IN_KERNEL
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [firmware_class] Fix compile with no builtin firmware
On Wed, Nov 21, 2012 at 12:01:40AM +0800, Ming Lei wrote: > > drivers/built-in.o: In function `release_firmware': > > (.text+0x192e2): undefined reference to `__end_builtin_fw' > > drivers/built-in.o: In function `release_firmware': > > (.text+0x19304): undefined reference to `__end_builtin_fw' > > drivers/built-in.o: In function `_request_firmware': > > firmware_class.c:(.text+0x1986c): undefined reference to `__end_builtin_fw' > > firmware_class.c:(.text+0x19886): undefined reference to `__end_builtin_fw' > > firmware_class.c:(.text+0x19a98): undefined reference to `__end_builtin_fw' > > drivers/built-in.o: In function `release_firmware': > > (.text+0x192dc): undefined reference to `__start_builtin_fw' > > drivers/built-in.o: In function `_request_firmware': > > firmware_class.c:(.text+0x19860): undefined reference to > > `__start_builtin_fw' > > firmware_class.c:(.text+0x19a8a): undefined reference to > > `__start_builtin_fw' > > I have tried to reproduce the compile failure but not succeed, could you share > your .config? The corresponding .config is attached. Note that it is for a uClinux 3.3.0-uc0 kernel. Even in the absence of the compile error, I believe the patch is correct. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. # # Automatically generated file; DO NOT EDIT. # Linux/m68k 3.3.0-uc0 Kernel Configuration # CONFIG_M68K=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_CSUM=y CONFIG_TIME_LOW_RES=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_NO_IOPORT=y # CONFIG_NO_DMA is not set CONFIG_ZONE_DMA=y CONFIG_CPU_HAS_NO_BITFIELDS=y CONFIG_CPU_HAS_NO_MULDIV64=y CONFIG_HZ=100 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_FHANDLE is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_SHOW=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_AIO=y CONFIG_EMBEDDED=y # # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_MMAP_ALLOW_UNINITIALIZED is not set # CONFIG_PROFILING is not set # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SYSV68_PARTITION is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set
Re: [PATCH] [firmware_class] Fix compile with no builtin firmware
On Tue, Nov 20, 2012 at 08:33:09AM -0800, Greg KH wrote: > > The corresponding .config is attached. Note that it is for a uClinux > > 3.3.0-uc0 kernel. > > Lots of things have changed in the firmware code since 3.3.0, can you > retest this on the 3.7-rc6 tree? Not easily; My employer is contracted to do some driver porting and we're stuck with the kernel the client provided. However, the patch is still relevant for upstream, because the underlying problem still exists: * The #ifdef wraps code that pertains solely to built-in firmware, (ie CONFIG_FIRMWARE_IN_KERNEL) and has an #else path for when it's disabled. * There is no point in a CONFIG_FW_LOADER test inside firmware_class.c when the file isn't even compiled unless CONFIG_FW_LOADER is defined. Perhaps the compile problem is solved in newer kernels (by always generating an empty builtin firmware list?) but the #ifdef is still incorrect. > Also, when sending patches, please cc: the proper maintainers (the > scripts/get_maintainers.pl tool can help you with that.) Ooops, sorry. I'll double-check that next time. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. pgpEGmKF2bMRv.pgp Description: PGP signature
Re: [PATCH 4/4] cw1200: hwio: Remove an unnecessary goto
On Tue, Jun 04, 2013 at 07:44:50AM -0700, Joe Perches wrote:
> goto after return is wrong.
>
> The other code in this block needs to set an
> error value then goto an error release block.
>
> This one doesn't need to release anything and
> was likely a copy/paste remainder.
>
> Signed-off-by: Joe Perches
Acked-By: Solomon Peachy
> ---
> drivers/net/wireless/cw1200/hwio.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/cw1200/hwio.c
> b/drivers/net/wireless/cw1200/hwio.c
> index 142f45ef..dad3fb3 100644
> --- a/drivers/net/wireless/cw1200/hwio.c
> +++ b/drivers/net/wireless/cw1200/hwio.c
> @@ -178,7 +178,6 @@ int cw1200_indirect_read(struct cw1200_common *priv, u32
> addr, void *buf,
> if ((buf_len / 2) >= 0x1000) {
> pr_err("Can't read more than 0xfff words.\n");
> return -EINVAL;
> - goto out;
> }
>
> priv->hwbus_ops->lock(priv->hwbus_priv);
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
pgp0hfe3t3G9W.pgp
Description: PGP signature
Re: [PATCH] cw1200: fix some obvious mistakes
On Mon, Jun 03, 2013 at 10:40:42AM +0200, Arnd Bergmann wrote: > It's much better than what you have today, but not ideal because it > means the driver cannot be a loadable module any more. At least not when being built with platform data, anyway. I suppose the next step here is to define some devicetree mappings for this device. > At least it's not in a released kernel yet. Given the boneheaded buffer overflow bug that was just pointed out (and fixed), I'm glad it's getting a lot more scrutiny. > Regarding a long-term solution, I think what we should do here is to > move the reset logic into the SDIO framework itself: We have similar > requirements even for eMMC and SD cards, where you need to provide > the correct voltage to a device on the MMC port in order for it to > work. Today this is supported to a varying degree on the MMC controller > level, where we hook into various frameworks (clk, reset-controller, > regulator, gpio, pinctrl, power domain) based on platformm data or > device tree information on the controller node. If I understand you correctly, the "traditional" platform data -- power supply, clock source, and gpio (ie POWERUP, RESET) lines would be brought up using this mechanism, in order to get the device to attach to the SDIO bus. One wrinkle here is that the cw1200 has some minimum timing requirements between when each of those signals are brought up; I don't know if there's a way to encode that into the devicetree. But that's only half the equation. Once the device has identified it to the SDIO bus and the driver's probe() function is called, the other half of the platform data is needed to successfully probe the hardware. Namely, the 'ref_clk' field. This would need to be made available to the probe() call (eg via func->dev.platform_data) but from what I can tell there's currently no mechanism to make that connection. Anyway, it's time for bed. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpbRT0QVvyWc.pgp Description: PGP signature
Re: [PATCH] cw1200: fix some obvious mistakes
On Sun, Jun 02, 2013 at 12:37:21AM +0200, Arnd Bergmann wrote: > I got compile errors with the cw1200, which has lead me to take a > closer look. It seems the driver still has a number of issues, > and this addresses some of them and marks others as FIXME: In short, NACK, at least not as posted. The concerns are legitimate, but the time to object to such fundamental stuff was at some point during the past *seven* rounds of patches I posted over a period of nearly as many months. Most of the objections you are raising are for deliberate design/implementation decisions I made to deal with the realities of the requirements of the cw1200 design and already-in-the-wild hardware that this driver has to support. > * The cw1200_sagrad.c file should not be there, hardcoding > hardware configuration in .c files has been obsolete since > Linux-2.4, so we should just remove it. Most of that file > was already commented out since it does not compile. The problem with the cw1200 is that you need certain information about the hardware design in order to initialize it; this information has to come from somewhere. The Sagrad wifi devices are available in a standard SD form factor reference design that plugs into a standard SDIO-supporing slot. The cw1200_sagrad module is there to support these off-the-shelf devices. Requiring users to recompile their kernel or update their devicetree data for what amounts to an off-the-shelf hot-pluggable device is simply not acceptable. At the same time, if people plop the sagrad device directly on their board (or independently do a chip-down design) they may need to make changes to the platform data depending on how closely it tracks the Sagrad reference design. Further complicating things, there's no way to alter the SDIO vendor/device IDs that the device reports in order to distingish between any of this. If you have a better suggestion on how to handle this set of conflicting requirements then I'm all ears, but it's rather pointless to object to code that's ugly because it has to support ugly hardware. (That said, the commented-out bits in cw1200_sagrad are mostly there for documentation purposes, and it could be moved to a proper documentation file instead.) > * Move the parts of cw1200_sagrad.c that actually got used into > cw1200_sdio.c, because it doesn't build otherwise. The idea was that either you build cw1200_sagrad or provide your own platform_data. I separated all of the implemenation-specific code out as cleanly as I could. > * Make the platform_data for the sdio driver private to > cw1200_sdio.c. The platform that was referenced here is > going to use device tree based probing only in the future, > which means the platform data has to go away anyway. When you say "the platform" what are you referring to? SDIO? There's no mention of any specific board (or even arch/subarch) in cw1200_sdio or cw1200_sagrad. In the real world, this driver will have to support non-devicetree operation for as long as Linux does, and indeed longer, thanks to compat-drivers/backports. And for what it's worth, none of the platforms I have access to have devicetree support since I'm stuck using vendor-supplied kernels. > * Move the platform_data for the spi driver to > include/linux/platform_data/net-cw1200.h where all other > drivers have their platform_data. Not all drivers, but fair enough. > * Add comments about passing GPIO numbers in platform_data: > You should not use IORESOURCE_IO, which is for legacy ISA > I/O ports on PCs, not for GPIOs. Fair enough. The use of resources was something already in the driver when I inherited it, but I've seen this pattern a lot elsewhere. Is there a specific driver I should reference instead? > It may actually be easier to remove the sdio driver entirely, > since it clearly doesn't work and requires a lot of cleanup. Several hundred thousand in-the-field devices already deployed with this driver clearly disagree with you. I've personally tested this driver on six different hardware platforms, using mainline kernels for some and vendor-supplied kernels for others. With module-down and SD-slot designs. Others have tested other platforms. Every configurable option and line item in both the SPI and SDIO platform data is there because it needs to be in order to support the variety of hardware designs already in the wild. This driver will also be part of the compat-drivers/backports project, and as such has to work within that framework as well. If you have constructive suggestions on how to handle this set of requirements in a cleaner manner, I'm all ears. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpOuwDNmVHx9.pgp Description: PGP signature
Re: [PATCH] cw1200: fix some obvious mistakes
On Sun, Jun 02, 2013 at 08:29:54AM -0400, Solomon Peachy wrote: > > * Add comments about passing GPIO numbers in platform_data: > > You should not use IORESOURCE_IO, which is for legacy ISA > > I/O ports on PCs, not for GPIOs. > > Fair enough. The use of resources was something already in the driver > when I inherited it, but I've seen this pattern a lot elsewhere. Is > there a specific driver I should reference instead? Reading linux/ioport.h I don't see a type that seems to be a better fit. It's not MEM, REG, IRQ, DMA, or BUS. IO seems to be the only type that fits. The reason the driver uses struct resources instead of straight-up numeric GPIO fields is for the 'name' field in the resources. Given that the use of platform_data pretty much makes it impossible to have more than one of these devices in a system at a time, there doesn't seem to be a point to using named resources. So I'll change these resource lists to using straight-up ints. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgptocu1XYimr.pgp Description: PGP signature
Re: [PATCH] cw1200: fix some obvious mistakes
just crashes when I do 'ifconfig wlan0 up' > or enable WLAN in the Android settings menu. :( > > I'm not blaming you for that ;-) What model, out of curiousity? > I think the most important part is separating the generic sagrad > add-on card code from any platform-specific code and removing the > use of cw1200_get_platform_data() function that breaks the build. I'll convert SDIO driver to using the sagrad data as default and add a 'set_platform_data' sort of function to allow it to be optionally overridden. It shouldn't take long, and I'll post the patch as soon as I'm finished. (I don't know how long it'll take to get merged though.. none of the already-posted followup cw1200 patches have been merged into wireless-next yet) - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpj4yuHu7hZd.pgp Description: PGP signature
Re: [PATCH] [firmware_class] Fix compile with no builtin firmware
On Wed, Nov 21, 2012 at 09:35:28AM +0800, Ming Lei wrote: > Solomon, I can't duplicate the build failure with your .config on > 3.7-rc5-next. Okay, so it's since been fixed. > > * The #ifdef wraps code that pertains solely to built-in firmware, (ie > >CONFIG_FIRMWARE_IN_KERNEL) and has an #else path for when it's disabled. > > * There is no point in a CONFIG_FW_LOADER test inside firmware_class.c > >when the file isn't even compiled unless CONFIG_FW_LOADER is defined. > > Enabling CONFIG_EXTRA_FIRMWARE still can make one firmware built in kernel > even though CONFIG_FIRMWARE_IN_KERNEL isn't defined, so your patch will break > this case. So... isn't the logical solution here to make CONFIG_EXTRA_FIRMARE depend on (or enable) CONFIG_FIRMWARE_IN_KERNEL? After all, the two are apparently related. I can update my patch to include this, and rewrite the commit message so it's relevant to modern kernels, or I can just drop this and forget the whole affair. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. pgpYbvGzbkVNx.pgp Description: PGP signature
Re: [PATCH] [firmware_class] Fix compile with no builtin firmware
On Thu, Nov 22, 2012 at 09:45:23AM +0800, Ming Lei wrote:
> No, it is not related closely, CONFIG_FIRMWARE_IN_KERNEL means
> that all in-kernel-tree firmware blobs should be included in kernel binary,
> but CONFIG_EXTRA_FIRMARE means that one additional firmware
> image will be put into kernel binary.
Okay.
> Considered that there is no your problem in -linus tree or -next tree
> and the current code works for long time, maybe it is better to not
> touch the code. Or suggest you to study this kind of config options
> and firmware/Makefie first, then figure out one proper patch.
Given what you've told me (i.e. support for loading "builtin" firmware is
always required), I propose this patch instead:
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..d291e15 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -38,8 +38,6 @@ MODULE_LICENSE("GPL");
/* Builtin firmware support */
-#ifdef CONFIG_FW_LOADER
-
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
@@ -69,19 +67,6 @@ static bool fw_is_builtin_firmware(const struct firmware *fw)
return false;
}
-#else /* Module case - no builtin firmware support */
-
-static inline bool fw_get_builtin_firmware(struct firmware *fw, const char
*name)
-{
- return false;
-}
-
-static inline bool fw_is_builtin_firmware(const struct firmware *fw)
-{
- return false;
-}
-#endif
-
enum {
FW_STATUS_LOADING,
FW_STATUS_DONE,
The empty stub functions can never be compiled, as firmware_class.c
isn't compiled when CONFIG_FW_LOADER isn't enabled. So let's just nuke
this unused code entirely.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
pgpTEJb4cbzBm.pgp
Description: PGP signature
Re: [PATCH] cw1200: fix bogus maybe-uninitialized warning
On Tue, Oct 25, 2016 at 01:24:55PM +, David Laight wrote:
> > - if (count > 1) {
> > - /* We already released one buffer, now for the rest */
> > - ret = wsm_release_tx_buffer(priv, count - 1);
> > - if (ret < 0)
> > - return ret;
> > - else if (ret > 0)
> > - cw1200_bh_wakeup(priv);
> > - }
> > + /* We already released one buffer, now for the rest */
> > + ret = wsm_release_tx_buffer(priv, count - 1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (ret > 0)
> > + cw1200_bh_wakeup(priv);
>
> That doesn't look equivalent to me (when count == 1).
I concur, this patch should not be applied in its current form.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
signature.asc
Description: PGP signature
