[REPOST 2, PATCH] builddeb: really include objtool binary in headers package
[added linux-kbu...@vger.kernel.org to Cc:, added Fixes:]
On May 4th, Bjørn Mork provided patch
697bbc7b832048d3a679cd55caf2268a325efbe0 to include objtool binaries in
the headers package. However, that one only works if $srctree=$objtree,
because the objtool binaries are not written to the srctree, but
to the objtree.
Signed-off-by: Wilfried Klaebe
Fixes: 697bbc7b8320 ("builddeb: include objtool binary in headers package")
---
builddeb |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 86e56fe..202d6e7 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -322,12 +322,12 @@ fi
# Build kernel header package
(cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) >
"$objtree/debian/hdrsrcfiles"
-if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then
- (cd $srctree; find tools/objtool -type f -executable) >>
"$objtree/debian/hdrsrcfiles"
-fi
(cd $srctree; find arch/*/include include scripts -type f) >>
"$objtree/debian/hdrsrcfiles"
(cd $srctree; find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms -o
-name Platform) >> "$objtree/debian/hdrsrcfiles"
(cd $srctree; find $(find arch/$SRCARCH -name include -o -name scripts -type
d) -type f) >> "$objtree/debian/hdrsrcfiles"
+if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then
+ (cd $objtree; find tools/objtool -type f -executable) >>
"$objtree/debian/hdrobjfiles"
+fi
(cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts -type
f) >> "$objtree/debian/hdrobjfiles"
destdir=$kernel_headers_dir/usr/src/linux-headers-$version
mkdir -p "$destdir"
--
[REPOST, PATCH] builddeb: really include objtool binary in headers package
On May 4th, Bjørn Mork provided patch 697bbc7b832048d3a679cd55caf2268a325efbe0 to include objtool binaries in the headers package. However, that one only works if $srctree=$objtree, because the objtool binaries are not written to the srctree, but to the objtree. Signed-off-by: Wilfried Klaebe --- builddeb |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/package/builddeb b/scripts/package/builddeb index 86e56fe..202d6e7 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -322,12 +322,12 @@ fi # Build kernel header package (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > "$objtree/debian/hdrsrcfiles" -if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then - (cd $srctree; find tools/objtool -type f -executable) >> "$objtree/debian/hdrsrcfiles" -fi (cd $srctree; find arch/*/include include scripts -type f) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms -o -name Platform) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find $(find arch/$SRCARCH -name include -o -name scripts -type d) -type f) >> "$objtree/debian/hdrsrcfiles" +if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then + (cd $objtree; find tools/objtool -type f -executable) >> "$objtree/debian/hdrobjfiles" +fi (cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts -type f) >> "$objtree/debian/hdrobjfiles" destdir=$kernel_headers_dir/usr/src/linux-headers-$version mkdir -p "$destdir" --
[PATCH] builddeb: really include objtool binary in headers package
On May 4th, Bjørn Mork provided patch 697bbc7b832048d3a679cd55caf2268a325efbe0 to include objtool binaries in the headers package. Sadly, that one only works if $srctree=$objtree, because the objtool binaries are not written to the srctree, but to the objtree. Signed-off-by: Wilfried Klaebe diff --git a/scripts/package/builddeb b/scripts/package/builddeb index 86e56fe..202d6e7 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -322,12 +322,12 @@ fi # Build kernel header package (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > "$objtree/debian/hdrsrcfiles" -if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then - (cd $srctree; find tools/objtool -type f -executable) >> "$objtree/debian/hdrsrcfiles" -fi (cd $srctree; find arch/*/include include scripts -type f) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms -o -name Platform) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find $(find arch/$SRCARCH -name include -o -name scripts -type d) -type f) >> "$objtree/debian/hdrsrcfiles" +if grep -q '^CONFIG_STACK_VALIDATION=y' $KCONFIG_CONFIG ; then + (cd $objtree; find tools/objtool -type f -executable) >> "$objtree/debian/hdrobjfiles" +fi (cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts -type f) >> "$objtree/debian/hdrobjfiles" destdir=$kernel_headers_dir/usr/src/linux-headers-$version mkdir -p "$destdir"
Re: [PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed
tldr: works now, without patch, without GRUB, with efi-stub
Am Tue, Nov 25, 2014 at 05:25:50PM + schrieb Matthew Garrett:
> On Tue, Nov 25, 2014 at 12:14:21PM -0500, Alex Deucher wrote:
> > The vbios image is available via ACPI prior to the OS taking over.
> > IIRC, Matthew Garret fixed up the bootloader to fetch the vbios image
> > prior to loading Linux so that it could be accessed after the OS
> > loaded.
>
> EFI rather than ACPI, but yeah. In theory this should work fine if
> you're using the EFI entry point. I don't know whether the patches for
> linuxefi were ever accepted by grub upstream - if not, pushing those
> would make more sense.
I could not find any patches for GRUB in this context. I did find big
numbers of web pages detailing how one would need to disable KMS to
use the radeon, or how to patch the radeon driver to load a vbios dump
from a file, or plain telling radeon didn't work. At least one for
about every Linux distribution I have heard of, and then some.
I could not find a way to use the EFI entry point from GRUB either.
Using the "linux" command was what never worked for me. I tried
"linuxefi", which complained about an invalid signature.
I then had a look at rEFInd again, upgraded it to the current version,
and then booted from rEFInd the same Linux 3.18-rc6 image (without the
patch) that did not work with GRUB earlier, and everything works ok.
Going to remove GRUB now :)
Sorry for any inconvenience...
Best regards,
Wilfried
---
Some details for others who might find this useful:
Hardware: MacBookPro8,2
Boot "chain": EFI -> rEFInd 0.8.3 ("gnuefi" variant) -> Linux 3.18-rc6
Kernel Commandline: "ro root=/dev/vg0/root video=radeondrmfb:1680x1050-32@60
radeon.dpm=1 video=inteldrmfb:1680x1050-32@60 i915.lvds_use_ssc=0
i915.lvds_downclock=1"
--
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/
[PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed
At least Apple's MacBook Pro 8,2 booting EFI -> GRUB2 -> Linux (without
BIOS emulation) seems to have no Radeon BIOS accessible via conventional
means. Loading one via firmware system previously dumped (with
"dd if=/dev/mem of=/lib/firmware/radeon/vbios.bin bs=65536 skip=12 count=1")
when booted with BIOS emulation works. I carry this patch around since
about 3.8 and never had any problems, not even with several dozen cycles
of suspend2ram and resume. Also, I tested every new release if this patch
was still necessary, and it always was.
Thanks to Stefan Dösinger and others at
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=26891
Signed-off-by: Wilfried Klaebe
---
Note: I'm not subscribed to dri-de...@lists.freedesktop.org, please cc:
me if replying there.
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 63ccb8f..cf55e0e 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -29,6 +29,7 @@
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
+#include
#include
#include
@@ -74,6 +75,44 @@ static bool igp_read_bios_from_vram(struct radeon_device
*rdev)
return true;
}
+static bool radeon_read_bios_from_firmware(struct radeon_device *rdev)
+{
+ const uint8_t __iomem *bios;
+ resource_size_t size;
+ const struct firmware *fw = NULL;
+ char *err = NULL;
+
+ request_firmware(&fw, "radeon/vbios.bin", rdev->dev);
+ if (!fw) {
+ err = "firmware request returned NULL\n";
+ goto out;
+ }
+ size = fw->size;
+ bios = fw->data;
+
+ if (size == 0 || !bios) {
+ err = "firmware request returned zero sized or NULL data\n";
+ goto out;
+ }
+
+ if (bios[0] != 0x55 || bios[1] != 0xaa) {
+ err = "wrong signature on firmware\n";
+ goto out;
+ }
+ rdev->bios = kmalloc(size, GFP_KERNEL);
+ if (rdev->bios == NULL) {
+ err = "failed to kmalloc() memory for firmware\n";
+ goto out;
+ }
+ memcpy(rdev->bios, bios, size);
+out:
+ if (err)
+ DRM_ERROR(err);
+ if (fw)
+ release_firmware(fw);
+ return !err;
+}
+
static bool radeon_read_bios(struct radeon_device *rdev)
{
uint8_t __iomem *bios;
@@ -662,6 +701,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = radeon_read_disabled_bios(rdev);
if (r == false)
r = radeon_read_platform_bios(rdev);
+ if (r == false)
+ r = radeon_read_bios_from_firmware(rdev);
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;
--
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/
[RESEND] [PATCH] radeon: clean up coding style differences in radeon_get_bios()
radeon: clean up coding style differences in radeon_get_bios()
Signed-off-by: Wilfried Klaebe
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 6a03624..63ccb8f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -658,12 +658,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
- if (r == false) {
+ if (r == false)
r = radeon_read_disabled_bios(rdev);
- }
- if (r == false) {
+ if (r == false)
r = radeon_read_platform_bios(rdev);
- }
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;
--
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/
--
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/
radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios()
radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios()
Signed-off-by: Wilfried Klaebe
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 6a03624..63ccb8f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -658,12 +658,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
- if (r == false) {
+ if (r == false)
r = radeon_read_disabled_bios(rdev);
- }
- if (r == false) {
+ if (r == false)
r = radeon_read_platform_bios(rdev);
- }
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;
--
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] [resend] net: get rid of SET_ETHTOOL_OPS
Am Sun, May 11, 2014 at 01:13:47PM +0530 schrieb Anish Khurana: > SET_ETHTOOL_OPS is equivalent to : > #define SET_ETHTOOL_OPS(netdev,ops) \ > ( (netdev)->ethtool_ops = (ops) ) > > how it makes difference removing this code and replacing with the > code mentioned ? It doesn't change anything in the resulting binaries. The whole point is to remove the macro, which is something Dave wants to happen. Kind regards, Wilfried -- 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/
[PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
net: get rid of SET_ETHTOOL_OPS
Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
This does that.
Mostly done via coccinelle script:
@@
struct ethtool_ops *ops;
struct net_device *dev;
@@
- SET_ETHTOOL_OPS(dev, ops);
+ dev->ethtool_ops = ops;
Compile tested only, but I'd seriously wonder if this broke anything.
Suggested-by: Dave Miller
Signed-off-by: Wilfried Klaebe
---
Applies against v3.15-rc4 and v3.15-rc5 likewise.
resend: trimmed CC list. Thanks to Dave for notifying me.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
index c4b3940..078cadd 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
@@ -105,5 +105,5 @@ static const struct ethtool_ops ipoib_ethtool_ops = {
void ipoib_set_ethtool_ops(struct net_device *dev)
{
- SET_ETHTOOL_OPS(dev, &ipoib_ethtool_ops);
+ dev->ethtool_ops = &ipoib_ethtool_ops;
}
diff --git a/drivers/net/ethernet/3com/3c509.c
b/drivers/net/ethernet/3com/3c509.c
index 35df0b9..a968654 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -534,7 +534,7 @@ static int el3_common_init(struct net_device *dev)
/* The EL3-specific entries in the device structure. */
dev->netdev_ops = &netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
- SET_ETHTOOL_OPS(dev, ðtool_ops);
+ dev->ethtool_ops = ðtool_ops;
err = register_netdev(dev);
if (err) {
diff --git a/drivers/net/ethernet/3com/3c589_cs.c
b/drivers/net/ethernet/3com/3c589_cs.c
index 063557e..f18647c 100644
--- a/drivers/net/ethernet/3com/3c589_cs.c
+++ b/drivers/net/ethernet/3com/3c589_cs.c
@@ -218,7 +218,7 @@ static int tc589_probe(struct pcmcia_device *link)
dev->netdev_ops = &el3_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
- SET_ETHTOOL_OPS(dev, &netdev_ethtool_ops);
+ dev->ethtool_ops = &netdev_ethtool_ops;
return tc589_config(link);
}
diff --git a/drivers/net/ethernet/3com/typhoon.c
b/drivers/net/ethernet/3com/typhoon.c
index 465cc71..e13b046 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2435,7 +2435,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
netif_napi_add(dev, &tp->napi, typhoon_poll, 16);
dev->watchdog_timeo = TX_TIMEOUT;
- SET_ETHTOOL_OPS(dev, &typhoon_ethtool_ops);
+ dev->ethtool_ops = &typhoon_ethtool_ops;
/* We can handle scatter gather, up to 16 entries, and
* we can do IP checksumming (only version 4, doh...)
diff --git a/drivers/net/ethernet/adaptec/starfire.c
b/drivers/net/ethernet/adaptec/starfire.c
index 171d73c..40dbbf7 100644
--- a/drivers/net/ethernet/adaptec/starfire.c
+++ b/drivers/net/ethernet/adaptec/starfire.c
@@ -784,7 +784,7 @@ static int starfire_init_one(struct pci_dev *pdev,
dev->netdev_ops = &netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
- SET_ETHTOOL_OPS(dev, ðtool_ops);
+ dev->ethtool_ops = ðtool_ops;
netif_napi_add(dev, &np->napi, netdev_poll, max_interrupt_work);
diff --git a/drivers/net/ethernet/alteon/acenic.c
b/drivers/net/ethernet/alteon/acenic.c
index 1517e9df..9a6991b 100644
--- a/drivers/net/ethernet/alteon/acenic.c
+++ b/drivers/net/ethernet/alteon/acenic.c
@@ -476,7 +476,7 @@ static int acenic_probe_one(struct pci_dev *pdev,
dev->watchdog_timeo = 5*HZ;
dev->netdev_ops = &ace_netdev_ops;
- SET_ETHTOOL_OPS(dev, &ace_ethtool_ops);
+ dev->ethtool_ops = &ace_ethtool_ops;
/* we only display this string ONCE */
if (!boards_found)
diff --git a/drivers/net/ethernet/altera/altera_tse_ethtool.c
b/drivers/net/ethernet/altera/altera_tse_ethtool.c
index 319ca74..8ac4bd2 100644
--- a/drivers/net/ethernet/altera/altera_tse_ethtool.c
+++ b/drivers/net/ethernet/altera/altera_tse_ethtool.c
@@ -231,5 +231,5 @@ static const struct ethtool_ops tse_ethtool_ops = {
void altera_tse_set_ethtool_ops(struct net_device *netdev)
{
- SET_ETHTOOL_OPS(netdev, &tse_ethtool_ops);
+ netdev->ethtool_ops = &tse_ethtool_ops;
}
diff --git a/drivers/net/ethernet/amd/amd8111e.c
b/drivers/net/ethernet/amd/amd8111e.c
index 26efaaa..068dc7c 100644
--- a/drivers/net/ethernet/amd/amd8111e.c
+++ b/drivers/net/ethernet/amd/amd8111e.c
@@ -1900,7 +1900,7 @@ static int amd8111e_probe_one(struct pci_dev *pdev,
/* Initialize driver entry points */
dev->netdev_ops = &amd8111e_netdev_ops;
- SET_ETHTOOL_OPS(dev, &ops);
+ dev->ethtool_ops = &ops;
dev->irq =pdev->irq;
dev->watchdog_timeo = AMD8111E_TX_TIMEOUT;
netif_napi_add(dev, &lp->napi, amd8111e_rx_poll, 32);
diff --git a/drivers/net/ethern
Re: [PATCH 23/24] net, diet: Add coccinelle script to convert drivers to ETHTOOL_OPS
Am Tue, May 06, 2014 at 11:05:04AM -0400 schrieb David Miller: > SET_ETHTOOL_OPS only exists so that drivers could be compiled > on "older" kernels. > > But the usefulness of that is long gone, we've had netdev->ethtool_ops > since way before we started using GIT. > > I'd rather see a patch which removes it, to be honest. Something like this? https://www.lebenslange-mailadresse.de/lkml/remove-SET_ETHTOOL_OPS.patch -- 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] staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
Am Tue, Mar 25, 2014 at 11:51:45AM -0700 schrieb Greg KH: > On Tue, Mar 25, 2014 at 06:36:18PM +0000, Wilfried Klaebe wrote: > > Am Tue, Mar 25, 2014 at 11:17:49AM -0700 schrieb Greg KH: > > > On Tue, Mar 25, 2014 at 05:59:39PM +0000, Wilfried Klaebe wrote: > > > > staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls > > > > > > > > It looks like someone did a search-and-replace on that driver, putting > > > > spaces before "=" characters, without checking this is OK everywhere. > > > > Also, in some places, there's memcpm()s/strncmp()s checking for some > > > > different length than the fixed string argument. > > > > > > > > These things result in code not working as intended. Fix that. > > > > > > What code is parsing string output from the kernel? > > > > I know about some userspace apps, for example a MiraCast Sink > > implementation for the Raspberry Pi, called piracast. > > > > This patch though is about the rtl8188eu driver parsing strings > > handed to it via "iwpriv wlanX p2p_set name=value". Which breaks, > > because the driver checks for "name =" instead of "name=" in several > > cases. > > That's horrid on so many levels... The real WTF is: why doesn't this driver use the stuff already there for Wi-Fi Direct (aka P2P Wifi)? But well, for now I just wanted to contribute my fixes to this obvious breakage; making a sensible driver out of that mess is a longer-term project. Regards, Wilfried -- 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] staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
Am Tue, Mar 25, 2014 at 11:17:49AM -0700 schrieb Greg KH: > On Tue, Mar 25, 2014 at 05:59:39PM +0000, Wilfried Klaebe wrote: > > staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls > > > > It looks like someone did a search-and-replace on that driver, putting > > spaces before "=" characters, without checking this is OK everywhere. > > Also, in some places, there's memcpm()s/strncmp()s checking for some > > different length than the fixed string argument. > > > > These things result in code not working as intended. Fix that. > > What code is parsing string output from the kernel? I know about some userspace apps, for example a MiraCast Sink implementation for the Raspberry Pi, called piracast. This patch though is about the rtl8188eu driver parsing strings handed to it via "iwpriv wlanX p2p_set name=value". Which breaks, because the driver checks for "name =" instead of "name=" in several cases. Regards, Wilfried -- 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/
[PATCH] staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
It looks like someone did a search-and-replace on that driver, putting
spaces before "=" characters, without checking this is OK everywhere.
Also, in some places, there's memcpm()s/strncmp()s checking for some
different length than the fixed string argument.
These things result in code not working as intended. Fix that.
Signed-off-by: Wilfried Klaebe
---
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 4ad80ae..aef393b 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -358,7 +358,7 @@ static char *translate_scan(struct adapter *padapter,
if (wpa_len > 0) {
p = buf;
_rtw_memset(buf, 0, MAX_WPA_IE_LEN);
- p += sprintf(p, "wpa_ie =");
+ p += sprintf(p, "wpa_ie=");
for (i = 0; i < wpa_len; i++)
p += sprintf(p, "%02x", wpa_ie[i]);
@@ -375,7 +375,7 @@ static char *translate_scan(struct adapter *padapter,
if (rsn_len > 0) {
p = buf;
_rtw_memset(buf, 0, MAX_WPA_IE_LEN);
- p += sprintf(p, "rsn_ie =");
+ p += sprintf(p, "rsn_ie=");
for (i = 0; i < rsn_len; i++)
p += sprintf(p, "%02x", rsn_ie[i]);
_rtw_memset(&iwe, 0, sizeof(iwe));
@@ -2948,7 +2948,7 @@ static int rtw_p2p_get_status(struct net_device *dev,
/* Commented by Albert 2010/10/12 */
/* Because of the output size limitation, I had removed the "Role"
information. */
/* About the "Role" information, we will use the new private IOCTL
to get the "Role" information. */
- sprintf(extra, "\n\nStatus =%.2d\n", rtw_p2p_state(pwdinfo));
+ sprintf(extra, "\n\nStatus=%.2d\n", rtw_p2p_state(pwdinfo));
wrqu->data.length = strlen(extra);
return ret;
@@ -2967,7 +2967,7 @@ static int rtw_p2p_get_req_cm(struct net_device *dev,
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct wifidirect_info *pwdinfo = &(padapter->wdinfo);
- sprintf(extra, "\n\nCM =%s\n",
pwdinfo->rx_prov_disc_info.strconfig_method_desc_of_prov_disc_req);
+ sprintf(extra, "\n\nCM=%s\n",
pwdinfo->rx_prov_disc_info.strconfig_method_desc_of_prov_disc_req);
wrqu->data.length = strlen(extra);
return ret;
}
@@ -2984,7 +2984,7 @@ static int rtw_p2p_get_role(struct net_device *dev,
pwdinfo->p2p_peer_interface_addr[0],
pwdinfo->p2p_peer_interface_addr[1], pwdinfo->p2p_peer_interface_addr[2],
pwdinfo->p2p_peer_interface_addr[3],
pwdinfo->p2p_peer_interface_addr[4], pwdinfo->p2p_peer_interface_addr[5]);
- sprintf(extra, "\n\nRole =%.2d\n", rtw_p2p_role(pwdinfo));
+ sprintf(extra, "\n\nRole=%.2d\n", rtw_p2p_role(pwdinfo));
wrqu->data.length = strlen(extra);
return ret;
}
@@ -3071,7 +3071,7 @@ static int rtw_p2p_get_op_ch(struct net_device *dev,
DBG_88E("[%s] Op_ch = %02x\n", __func__, pwdinfo->operating_channel);
- sprintf(extra, "\n\nOp_ch =%.2d\n", pwdinfo->operating_channel);
+ sprintf(extra, "\n\nOp_ch=%.2d\n", pwdinfo->operating_channel);
wrqu->data.length = strlen(extra);
return ret;
}
@@ -3092,7 +3092,7 @@ static int rtw_p2p_get_wps_configmethod(struct net_device
*dev,
u8 blnMatch = 0;
u16 attr_content = 0;
uint attr_contentlen = 0;
- /* 6 is the string "wpsCM =", 17 is the MAC addr, we have to clear it
at wrqu->data.pointer */
+ /* 6 is the string "wpsCM=", 17 is the MAC addr, we have to clear it at
wrqu->data.pointer */
u8 attr_content_str[6 + 17] = {0x00};
/* Commented by Albert 20110727 */
@@ -3128,7 +3128,7 @@ static int rtw_p2p_get_wps_configmethod(struct net_device
*dev,
rtw_get_wps_attr_content(wpsie, wpsie_len,
WPS_ATTR_CONF_METHOD, (u8 *) &be_tmp, &attr_contentlen);
if (attr_contentlen) {
attr_content = be16_to_cpu(be_tmp);
- sprintf(attr_content_str, "\n\nM
=%.4d", attr_content);
+ sprintf(attr_content_str, "\n\nM=%.4d",
attr_content);
blnMatch = 1;
}
Re: What still uses the block layer?
Am Mon, Oct 15, 2007 at 04:26:04AM -0500 schrieb Rob Landley: > To clarify, I think that merging ide, sata, usb, firewire, and others into a > single device namespace causes each type of device to inherit that > namespace's cumulative ordering issues, which is a bad thing. I have no real > attachment to the underlying scsi or block layers. I've never seriously > worked on either (although I'm trying to understand both). > > For example, usb devices are never easy to order. IDE devices (back when > they > had their own namespace) were trivial to order back when /dev/hda couldn't > move without use of a screwdriver. USB and IDE devices are very different in > that it's not possible to plug a USB device into an IDE controller (not > without one _heck_ of an adapter) and vice versa. USB devices usually live > outside the computer's case, and IDE devices inside the case. They're not > the same thing. > > Combining USB and IDE into the same /dev/sd? namespace makes enumerating the > IDE devices much harder than in the traditional "/dev/hdb doesn't move > without a screwdriver" model. I have udev here, and it generates several useful symlinks. /dev/disk/by-path/pci-:00:1f.1-scsi-0:0:0:0-part2 will always point to the second primary partition of the IDE master on the first IDE channel here, be there as many USB sticks as there may. (But still I'd like it if it wasn't named "scsi-0:0:0:0", because the "0:0:0:0" part could change.) > The merger creates a new problem for IDE, one > which didn't exist before: the addition or removal of other unrelated types > of devices may change this device's location next boot. It may be possible > to add additional complication to the system to compensate, but what was the > advantage of merging the namespaces in the first place? I don't think there was any intent to merge namespaces. It "just happened" as a byproduct of having sata/pata use the scsi subsystem. Wilfried -- Irgendwas ist ja immer... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build error
On Tue, Oct 02, 2007 at 05:39:21PM -0700 Stephen Hemminger wrote: > There were earlier reports of gcc 4.3 bogus optimization: > http://lkml.org/lkml/2007/5/18/355 Indeed, it compiled cleanly with gcc 4.2. Thanks. This won't happen again. Wilfried -- Irgendwas ist ja immer... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
