Re: [PATCH v3 2/4] staging: rtl8192u: fix whitespace
On Wed, Dec 31, 2014 at 09:40:13PM -0800, Joe Perches wrote: > On Thu, 2015-01-01 at 10:17 +0530, Sudip Mukherjee wrote: > > On Wed, Dec 31, 2014 at 09:33:43PM +, Lorenzo Stoakes wrote: > > > This patch fixes warnings/errors raised by checkpatch.pl relating to > > > whitespace > > > in r8192U_dm.c and additionally it removes inconsistent whitespace > > > throughout. > > > > > > Additionally some 0x00... padding has been added for alignment to the > > > edca_setting_* variables. > > > > i may be wrong, but looks like you are doing many different things in the > > patch, not just whitespace errors. > > marked a few, please see inline - > > Don't get carried away with patch type separation > and please remember to trim your replies to just > the areas you comment on. sorry for not trimming that. I noticed the big size while sending, but at that time the damage has already been done. but is it ok if we mention one thing in the commit log and do other things also? shouldn't we atleast mention that in the commit? sorry again. sudip > > -- 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 v3 2/4] staging: rtl8192u: fix whitespace
On Thu, 2015-01-01 at 10:17 +0530, Sudip Mukherjee wrote: > On Wed, Dec 31, 2014 at 09:33:43PM +, Lorenzo Stoakes wrote: > > This patch fixes warnings/errors raised by checkpatch.pl relating to > > whitespace > > in r8192U_dm.c and additionally it removes inconsistent whitespace > > throughout. > > > > Additionally some 0x00... padding has been added for alignment to the > > edca_setting_* variables. > > i may be wrong, but looks like you are doing many different things in the > patch, not just whitespace errors. > marked a few, please see inline - Don't get carried away with patch type separation and please remember to trim your replies to just the areas you comment on. -- 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] ovl: Prevent rw remount when it should be ro mount
Overlayfs should be mounted read-only when upper fs is r/o or nonexistend.
But now it can be remounted read-write and this can causes kernel panic.
So we should prevent read-write remount when the above situation.
Signed-off-by: Seunghun Lee
---
fs/overlayfs/super.c | 8
1 file changed, 8 insertions(+)
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 84f3144..1faa5e5 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -522,6 +522,14 @@ static int ovl_show_options(struct seq_file *m, struct
dentry *dentry)
return 0;
}
+static int squashfs_remount(struct super_block *sb, int *flags, char *data)
+{
+ if (!ufs->upper_mnt || (ufs->upper_mnt->mnt_sb->s_flags & MS_RDONLY))
+ *flags |= MS_RDONLY;
+
+ return 0;
+}
+
static const struct super_operations ovl_super_operations = {
.put_super = ovl_put_super,
.statfs = ovl_statfs,
--
2.1.3
--
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 v2 3/4] staging: rtl8192u: remove redundant code
On Thu, Jan 01, 2015 at 10:19:56AM +0530, Sudip Mukherjee wrote:
> On Wed, Dec 31, 2014 at 09:10:42PM +, Lorenzo Stoakes wrote:
> > This patch fixes warnings/errors raised by checkpatch.pl relating to
> > redundant
> > code in r8192U_dm.c.
> >
> > Signed-off-by: Lorenzo Stoakes
> > ---
> > drivers/staging/rtl8192u/r8192U_dm.c | 176
> > +--
> > 1 file changed, 84 insertions(+), 92 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> > b/drivers/staging/rtl8192u/r8192U_dm.c
> > index 862d2ab..ed566bb 100644
> > --- a/drivers/staging/rtl8192u/r8192U_dm.c
> > +++ b/drivers/staging/rtl8192u/r8192U_dm.c
> > @@ -410,9 +410,9 @@ static void dm_check_rate_adaptive(struct net_device
> > *dev)
> >
> > ratr_value = targetRATR;
> > RT_TRACE(COMP_RATE, "currentRATR = %x, targetRATR =
> > %x\n", currentRATR, targetRATR);
> > - if (priv->rf_type == RF_1T2R) {
> > + if (priv->rf_type == RF_1T2R)
> > ratr_value &= ~(RATE_ALL_OFDM_2SS);
> > - }
> > +
> but this is just removal of unnecessary braces. this is not removal of
> redundant code.
and, missed writing in the last mail.
your [PATCH v2 2/4] and [PATCH v2 3/4] are same.
thanks
sudip
>
> > write_nic_dword(dev, RATR0, ratr_value);
> > write_nic_byte(dev, UFWP, 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/
Re: [PATCH v2 3/4] staging: rtl8192u: remove redundant code
On Wed, Dec 31, 2014 at 09:10:42PM +, Lorenzo Stoakes wrote:
> This patch fixes warnings/errors raised by checkpatch.pl relating to redundant
> code in r8192U_dm.c.
>
> Signed-off-by: Lorenzo Stoakes
> ---
> drivers/staging/rtl8192u/r8192U_dm.c | 176
> +--
> 1 file changed, 84 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> b/drivers/staging/rtl8192u/r8192U_dm.c
> index 862d2ab..ed566bb 100644
> --- a/drivers/staging/rtl8192u/r8192U_dm.c
> +++ b/drivers/staging/rtl8192u/r8192U_dm.c
> @@ -410,9 +410,9 @@ static void dm_check_rate_adaptive(struct net_device *dev)
>
> ratr_value = targetRATR;
> RT_TRACE(COMP_RATE, "currentRATR = %x, targetRATR =
> %x\n", currentRATR, targetRATR);
> - if (priv->rf_type == RF_1T2R) {
> + if (priv->rf_type == RF_1T2R)
> ratr_value &= ~(RATE_ALL_OFDM_2SS);
> - }
> +
but this is just removal of unnecessary braces. this is not removal of
redundant code.
> write_nic_dword(dev, RATR0, ratr_value);
> write_nic_byte(dev, UFWP, 1);
>
> @@ -440,18 +440,17 @@ static void dm_bandwidth_autoswitch(struct net_device
> *dev)
> {
> struct r8192_priv *priv = ieee80211_priv(dev);
>
> - if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
> !priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable) {
> + if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
> !priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable)
> return;
> - } else {
> - if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
> false) { /* If send packets in 40 Mhz in 20/40 */
> - if (priv->undecorated_smoothed_pwdb <=
> priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
> -
> priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = true;
> - } else { /* in force send packets in 20 Mhz in 20/40 */
> - if (priv->undecorated_smoothed_pwdb >=
> priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
> -
> priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = false;
>
> - }
> + if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz == false) {
> /* If send packets in 40 Mhz in 20/40 */
> + if (priv->undecorated_smoothed_pwdb <=
> priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
> + priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
> = true;
> + } else { /* in force send packets in 20 Mhz in 20/40 */
> + if (priv->undecorated_smoothed_pwdb >=
> priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
> + priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
> = false;
> }
> +
> }/* dm_BandwidthAutoSwitch */
>
> /* OFDM default at 0db, index=6. */
> @@ -538,9 +537,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
> net_device *dev)
> tx_cmd.Length = 4;
> tx_cmd.Value = Value;
> rtStatus = SendTxCommandPacket(dev, _cmd, 12);
> - if (rtStatus == RT_STATUS_FAILURE) {
> + if (rtStatus == RT_STATUS_FAILURE)
> RT_TRACE(COMP_POWER_TRACKING, "Set configuration with
> tx cmd queue fail!\n");
> - }
> mdelay(1);
> /*DbgPrint("hi, vivi, strange\n");*/
> for (i = 0; i <= 30; i++) {
> @@ -580,9 +578,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
> net_device *dev)
> break;
> }
>
> - for (k = 0; k < 5; k++) {
> + for (k = 0; k < 5; k++)
> Avg_TSSI_Meas_from_driver += tmp_report[k];
> - }
>
> Avg_TSSI_Meas_from_driver =
> Avg_TSSI_Meas_from_driver*100/5;
> RT_TRACE(COMP_POWER_TRACKING,
> "Avg_TSSI_Meas_from_driver = %d\n", Avg_TSSI_Meas_from_driver);
> @@ -605,56 +602,55 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
> net_device *dev)
> RT_TRACE(COMP_POWER_TRACKING,
> "priv->cck_present_attentuation_difference = %d\n",
> priv->cck_present_attentuation_difference);
> RT_TRACE(COMP_POWER_TRACKING,
> "priv->cck_present_attentuation = %d\n", priv->cck_present_attentuation);
> return;
> - } else {
> - if (Avg_TSSI_Meas_from_driver < TSSI_13dBm -
> E_FOR_TX_POWER_TRACK) {
> - if (priv->rfa_txpowertrackingindex > 0)
> {
> -
> priv->rfa_txpowertrackingindex--;
> -
Re: [PATCH v3 2/4] staging: rtl8192u: fix whitespace
On Wed, Dec 31, 2014 at 09:33:43PM +, Lorenzo Stoakes wrote:
> This patch fixes warnings/errors raised by checkpatch.pl relating to
> whitespace
> in r8192U_dm.c and additionally it removes inconsistent whitespace
> throughout.
>
> Additionally some 0x00... padding has been added for alignment to the
> edca_setting_* variables.
i may be wrong, but looks like you are doing many different things in the
patch, not just whitespace errors.
marked a few, please see inline -
>
> Signed-off-by: Lorenzo Stoakes
> ---
> drivers/staging/rtl8192u/r8192U_dm.c | 1606
> +-
> 1 file changed, 625 insertions(+), 981 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> b/drivers/staging/rtl8192u/r8192U_dm.c
> index cafc717..862d2ab 100644
> --- a/drivers/staging/rtl8192u/r8192U_dm.c
> +++ b/drivers/staging/rtl8192u/r8192U_dm.c
> @@ -22,11 +22,12 @@ Major Change History:
> #include "r819xU_cmdpkt.h"
> /*---Define Local
> Constant---*/
> /* Indicate different AP vendor for IOT issue. */
> -static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
> 0xa44f, 0x5ea44f};
> -static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
> 0x5ea44f, 0x5ea44f};
> -
> +static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0x00a44f, 0x5ea44f
> +};
> +static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0x00a44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
> +};
first type of change
>
> #define RTK_UL_EDCA 0xa44f
> #define RTK_DL_EDCA 0x5e4322
> @@ -37,7 +38,7 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
> /* Debug variable ? */
> dig_tdm_digtable;
> /* Store current software write register content for MAC PHY. */
> -u8 dm_shadow[16][256] = {{0}};
> +u8 dm_shadow[16][256] = { {0} };
second type of change
> /* For Dynamic Rx Path Selection by Signal Strength */
> DRxPathSel DM_RxPathSelTable;
> /*Define global
> variable-*/
> @@ -66,11 +67,8 @@ static voiddm_bandwidth_autoswitch(struct
> net_device *dev);
>
> static voiddm_check_txpower_tracking(struct net_device *dev);
>
> -
> -
> /*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
>
> -
third type of change
> /* DM --> Dynamic Init Gain by RSSI */
> static voiddm_dig_init(struct net_device *dev);
> static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
> @@ -89,13 +87,11 @@ staticvoiddm_check_edca_turbo(struct net_device
> *dev);
> /* DM --> Check PBC */
> static void dm_check_pbc_gpio(struct net_device *dev);
>
> -
> /* DM --> Check current RX RF path state */
> static voiddm_check_rx_path_selection(struct net_device *dev);
> static void dm_init_rxpath_selection(struct net_device *dev);
> static void dm_rxpath_sel_byrssi(struct net_device *dev);
>
> -
> /* DM --> Fsync for broadcom ap */
> static void dm_init_fsync(struct net_device *dev);
> static void dm_deInit_fsync(struct net_device *dev);
> @@ -109,7 +105,6 @@ staticvoiddm_check_txrateandretrycount(struct
> net_device *dev);
> static voiddm_init_dynamic_txpower(struct net_device *dev);
> static voiddm_dynamic_txpower(struct net_device *dev);
>
> -
> /* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
> static void dm_send_rssi_tofw(struct net_device *dev);
> static voiddm_ctstoself(struct net_device *dev);
> @@ -148,14 +143,12 @@ void init_hal_dm(struct net_device *dev)
>
> void deinit_hal_dm(struct net_device *dev)
> {
> -
> dm_deInit_fsync(dev);
> -
> }
>
> -
> #ifdef USB_RX_AGGREGATION_SUPPORT
> -void dm_CheckRxAggregation(struct net_device *dev) {
> +void dm_CheckRxAggregation(struct net_device *dev)
> +{
fourth type of change
> struct r8192_priv *priv = ieee80211_priv((struct net_device *)dev);
> PRT_HIGH_THROUGHPUT pHTInfo = priv->ieee80211->pHTInfo;
> static unsigned longlastTxOkCnt;
> @@ -184,14 +177,15 @@ void dm_CheckRxAggregation(struct net_device *dev) {
> if ((curTxOkCnt + curRxOkCnt) < 1500)
> return;
>
> - if(curTxOkCnt > 4*curRxOkCnt) {
> + if (curTxOkCnt > 4*curRxOkCnt) {
fifth type of change
> if (priv->bCurrentRxAggrEnable) {
> write_nic_dword(dev, 0x1a8, 0);
> priv->bCurrentRxAggrEnable = false;
> }
> - }else{
> + } else {
> if (!priv->bCurrentRxAggrEnable &&
> !pHTInfo->bCurrentRT2RTAggregation) {
> u32 ulValue;
> +
> ulValue = (pHTInfo->UsbRxFwAggrEn<<24) |
> (pHTInfo->UsbRxFwAggrPageNum<<16) |
>
re
Hello! $1.5 million usd. registered by an Official of the United Nation. The Fund is a donation to you from the U.N through e-mails balloting in affiliation with commonwealth poverty eradication program. For your information the VAT and COD have been paid and the only money you will have to pay is the security keeping fee which is $150.00. Payment of $150.00 must be paid before shipment. Do contact the FedEx with your. Names: Age: Telephone: Delivery Address Contact FedEx Delivery Department: Mr. Micheal Brown fedexdeliveryteamcen...@outlook.com Mobile +233543150238 Copyright © 2012 FedEx! Inc. All rights couriercompan...@gmail.com -- 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 V1 1/1] iio: Added Capella cm3232 ambient light sensor driver.
Kevin,
On Wed, Dec 31, 2014 at 04:10:30PM -0800, Kevin Tsai wrote:
> CM3232 is an advanced ambient light sensor with I2C protocol interface.
> The I2C slave address is internally hardwired as 0x10 (7-bit). Writing
> to configure register is byte mode, but reading ALS register requests to
> use word mode for 16-bit resolution.
>
> Signed-off-by: Kevin Tsai
> ---
> .../devicetree/bindings/i2c/trivial-devices.txt| 1 +
> MAINTAINERS| 6 +
> drivers/iio/light/Kconfig | 11 +
[...]
> +static int cm3232_get_lux(struct cm3232_chip *chip);
> +static int cm3232_read_als_it(struct cm3232_chip *chip, int *val2);
> +
> +/**
> + * cm3232_reg_init() - Initialize CM3232 registers
> + * @chip:pointer of struct cm3232.
> + *
> + * Initialize CM3232 ambient light sensor register to default values.
> + *
> + Return: 0 for success; otherwise for error code.
Is a '*' missing?
> + */
> +static int cm3232_reg_init(struct cm3232_chip *chip)
> +{
> + struct i2c_client *client = chip->client;
> + struct cm3232_als_info *als_info;
> + s32 ret;
> +
> + /* Identify device */
[...]
> +
> + /* Calculate mlux per bit based on als_it */
> + ret = cm3232_read_als_it(chip, _it);
> + if (ret < 0)
> + return -EINVAL;
> + tmp = (__force u64)als_info->mlux_per_bit;
> + tmp *= als_info->mlux_per_bit_base_it;
> + tmp = div_u64 (tmp, als_it);
^
no space after function
> +
> + /* Get als_raw */
> + als_info->als_raw = i2c_smbus_read_word_data(
> + client,
> + CM3232_REG_ADDR_ALS);
> + if (als_info->als_raw < 0)
> + return als_info->als_raw;
> +
> + tmp *= als_info->als_raw;
> + tmp *= als_info->calibscale;
> + tmp = div_u64(tmp, CM3232_CALIBSCALE_RESOLUTION);
> + tmp = div_u64(tmp, CM3232_MLUX_PER_LUX);
[...]
It builds clean and there are no checkpatch or sparse errors.
Overall it looks good.
--
- Jeremiah Mahler
--
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/
WIP alternative - was Re: [PATCH v3 14/20] selftests/size: add install target to enable test install
On 12/24/2014 08:27 AM, Shuah Khan wrote: > Add a new make target to enable installing test. This target > installs test in the kselftest install location and add to the > kselftest script to run the test. Install target can be run > only from top level kernel source directory. > > Signed-off-by: Shuah Khan > --- > tools/testing/selftests/size/Makefile | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/size/Makefile > b/tools/testing/selftests/size/Makefile > index 04dc25e..bb7113b 100644 > --- a/tools/testing/selftests/size/Makefile > +++ b/tools/testing/selftests/size/Makefile > @@ -1,12 +1,22 @@ > CC = $(CROSS_COMPILE)gcc > > +TEST_STR = ./get_size || echo get_size selftests: [FAIL] > + > all: get_size > > get_size: get_size.c > $(CC) -static -ffreestanding -nostartfiles -s $< -o $@ > > +install: > +ifdef INSTALL_KSFT_PATH > + install ./get_size $(INSTALL_KSFT_PATH) > + @echo "$(TEST_STR)" >> $(KSELFTEST) > +else > + @echo Run make kselftest_install in top level source directory > +endif > + > run_tests: all > - ./get_size > + @$(TEST_STR) > > clean: > $(RM) get_size > The install phase is desperately needed for usage of kselftest in cross-target situations (applicable to almost all embedded). So this is great stuff. I worked a bit on isolating the install stuff to a makefile include file. This allows simplifying some of the sub-level Makefiles a bit, and allowing control of some of the install and run logic in less places. This is still a work in progress, but before I got too far along, I wanted to post it for people to provide feedback. A couple of problems cropped up that are worth discussing, IMHO. 1) I think it should be a requirement that each test has a single "main" program to execute to run the tests. If multiple tests are supported or more flexibility is desired for additional arguments, or that sort of thing, then that's fine, but the automated script builder should be able to run just a single program or script to have things work. This also makes things more consistent. In the case of the firmware test, I created a single fw_both.sh script to do this, instead of having two separate blocks in the kselftest.sh script. 2) I've added a CROSS_INSTALL variable, which can call an arbitrary program to place files on the target system (rather than just calling 'install'). In my case, I'd use my own 'ttc cp' command, which I can extend as necessary to put things on a remote machine. This works for a single directory, but things get dicier with sub-directory trees full of files (like the ftrace test uses.) If additional items need to be installed to the target, then maybe a setup program should be used, rather than just copying files. 3) Some of the scripts were using /bin/bash to execute them, rather than rely on the interpreter line in the script itself (and having the script have executable privileges). Is there a reason for this? I modified a few scripts to be executable, and got rid of the explicit execution with /bin/bash. The following is just a start... Let me know if this direction looks OK, and I'll finish this up. The main item to look at is kselftest.include file. Note that these patches are based on Shuah's series - but if you want to use these ideas I can rebase them onto mainline, and break them out per test sub-level like Shuah did. Let me know what you think. >From 14164fd3117c97799a050f8cf791dedc93aa5e82 Mon Sep 17 00:00:00 2001 From: Tim Bird Date: Wed, 31 Dec 2014 18:04:08 -0800 Subject: [PATCH] Switch to using an include file for common kselftest_install actions --- tools/testing/selftests/cpu-hotplug/Makefile | 15 +++--- .../selftests/cpu-hotplug/cpu-on-off-test.sh | 0 tools/testing/selftests/efivarfs/Makefile | 21 -- tools/testing/selftests/efivarfs/efivarfs.sh | 0 tools/testing/selftests/firmware/Makefile | 32 -- tools/testing/selftests/firmware/fw_both.sh| 13 + tools/testing/selftests/kselftest.include | 26 ++ tools/testing/selftests/size/Makefile | 19 +++-- 9 files changed, 60 insertions(+), 69 deletions(-) mode change 100644 => 100755 tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh mode change 100644 => 100755 tools/testing/selftests/efivarfs/efivarfs.sh create mode 100755 tools/testing/selftests/firmware/fw_both.sh create mode 100644 tools/testing/selftests/kselftest.include diff --git a/tools/testing/selftests/cpu-hotplug/Makefile b/tools/testing/selftests/cpu-hotplug/Makefile index c9e15ee..d2e540d 100644 --- a/tools/testing/selftests/cpu-hotplug/Makefile +++ b/tools/testing/selftests/cpu-hotplug/Makefile @@ -1,18 +1,11 @@ -TEST_STR=/bin/bash ./cpu-on-off-test.sh || echo cpu-hotplug selftests: [FAIL] +TEST_TITLE = cpu-hotplug +TEST_MAIN_PROG = cpu-on-off-test.sh all: -install:
Re: [PATCH v3 0/6] support GMAC driver for RK3288
Hi David, Am Mittwoch, 31. Dezember 2014, 19:15:38 schrieb David Miller: > From: Roger Chen > Date: Mon, 29 Dec 2014 17:42:32 +0800 > > > Roger Chen (6): > > patch1: add driver for Rockchip RK3288 SoCs integrated GMAC > > patch2: define clock ID used for GMAC > > patch3: modify CRU config for Rockchip RK3288 SoCs integrated GMAC > > patch4: dts: rockchip: add gmac info for rk3288 > > patch5: dts: rockchip: enable gmac on RK3288 evb board > > patch6: add document for Rockchip RK3288 GMAC > > > > Tested on rk3288 evb board: > > Execute the following command to enable ethernet, > > set local IP and ping a remote host. > > > > busybox ifconfig eth0 up > > busybox ifconfig eth0 192.168.1.111 > > ping 192.168.1.1 > > Series applied to net-next, thanks. could we split this up a bit instead? If everything goes through your tree, we'll end up with a lot of conflicts with other pending stuff, so I'd really appreciate if you could leave out patches patch2: define clock ID used for GMAC patch3: modify CRU config for Rockchip RK3288 SoCs integrated GMAC patch4: dts: rockchip: add gmac info for rk3288 patch5: dts: rockchip: enable gmac on RK3288 evb board so only take the driver itself and the dt-binding and I would take these 4 above through the appropriate trees (clk and arm-soc) Thanks and happy new year Heiko -- 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: [RFC 0/8] ARM64: Uprobe support added
+Dave
Sorry, I took all cc list from your kprobe patches and forgot to add you. :(
Please review.
On Wednesday 31 December 2014 08:51 PM, Pratyush Anand wrote:
These patches have been prepared on top of ARM64 kprobe v3 patches [1]
under review.
Unit test for following has been done so far and they have been found
working
1. Normal instruction, which can be probed like sub, ldr, add etc.
2. Instructions which can be simulated like ret.
3. uretprobe
[1]https://lkml.org/lkml/2014/11/18/33
Pratyush Anand (8):
ARM64: Move BRK opcodes defines from kprobes.h to insn.h
ARM64: Refactor kprobes-arm64
Kernel/uprobe: Define arch_uprobe_exception_notify as __weak
ARM64: Add instruction_pointer_set function
ARM64: Re-factor flush_ptrace_access
ARM64: Handle TRAP_HWBRKPT for user mode as well
ARM64: Handle TRAP_BRKPT for user mode as well
ARM64: Add uprobe support
arch/arm/kernel/uprobes.c | 6 -
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/insn.h | 8 +
arch/arm64/include/asm/probes.h| 26 ++-
arch/arm64/include/asm/ptrace.h| 7 +
arch/arm64/include/asm/thread_info.h | 5 +-
arch/arm64/include/asm/uprobes.h | 43
arch/arm64/kernel/Makefile | 5 +-
arch/arm64/kernel/debug-monitors.c | 14 +-
arch/arm64/kernel/kprobes.c| 11 +-
arch/arm64/kernel/kprobes.h| 7 +-
.../kernel/{kprobes-arm64.c => probes-arm64.c} | 84 +++
.../kernel/{kprobes-arm64.h => probes-arm64.h} | 17 +-
arch/arm64/kernel/probes-condn-check.c | 2 +-
arch/arm64/kernel/probes-decode.h | 4 +-
arch/arm64/kernel/signal.c | 4 +-
arch/arm64/kernel/uprobes.c| 255 +
arch/arm64/mm/flush.c | 30 ++-
kernel/events/uprobes.c| 18 ++
19 files changed, 445 insertions(+), 104 deletions(-)
create mode 100644 arch/arm64/include/asm/uprobes.h
rename arch/arm64/kernel/{kprobes-arm64.c => probes-arm64.c} (79%)
rename arch/arm64/kernel/{kprobes-arm64.h => probes-arm64.h} (60%)
create mode 100644 arch/arm64/kernel/uprobes.c
--
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 v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
Hi,
Would anyone be able to look at this to help us move forward? Thanks.
On 14-12-19 03:03 PM, Jonathan Richardson wrote:
> On 14-12-19 02:26 PM, Joe Perches wrote:
>> On Fri, 2014-12-19 at 14:17 -0800, Jonathan Richardson wrote:
>>> Add initial version of the Broadcom touchscreen driver.
>>
>> more trivia:
>>
>>> diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c
>>> b/drivers/input/touchscreen/bcm_iproc_tsc.c
>> []
>>> +static int get_tsc_config(struct device_node *np, struct iproc_ts_priv
>>> *priv)
>>> +{
>>> + u32 val;
>> []
>>> + if (of_property_read_u32(np, "debounce_timeout", ) >= 0) {
>>> + if (val < 0 || val > 255) {
>>> + dev_err(dev, "debounce_timeout must be [0-255]\n");
>>> + return -EINVAL;
>>> + }
>>> + priv->cfg_params.debounce_timeout = val;
>>
>> Doesn't the compiler generate a warning message
>> about an impossible "unsigned < 0" test for all
>> of these "val < 0" uses?
>>
>
> Actually no it doesn't. The gcc output shows that neither -Wtype-limits
> nor -Wextra are used to compile that file. I assume this is because
> there would be just too many warnings.
>
>
>>> + }
>>> +
>>> + if (of_property_read_u32(np, "settling_timeout", ) >= 0) {
>>> + if (val < 0 || val > 11) {
>> []
>>> + if (of_property_read_u32(np, "touch_timeout", ) >= 0) {
>>> + if (val < 0 || val > 255) {
>> []
>>> + if (of_property_read_u32(np, "average_data", ) >= 0) {
>>> + if (val < 0 || val > 8) {
>> []
>>> + if (of_property_read_u32(np, "fifo_threshold", ) >= 0) {
>>> + if (val < 0 || val > 31) {
>>
>>
>
--
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 V8 00/33] loop: Issue O_DIRECT aio using bio_vec
On Thu, Jan 1, 2015 at 6:35 AM, Sedat Dilek wrote: > On Wed, Dec 31, 2014 at 10:52 PM, Dave Kleikamp > wrote: >> On 12/31/2014 02:38 PM, Sedat Dilek wrote: >>> >>> What has happened to that aio_loop patchset? >>> Is it in Linux-next? >>> ( /me started to play with "block: loop: convert to blk-mq (v3)", so I >>> recalled this other improvement. ) >> >> It met with some harsh resistance, so I backed off on it. Then Al Viro >> got busy re-writing the iov_iter infrastructure and I put my patchset on >> the shelf to look at later. Then Ming Lei submitted more up-to-date >> patchset: https://lkml.org/lkml/2014/8/6/175 >> >> It looks like Ming is currently only pushing the first half of that >> patchset. I don't know what his plans are for the last three patches: >> >> aio: add aio_kernel_() interface >> fd/direct-io: introduce should_dirty for kernel aio >> block: loop: support to submit I/O via kernel aio based >> > > I tested with block-mq-v3 (for next-20141231) [1] and this looks promising > [2]. > > Maybe Ming can say what the plan is with the missing parts. I have compared kernel aio based loop-mq(the other 3 aio patches against loop-mq v2, [1]) with loop-mq v3, looks the data isn't better than loop-mq v3. kernel aio based approach requires direct I/O, at least direct write shouldn't be good as page cache write, IMO. So I think we need to investigate kernel aio based approach further wrt. loop improvement. [1] http://marc.info/?l=linux-kernel=140941494422520=2 Thanks, Ming Lei > > - Sedat - > > [1] http://marc.info/?l=linux-kernel=142003226701471=2 > [2]http://marc.info/?l=linux-kernel=142006516408381=2 > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v3 0/5] block: loop: convert to blk-mq
On Thu, Jan 1, 2015 at 8:18 AM, Sedat Dilek wrote:
> On Thu, Jan 1, 2015 at 1:01 AM, Ming Lei wrote:
>> Hi Sedat,
>>
>> On Thu, Jan 1, 2015 at 6:32 AM, Sedat Dilek wrote:
>>> Forgot to CC LKML and linux-fsdevel.
>>>
>>> - Sedat -
>>
>>>
>>> OK, I have installed fio (1.59-1) and libaio1 (0.3.109-2ubuntu1) here.
>>>
>>> You say in [1]:
>>>
>>> "In the following test:
>>> - base: v3.19-rc2-2041231
>>> - loop over file in ext4 file system on SSD disk
>>> - bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
>>> - throughput: IOPS"
>>>
>>> I tried to reproduce that inspired by [2]...
>>>
>>> root# fio --name=randread --rw=randread --bs=4k --ioengine=libaio
>>> --iodepth=64 --direct=1 --numjobs=1 --size=1G
>>>
>>> ...you had no size given (here: 1GiB) - fio requires that parameter to run.
>>>
>>> This results in 165 VS. 515 IOPS here.
>>
>> Thanks for your test.
>>
>> Also if your disk is quick enough, you will observe improvement on
>> read test too.
>>
>
> This is no SSD here.
>
> # dmesg | egrep -i 'hitachi|ata1|sda'
> [0.457892] ata1: SATA max UDMA/133 abar m2048@0xf0708000 port
> 0xf0708100 irq 25
> [0.777445] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [0.778759] ata1.00: ATA-8: Hitachi HTS545050A7E380, GG2OA6C0, max UDMA/133
> [0.778778] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32),
> AA
> [0.780154] ata1.00: configured for UDMA/133
> [0.780970] scsi 0:0:0:0: Direct-Access ATA Hitachi
> HTS54505 A6C0 PQ: 0 ANSI: 5
> [0.782050] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks:
> (500 GB/465 GiB)
> [0.782058] sd 0:0:0:0: [sda] 4096-byte physical blocks
> [0.782255] sd 0:0:0:0: [sda] Write Protect is off
> [0.782262] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [0.782339] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [0.800644] sda: sda1 sda2 sda3
> [0.802029] sd 0:0:0:0: [sda] Attached SCSI disk
>
> How did you test with fio (your fio lines)?
Your fio command line is basically same with my fio config, and you
can attach one image to loop via: losetup -f file_name. Looks your
randread result is good, and I can observe ~80 IOPS vs. ~200 IOPS
on my slow HDD. in the randread test too.
#fio config##
[global]
direct=1
size=128G
bsrange=4k-4k
timeout=30
numjobs=1
ioengine=libaio
iodepth=64
filename=/dev/loop0
group_reporting=1
[f]
rw=${RW}
Thanks,
Ming Lei
--
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] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, 31 Dec 2014, Arend van Spriel wrote: On 12/31/14 22:57, Linus Torvalds wrote: On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o wrote: Yeah, the confusing part is that "ip" tends to use "verb object" scheme, which is consistent with the Cisco IOS command set it was trying to emulate. Side note: does anybody think that was really a good idea to begin with? I mean, Cisco iOS is just _s_ universally loved, right? I think I sense a bit cynical (under)tone here ;-) And yeah, I refuse to use "ip link" or other insane commands. Let's face it, "ifconfig" and "route" are perfectly fine commands, and a whole lot less confusing than "ip" with random crap after it. I'm really not seeing why that "ip" command was seen as an improvement. So does "ip" provide the same functionality as "ifconfig" and "route" or does the package have more to offer. there are things that you can do with "ip" that you can't do with "ifconfig", but they tend to be rather esoteric things (hundreds of IP addresses on "eth0" without using eth0:1, eth0:2, etc as one example) The trouble is that doing simple things is harder with "ip" than "ifconfig" David Lang The "iw" tool provides much more subcommands to perform different wireless tasks that are not provided by "iwconfig" and friends. So functionally "iw" provides a superset. Just have to get equivalent output format to mimic "iwconfig" as Ted suggested. Well, that's something for next year as we are getting close to midnight over here. Regards, Arend (Ok, "ip route" isn't any more complex than "route", but "ip link" sure as hell isn't simpler than "ifconfig" for most things I can think of) Linus -- 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/
Re: [PATCH] qlcnic: Fix return value in qlcnic_probe()
From: xuyongjia...@163.com Date: Tue, 30 Dec 2014 16:03:46 +0800 > From: Yongjian Xu > > If the check of adapter fails and goes into the 'else' branch, the > return value 'err' should not still be zero. > > Signed-off-by: Yongjian Xu Applied, thank you. -- 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 2/8] myri10ge: fix error return code
From: Julia Lawall Date: Mon, 29 Dec 2014 18:04:37 +0100 > Return a negative error code on failure. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) ... The patch also modifies the test of mgp->cmd to satisfy checkpatch. > > Signed-off-by: Julia Lawall Applied. -- 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 5/8] net: sun4i-emac: fix error return code
From: Julia Lawall Date: Mon, 29 Dec 2014 18:04:40 +0100 > Return a negative error code on failure. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall Applied. -- 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 1/8] net: Xilinx: fix error return code
From: Julia Lawall Date: Mon, 29 Dec 2014 18:04:36 +0100 > Return a negative error code on failure. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall Applied. -- 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 7/8] net: axienet: fix error return code
From: Julia Lawall Date: Mon, 29 Dec 2014 18:04:42 +0100 > Return a negative error code on failure. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall Applied. -- 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 V1 1/1] iio: Added Capella cm3232 ambient light sensor driver.
CM3232 is an advanced ambient light sensor with I2C protocol interface.
The I2C slave address is internally hardwired as 0x10 (7-bit). Writing
to configure register is byte mode, but reading ALS register requests to
use word mode for 16-bit resolution.
Signed-off-by: Kevin Tsai
---
.../devicetree/bindings/i2c/trivial-devices.txt| 1 +
MAINTAINERS| 6 +
drivers/iio/light/Kconfig | 11 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/cm3232.c | 403 +
5 files changed, 422 insertions(+)
create mode 100644 drivers/iio/light/cm3232.c
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 9f4e382..572a7c4 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -34,6 +34,7 @@ atmel,24c512 i2c serial eeprom (24cxx)
atmel,24c1024 i2c serial eeprom (24cxx)
atmel,at97sc3204t i2c trusted platform module (TPM)
capella,cm32181CM32181: Ambient Light Sensor
+capella,cm3232 CM3232: Ambient Light Sensor
catalyst,24c32 i2c serial eeprom
cirrus,cs42l51 Cirrus Logic CS42L51 audio codec
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..06a613a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2378,6 +2378,12 @@ F: security/capability.c
F: security/commoncap.c
F: kernel/capability.c
+CAPELLA MICROSYSTEMS LIGHT SENSOR DRIVER
+M: Kevin Tsai
+S: Maintained
+F: drivers/iio/light/cm*
+F: Documentation/devicetree/bindings/i2c/trivial-devices.txt
+
CC2520 IEEE-802.15.4 RADIO DRIVER
M: Varka Bhadram
L: linux-w...@vger.kernel.org
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5bea821..d2318e2 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -48,6 +48,17 @@ config CM32181
To compile this driver as a module, choose M here:
the module will be called cm32181.
+config CM3232
+ depends on I2C
+ tristate "CM3232 driver"
+ help
+Say Y here if you use cm3232.
+This option enables ambient light sensor using
+Capella Microsystems cm3232 device driver.
+
+To compile this driver as a module, choose M here:
+the module will be called cm3232.
+
config CM36651
depends on I2C
tristate "CM36651 driver"
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 47877a3..f2c8d55 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_AL3320A) += al3320a.o
obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_CM32181) += cm32181.o
+obj-$(CONFIG_CM3232) += cm3232.o
obj-$(CONFIG_CM36651) += cm36651.o
obj-$(CONFIG_GP2AP020A00F) += gp2ap020a00f.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c
new file mode 100644
index 000..fd98eeb
--- /dev/null
+++ b/drivers/iio/light/cm3232.c
@@ -0,0 +1,403 @@
+/*
+ * Copyright (C) 2014 Capella Microsystems Inc.
+ * Author: Kevin Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers Address */
+#define CM3232_REG_ADDR_CMD0x00
+#define CM3232_REG_ADDR_ALS0x50
+#define CM3232_REG_ADDR_ID 0x53
+
+/* CMD register */
+#define CM3232_CMD_ALS_DISABLE BIT(0)
+#defineCM3232_CMD_ALS_HS BIT(1)
+
+#define CM3232_CMD_ALS_IT_SHIFT 2
+#define CM3232_CMD_ALS_IT_MASK (0x07 << CM3232_CMD_ALS_IT_SHIFT)
+#define CM3232_CMD_ALS_IT_DEFAULT (0x01 << CM3232_CMD_ALS_IT_SHIFT)
+
+#defineCM3232_CMD_ALS_RESETBIT(6)
+
+#define CM3232_CMD_DEFAULT CM3232_CMD_ALS_IT_DEFAULT
+
+#define CM3232_CALIBSCALE_DEFAULT 10
+#define CM3232_CALIBSCALE_RESOLUTION 10
+#define CM3232_MLUX_PER_LUX1000
+
+#define CM3232_MLUX_PER_BIT_DEFAULT64
+#define CM3232_MLUX_PER_BIT_BASE_IT10
+static const int CM3232_als_it_bits[] = { 0, 1, 2, 3, 4, 5};
+static const int CM3232_als_it_values[] = {
+ 10, 20, 40, 80, 160, 320};
+
+struct cm3232_als_info {
+ u32 id;
+ int calibscale;
+ int mlux_per_bit;
+ int mlux_per_bit_base_it;
+ const int *als_it_bits;
+ const int *als_it_values;
+ const
Re: [PATCH v3 0/5] block: loop: convert to blk-mq
On Thu, Jan 1, 2015 at 1:01 AM, Ming Lei wrote: > Hi Sedat, > > On Thu, Jan 1, 2015 at 6:32 AM, Sedat Dilek wrote: >> Forgot to CC LKML and linux-fsdevel. >> >> - Sedat - > >> >> OK, I have installed fio (1.59-1) and libaio1 (0.3.109-2ubuntu1) here. >> >> You say in [1]: >> >> "In the following test: >> - base: v3.19-rc2-2041231 >> - loop over file in ext4 file system on SSD disk >> - bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1 >> - throughput: IOPS" >> >> I tried to reproduce that inspired by [2]... >> >> root# fio --name=randread --rw=randread --bs=4k --ioengine=libaio >> --iodepth=64 --direct=1 --numjobs=1 --size=1G >> >> ...you had no size given (here: 1GiB) - fio requires that parameter to run. >> >> This results in 165 VS. 515 IOPS here. > > Thanks for your test. > > Also if your disk is quick enough, you will observe improvement on > read test too. > This is no SSD here. # dmesg | egrep -i 'hitachi|ata1|sda' [0.457892] ata1: SATA max UDMA/133 abar m2048@0xf0708000 port 0xf0708100 irq 25 [0.777445] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [0.778759] ata1.00: ATA-8: Hitachi HTS545050A7E380, GG2OA6C0, max UDMA/133 [0.778778] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [0.780154] ata1.00: configured for UDMA/133 [0.780970] scsi 0:0:0:0: Direct-Access ATA Hitachi HTS54505 A6C0 PQ: 0 ANSI: 5 [0.782050] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) [0.782058] sd 0:0:0:0: [sda] 4096-byte physical blocks [0.782255] sd 0:0:0:0: [sda] Write Protect is off [0.782262] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.782339] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [0.800644] sda: sda1 sda2 sda3 [0.802029] sd 0:0:0:0: [sda] Attached SCSI disk How did you test with fio (your fio lines)? - Sedat - >> # grep "iops=" test-* >> test-1-next20141231.txt: read : io=1024.0MB, bw=678578 B/s, iops=165 >> , runt=1582340msec >> test-2-next20141231-block-mq-v3.txt: read : io=1024.0MB, >> bw=2063.4KB/s, iops=515 , runt=508182msec >> >> Full fio-logs and some other useful configs/logs/patches attached. >> >> - Sedat - >> >> [1] http://marc.info/?l=linux-kernel=142003220301459=2 >> [2] >> http://wiki.mikejung.biz/Benchmarking#Fio_Random_Write_Test_using_libaio_and_direct_flags > > > > Thanks, > Ming Lei -- 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 v3 0/6] support GMAC driver for RK3288
From: Roger Chen Date: Mon, 29 Dec 2014 17:42:32 +0800 > Roger Chen (6): > patch1: add driver for Rockchip RK3288 SoCs integrated GMAC > patch2: define clock ID used for GMAC > patch3: modify CRU config for Rockchip RK3288 SoCs integrated GMAC > patch4: dts: rockchip: add gmac info for rk3288 > patch5: dts: rockchip: enable gmac on RK3288 evb board > patch6: add document for Rockchip RK3288 GMAC > > Tested on rk3288 evb board: > Execute the following command to enable ethernet, > set local IP and ping a remote host. > > busybox ifconfig eth0 up > busybox ifconfig eth0 192.168.1.111 > ping 192.168.1.1 Series applied to net-next, thanks. -- 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: [GIT PULL] Audit fixes for 3.19 #2
On Wed, Dec 31, 2014 at 05:08:12PM -0500, Paul Moore wrote:
> The getname/putname hacks work in the normal file case, but it falls apart
> when you start talking about AF_UNIX socket files where the filename string
> doesn't go through the getname/putname refcount tricks. In the past (no idea
> how far back this goes off the top of my head) this wasn't an issue since the
> code which recorded the filenames in the audit records was broken, but since
> we just "fixed" that problem, the AF_UNIX socket problem is now making an
> appearance.
>
> At least that is how it looks to me right now, if I'm wrong about this and
> I'm
> missing an obvious fix I'm all ears/eyes/etc.
Umm... How about just adding a function that would be used instead of
all those
struct filename filename = { .name = name };
and created an object that would be destroyed later by putname()?
--
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 v3 0/5] block: loop: convert to blk-mq
Hi Sedat, On Thu, Jan 1, 2015 at 6:32 AM, Sedat Dilek wrote: > Forgot to CC LKML and linux-fsdevel. > > - Sedat - > > OK, I have installed fio (1.59-1) and libaio1 (0.3.109-2ubuntu1) here. > > You say in [1]: > > "In the following test: > - base: v3.19-rc2-2041231 > - loop over file in ext4 file system on SSD disk > - bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1 > - throughput: IOPS" > > I tried to reproduce that inspired by [2]... > > root# fio --name=randread --rw=randread --bs=4k --ioengine=libaio > --iodepth=64 --direct=1 --numjobs=1 --size=1G > > ...you had no size given (here: 1GiB) - fio requires that parameter to run. > > This results in 165 VS. 515 IOPS here. Thanks for your test. Also if your disk is quick enough, you will observe improvement on read test too. > # grep "iops=" test-* > test-1-next20141231.txt: read : io=1024.0MB, bw=678578 B/s, iops=165 > , runt=1582340msec > test-2-next20141231-block-mq-v3.txt: read : io=1024.0MB, > bw=2063.4KB/s, iops=515 , runt=508182msec > > Full fio-logs and some other useful configs/logs/patches attached. > > - Sedat - > > [1] http://marc.info/?l=linux-kernel=142003220301459=2 > [2] > http://wiki.mikejung.biz/Benchmarking#Fio_Random_Write_Test_using_libaio_and_direct_flags Thanks, Ming Lei -- 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] net: ethernet: intel: i40e: i40e_fcoe.c: Remove unused function
On Wed, 2014-12-31 at 17:48 +0100, Rickard Strandqvist wrote: > Remove the function i40e_rx_is_fip() that is not used anywhere. > > This was partially found by using a static code analysis program > called cppcheck. > > Signed-off-by: Rickard Strandqvist > > --- > drivers/net/ethernet/intel/i40e/i40e_fcoe.c |9 - > 1 file changed, 9 deletions(-) Thanks Rickard! I thought I had some patches in my queue that started to make use of that function, but come to find out, I don't... :-) I will add your patch to my queue, thanks! signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] Audit fixes for 3.19 #2
On Wed, Dec 31, 2014 at 2:08 PM, Paul Moore wrote: > > The getname/putname hacks work in the normal file case, but it falls apart > when you start talking about AF_UNIX socket files where the filename string > doesn't go through the getname/putname refcount tricks. In the past (no idea > how far back this goes off the top of my head) this wasn't an issue since the > code which recorded the filenames in the audit records was broken, but since > we just "fixed" that problem, the AF_UNIX socket problem is now making an > appearance. Ugh. Ok, I pulled the thing, even if I really hope for a better solution long-term. That better solution may well be to get rid of all the audit hackery in getname()/putname(), I wouldn't mind that at all. Linus -- 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 v2 2/2] doc: detailed documentation for completion
On Tue, 23 Dec 2014 20:41:40 +0100 Nicholas Mc Guire wrote: > diff --git a/Documentation/scheduler/completion-design.txt > b/Documentation/scheduler/completion-design.txt > new file mode 100644 > index 000..ec3e320 > --- /dev/null > +++ b/Documentation/scheduler/completion-design.txt > @@ -0,0 +1,498 @@ > +completion - wait for completion handler > + > + > +Origin: Linus Torvalds, kernel 2.4.7, 2001 [1] > +Location: kernel/sched/completion.c [11] > + include/linux/completion.h > +Users: all subsystems - mostly wait_for_completion and > + wait_for_completion_timeout is in use. Again, I'm not sure we need this bit of stuff. > +This document was originally written based on 3.18.0 (linux-next) > +For general constraints and usage of completion see completion.txt completion*s* > + > +Design Goal: > + > + > + - Replace the semaphores used as "code"-locks - primarily for driver > + synchronization. > + - Provide a primitive that is optimized for the contended case and > + not for the uncontended case (as semaphores are). > + - Allow multiple threads to wait for the same condition to 'complete'. > + - Provide a code-lock (similar to pthread_barriers or conditional > + variables) > + just a bit simpler. > + - Have an API that makes the intent of the code clear (which the use > + of locks did not). > + - Provide a proper way to yield the CPU for waiting on events which > + yield(); does not do [7] > + > +Design: > +--- > + > + Locking, from the threads perspective, is intended to be used for > + exclusion which raises issues of priority inversion, deadlocks etc. > + while waiting for a specific state change to occur aka "completion" > + is a thread synchronization point - so the exact opposite of an > + exclusion point. > + > + Locks have been traditionally in (mis)use for code-locking while they > + are intended for data locking only. > + > + Completion provides a simple counter to indicate how many waiting "Completions provide..." > + threads can continue. If a single thread should be allowed to > + continue, the counter is incremented by 1 if ALL should be allowed to semicolon after 1 > + continue it is simply incremented by UINT_MAX/2 which ensures that > + ALL will be woken. Note that this behavior implies a one-shot nature > + of completion - that means it is intended to signal one event only completion*s*...I won't point this out everywhere. > + and if a new event/condition is to be signaled then it needs to be > + reinitialized. Completion has no notion of unlock/lock rather it is > + initialized in a "not done"/locked state and can be unlocked once. > + > + The tasks that wait_for_completion are put on a wait-queue and when the > + condition they are waiting for is signaled by a thread calling complete() > + on the appropriate struct completion, the tasks waiting (one or all) is > + woken by a call to try_to_wake_up(). > + > + As the completion structure does not have an/ associated lock of its Extraneous "/"? > + own the wait-queue lock is used in cases where locking is needed e.g. "wait queue" > + complete(),complete_all(),try_wait_for_completion() and > + completion_done(). > + > + Completion replaced the (mis)used semaphores in synchronizing execution > + paths - notably when there were multiple waiters. > + > + > + The basic summary is that we had this (fairly common) way of > + waiting for certain events by having a locked semaphore on the > + stack of the waiter, and then having the waiter do a "down()" > + which caused it to block until the thing it was waiting for did > + an "up()". > + [1] A quote like this could use some context. "As Linus put it in 2001:" or some such? > + The design and also the core API implementation has been stable > + since 2004. > + > + The _timeout/_interruptible API extension was added in 2004 [10] > + to allow converting the racy sleep_on() users to the sound > + completion API. > + > + An extension initially for the XFS object flushing was added in s/the// > + 2008 extending the API by the try_wait_for_completion() and here too > + completion_done() allowing safe use with held locks. > + > + The last extension was to add the _io variants in 2013 [14]. These > + were added to correct iowait time accounting when the completion > + is used for waiting on IO (e.g. completion of a bio request in > + the block layer). Currently this is only used in the block layer. > + > + > +Design rational for a new primitive: rationale > + > + > + So why not extend semaphores rather than add a new primitive ? > + > + - Semaphores are optimized for the non-contention case. The "wait > + for completion" usage has the opposite default case. > + - The optimization of semaphores is architecture-specific, making > + it hard to change this and probably would have not been possible > + without a penalty. There as at least an attempt to
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On 12/31/14 22:57, Linus Torvalds wrote: On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o wrote: Yeah, the confusing part is that "ip" tends to use "verb object" scheme, which is consistent with the Cisco IOS command set it was trying to emulate. Side note: does anybody think that was really a good idea to begin with? I mean, Cisco iOS is just _s_ universally loved, right? I think I sense a bit cynical (under)tone here ;-) And yeah, I refuse to use "ip link" or other insane commands. Let's face it, "ifconfig" and "route" are perfectly fine commands, and a whole lot less confusing than "ip" with random crap after it. I'm really not seeing why that "ip" command was seen as an improvement. So does "ip" provide the same functionality as "ifconfig" and "route" or does the package have more to offer. The "iw" tool provides much more subcommands to perform different wireless tasks that are not provided by "iwconfig" and friends. So functionally "iw" provides a superset. Just have to get equivalent output format to mimic "iwconfig" as Ted suggested. Well, that's something for next year as we are getting close to midnight over here. Regards, Arend (Ok, "ip route" isn't any more complex than "route", but "ip link" sure as hell isn't simpler than "ifconfig" for most things I can think of) Linus -- 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 V8 00/33] loop: Issue O_DIRECT aio using bio_vec
On Wed, Dec 31, 2014 at 10:52 PM, Dave Kleikamp wrote: > On 12/31/2014 02:38 PM, Sedat Dilek wrote: >> >> What has happened to that aio_loop patchset? >> Is it in Linux-next? >> ( /me started to play with "block: loop: convert to blk-mq (v3)", so I >> recalled this other improvement. ) > > It met with some harsh resistance, so I backed off on it. Then Al Viro > got busy re-writing the iov_iter infrastructure and I put my patchset on > the shelf to look at later. Then Ming Lei submitted more up-to-date > patchset: https://lkml.org/lkml/2014/8/6/175 > > It looks like Ming is currently only pushing the first half of that > patchset. I don't know what his plans are for the last three patches: > > aio: add aio_kernel_() interface > fd/direct-io: introduce should_dirty for kernel aio > block: loop: support to submit I/O via kernel aio based > I tested with block-mq-v3 (for next-20141231) [1] and this looks promising [2]. Maybe Ming can say what the plan is with the missing parts. - Sedat - [1] http://marc.info/?l=linux-kernel=142003226701471=2 [2]http://marc.info/?l=linux-kernel=142006516408381=2 -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On 12/31/14 22:44, Theodore Ts'o wrote: On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote: Agree. I can't even recall using "ip" ever. iw help system does provide command specific help. The phy keyword is both a command and a selector key, which I realize is confusing to the user, eg. 'iw help info' does provide help for the 'info' subcommand. Yeah, the confusing part is that "ip" tends to use "verb object" scheme, which is consistent with the Cisco IOS command set it was trying to emulate. So for ip, you do something like ip link info eth0 Where as for "iw" it's almost exactly backwards, i.e.: iw wlan0 info It's actually rather unfortunate that there is no consistency between many of these tools, for example: ethtool --show-features eth0 If we were going to create a new interface, wouldn't be nice if we could have some kind of consistency? Sigh; oh well, water under the bridge at this point. And on that water there are different ships with different captains ;-) Thanks. If there are still drivers, upstream or out-of-tree, providing only WEXT API this will not work unless iwconfig/iwlist can distinguish those from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl syscalls. Just not sure if it is worth the effort. As you stated below, it does not seem "evil" to retain WEXT if that is providing users what they need. Is it really that much effort? Unless there is some license incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already there in the wireless-tools source. It would just be a matter of trying the new ioctls first, and then falling back to the WEXT ones if needed, right? I don't think it is much effort. I think the nl80211 netlink api is not an ioctl, but yeah it seems trivial. But if WEXT needs to stay for people using WEXT-only drivers, it may be fine to keep cfg80211 wext compatibility in place. Regards, Arend Cheers, - Ted -- 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 v2 1/2] doc: brief user documentation for completion
I'm finally getting around to looking at this. Honestly, I think we could
add it now and make our documentation better, but I'm going to pick nits
anyway in the hopes of one more round of improvement :)
On Tue, 23 Dec 2014 20:41:39 +0100
Nicholas Mc Guire wrote:
> diff --git a/Documentation/scheduler/completion.txt
> b/Documentation/scheduler/completion.txt
> new file mode 100644
> index 000..d35a948
> --- /dev/null
> +++ b/Documentation/scheduler/completion.txt
> @@ -0,0 +1,198 @@
> +completion - wait for completion handler
> +
> +
> +Origin: Linus Torvalds, kernel 2.4.7, 2001
> +Location: kernel/sched/completion.c
> + include/linux/completion.h
> +Users: all subsystems - mostly wait_for_completion and
> + wait_for_completion_timeout is in use.
I'm not sure we need this stuff; will it really help readers to use this
facility?
> +This document was originally written based on 3.18.0 (linux-next)
This, instead, is something I wish we had in more of our documentation; it
lets future readers get a sense for how likely it is to be current.
> +Introduction:
> +=
> +
> +Completion is a code synchronization mechanism that is preferable to mis-
It would read a bit better to talk about completions in the plural
everywhere. "Completions are..."
> +using of locks - semantically they are somewhat like a pthread_barrier. If
> +you have one or more threads of execution that must wait for some process
> +to have reached a point or a specific state, completions can provide a race
> +free solution to this problem.
> +
> +Completion is built on top of the generic event infrastructure in Linux,
Here too
> +with the event reduced to a simple flag appropriately called "done" in
> +struct completion, that tells the waiting threads of execution that they
> +can continue safely.
> +
> +For details on completion design and implementation see completion-design.txt
> +
> +Usage:
> +==
> +
> +Basically there are three parts to the API, the initialization of the
"There are three parts to the API: ..."
> +completion, the waiting part through a call to a variant of
> +wait_to_completion and the signaling side through a call to complete()
Let's use the function notation consistently (and get the name right while
we're at it) - wait_for_completion()
> +or complete_all().
> +
> +To use completions one needs to including and
> +creating a variable of type struct completion. The structure used for
"to include" and "create"
> +handling of completion is:
> +
> + struct completion {
> + unsigned int done;
> + wait_queue_head_t wait;
> + };
> +
> +providing the wait queue to place tasks on for waiting and the flag for
> +indicating the state of affairs.
> +
> +Completions should be named to convey the intent of the waiter. A good
> +example is:
> +
> + wait_for_completion(_console_added);
> +
> + complete(_console_added);
> +
> +good naming (as always) helps code readability.
> +
> +
> +init_completion:
init_completion(). But even better would be "Initialization" or something
like that.
> +
> +
> +Initialization is accomplished by init_completion() for dynamic
accomplished *by calling* init_completion()...
> +initialization. It initializes the wait-queue and sets the default state
wait queue (no hyphen)
> +to "not available", that is, "done" is set to 0.
> +
> +The reinitialization reinit_completion(), simply resets the done element
The reinitialization *function* reinit_completion()...
> +to "not available", thus again to 0, without touching the wait-queue.
> +
> +declaration and initialization macros available are:
*The* declaration and ...
> +
> + static DECLARE_COMPLETION(setup_done)
> +
> +used for static declarations in file scope - probably NOT what you want to
> +use - instead use:
There are some 50 uses, so it has its value.
> + DECLARE_COMPLETION_ONSTACK(setup_done)
> +
> +used for automatic/local variables on the stack and will make lockdep happy.
All this is good, but the predominant use looks to be embedding a
completion directly into some other structure and initializing it
explicitly. It might be worth finding a way to actually say that.
> +wait_for_completion:
wait_for_completion() (or "Waiting")
> +
> +
> +For a thread of execution to wait on some other thread to reach some
> +preparatory action to reach completion, this is achieved by passing the
> +completion event to wait_for_completion():
That sentence is a bit hard to read. How about something like:
A thread may wait for a completion to be signaled by calling one of
the variants of wait_for_completion().
> +
> + wait_for_completion(struct completion *done):
Here (and with all of them) it would be nice to have the return type too.
"void" in this case.
> +The default behavior is to wait without a timeout and mark the task as
> +uninterruptible.
> +
> +
> +Variants
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote: > Side note: does anybody think that was really a good idea to begin > with? I mean, Cisco iOS is just _s_ universally loved, right? Well, at the time when it was "ip" came out, Cisco had a defacto monopoly on routing equipment, and some of the folks who were working on Linux networking had this insane dream of having Linux be better at the routing game than Cisco (there was this minor issue of Cisco having hardware assist for their fastpath :-). So I think I *understand* the rationale behind the design choice, even though it's probably not the decision I would have made at the time, and certainly not with the benefit of 20/20 hindsight! And I won't say that I *loved* IOS, but I certainly used it enough when I was working in the MIT Network Operations group. :-) > And yeah, I refuse to use "ip link" or other insane commands. Let's > face it, "ifconfig" and "route" are perfectly fine commands, and a > whole lot less confusing than "ip" with random crap after it. I'm > really not seeing why that "ip" command was seen as an improvement. The real problem is that they were trying to do way more complicated things in terms of routing rules (including some stuff that could be done by Cisco IOS). So if you want to try to do the insanely complicated stuff, you have to use the "ip route" command. Meh. Could it have been shoehorned into the legacy "route" command? Perhaps, although it would have been a bit of mess, I suspect. The question I find more interesting is how many people are actually *using* all of the complexity that currently can only be accessed via the "ip", "tc", and "ss" commands. But in any case, given that "ip", "tc", "ss", etc. are using the IOS syntax, most users will probably find it confusing and surprising that "iw" is using something different. It's probably too hard to maintain script compatibility to make such a UX change to iw at this point, though. And besides, most users are probably using "ifconfig", "route", and if they're not using network-manager or wicdw, they're using "iwconfig" or "iwlist" --- so it's a moot point. :-) - Ted -- 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: [GIT PULL] Audit fixes for 3.19 #2
On Wednesday, December 31, 2014 01:23:14 PM Linus Torvalds wrote: > On Wed, Dec 31, 2014 at 12:33 PM, Paul Moore wrote: > > One audit patch to resolve a panic/oops when recording filenames in the > > audit log, see the mail archive link below. The fix isn't as nice as I > > would like, as it involves an allocate/copy of the filename, but it > > solves the problem and the overhead should only affect users who have > > configured audit rules involving file names. > > This fix looks wrong. > > The kernel "getname()" function already has hacks explicitly for this > audit usage. Why aren't those hacks working? See the whole > "audit_getname()" and "audit_putname()" thing in fs/namei.c. > > So why does audit now need to copy the name *again*, when the whole - > and only - point of the current fs/namei.c audit hackery is exactly so > that audit can control the lifetime of the pathnames? The getname/putname hacks work in the normal file case, but it falls apart when you start talking about AF_UNIX socket files where the filename string doesn't go through the getname/putname refcount tricks. In the past (no idea how far back this goes off the top of my head) this wasn't an issue since the code which recorded the filenames in the audit records was broken, but since we just "fixed" that problem, the AF_UNIX socket problem is now making an appearance. At least that is how it looks to me right now, if I'm wrong about this and I'm missing an obvious fix I'm all ears/eyes/etc. > Hmm? Alternatively, could we just remove the fs/namei.c hackery > entirely, and rely on audit always copying the filenames for its own > use? I'm still coming up to speed on this mess of a subsystem, so I can't say I'm well versed in all the audit design decisions up to this point, but ... I'd hate to see us lose the getname/putname hacks if we can find a way to differentiate between normal files and things like AF_UNIX. I've got some ideas but I wanted to get you a patch soonish since v3.19-rc2 pukes all over itself if you configure audit in a particular way (evidently the Gentoo default config triggers the problem). If you're okay with waiting a bit longer I can work on this a bit more and try to find a more elegant solution; I'm already working this on anyway for v3.20 (or whatever it happens to be when the patch is ready). -- paul moore www.paul-moore.com -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o wrote: > > Yeah, the confusing part is that "ip" tends to use "verb object" > scheme, which is consistent with the Cisco IOS command set it was > trying to emulate. Side note: does anybody think that was really a good idea to begin with? I mean, Cisco iOS is just _s_ universally loved, right? And yeah, I refuse to use "ip link" or other insane commands. Let's face it, "ifconfig" and "route" are perfectly fine commands, and a whole lot less confusing than "ip" with random crap after it. I'm really not seeing why that "ip" command was seen as an improvement. (Ok, "ip route" isn't any more complex than "route", but "ip link" sure as hell isn't simpler than "ifconfig" for most things I can think of) Linus -- 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 V8 00/33] loop: Issue O_DIRECT aio using bio_vec
On 12/31/2014 02:38 PM, Sedat Dilek wrote: > > What has happened to that aio_loop patchset? > Is it in Linux-next? > ( /me started to play with "block: loop: convert to blk-mq (v3)", so I > recalled this other improvement. ) It met with some harsh resistance, so I backed off on it. Then Al Viro got busy re-writing the iov_iter infrastructure and I put my patchset on the shelf to look at later. Then Ming Lei submitted more up-to-date patchset: https://lkml.org/lkml/2014/8/6/175 It looks like Ming is currently only pushing the first half of that patchset. I don't know what his plans are for the last three patches: aio: add aio_kernel_() interface fd/direct-io: introduce should_dirty for kernel aio block: loop: support to submit I/O via kernel aio based Dave -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote: > > Agree. I can't even recall using "ip" ever. iw help system does provide > command specific help. The phy keyword is both a command and a selector key, > which I realize is confusing to the user, eg. 'iw help info' does provide > help for the 'info' subcommand. Yeah, the confusing part is that "ip" tends to use "verb object" scheme, which is consistent with the Cisco IOS command set it was trying to emulate. So for ip, you do something like ip link info eth0 Where as for "iw" it's almost exactly backwards, i.e.: iw wlan0 info It's actually rather unfortunate that there is no consistency between many of these tools, for example: ethtool --show-features eth0 If we were going to create a new interface, wouldn't be nice if we could have some kind of consistency? Sigh; oh well, water under the bridge at this point. > Thanks. If there are still drivers, upstream or out-of-tree, providing only > WEXT API this will not work unless iwconfig/iwlist can distinguish those > from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl > syscalls. Just not sure if it is worth the effort. As you stated below, it > does not seem "evil" to retain WEXT if that is providing users what they > need. Is it really that much effort? Unless there is some license incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already there in the wireless-tools source. It would just be a matter of trying the new ioctls first, and then falling back to the WEXT ones if needed, right? Cheers, - Ted -- 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 v2] sound: pci: asihpi: hpifunc.c: Remove some unused functions
>>> More code changes may land in near future, so removing functions isn't >>> good at all at this moment. We need to wait until the all things are >>> settled down. IOW, forget about this for a while :) Hi Richard, Takashi, In principle I don't object to this patch (thanks for the work Richard), but right now I'm really on vacation, and then at LCA so won't be spending time on it until late January. How about I take the patch into my tree, and include in my next set of updates, allowing for any further tweaks to the unused function list. -- Eliot -- 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 v3 2/4] staging: rtl8192u: fix whitespace
This patch fixes warnings/errors raised by checkpatch.pl relating to whitespace
in r8192U_dm.c and additionally it removes inconsistent whitespace
throughout.
Additionally some 0x00... padding has been added for alignment to the
edca_setting_* variables.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 1606 +-
1 file changed, 625 insertions(+), 981 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index cafc717..862d2ab 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -22,11 +22,12 @@ Major Change History:
#include "r819xU_cmdpkt.h"
/*---Define Local Constant---*/
/* Indicate different AP vendor for IOT issue. */
-static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
0xa44f, 0x5ea44f};
-static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
0x5ea44f, 0x5ea44f};
-
+static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0x00a44f, 0x5ea44f
+};
+static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0x00a44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
+};
#define RTK_UL_EDCA 0xa44f
#define RTK_DL_EDCA 0x5e4322
@@ -37,7 +38,7 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
/* Debug variable ? */
dig_t dm_digtable;
/* Store current software write register content for MAC PHY. */
-u8 dm_shadow[16][256] = {{0}};
+u8 dm_shadow[16][256] = { {0} };
/* For Dynamic Rx Path Selection by Signal Strength */
DRxPathSel DM_RxPathSelTable;
/*Define global variable-*/
@@ -66,11 +67,8 @@ static voiddm_bandwidth_autoswitch(struct
net_device *dev);
static voiddm_check_txpower_tracking(struct net_device *dev);
-
-
/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
-
/* DM --> Dynamic Init Gain by RSSI */
static voiddm_dig_init(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
@@ -89,13 +87,11 @@ static voiddm_check_edca_turbo(struct net_device
*dev);
/* DM --> Check PBC */
static void dm_check_pbc_gpio(struct net_device *dev);
-
/* DM --> Check current RX RF path state */
static voiddm_check_rx_path_selection(struct net_device *dev);
static void dm_init_rxpath_selection(struct net_device *dev);
static void dm_rxpath_sel_byrssi(struct net_device *dev);
-
/* DM --> Fsync for broadcom ap */
static void dm_init_fsync(struct net_device *dev);
static void dm_deInit_fsync(struct net_device *dev);
@@ -109,7 +105,6 @@ static voiddm_check_txrateandretrycount(struct
net_device *dev);
static voiddm_init_dynamic_txpower(struct net_device *dev);
static voiddm_dynamic_txpower(struct net_device *dev);
-
/* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
static void dm_send_rssi_tofw(struct net_device *dev);
static voiddm_ctstoself(struct net_device *dev);
@@ -148,14 +143,12 @@ void init_hal_dm(struct net_device *dev)
void deinit_hal_dm(struct net_device *dev)
{
-
dm_deInit_fsync(dev);
-
}
-
#ifdef USB_RX_AGGREGATION_SUPPORT
-void dm_CheckRxAggregation(struct net_device *dev) {
+void dm_CheckRxAggregation(struct net_device *dev)
+{
struct r8192_priv *priv = ieee80211_priv((struct net_device *)dev);
PRT_HIGH_THROUGHPUT pHTInfo = priv->ieee80211->pHTInfo;
static unsigned longlastTxOkCnt;
@@ -184,14 +177,15 @@ void dm_CheckRxAggregation(struct net_device *dev) {
if ((curTxOkCnt + curRxOkCnt) < 1500)
return;
- if(curTxOkCnt > 4*curRxOkCnt) {
+ if (curTxOkCnt > 4*curRxOkCnt) {
if (priv->bCurrentRxAggrEnable) {
write_nic_dword(dev, 0x1a8, 0);
priv->bCurrentRxAggrEnable = false;
}
- }else{
+ } else {
if (!priv->bCurrentRxAggrEnable &&
!pHTInfo->bCurrentRT2RTAggregation) {
u32 ulValue;
+
ulValue = (pHTInfo->UsbRxFwAggrEn<<24) |
(pHTInfo->UsbRxFwAggrPageNum<<16) |
(pHTInfo->UsbRxFwAggrPacketNum<<8) |
(pHTInfo->UsbRxFwAggrTimeout);
/*
@@ -209,8 +203,6 @@ void dm_CheckRxAggregation(struct net_device *dev) {
} /* dm_CheckEdcaTurbo */
#endif
-
-
void hal_dm_watchdog(struct net_device *dev)
{
/*struct r8192_priv *priv = ieee80211_priv(dev);*/
@@ -237,7 +229,6 @@ void hal_dm_watchdog(struct net_device *dev)
#endif
} /* HalDmWatchDog */
-
/*
* Decide Rate Adaptive Set according to distance (signal strength)
* 01/11/2008 MHC Modify input arguments and
[PATCH] serial: omap_8250: Fix RTS handling, part B
Because the OMAP3 UART ignores MCR[1] (RTS) in autoRTS mode, autoRTS
mode must not be enabled unless RTS is set (or port->mctrl & TIOCM_RTS,
which is equivalent).
Fixes premature raising of RTS in omap_8250_set_termios() -- RTS was
raised even before UART mode was selected.
Fixes raise of RTS after port has been shutdown; omap_8250_pm() re-enabled
RTS after omap_8250_shutdown().
Cc: Sebastian Andrzej Siewior
Signed-off-by: Peter Hurley
---
drivers/tty/serial/8250/8250_omap.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 428f384..316c37b 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -272,7 +272,10 @@ static void omap8250_restore_regs(struct uart_8250_port
*up)
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_dl_write(up, priv->quot);
- serial_out(up, UART_EFR, priv->efr);
+ if (up->port.mctrl & TIOCM_RTS)
+ serial_out(up, UART_EFR, priv->efr);
+ else
+ serial_out(up, UART_EFR, priv->efr & ~UART_EFR_RTS);
/* Configure flow control */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
@@ -468,18 +471,18 @@ static void omap_8250_set_termios(struct uart_port *port,
static void omap_8250_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate)
{
- struct uart_8250_port *up =
- container_of(port, struct uart_8250_port, port);
- struct omap8250_priv *priv = up->port.private_data;
+ struct uart_8250_port *up = up_to_u8250p(port);
+ u8 efr;
pm_runtime_get_sync(port->dev);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_out(up, UART_EFR, priv->efr | UART_EFR_ECB);
+ efr = serial_in(up, UART_EFR);
+ serial_out(up, UART_EFR, efr | UART_EFR_ECB);
serial_out(up, UART_LCR, 0);
serial_out(up, UART_IER, (state != 0) ? UART_IERX_SLEEP : 0);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_out(up, UART_EFR, priv->efr);
+ serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, 0);
pm_runtime_mark_last_busy(port->dev);
--
2.2.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/
Re: [PATCH v2 2/4] staging: rtl8192u: fix whitespace
On 31 December 2014 at 21:20, Joe Perches wrote:
> It'd be nicer to use the same form and indentation
> for both entries.
>
> Probably be nicer to use:
>
> static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
> 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0x00a44f, 0x5ea44f
> };
> static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
> 0x5e4322, 0x00a44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
> };
>
> so that the entries align too.
Ack... I am a bit of a beginner at the kernel, I think you can tell
;-) I didn't mean for this to have different indentation, in fixing up
other issues I missed this one, will fix. Will also add the 00 prefix,
good idea (+ update the commit message to accommodate.)
>
> Would it be better to use const?
>
I think this would be better as a separate patch as that is getting
into changing actual semantics rather than just simple style fixes,
there is a lot that could be improved here in that realm I think :)
Best, Lorenzo
--
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: [GIT PULL] Audit fixes for 3.19 #2
On Wed, Dec 31, 2014 at 12:33 PM, Paul Moore wrote: > > One audit patch to resolve a panic/oops when recording filenames in the audit > log, see the mail archive link below. The fix isn't as nice as I would like, > as it involves an allocate/copy of the filename, but it solves the problem and > the overhead should only affect users who have configured audit rules > involving file names. This fix looks wrong. The kernel "getname()" function already has hacks explicitly for this audit usage. Why aren't those hacks working? See the whole "audit_getname()" and "audit_putname()" thing in fs/namei.c. So why does audit now need to copy the name *again*, when the whole - and only - point of the current fs/namei.c audit hackery is exactly so that audit can control the lifetime of the pathnames? Hmm? Alternatively, could we just remove the fs/namei.c hackery entirely, and rely on audit always copying the filenames for its own use? Linus -- 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 v2 2/4] staging: rtl8192u: fix whitespace
On Wed, 2014-12-31 at 21:10 +, Lorenzo Stoakes wrote:
> This patch fixes warnings/errors raised by checkpatch.pl relating to
> whitespace
> in r8192U_dm.c and additionally it removes inconsistent whitespace throughout.
[]
> diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> b/drivers/staging/rtl8192u/r8192U_dm.c
[]
> +static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
> +};
> +static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
> +};
It'd be nicer to use the same form and indentation
for both entries.
Probably be nicer to use:
static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0x00a44f, 0x5ea44f
};
static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
0x5e4322, 0x00a44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
};
so that the entries align too.
Would it be better to use const?
--
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 v2 3/4] staging: rtl8192u: remove redundant code
This patch fixes warnings/errors raised by checkpatch.pl relating to redundant
code in r8192U_dm.c.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 176 +--
1 file changed, 84 insertions(+), 92 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 862d2ab..ed566bb 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -410,9 +410,9 @@ static void dm_check_rate_adaptive(struct net_device *dev)
ratr_value = targetRATR;
RT_TRACE(COMP_RATE, "currentRATR = %x, targetRATR =
%x\n", currentRATR, targetRATR);
- if (priv->rf_type == RF_1T2R) {
+ if (priv->rf_type == RF_1T2R)
ratr_value &= ~(RATE_ALL_OFDM_2SS);
- }
+
write_nic_dword(dev, RATR0, ratr_value);
write_nic_byte(dev, UFWP, 1);
@@ -440,18 +440,17 @@ static void dm_bandwidth_autoswitch(struct net_device
*dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
- if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable) {
+ if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable)
return;
- } else {
- if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
false) { /* If send packets in 40 Mhz in 20/40 */
- if (priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = true;
- } else { /* in force send packets in 20 Mhz in 20/40 */
- if (priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = false;
- }
+ if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz == false) {
/* If send packets in 40 Mhz in 20/40 */
+ if (priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= true;
+ } else { /* in force send packets in 20 Mhz in 20/40 */
+ if (priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= false;
}
+
} /* dm_BandwidthAutoSwitch */
/* OFDM default at 0db, index=6. */
@@ -538,9 +537,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
tx_cmd.Length = 4;
tx_cmd.Value = Value;
rtStatus = SendTxCommandPacket(dev, _cmd, 12);
- if (rtStatus == RT_STATUS_FAILURE) {
+ if (rtStatus == RT_STATUS_FAILURE)
RT_TRACE(COMP_POWER_TRACKING, "Set configuration with
tx cmd queue fail!\n");
- }
mdelay(1);
/*DbgPrint("hi, vivi, strange\n");*/
for (i = 0; i <= 30; i++) {
@@ -580,9 +578,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
break;
}
- for (k = 0; k < 5; k++) {
+ for (k = 0; k < 5; k++)
Avg_TSSI_Meas_from_driver += tmp_report[k];
- }
Avg_TSSI_Meas_from_driver =
Avg_TSSI_Meas_from_driver*100/5;
RT_TRACE(COMP_POWER_TRACKING,
"Avg_TSSI_Meas_from_driver = %d\n", Avg_TSSI_Meas_from_driver);
@@ -605,56 +602,55 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
RT_TRACE(COMP_POWER_TRACKING,
"priv->cck_present_attentuation_difference = %d\n",
priv->cck_present_attentuation_difference);
RT_TRACE(COMP_POWER_TRACKING,
"priv->cck_present_attentuation = %d\n", priv->cck_present_attentuation);
return;
- } else {
- if (Avg_TSSI_Meas_from_driver < TSSI_13dBm -
E_FOR_TX_POWER_TRACK) {
- if (priv->rfa_txpowertrackingindex > 0)
{
-
priv->rfa_txpowertrackingindex--;
- if
(priv->rfa_txpowertrackingindex_real > 4) {
-
priv->rfa_txpowertrackingindex_real--;
- rtl8192_setBBreg(dev,
rOFDM0_XATxIQImbalance, bMaskDWord,
[PATCH v2 2/4] staging: rtl8192u: fix whitespace
This patch fixes warnings/errors raised by checkpatch.pl relating to whitespace
in r8192U_dm.c and additionally it removes inconsistent whitespace throughout.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 1606 +-
1 file changed, 625 insertions(+), 981 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index cafc717..862d2ab 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -22,11 +22,12 @@ Major Change History:
#include "r819xU_cmdpkt.h"
/*---Define Local Constant---*/
/* Indicate different AP vendor for IOT issue. */
-static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
0xa44f, 0x5ea44f};
-static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
0x5ea44f, 0x5ea44f};
-
+static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
+};
+static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
+};
#define RTK_UL_EDCA 0xa44f
#define RTK_DL_EDCA 0x5e4322
@@ -37,7 +38,7 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
/* Debug variable ? */
dig_t dm_digtable;
/* Store current software write register content for MAC PHY. */
-u8 dm_shadow[16][256] = {{0}};
+u8 dm_shadow[16][256] = { {0} };
/* For Dynamic Rx Path Selection by Signal Strength */
DRxPathSel DM_RxPathSelTable;
/*Define global variable-*/
@@ -66,11 +67,8 @@ static voiddm_bandwidth_autoswitch(struct
net_device *dev);
static voiddm_check_txpower_tracking(struct net_device *dev);
-
-
/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
-
/* DM --> Dynamic Init Gain by RSSI */
static voiddm_dig_init(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
@@ -89,13 +87,11 @@ static voiddm_check_edca_turbo(struct net_device
*dev);
/* DM --> Check PBC */
static void dm_check_pbc_gpio(struct net_device *dev);
-
/* DM --> Check current RX RF path state */
static voiddm_check_rx_path_selection(struct net_device *dev);
static void dm_init_rxpath_selection(struct net_device *dev);
static void dm_rxpath_sel_byrssi(struct net_device *dev);
-
/* DM --> Fsync for broadcom ap */
static void dm_init_fsync(struct net_device *dev);
static void dm_deInit_fsync(struct net_device *dev);
@@ -109,7 +105,6 @@ static voiddm_check_txrateandretrycount(struct
net_device *dev);
static voiddm_init_dynamic_txpower(struct net_device *dev);
static voiddm_dynamic_txpower(struct net_device *dev);
-
/* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
static void dm_send_rssi_tofw(struct net_device *dev);
static voiddm_ctstoself(struct net_device *dev);
@@ -148,14 +143,12 @@ void init_hal_dm(struct net_device *dev)
void deinit_hal_dm(struct net_device *dev)
{
-
dm_deInit_fsync(dev);
-
}
-
#ifdef USB_RX_AGGREGATION_SUPPORT
-void dm_CheckRxAggregation(struct net_device *dev) {
+void dm_CheckRxAggregation(struct net_device *dev)
+{
struct r8192_priv *priv = ieee80211_priv((struct net_device *)dev);
PRT_HIGH_THROUGHPUT pHTInfo = priv->ieee80211->pHTInfo;
static unsigned longlastTxOkCnt;
@@ -184,14 +177,15 @@ void dm_CheckRxAggregation(struct net_device *dev) {
if ((curTxOkCnt + curRxOkCnt) < 1500)
return;
- if(curTxOkCnt > 4*curRxOkCnt) {
+ if (curTxOkCnt > 4*curRxOkCnt) {
if (priv->bCurrentRxAggrEnable) {
write_nic_dword(dev, 0x1a8, 0);
priv->bCurrentRxAggrEnable = false;
}
- }else{
+ } else {
if (!priv->bCurrentRxAggrEnable &&
!pHTInfo->bCurrentRT2RTAggregation) {
u32 ulValue;
+
ulValue = (pHTInfo->UsbRxFwAggrEn<<24) |
(pHTInfo->UsbRxFwAggrPageNum<<16) |
(pHTInfo->UsbRxFwAggrPacketNum<<8) |
(pHTInfo->UsbRxFwAggrTimeout);
/*
@@ -209,8 +203,6 @@ void dm_CheckRxAggregation(struct net_device *dev) {
} /* dm_CheckEdcaTurbo */
#endif
-
-
void hal_dm_watchdog(struct net_device *dev)
{
/*struct r8192_priv *priv = ieee80211_priv(dev);*/
@@ -237,7 +229,6 @@ void hal_dm_watchdog(struct net_device *dev)
#endif
} /* HalDmWatchDog */
-
/*
* Decide Rate Adaptive Set according to distance (signal strength)
* 01/11/2008 MHC Modify input arguments and RATR table
level.
@@ -246,7 +237,6 @@ void hal_dm_watchdog(struct net_device *dev)
*/
void
[PATCH v2 1/4] staging: rtl8192u: fix comments
This patch fixes errors raised by checkpatch.pl relating to use of C99 comments
in r8192U_dm.c and cleans up existing ANSI C comments.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 811 ++-
1 file changed, 420 insertions(+), 391 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 936565d..cafc717 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -21,9 +21,7 @@ Major Change History:
#include "r8190_rtl8256.h"
#include "r819xU_cmdpkt.h"
/*---Define Local Constant---*/
-//
-// Indicate different AP vendor for IOT issue.
-//
+/* Indicate different AP vendor for IOT issue. */
static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
{ 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
0xa44f, 0x5ea44f};
static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
@@ -36,11 +34,11 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
/*Define global variable-*/
-// Debug variable ?
+/* Debug variable ? */
dig_t dm_digtable;
-// Store current software write register content for MAC PHY.
+/* Store current software write register content for MAC PHY. */
u8 dm_shadow[16][256] = {{0}};
-// For Dynamic Rx Path Selection by Signal Strength
+/* For Dynamic Rx Path Selection by Signal Strength */
DRxPathSel DM_RxPathSelTable;
/*Define global variable-*/
@@ -56,24 +54,24 @@ extern void dm_check_fsync(struct net_device *dev);
/*-Define local function prototype---*/
-// DM --> Rate Adaptive
+/* DM --> Rate Adaptive */
static voiddm_check_rate_adaptive(struct net_device *dev);
-// DM --> Bandwidth switch
+/* DM --> Bandwidth switch */
static voiddm_init_bandwidth_autoswitch(struct net_device *dev);
static voiddm_bandwidth_autoswitch(struct net_device *dev);
-// DM --> TX power control
-//static voiddm_initialize_txpower_tracking(struct net_device *dev);
+/* DM --> TX power control */
+/*static voiddm_initialize_txpower_tracking(struct net_device
*dev);*/
static voiddm_check_txpower_tracking(struct net_device *dev);
-//static voiddm_txpower_reset_recovery(struct net_device *dev);
+/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
-// DM --> Dynamic Init Gain by RSSI
+/* DM --> Dynamic Init Gain by RSSI */
static voiddm_dig_init(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi_highpwr(struct net_device *dev);
@@ -84,61 +82,61 @@ static voiddm_pd_th(struct net_device *dev);
static voiddm_cs_ratio(struct net_device *dev);
static void dm_init_ctstoself(struct net_device *dev);
-// DM --> EDCA turbo mode control
+/* DM --> EDCA turbo mode control */
static voiddm_check_edca_turbo(struct net_device *dev);
-//static voiddm_gpio_change_rf(struct net_device *dev);
-// DM --> Check PBC
+/*static voiddm_gpio_change_rf(struct net_device *dev);*/
+/* DM --> Check PBC */
static void dm_check_pbc_gpio(struct net_device *dev);
-// DM --> Check current RX RF path state
+/* DM --> Check current RX RF path state */
static voiddm_check_rx_path_selection(struct net_device *dev);
static void dm_init_rxpath_selection(struct net_device *dev);
static void dm_rxpath_sel_byrssi(struct net_device *dev);
-// DM --> Fsync for broadcom ap
+/* DM --> Fsync for broadcom ap */
static void dm_init_fsync(struct net_device *dev);
static void dm_deInit_fsync(struct net_device *dev);
-//Added by vivi, 20080522
+/* Added by vivi, 20080522 */
static voiddm_check_txrateandretrycount(struct net_device *dev);
/*-Define local function prototype---*/
-/*-Define of Tx Power Control For Near/Far Range
*/ //Add by Jacken 2008/02/18
+/*-Define of Tx Power Control For Near/Far Range
*/ /*Add by Jacken 2008/02/18 */
static voiddm_init_dynamic_txpower(struct net_device *dev);
static voiddm_dynamic_txpower(struct net_device *dev);
-// DM --> For rate adaptive and DIG, we must send RSSI to firmware
+/* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
static void dm_send_rssi_tofw(struct net_device *dev);
static voiddm_ctstoself(struct net_device *dev);
/*---Define function
prototype*/
-//
-// HW Dynamic mechanism interface.
-//
-
-//
-// Description:
-// Prepare SW resource for HW dynamic
[PATCH v2 4/4] staging: rtl8192u: Refactor heavy nesting
This patch fixes warnings raised by checkpatch.pl relating to heavily indented
lines in r8192U_dm.c. It refactors a couple of else if cases to achieve the same
outcome indented by one fewer tab. It additionally updateds comment positioning
to be consistent across these cases.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index ed566bb..bae8511 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -2581,28 +2581,25 @@ static void dm_rxpath_sel_byrssi(struct net_device *dev)
cck_rx_ver2_sec_index =
cck_rx_ver2_max_index;
tmp_cck_max_pwdb = cur_cck_pwdb;
cck_rx_ver2_max_index = i;
- } else if (cur_cck_pwdb ==
tmp_cck_max_pwdb) { /* let sec and min point to the different index */
+ } else if (cur_cck_pwdb ==
tmp_cck_max_pwdb) {
+ /* let sec and min point to the
different index */
tmp_cck_sec_pwdb = cur_cck_pwdb;
cck_rx_ver2_sec_index = i;
} else if ((cur_cck_pwdb <
tmp_cck_max_pwdb) && (cur_cck_pwdb > tmp_cck_sec_pwdb)) {
tmp_cck_sec_pwdb = cur_cck_pwdb;
cck_rx_ver2_sec_index = i;
- } else if (cur_cck_pwdb ==
tmp_cck_sec_pwdb) {
- if (tmp_cck_sec_pwdb ==
tmp_cck_min_pwdb) { /* let sec and min point to the different index */
- tmp_cck_sec_pwdb =
cur_cck_pwdb;
- cck_rx_ver2_sec_index =
i;
- } else {
- /* This case we don't
need to set any index */
- }
+ } else if (cur_cck_pwdb ==
tmp_cck_sec_pwdb && tmp_cck_sec_pwdb == tmp_cck_min_pwdb) {
+ /* let sec and min point to the
different index */
+ tmp_cck_sec_pwdb = cur_cck_pwdb;
+ cck_rx_ver2_sec_index = i;
+ /* otherwise we don't need to
set any index */
} else if ((cur_cck_pwdb <
tmp_cck_sec_pwdb) && (cur_cck_pwdb > tmp_cck_min_pwdb)) {
/* This case we don't need to
set any index */
- } else if (cur_cck_pwdb ==
tmp_cck_min_pwdb) {
- if (tmp_cck_sec_pwdb ==
tmp_cck_min_pwdb) { /* let sec and min point to the different index */
- tmp_cck_min_pwdb =
cur_cck_pwdb;
- cck_rx_ver2_min_index =
i;
- } else {
- /* This case we don't
need to set any index */
- }
+ } else if (cur_cck_pwdb ==
tmp_cck_min_pwdb && tmp_cck_sec_pwdb == tmp_cck_min_pwdb) {
+ /* let sec and min point to
the different index */
+ tmp_cck_min_pwdb = cur_cck_pwdb;
+ cck_rx_ver2_min_index = i;
+ /* otherwise we don't need to
set any index */
} else if (cur_cck_pwdb <
tmp_cck_min_pwdb) {
tmp_cck_min_pwdb = cur_cck_pwdb;
cck_rx_ver2_min_index = i;
--
2.2.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/
Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila wrote: > Use the irq_chip bus_sync_unlock method to update hardware registers > instead of scheduling work from the mask/unmask methods. This simplifies > a bit the driver and make it more uniform with the other GPIO IRQ > drivers. > > Signed-off-by: Octavian Purdila Patch applied for fixes. Yours, Linus Walleij -- 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 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila wrote: > As noticed during suspend/resume operations, the IRQ can be unmasked > then disabled in suspend and eventually enabled in resume, but without > being unmasked. > > The current implementation does not take into account interactions > between mask/unmask and enable/disable interrupts, and thus in the > above scenarios the IRQs remain unactive. > > To fix this we removed the enable/disable operations as they fallback > to mask/unmask anyway. > > We also remove the pending bitmaks as it is already done in irq_data > (i.e. IRQS_PENDING). > > Signed-off-by: Octavian Purdila Patch applied for fixes. Yours, Linus Walleij -- 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 V8 00/33] loop: Issue O_DIRECT aio using bio_vec
On Thu, Jul 25, 2013 at 7:50 PM, Dave Kleikamp wrote: > This patch series adds a kernel interface to fs/aio.c so that kernel code can > issue concurrent asynchronous IO to file systems. It adds an aio command and > file system methods which specify io memory with pages instead of userspace > addresses. > > This series was written to reduce the current overhead loop imposes by > performing synchronus buffered file system IO from a kernel thread. These > patches turn loop into a light weight layer that translates bios into iocbs. > > It introduces new file ops, read_iter() and write_iter(), that replace the > aio_read() and aio_write() operations. The iov_iter structure can now contain > either a user-space iovec or a kernel-space bio_vec. Since it would be > overly complicated to replace every instance of aio_read() and aio_write(), > the old operations are not removed, but file systems implementing the new > ones need not keep the old ones. > > Verion 8 is little changed from Version 7 that I send out in March, just > updated to the latest kernel. These patches apply to 3.11-rc2 and can > also be found at: > > git://github.com/kleikamp/linux-shaggy.git aio_loop > What has happened to that aio_loop patchset? Is it in Linux-next? ( /me started to play with "block: loop: convert to blk-mq (v3)", so I recalled this other improvement. ) - Sedat - > Asias He (1): > block_dev: add support for read_iter, write_iter > > Dave Kleikamp (22): > iov_iter: iov_iter_copy_from_user() should use non-atomic copy > iov_iter: add __iovec_copy_to_user() > fuse: convert fuse to use iov_iter_copy_[to|from]_user > iov_iter: ii_iovec_copy_to_user should pre-fault user pages > dio: Convert direct_IO to use iov_iter > dio: add bio_vec support to __blockdev_direct_IO() > aio: add aio_kernel_() interface > aio: add aio support for iov_iter arguments > fs: create file_readable() and file_writable() functions > fs: use read_iter and write_iter rather than aio_read and aio_write > fs: add read_iter and write_iter to several file systems > ocfs2: add support for read_iter and write_iter > ext4: add support for read_iter and write_iter > nfs: add support for read_iter, write_iter > nfs: simplify swap > btrfs: add support for read_iter and write_iter > xfs: add support for read_iter and write_iter > gfs2: Convert aio_read/write ops to read/write_iter > udf: convert file ops from aio_read/write to read/write_iter > afs: add support for read_iter and write_iter > ecrpytfs: Convert aio_read/write ops to read/write_iter > ubifs: convert file ops from aio_read/write to read/write_iter > > Hugh Dickins (1): > tmpfs: add support for read_iter and write_iter > > Zach Brown (9): > iov_iter: move into its own file > iov_iter: add copy_to_user support > iov_iter: hide iovec details behind ops function pointers > iov_iter: add bvec support > iov_iter: add a shorten call > iov_iter: let callers extract iovecs and bio_vecs > fs: pull iov_iter use higher up the stack > bio: add bvec_length(), like iov_length() > loop: use aio to perform io on the underlying file > > Documentation/filesystems/Locking | 6 +- > Documentation/filesystems/vfs.txt | 12 +- > drivers/block/loop.c| 148 > drivers/char/raw.c | 4 +- > drivers/mtd/nand/nandsim.c | 4 +- > drivers/usb/gadget/storage_common.c | 4 +- > fs/9p/vfs_addr.c| 12 +- > fs/9p/vfs_file.c| 8 +- > fs/Makefile | 2 +- > fs/adfs/file.c | 4 +- > fs/affs/file.c | 4 +- > fs/afs/file.c | 4 +- > fs/afs/internal.h | 3 +- > fs/afs/write.c | 9 +- > fs/aio.c| 152 - > fs/bad_inode.c | 14 ++ > fs/bfs/file.c | 4 +- > fs/block_dev.c | 27 ++- > fs/btrfs/file.c | 42 ++-- > fs/btrfs/inode.c| 63 +++--- > fs/ceph/addr.c | 3 +- > fs/cifs/file.c | 4 +- > fs/direct-io.c | 223 +-- > fs/ecryptfs/file.c | 15 +- > fs/exofs/file.c | 4 +- > fs/ext2/file.c | 4 +- > fs/ext2/inode.c | 8 +- > fs/ext3/file.c | 4 +- > fs/ext3/inode.c | 15 +- > fs/ext4/ext4.h | 3 +- > fs/ext4/file.c | 34 +-- > fs/ext4/indirect.c | 16 +- > fs/ext4/inode.c | 23 +- > fs/f2fs/data.c | 4 +- > fs/f2fs/file.c | 4 +- > fs/fat/file.c | 4 +- > fs/fat/inode.c | 10 +- > fs/fuse/cuse.c
[GIT PULL] Audit fixes for 3.19 #2
Hi Linus, One audit patch to resolve a panic/oops when recording filenames in the audit log, see the mail archive link below. The fix isn't as nice as I would like, as it involves an allocate/copy of the filename, but it solves the problem and the overhead should only affect users who have configured audit rules involving file names. We'll revisit this issue with future kernels in an attempt to make this suck less, but in the meantime I think this fix should go into the next release of v3.19-rcX. * https://marc.info/?t=14198692761=1=2 Thanks, -Paul --- The following changes since commit 041d7b98ffe59c59fdd639931dea7d74f9aa9a59: audit: restore AUDIT_LOGINUID unset ABI (2014-12-23 16:40:18 -0500) are available in the git repository at: git://git.infradead.org/users/pcmoore/audit upstream for you to fetch changes up to fcf22d8267ad2601fe9b6c549d1be96401c23e0b: audit: create private file name copies when auditing inodes (2014-12-30 09:26:21 -0500) Paul Moore (1): audit: create private file name copies when auditing inodes kernel/auditsc.c | 49 - 1 file changed, 40 insertions(+), 9 deletions(-) -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On 12/31/14 18:31, Theodore Ts'o wrote: On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote: It is unfortunately indeed. I think iwconfig and friends will never go away although iw is a better alternative, simply because people don't like to change their home-made scripts/tools. WIRELESS_EXT actually is largely, but not entirely, gone in upstream drivers and what we are talking about here is CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based drivers through a compatibility layer. Most poeple are still using "route" and "ifconfig" instead of "ip". Deal with it. Personally, I find it much easier to use the existing commands instead of figuring all of the various subcommands, and the options to the subcommands to commands like "ip" and "iw". At least "ip help route" will give me all of the options to "ip route", where as "iw help phy" doesn't tell give me the options; instead I have to paw through 300 lines of "iw help" in order to find the command I need. So having a better user interface / help system so people can better understand how to use iw would be a great step forward. Agree. I can't even recall using "ip" ever. iw help system does provide command specific help. The phy keyword is both a command and a selector key, which I realize is confusing to the user, eg. 'iw help info' does provide help for the 'info' subcommand. Better yet, why not hack into the "iw" command backwards compatibility so that if argv[0] is "iwlist" or "iwconfig", it provides the limited subset compatibility to the legacy commands. Then all you need to do is to convince the distributions to set up the packaging rules so that "iw" conflicts with wireless-tools, and you will be able to get everyone switched over to iw after at least seven years. Thanks. If there are still drivers, upstream or out-of-tree, providing only WEXT API this will not work unless iwconfig/iwlist can distinguish those from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl syscalls. Just not sure if it is worth the effort. As you stated below, it does not seem "evil" to retain WEXT if that is providing users what they need. Regards, Arend Note that I said *seven* years --- there are people who try to use an enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace, with a newer kernel, and and if said users notice, and complain, Linus *will* revert the commit. (Note that I've worked at more than one company where I was forced to use an older Ubuntu LTS or RHEL distro if I wanted to connect to the intranet, and I was using bleeding edge kernels --- and if anything like that had broken, I would have complained directly to Linus, cc'ing the patch author and the wireless maintainers with the revert. And while I fortunately am not trying to do upstream development with a stable distro, be sure there are other such folks around who have to live with similar restrictions.) - Ted P.S. If you really think it's evil that users use the simpler-to-understand iwconfig/iwlist interface over the iw command line interface, if you provide full backwards compatibility for the iwconfig/iwlist commands so you can "take over" from wireless-tools, you could even have a mode which, in addition to doing what the user wants, prints a "by the way, here's the equivalent if you want to use the iw command instead". I don't see the reason of allowing users to continue to use iwconfig and iwlist, though --- face it, route and ifconfig are going to be around for a long time; why not let users use iwconfig and iwlist if it's sufficient for their needs? -- 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 repost 12/16] parisc/uaccess: fix sparse errors
On Wed, 2014-12-31 at 20:38 +0200, Michael S. Tsirkin wrote: > On Wed, Dec 31, 2014 at 09:17:20AM -0800, James Bottomley wrote: [...] > > OK, parisc developers still being dense, but this does look like an > > abuse of the bitwise type. > > To give you another example: > > __le16 __user *p; > __le16 foo; > int rc = get_user(v, p); > > really should be fine, ATM this gives a warning. OK, I think I've figured it out. You're saying that casting __gu_val to a bitwise annotated type is an automatic sparse failure because it has to be a long in our assembly code to receive the load/store as a register. However, this is required for sparse to do the correct lvalue type = rvalue type check in the assignment to x. We were all thinking the __force just killed these sparse type checks. In that case, I think parisc is fine with this. James -- 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: scsi: non atomic allocation in mempool_alloc in atomic context
On 14-12-31 01:14 PM, Sasha Levin wrote:
Hi Christoph,
I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
a gfp_mask argument down the command setup path"):
[ 3395.328221] BUG: sleeping function called from invalid context at
mm/mempool.c:206
[ 3395.329540] in_atomic(): 1, irqs_disabled(): 0, pid: 6399, name: trinity-c531
[ 3395.331104] no locks held by trinity-c531/6399.
[ 3395.331849] Preemption disabled blk_execute_rq_nowait (block/blk-exec.c:95)
[ 3395.333145]
[ 3395.92] CPU: 5 PID: 6399 Comm: trinity-c531 Not tainted
3.19.0-rc1-next-20141226-sasha-00051-g2dd3d73 #1646
[ 3395.335266] 880608948000
880645a07548
[ 3395.337679] 9137c79d 880608948000
880645a07588
[ 3395.340220] 814ad713 9de20590 880608948000
926a166c
[ 3395.342643] Call Trace:
[ 3395.345099] dump_stack (lib/dump_stack.c:52)
[ 3395.346793] ___might_sleep (kernel/sched/core.c:7342)
[ 3395.348571] __might_sleep (kernel/sched/core.c:7308)
[ 3395.351944] mempool_alloc (mm/mempool.c:206 (discriminator 1))
[ 3395.355196] scsi_sg_alloc (drivers/scsi/scsi_lib.c:582)
[ 3395.356893] __sg_alloc_table (lib/scatterlist.c:282)
[ 3395.358844] ? sdev_disable_disk_events (drivers/scsi/scsi_lib.c:577)
[ 3395.360873] scsi_alloc_sgtable (drivers/scsi/scsi_lib.c:608)
[ 3395.362769] scsi_init_sgtable (drivers/scsi/scsi_lib.c:1087)
[ 3395.364583] ? lockdep_init_map (kernel/locking/lockdep.c:2986)
[ 3395.366354] scsi_init_io (drivers/scsi/scsi_lib.c:1122)
[ 3395.368092] ? do_init_timer (kernel/time/timer.c:669)
[ 3395.369837] scsi_setup_cmnd (drivers/scsi/scsi_lib.c:1220
drivers/scsi/scsi_lib.c:1268)
[ 3395.371743] scsi_queue_rq (drivers/scsi/scsi_lib.c:1875
drivers/scsi/scsi_lib.c:1980)
[ 3395.373471] __blk_mq_run_hw_queue (block/blk-mq.c:751)
[ 3395.375481] blk_mq_run_hw_queue (block/blk-mq.c:831)
[ 3395.377324] blk_mq_insert_request (block/blk-mq.h:92 block/blk-mq.c:974)
[ 3395.379377] ? blk_rq_map_user (block/blk-map.c:78 block/blk-map.c:142)
[ 3395.381307] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559
kernel/locking/lockdep.c:2601)
[ 3395.383485] blk_execute_rq_nowait (block/blk-exec.c:95)
[ 3395.386995] sg_common_write.isra.2 (drivers/scsi/sg.c:823)
[ 3395.388712] ? might_fault (mm/memory.c:3730)
[ 3395.390624] sg_write (drivers/scsi/sg.c:686)
[ 3395.403014] do_loop_readv_writev (fs/read_write.c:722)
[ 3395.407429] do_readv_writev (fs/read_write.c:854)
[ 3395.415486] vfs_writev (fs/read_write.c:893)
[ 3395.417116] SyS_writev (fs/read_write.c:926 fs/read_write.c:917)
[ 3395.418851] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:33)
[ 3395.420922] system_call_fastpath (arch/x86/kernel/entry_64.S:423)
Looks interesting: vfs injecting SCSI commands with iovec
through the sg driver's async interface.
The problem seems to be here in scsi_lib.c, mq=true:
static int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, int nents, bool mq)
{
struct scatterlist *first_chunk = NULL;
gfp_t gfp_mask = mq ? GFP_NOIO : GFP_ATOMIC;
int ret;
...
What is the downside of setting gfp_mask to GFP_ATOMIC
in all cases?
Doug Gilbert
--
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] Revert "cfg80211: make WEXT compatibility unselectable"
On 12/31/14 16:14, Andreas Hartmann wrote: Jiri Kosina wrote: On Wed, 31 Dec 2014, Arend van Spriel wrote: The thing with WEXT is that it will stay as is. So if tools like wicd want to support new features like P2P it will need to make the switch. I checked out wicd repo and found a number of iwconfig calls and they kick off wpa_supplicant with wext driver. Unfortunately this is by no means just about wicd. I have already received a few off-list mails from people who were wondering why their home-made scripts / tools, which are running 'iwconfig' directly suddenly stopped to work, and that it was indeed fallout of WEXT going away. Given the very short time this has been in mainline, you can probably imagine the fireworks once this appears in major release. It is not just the userspace tools (I prefer them, too), which need wext, but a lot of drivers, too, such as Mediathek drivers e.g. which perform *much* better compared to rt2x00, especially concerning USB chips like the one used by Linksys AE3000 (3x3 Mimo) (https://wikidevi.com/wiki/Linksys_AE3000), which achieves average throughputs around 14 MB/s *average* with scp of big (> 10 GB) crypted files even through reinforced-concrete floor(!) - rt2x00 is *far* away of providing such a performance. Next bad point of rt2x00 e.g. is the huge CPU overhead - compare rt5572sta on Raspi with rt2x00 running netperf and you will see the huge problem of rt2x00 (which is covered on x86 by mostly oversized multi core CPUs). Another big advantage of rt5572sta is: it is *stable* over a lot of kernel versions (as long as the kernel didn't break interfaces - but there are patches to catch them). Even ath9k, which usually is a really fine driver, is broken on some kernel versions (link and throughput is not stable - my use case depends *heavily* on very high and longterm stable throughput). That's why I'm using a VM for my ath9k-device to be independent of these quality problems of mac80211 (or maybe ath9k - don't know) over different kernel versions. All in all: If you want to get rid of wext, you still have to go a *very* long way to get the same *stable* and high throughput quality with *all* chips depending on mac80211 and not just a few flagship drivers like Atheros. Hi Andreas, That's a nice list of unrelated stuff. This has all nothing to do with WEXT. Actually, you can build rt5572sta with cfg80211 support (RT_CFG80211_SUPPORT). This thread is about the configuration API and not about driver performance. Regards, Arend Kind regards, Andreas Hartmann -- 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/
Re: perf-probe crash in dwarf_getcfi_elf
On Tue, Dec 30, 2014 at 06:05:33PM +0900, Namhyung Kim wrote: > And I found a related commit (5704c8c4fa71 "getcfi_scn_eh_frame: Don't > crash and burn when .eh_frame bits aren't there.") in elfutils that > can lead to a unexpected crash like this. To safely use the function, > it needs to check the .eh_frame section is a PROGBITS type. Sorry about that bug. It was fixed in elfutils 0.156, released July 2013. Latest elfutils release is 0.161. Checking .eh_frame is SHT_PROGBITS (and not SHT_NOBITS) looks like the correct workaround if you have to deal with older elfutils releases. Note that dwarf_getcfi_elf gets the CFI information from the .eh_frame section associated with the ELF file underlying the Dwarf dbg and needs to be released with a call to dwarf_cfi_end (). dwarf_getcfi () gets the CFI information from the .debug_frame section data of the Dwarf dbg and gets automatically releassed when dwarf_end () is called (you should not call dwarf_cfi_end () on the result). If the Dwarf dbg handle is associated with a separate debuginfo file, then the .eh_frame section data will not be available (has SHT_NOBITS) and you can get the .eh_frame section (and call dwarf_getcfi_elf ()) on the original ELF file from which the Dwarf debuginfo file was split off. In your patch you call dwarf_getcfi () as backup to get some CFI information when you cannot call dwarf_getcfi_elf (). In general it might make sense to also do this when dwarf_getcfi_elf fails. Or try to get the CFI through both .eh_frame (from the executable ELF file) with dwarf_getcfi_elf () and .debug_frame (from the Dwarf dbg file) with dwarf_getcfi () and try to match an address in both tables if one or the other fails. Cheers, Mark -- 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 1/4] staging: rtl8192u: fix comments
On 12/31, Lorenzo Stoakes wrote: > On 31 December 2014 at 19:00, Konrad Zapalowicz > wrote: > > > > You also fix the line length here which shall be the subject of a > > separate patch as this is not C99 comments related change. > > > > Apologies - I missed this, will prepare a v2 with this separated out > into a different patch. Relatedly, the intent was to fix whitespace > issues rather than line length as I gather a specific line length > limit is still a matter of debate in kernel style? I didn't want to Usually the kernel people like the line length of 80 characters. There are exceptions like for example for log messages because it makes easier to search for it however most of the time 80 is good and whenever possible it shall be applied. You can read about it in the https://www.kernel.org/doc/Documentation/CodingStyle document in second chapter. cheers, konrad > create additional noise by attempting to address that as well. > > Best, Lorenzo -- 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 1/4] staging: rtl8192u: fix comments
On 31 December 2014 at 19:23, Jeremiah Mahler wrote: > But this change is not related to C99 comments and you didn't > explain why this change was made in your log message. > It should probably be in a separate patch. Absolutely, I am currently fixing this and checking for any other instances where unrelated changes may have crept in. Apologies for this, a v2 of this patch set is coming shortly with this fixed. Best, Lorenzo -- 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 1/4] staging: rtl8192u: fix comments
Lorenzo,
On Wed, Dec 31, 2014 at 06:42:53PM +, Lorenzo Stoakes wrote:
> This patch fixes errors raised by checkpatch.pl relating to use of C99
> comments
> in r8192U_dm.c.
>
> Signed-off-by: Lorenzo Stoakes
> ---
> drivers/staging/rtl8192u/r8192U_dm.c | 841
> ++-
> 1 file changed, 432 insertions(+), 409 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> b/drivers/staging/rtl8192u/r8192U_dm.c
> index 936565d..44f4c38 100644
> --- a/drivers/staging/rtl8192u/r8192U_dm.c
> +++ b/drivers/staging/rtl8192u/r8192U_dm.c
> @@ -21,14 +21,15 @@ Major Change History:
> #include "r8190_rtl8256.h"
> #include "r819xU_cmdpkt.h"
> /*---Define Local
> Constant---*/
> -//
> -// Indicate different AP vendor for IOT issue.
> -//
> -static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
> 0xa44f, 0x5ea44f};
> -static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
> 0x5ea44f, 0x5ea44f};
> -
> +/*
> + * Indicate different AP vendor for IOT issue.
> + */
This is OK.
> +static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
> +};
> +static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
> +};
But this change is not related to C99 comments and you didn't
explain why this change was made in your log message.
It should probably be in a separate patch.
[...]
--
- Jeremiah Mahler
--
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 net-next] tun: return proper error code from tun_do_read
From: Alex Gartrell Date: Thu, 25 Dec 2014 23:22:49 -0800 > Instead of -1 with EAGAIN, read on a O_NONBLOCK tun fd will return 0. This > fixes this by properly returning the error code from __skb_recv_datagram. > > Signed-off-by: Alex Gartrell Applied. -- 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 net-next] tun: Fixed unsigned/signed comparison
From: Alex Gartrell Date: Thu, 25 Dec 2014 23:05:03 -0800 > Validated that this was actually using the unsigned comparison with gdb. > > Signed-off-by: Alex Gartrell Applied. -- 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 1/4] staging: rtl8192u: fix comments
On 31 December 2014 at 19:00, Konrad Zapalowicz wrote: > > You also fix the line length here which shall be the subject of a > separate patch as this is not C99 comments related change. > Apologies - I missed this, will prepare a v2 with this separated out into a different patch. Relatedly, the intent was to fix whitespace issues rather than line length as I gather a specific line length limit is still a matter of debate in kernel style? I didn't want to create additional noise by attempting to address that as well. Best, Lorenzo -- 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 akpm/next] lib: crc32: conditionally constify crc32 lookup table
Commit 8f243af42ade ("sections: fix const sections for crc32 table")
removed the compile-time generated crc32 tables from the RO sections,
because it conflicts with the definition of __cacheline_aligned
which puts all such aligned data into .data..cacheline_aligned section
optimized for wasting less space, and causes const align issues with
some GCC versions (see #52181, for example).
We can fix that in two steps: 1) by using the cacheline_aligned
version, which only aligns the data but doesn't move it into specific
sections, 2) test GCC and in problematic cases fall back to the current
code, otherwise use const and proper alignment for the lookup tables.
After patch tables are in RO:
$ nm -v lib/crc32.o | grep -1 -E "crc32c?table"
t arch_local_irq_enable
r crc32ctable_le
t crc32_exit
--
0960 t test_buf
2000 r crc32table_be
4000 r crc32table_le
1d1056e5 A __crc_crc32_be
Signed-off-by: Daniel Borkmann
Cc: Joe Mario
---
Makefile | 5 +
lib/Makefile | 3 +++
lib/gen_crc32table.c | 21 +++--
scripts/gcc-const-align.sh | 21 +
4 files changed, 44 insertions(+), 6 deletions(-)
create mode 100755 scripts/gcc-const-align.sh
diff --git a/Makefile b/Makefile
index ef748e1..be02ac2 100644
--- a/Makefile
+++ b/Makefile
@@ -776,6 +776,11 @@ ifeq ($(shell $(CONFIG_SHELL)
$(srctree)/scripts/gcc-goto.sh $(CC)), y)
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
endif
+# check for const + align
+ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-const-align.sh $(CC)), y)
+ KBUILD_CFLAGS += -DCC_HAVE_CONST_ALIGN
+endif
+
include $(srctree)/scripts/Makefile.extrawarn
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
diff --git a/lib/Makefile b/lib/Makefile
index 3c3b30b..8b33eec 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -171,6 +171,9 @@ obj-$(CONFIG_FONT_SUPPORT) += fonts/
hostprogs-y:= gen_crc32table
clean-files:= crc32table.h
+# We need to transfer this flag to the host compiler if present
+HOSTCFLAGS_gen_crc32table.o := $(findstring
-DCC_HAVE_CONST_ALIGN,$(KBUILD_CFLAGS))
+
$(obj)/crc32.o: $(obj)/crc32table.h
quiet_cmd_crc32 = GEN $@
diff --git a/lib/gen_crc32table.c b/lib/gen_crc32table.c
index 71fcfcd..2f06893 100644
--- a/lib/gen_crc32table.c
+++ b/lib/gen_crc32table.c
@@ -21,6 +21,14 @@
# define BE_TABLE_SIZE (1 << CRC_BE_BITS)
#endif
+#ifdef CC_HAVE_CONST_ALIGN
+# define TABLE_CONST_ATTR "const"
+# define TABLE_ALIGNMENT "cacheline_aligned"
+#else
+# define TABLE_CONST_ATTR ""
+# define TABLE_ALIGNMENT "__cacheline_aligned"
+#endif
+
static uint32_t crc32table_le[LE_TABLE_ROWS][256];
static uint32_t crc32table_be[BE_TABLE_ROWS][256];
static uint32_t crc32ctable_le[LE_TABLE_ROWS][256];
@@ -109,8 +117,8 @@ int main(int argc, char** argv)
if (CRC_LE_BITS > 1) {
crc32init_le();
- printf("static u32 __cacheline_aligned "
- "crc32table_le[%d][%d] = {",
+ printf("static %s u32 %s crc32table_le[%d][%d] = {",
+ TABLE_CONST_ATTR, TABLE_ALIGNMENT,
LE_TABLE_ROWS, LE_TABLE_SIZE);
output_table(crc32table_le, LE_TABLE_ROWS,
LE_TABLE_SIZE, "tole");
@@ -119,17 +127,18 @@ int main(int argc, char** argv)
if (CRC_BE_BITS > 1) {
crc32init_be();
- printf("static u32 __cacheline_aligned "
- "crc32table_be[%d][%d] = {",
+ printf("static %s u32 %s crc32table_be[%d][%d] = {",
+ TABLE_CONST_ATTR, TABLE_ALIGNMENT,
BE_TABLE_ROWS, BE_TABLE_SIZE);
output_table(crc32table_be, LE_TABLE_ROWS,
BE_TABLE_SIZE, "tobe");
printf("};\n");
}
+
if (CRC_LE_BITS > 1) {
crc32cinit_le();
- printf("static u32 __cacheline_aligned "
- "crc32ctable_le[%d][%d] = {",
+ printf("static %s u32 %s crc32ctable_le[%d][%d] = {",
+ TABLE_CONST_ATTR, TABLE_ALIGNMENT,
LE_TABLE_ROWS, LE_TABLE_SIZE);
output_table(crc32ctable_le, LE_TABLE_ROWS,
LE_TABLE_SIZE, "tole");
diff --git a/scripts/gcc-const-align.sh b/scripts/gcc-const-align.sh
new file mode 100755
index 000..9b4cf69
--- /dev/null
+++ b/scripts/gcc-const-align.sh
@@ -0,0 +1,21 @@
+#!/bin/sh
+# Test for gcc const + __attribute__((aligned())) support
+
+cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
+/*
+ * Some GCC versions will result in broken alignment, probe for
+ * them so we can work around this (see GCC Bug 52181).
+ */
+#define SMP_CACHE_BYTES 64 /* Example alignment. */
+extern const int tv1[];
+const int
Re: [PATCH 1/4] staging: rtl8192u: fix comments
On 12/31, Lorenzo Stoakes wrote:
> This patch fixes errors raised by checkpatch.pl relating to use of C99
> comments
> in r8192U_dm.c.
>
> Signed-off-by: Lorenzo Stoakes
> ---
> drivers/staging/rtl8192u/r8192U_dm.c | 841
> ++-
> 1 file changed, 432 insertions(+), 409 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> b/drivers/staging/rtl8192u/r8192U_dm.c
> index 936565d..44f4c38 100644
> --- a/drivers/staging/rtl8192u/r8192U_dm.c
> +++ b/drivers/staging/rtl8192u/r8192U_dm.c
> @@ -21,14 +21,15 @@ Major Change History:
> #include "r8190_rtl8256.h"
> #include "r819xU_cmdpkt.h"
> /*---Define Local
> Constant---*/
> -//
> -// Indicate different AP vendor for IOT issue.
> -//
> -static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
> 0xa44f, 0x5ea44f};
> -static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
> - { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
> 0x5ea44f, 0x5ea44f};
> -
> +/*
> + * Indicate different AP vendor for IOT issue.
> + */
> +static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
> +};
> +static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
> + 0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
> +};
You also fix the line length here which shall be the subject of a
separate patch as this is not C99 comments related change.
Thanks,
Konrad
> #define RTK_UL_EDCA 0xa44f
> #define RTK_DL_EDCA 0x5e4322
> @@ -36,11 +37,11 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
>
>
> /*Define global
> variable-*/
> -// Debug variable ?
> +/* Debug variable ? */
> dig_tdm_digtable;
> -// Store current software write register content for MAC PHY.
> +/* Store current software write register content for MAC PHY. */
> u8 dm_shadow[16][256] = {{0}};
> -// For Dynamic Rx Path Selection by Signal Strength
> +/* For Dynamic Rx Path Selection by Signal Strength */
> DRxPathSel DM_RxPathSelTable;
> /*Define global
> variable-*/
>
> @@ -56,24 +57,24 @@ externvoid dm_check_fsync(struct net_device *dev);
>
>
> /*-Define local function
> prototype---*/
> -// DM --> Rate Adaptive
> +/* DM --> Rate Adaptive */
> static voiddm_check_rate_adaptive(struct net_device *dev);
>
> -// DM --> Bandwidth switch
> +/* DM --> Bandwidth switch */
> static voiddm_init_bandwidth_autoswitch(struct net_device *dev);
> static voiddm_bandwidth_autoswitch(struct net_device *dev);
>
> -// DM --> TX power control
> -//static voiddm_initialize_txpower_tracking(struct net_device *dev);
> +/* DM --> TX power control */
> +/*static voiddm_initialize_txpower_tracking(struct net_device
> *dev);*/
>
> static voiddm_check_txpower_tracking(struct net_device *dev);
>
>
>
> -//static voiddm_txpower_reset_recovery(struct net_device *dev);
> +/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
>
>
> -// DM --> Dynamic Init Gain by RSSI
> +/* DM --> Dynamic Init Gain by RSSI */
> static voiddm_dig_init(struct net_device *dev);
> static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
> static voiddm_ctrl_initgain_byrssi_highpwr(struct net_device *dev);
> @@ -84,61 +85,61 @@ staticvoiddm_pd_th(struct net_device *dev);
> static voiddm_cs_ratio(struct net_device *dev);
>
> static void dm_init_ctstoself(struct net_device *dev);
> -// DM --> EDCA turbo mode control
> +/* DM --> EDCA turbo mode control */
> static voiddm_check_edca_turbo(struct net_device *dev);
>
> -//static voiddm_gpio_change_rf(struct net_device *dev);
> -// DM --> Check PBC
> +/*static voiddm_gpio_change_rf(struct net_device *dev);*/
> +/* DM --> Check PBC */
> static void dm_check_pbc_gpio(struct net_device *dev);
>
>
> -// DM --> Check current RX RF path state
> +/* DM --> Check current RX RF path state */
> static voiddm_check_rx_path_selection(struct net_device *dev);
> static void dm_init_rxpath_selection(struct net_device *dev);
> static void dm_rxpath_sel_byrssi(struct net_device *dev);
>
>
> -// DM --> Fsync for broadcom ap
> +/* DM --> Fsync for broadcom ap */
> static void dm_init_fsync(struct net_device *dev);
> static void dm_deInit_fsync(struct net_device *dev);
>
> -//Added by vivi, 20080522
> +/* Added by vivi, 20080522 */
> static voiddm_check_txrateandretrycount(struct net_device *dev);
>
> /*-Define local function
> prototype---*/
>
> -/*-Define of Tx Power Control For Near/Far Range
> */ //Add by
[PATCH v3] staging: lustre: libcfs: fix sparse warnings about static declaration
Fixes the following sparse warnings:
drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c:198:1: warning:
symbol 'libcfs_arch_init' was not declared. Should it be static?
drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c:204:1: warning:
symbol 'libcfs_arch_cleanup' was not declared. Should it be static?
Signed-off-by: Serguey Parkhomovsky
---
v3: Wrap commit message at 72 cols, and remove filename from subject line.
v2: Don't break the build, and fix the warnings by defining the functions in
libcfs.h.
drivers/staging/lustre/include/linux/libcfs/libcfs.h | 3 +++
drivers/staging/lustre/lustre/libcfs/module.c| 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index a6b2f90..4410d7f 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -85,6 +85,9 @@ static inline int __is_po2(unsigned long long val)
#include
+int libcfs_arch_init(void);
+void libcfs_arch_cleanup(void);
+
/* libcfs tcpip */
int libcfs_ipif_query(char *name, int *up, __u32 *ip, __u32 *mask);
int libcfs_ipif_enumerate(char ***names);
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
b/drivers/staging/lustre/lustre/libcfs/module.c
index 2c4fc74..31a4d19 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -334,8 +334,6 @@ extern struct mutex cfs_trace_thread_mutex;
extern struct cfs_wi_sched *cfs_sched_rehash;
extern void libcfs_init_nidstrings(void);
-extern int libcfs_arch_init(void);
-extern void libcfs_arch_cleanup(void);
static int init_libcfs_module(void)
{
--
1.9.3
--
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 v2] staging: lustre: linux-prim.c: fix sparse warnings about static declaration
On Wed, Dec 31, 2014 at 11:40:29AM +0100, Konrad Zapalowicz wrote: > This lines are way too long. You should break the commit message line > around 72nd column so that it looks nice when emailed. > > You can also omit the filename from the topic line as this is already in > the diff. Thanks for the feedback; I'll send an updated patch that fixes these issues. Serguey -- 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 4/4] staging: rtl8192u: Refactor heavy nesting
This patch fixes warnings raised by checkpatch.pl relating to heavily indented
lines in r8192U_dm.c. It refactors a couple of else if cases to achieve the same
outcome indented by one fewer tab. It additionally updateds comment positioning
to be consistent across these cases.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 0839ea7..72d1f47 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -2585,28 +2585,25 @@ static void dm_rxpath_sel_byrssi(struct net_device *dev)
cck_rx_ver2_sec_index =
cck_rx_ver2_max_index;
tmp_cck_max_pwdb = cur_cck_pwdb;
cck_rx_ver2_max_index = i;
- } else if (cur_cck_pwdb ==
tmp_cck_max_pwdb) { /* let sec and min point to the different index */
+ } else if (cur_cck_pwdb ==
tmp_cck_max_pwdb) {
+ /* let sec and min point to the
different index */
tmp_cck_sec_pwdb = cur_cck_pwdb;
cck_rx_ver2_sec_index = i;
} else if ((cur_cck_pwdb <
tmp_cck_max_pwdb) && (cur_cck_pwdb > tmp_cck_sec_pwdb)) {
tmp_cck_sec_pwdb = cur_cck_pwdb;
cck_rx_ver2_sec_index = i;
- } else if (cur_cck_pwdb ==
tmp_cck_sec_pwdb) {
- if (tmp_cck_sec_pwdb ==
tmp_cck_min_pwdb) { /* let sec and min point to the different index */
- tmp_cck_sec_pwdb =
cur_cck_pwdb;
- cck_rx_ver2_sec_index =
i;
- } else {
- /* This case we don't
need to set any index */
- }
+ } else if (cur_cck_pwdb ==
tmp_cck_sec_pwdb && tmp_cck_sec_pwdb == tmp_cck_min_pwdb) {
+ /* let sec and min point to the
different index */
+ tmp_cck_sec_pwdb = cur_cck_pwdb;
+ cck_rx_ver2_sec_index = i;
+ /* otherwise we don't need to
set any index */
} else if ((cur_cck_pwdb <
tmp_cck_sec_pwdb) && (cur_cck_pwdb > tmp_cck_min_pwdb)) {
/* This case we don't need to
set any index */
- } else if (cur_cck_pwdb ==
tmp_cck_min_pwdb) {
- if (tmp_cck_sec_pwdb ==
tmp_cck_min_pwdb) { /* let sec and min point to the different index */
- tmp_cck_min_pwdb =
cur_cck_pwdb;
- cck_rx_ver2_min_index =
i;
- } else {
- /* This case we don't
need to set any index */
- }
+ } else if (cur_cck_pwdb ==
tmp_cck_min_pwdb && tmp_cck_sec_pwdb == tmp_cck_min_pwdb) {
+ /* let sec and min point to
the different index */
+ tmp_cck_min_pwdb = cur_cck_pwdb;
+ cck_rx_ver2_min_index = i;
+ /* otherwise we don't need to
set any index */
} else if (cur_cck_pwdb <
tmp_cck_min_pwdb) {
tmp_cck_min_pwdb = cur_cck_pwdb;
cck_rx_ver2_min_index = i;
--
2.2.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 3/4] staging: rtl8192u: remove redundant code
This patch fixes warnings/errors raised by checkpatch.pl relating to redundant
code in r8192U_dm.c.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 160 +--
1 file changed, 77 insertions(+), 83 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index bf141c6..0839ea7 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -412,9 +412,9 @@ static void dm_check_rate_adaptive(struct net_device *dev)
ratr_value = targetRATR;
RT_TRACE(COMP_RATE, "currentRATR = %x, targetRATR =
%x\n", currentRATR, targetRATR);
- if (priv->rf_type == RF_1T2R) {
+ if (priv->rf_type == RF_1T2R)
ratr_value &= ~(RATE_ALL_OFDM_2SS);
- }
+
write_nic_dword(dev, RATR0, ratr_value);
write_nic_byte(dev, UFWP, 1);
@@ -442,18 +442,17 @@ static void dm_bandwidth_autoswitch(struct net_device
*dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
- if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable) {
+ if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable)
return;
- } else {
- if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
false) { /* If send packets in 40 Mhz in 20/40 */
- if (priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = true;
- } else { /* in force send packets in 20 Mhz in 20/40 */
- if (priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = false;
- }
+ if (priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz == false) {
/* If send packets in 40 Mhz in 20/40 */
+ if (priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= true;
+ } else { /* in force send packets in 20 Mhz in 20/40 */
+ if (priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= false;
}
+
} /* dm_BandwidthAutoSwitch */
/* OFDM default at 0db, index=6. */
@@ -540,9 +539,9 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
tx_cmd.Length = 4;
tx_cmd.Value= Value;
rtStatus = SendTxCommandPacket(dev, _cmd, 12);
- if (rtStatus == RT_STATUS_FAILURE) {
+ if (rtStatus == RT_STATUS_FAILURE)
RT_TRACE(COMP_POWER_TRACKING, "Set configuration with tx cmd
queue fail!\n");
- }
+
mdelay(1);
/*DbgPrint("hi, vivi, strange\n");*/
for (i = 0; i <= 30; i++) {
@@ -582,9 +581,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
break;
}
- for (k = 0; k < 5; k++) {
+ for (k = 0; k < 5; k++)
Avg_TSSI_Meas_from_driver += tmp_report[k];
- }
Avg_TSSI_Meas_from_driver = Avg_TSSI_Meas_from_driver*100/5;
RT_TRACE(COMP_POWER_TRACKING, "Avg_TSSI_Meas_from_driver =
%d\n", Avg_TSSI_Meas_from_driver);
@@ -607,43 +605,44 @@ static void dm_TXPowerTrackingCallback_TSSI(struct
net_device *dev)
RT_TRACE(COMP_POWER_TRACKING,
"priv->cck_present_attentuation_difference = %d\n",
priv->cck_present_attentuation_difference);
RT_TRACE(COMP_POWER_TRACKING,
"priv->cck_present_attentuation = %d\n", priv->cck_present_attentuation);
return;
- } else {
- if (Avg_TSSI_Meas_from_driver < TSSI_13dBm -
E_FOR_TX_POWER_TRACK) {
- if (priv->rfa_txpowertrackingindex > 0) {
- priv->rfa_txpowertrackingindex--;
- if (priv->rfa_txpowertrackingindex_real
> 4) {
-
priv->rfa_txpowertrackingindex_real--;
- rtl8192_setBBreg(dev,
rOFDM0_XATxIQImbalance, bMaskDWord,
priv->txbbgain_table[priv->rfa_txpowertrackingindex_real].txbbgain_value);
- }
- }
- } else {
-
[PATCH 1/4] staging: rtl8192u: fix comments
This patch fixes errors raised by checkpatch.pl relating to use of C99 comments
in r8192U_dm.c.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 841 ++-
1 file changed, 432 insertions(+), 409 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 936565d..44f4c38 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -21,14 +21,15 @@ Major Change History:
#include "r8190_rtl8256.h"
#include "r819xU_cmdpkt.h"
/*---Define Local Constant---*/
-//
-// Indicate different AP vendor for IOT issue.
-//
-static u32 edca_setting_DL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0x5e4322, 0x5e4322, 0x604322,
0xa44f, 0x5ea44f};
-static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
- { 0x5e4322, 0xa44f, 0x5e4322, 0x604322,
0x5ea44f, 0x5ea44f};
-
+/*
+ * Indicate different AP vendor for IOT issue.
+ */
+static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
+};
+static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
+ 0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
+};
#define RTK_UL_EDCA 0xa44f
#define RTK_DL_EDCA 0x5e4322
@@ -36,11 +37,11 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] =
/*Define global variable-*/
-// Debug variable ?
+/* Debug variable ? */
dig_t dm_digtable;
-// Store current software write register content for MAC PHY.
+/* Store current software write register content for MAC PHY. */
u8 dm_shadow[16][256] = {{0}};
-// For Dynamic Rx Path Selection by Signal Strength
+/* For Dynamic Rx Path Selection by Signal Strength */
DRxPathSel DM_RxPathSelTable;
/*Define global variable-*/
@@ -56,24 +57,24 @@ extern void dm_check_fsync(struct net_device *dev);
/*-Define local function prototype---*/
-// DM --> Rate Adaptive
+/* DM --> Rate Adaptive */
static voiddm_check_rate_adaptive(struct net_device *dev);
-// DM --> Bandwidth switch
+/* DM --> Bandwidth switch */
static voiddm_init_bandwidth_autoswitch(struct net_device *dev);
static voiddm_bandwidth_autoswitch(struct net_device *dev);
-// DM --> TX power control
-//static voiddm_initialize_txpower_tracking(struct net_device *dev);
+/* DM --> TX power control */
+/*static voiddm_initialize_txpower_tracking(struct net_device
*dev);*/
static voiddm_check_txpower_tracking(struct net_device *dev);
-//static voiddm_txpower_reset_recovery(struct net_device *dev);
+/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
-// DM --> Dynamic Init Gain by RSSI
+/* DM --> Dynamic Init Gain by RSSI */
static voiddm_dig_init(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi_highpwr(struct net_device *dev);
@@ -84,61 +85,61 @@ static voiddm_pd_th(struct net_device *dev);
static voiddm_cs_ratio(struct net_device *dev);
static void dm_init_ctstoself(struct net_device *dev);
-// DM --> EDCA turbo mode control
+/* DM --> EDCA turbo mode control */
static voiddm_check_edca_turbo(struct net_device *dev);
-//static voiddm_gpio_change_rf(struct net_device *dev);
-// DM --> Check PBC
+/*static voiddm_gpio_change_rf(struct net_device *dev);*/
+/* DM --> Check PBC */
static void dm_check_pbc_gpio(struct net_device *dev);
-// DM --> Check current RX RF path state
+/* DM --> Check current RX RF path state */
static voiddm_check_rx_path_selection(struct net_device *dev);
static void dm_init_rxpath_selection(struct net_device *dev);
static void dm_rxpath_sel_byrssi(struct net_device *dev);
-// DM --> Fsync for broadcom ap
+/* DM --> Fsync for broadcom ap */
static void dm_init_fsync(struct net_device *dev);
static void dm_deInit_fsync(struct net_device *dev);
-//Added by vivi, 20080522
+/* Added by vivi, 20080522 */
static voiddm_check_txrateandretrycount(struct net_device *dev);
/*-Define local function prototype---*/
-/*-Define of Tx Power Control For Near/Far Range
*/ //Add by Jacken 2008/02/18
+/*-Define of Tx Power Control For Near/Far Range
*/ /*Add by Jacken 2008/02/18 */
static voiddm_init_dynamic_txpower(struct net_device *dev);
static voiddm_dynamic_txpower(struct net_device *dev);
-// DM --> For rate adaptive and DIG, we must send RSSI to firmware
+/* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
static void dm_send_rssi_tofw(struct net_device *dev);
static voiddm_ctstoself(struct net_device *dev);
[PATCH 2/4] staging: rtl8192u: fix whitespace
This patch fixes warnings/errors raised by checkpatch.pl relating to whitespace
in r8192U_dm.c.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/rtl8192u/r8192U_dm.c | 1409 +-
1 file changed, 530 insertions(+), 879 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 44f4c38..bf141c6 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -25,7 +25,7 @@ Major Change History:
* Indicate different AP vendor for IOT issue.
*/
static u32 edca_setting_DL[HT_IOT_PEER_MAX] = {
- 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
+ 0x5e4322, 0x5e4322, 0x5e4322, 0x604322, 0xa44f, 0x5ea44f
};
static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
0x5e4322, 0xa44f, 0x5e4322, 0x604322, 0x5ea44f, 0x5ea44f
@@ -40,7 +40,7 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
/* Debug variable ? */
dig_t dm_digtable;
/* Store current software write register content for MAC PHY. */
-u8 dm_shadow[16][256] = {{0}};
+u8 dm_shadow[16][256] = { {0} };
/* For Dynamic Rx Path Selection by Signal Strength */
DRxPathSel DM_RxPathSelTable;
/*Define global variable-*/
@@ -69,11 +69,8 @@ static voiddm_bandwidth_autoswitch(struct
net_device *dev);
static voiddm_check_txpower_tracking(struct net_device *dev);
-
-
/*static voiddm_txpower_reset_recovery(struct net_device *dev);*/
-
/* DM --> Dynamic Init Gain by RSSI */
static voiddm_dig_init(struct net_device *dev);
static voiddm_ctrl_initgain_byrssi(struct net_device *dev);
@@ -92,13 +89,11 @@ static voiddm_check_edca_turbo(struct net_device
*dev);
/* DM --> Check PBC */
static void dm_check_pbc_gpio(struct net_device *dev);
-
/* DM --> Check current RX RF path state */
static voiddm_check_rx_path_selection(struct net_device *dev);
static void dm_init_rxpath_selection(struct net_device *dev);
static void dm_rxpath_sel_byrssi(struct net_device *dev);
-
/* DM --> Fsync for broadcom ap */
static void dm_init_fsync(struct net_device *dev);
static void dm_deInit_fsync(struct net_device *dev);
@@ -112,7 +107,6 @@ static voiddm_check_txrateandretrycount(struct
net_device *dev);
static voiddm_init_dynamic_txpower(struct net_device *dev);
static voiddm_dynamic_txpower(struct net_device *dev);
-
/* DM --> For rate adaptive and DIG, we must send RSSI to firmware */
static void dm_send_rssi_tofw(struct net_device *dev);
static voiddm_ctstoself(struct net_device *dev);
@@ -151,14 +145,12 @@ void init_hal_dm(struct net_device *dev)
void deinit_hal_dm(struct net_device *dev)
{
-
dm_deInit_fsync(dev);
-
}
-
#ifdef USB_RX_AGGREGATION_SUPPORT
-void dm_CheckRxAggregation(struct net_device *dev) {
+void dm_CheckRxAggregation(struct net_device *dev)
+{
struct r8192_priv *priv = ieee80211_priv((struct net_device *)dev);
PRT_HIGH_THROUGHPUT pHTInfo = priv->ieee80211->pHTInfo;
static unsigned longlastTxOkCnt;
@@ -187,14 +179,15 @@ void dm_CheckRxAggregation(struct net_device *dev) {
if ((curTxOkCnt + curRxOkCnt) < 1500)
return;
- if(curTxOkCnt > 4*curRxOkCnt) {
+ if (curTxOkCnt > 4*curRxOkCnt) {
if (priv->bCurrentRxAggrEnable) {
write_nic_dword(dev, 0x1a8, 0);
priv->bCurrentRxAggrEnable = false;
}
- }else{
+ } else {
if (!priv->bCurrentRxAggrEnable &&
!pHTInfo->bCurrentRT2RTAggregation) {
u32 ulValue;
+
ulValue = (pHTInfo->UsbRxFwAggrEn<<24) |
(pHTInfo->UsbRxFwAggrPageNum<<16) |
(pHTInfo->UsbRxFwAggrPacketNum<<8) |
(pHTInfo->UsbRxFwAggrTimeout);
/*
@@ -212,8 +205,6 @@ void dm_CheckRxAggregation(struct net_device *dev) {
} /* dm_CheckEdcaTurbo */
#endif
-
-
void hal_dm_watchdog(struct net_device *dev)
{
/*struct r8192_priv *priv = ieee80211_priv(dev);*/
@@ -240,7 +231,6 @@ void hal_dm_watchdog(struct net_device *dev)
#endif
} /* HalDmWatchDog */
-
/*
* Decide Rate Adaptive Set according to distance (signal strength)
* 01/11/2008 MHC Modify input arguments and RATR table
level.
@@ -249,7 +239,6 @@ void hal_dm_watchdog(struct net_device *dev)
*/
void init_rate_adaptive(struct net_device *dev)
{
-
struct r8192_priv *priv = ieee80211_priv(dev);
prate_adaptive pra = (prate_adaptive)>rate_adaptive;
@@ -262,15 +251,13 @@ void init_rate_adaptive(struct net_device *dev)
pra->low_rssi_thresh_for_ra20M = RateAdaptiveTH_Low_20M;
pra->low_rssi_thresh_for_ra40M = RateAdaptiveTH_Low_40M;
- if(priv->CustomerID == RT_CID_819x_Netcore)
+ if (priv->CustomerID == RT_CID_819x_Netcore)
Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
On Wed, Dec 31, 2014 at 09:17:20AM -0800, James Bottomley wrote:
> On Sat, 2014-12-27 at 18:14 +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 25, 2014 at 11:37:45PM +0100, Helge Deller wrote:
> > > Hi Michael,
> > >
> > > On 12/25/2014 10:29 AM, Michael S. Tsirkin wrote:
> > > >virtio wants to read bitwise types from userspace using get_user. At the
> > >
> > > I don't know the virtio code much yet, but does it makes sense to read
> > > bitwise types?
> > > Will virtio then get possible troubles because of endianess correct as
> > > well?
> >
> > There's no conversion: we are reading from __virtio16 __user *
> > pointer into __virtio16 v value.
> >
> > > Do you have a code example, or the sparse error message ?
> > >
> > > Helge
> >
> > Sure. the code is upstream now.
> > The warning is below.
> >
> > sparse warnings: (new ones prefixed by >>)
> >
> > >> drivers/vhost/vringh.c:554:18: sparse: cast to restricted __virtio16
> >
> > vim +554 drivers/vhost/vringh.c
> >
> >538 __virtio16
> > *p, u16 val))
> >539 {
> >540 if (!vrh->event_indices) {
> >541 /* Old-school; update flags. */
> >542 if (putu16(vrh, >vring.used->flags,
> >543 VRING_USED_F_NO_NOTIFY)) {
> >544 vringh_bad("Setting used flags %p",
> >545 >vring.used->flags);
> >546 }
> >547 }
> >548 }
> >549
> >550 /* Userspace access helpers: in this case, addresses are really
> > userspace. */
> >551 static inline int getu16_user(const struct vringh *vrh, u16 *val,
> > const __virtio16 *p)
> >552 {
> >553 __virtio16 v = 0;
> > > 554 int rc = get_user(v, (__force __virtio16 __user *)p);
> >555 *val = vringh16_to_cpu(vrh, v);
> >556 return rc;
> >557 }
> >558
> >559 static inline int putu16_user(const struct vringh *vrh, __virtio16
> > *p, u16 val)
> >560 {
> >561 __virtio16 v = cpu_to_vringh16(vrh, val);
> >562 return put_user(v, (__force __virtio16 __user *)p);
>
> OK, parisc developers still being dense, but this does look like an
> abuse of the bitwise type.
To give you another example:
__le16 __user *p;
__le16 foo;
int rc = get_user(v, p);
really should be fine, ATM this gives a warning.
> bitwise is supposed to be consumed by endian
> specific accessors.
Surely, assignment is OK too? get_user is exactly that.
vringh16_to_cpu is an endian specific accessor.
Look up it's definition please. The reason for that __force is
because we are adding __user.
It's a decision Rusty made to reduce code duplication:
we have some code that handles both kernel and userspace pointers.
> get/put_user have no endian tags because they
> really can't do this ... the potential for width mismatch between the
> user and kernel address spaces could cause havoc if people get this
> wrong, so the warning looks correct to me.
I'm sorry I don't understand.
Why is
access_ok
__get_user
safer than
get_user
?
It does not trigger the warning, because
__get_user does not have the cast to long internally.
Also, on some architectures get_user does not cast to long
internally so there's no warning.
> If we take your proposed patch we lose the type checking on all
> accessors because of the __force.
Did you try? In my testing, this is not at all true.
For example with my patch:
u16 v = 0;
int rc = get_user(v, (__force __virtio16 __user *)p);
correctly triggers a warning.
> Why not, instead, alter your code to
> tell the kernel you know what you're doing:
>
> __u16 v = 0;
> int rc = get_user(v, (__force __u16 __user *)p);
> *val = vringh16_to_cpu(vrh, (__force __virtio16)v);
> return rc;
>
> That way the accessors still warn if anyone else tries this
Hmm I don't understand, sorry. Tries what?
Can you please show me an invalid use of get_user that
produces a warning currently but won't with my patch?
> but your
> warning is gone and the code basically says you knew the u16 was really
> an endianness specific virtio quantity?
>
> James
>
(__force __virtio16 __user *)
tells get_user exactly that pointer is to type __virtio16.
It does not get any more explicit.
What you are proposing is really discarding type
information by a bunch of __force calls.
I am very reluctant to do this.
In fact, because of the static checking I added,
conversion to virtio 1.0 went so smoothly:
most drivers worked right away after the conversion.
I'm very sure without static checking, or with
__force thrown around liberally, I would have
vringh specifically has one __force cast anyway because
it's mixing userspace and kernel pointers.
But, I also have an out of tree patch that use
Re: EFI mixed mode + perf = rampant triple faults
On Wed, 17 Dec, at 08:54:56AM, Andy Lutomirski wrote: > [trying again with .org spelled correctly. also cc: bpetkov] > > On Wed, Dec 17, 2014 at 8:51 AM, Andy Lutomirski wrote: > > I figured I should send this email before I forget about this issue: > > > > If you run perf record across any EFI mixed mode call or otherwise > > receive an NMI or MCE, the machine triple-faults. The cause is > > straightforward: there is no valid IDT when we have long mode disabled > > for the duration of the EFI call. Right, the lack of IDT is intentional since we disable interrupts while making the EFI call and so far I have side-stepped (ignored) the NMI/MCE issue. Perf is an interesting use case. I've admittedly never used it with EFI mixed mode, but yes, we should definitely get that working (if NMI/MCE handling wasn't justification enough). > > As far as I know, the only way to have continuously functional interrupt > > handling across a long mode transition is to install an interrupt vector > > table and hope that CPUs actually do something intelligent when > > receiving an interrupt with LME=1, LMA=1, and PG=0. Yuck. > > > > Could we get away with issuing 32-bit EFI calls in compat mode, i.e. > > with a 32-bit CPL0 CS but while still in long mode? I think that > > delivery of an IST interrupt (which includes both NMI and MCE) will > > correctly switch to a fully valid 64-bit state and would correctly > > switch back when we execute IRET at the end. (Am I missing some reason > > that switching bitness without a privilege level change doesn't work > > well? I haven't thought of anything, other than the lack of SS/SP controls > > on intra-ring interrupts, but that shouldn't be an issue here.) > > > > As an added benefit, this would considerably simplify the code. I can't immediately think of a reason that this wouldn't work, but I've Cc'd more x86 folks for additional insight. I will schedule some time to look into this issue in the new year. Thanks Andy. -- Matt Fleming, Intel Open Source Technology Center -- 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] Drivers: isdn: gigaset: checkpatch cleanup
Bas, On Wed, Dec 31, 2014 at 07:04:30PM +0100, Bas Peters wrote: > 2014-12-31 18:49 GMT+01:00 Jeremiah Mahler : > > Bas, > > > > On Wed, Dec 31, 2014 at 06:34:58PM +0100, Bas Peters wrote: > >> Fixed many checkpatch.pl complaints, ranging from whitespace issues to > >> reportedly deprecated function and macro usage. > >> > > One patch should fix one type of problem. This needs to be broken up > > in to individual patches. > > > >> I have not been able to test the code as I do not have access to the > >> hardware but since no new features were really added I don't think that > >> should pose a problem. > >> > >> There are still some checkpatch complaints, particularly concerning > >> potentially unnecessary 'out of memory' messages. I will provide patches > >> for these complaints when I figure out the reason behind it and what to > >> do about it. > >> > >> NOTE: This is my first patch (ever). I have attempted to follow all > >> guidelines provided, but I probably will have missed some. If you have > >> any comments regarding the quality of this patch or suggestions as to > >> what I could do better in the future, please let me know. > >> > > You are ambitious. I would suggest trying a smaller patch first to > > make sure you are doing everything right. > > With 'smaller patch', do you refer to less files at once or a different > driver? > Is it generally preferred to send patches that relate to the same > issue (changes to a single file, > grouping of patches to tackle the same issue, such as conversion of a > specific function) over > patch(sets) that deal with an entire driver? > > Thanks for the advice! > Your patch should solve one problem. This could result in a single file being changed or many being changed. For simple checkpatch errors I usually group all of one type of error for one file as a patch. The goal is to make it easy to review. If you fixed 10 different types of issues in one patch it would difficult to review because I would have to remember whether the change I am looking at was for issue 3 or 8 or 5 or ...? Also, if the code had a bug, a bisect will point me to the patch. But then I have to figure out which of the 10 changes in that one patch created the problem. This is much easier if there was only one change in that one patch. Also have a look at Documentation/SubmittingPatches. Specifically the section "Separate your changes". > > > >> Signed-off-by: Bas Peters > >> --- > >> drivers/isdn/gigaset/asyncdata.c | 9 +++-- > >> drivers/isdn/gigaset/bas-gigaset.c | 80 > >> -- > >> drivers/isdn/gigaset/capi.c| 5 ++- > >> drivers/isdn/gigaset/common.c | 8 ++-- > >> drivers/isdn/gigaset/ev-layer.c| 38 +++--- > >> drivers/isdn/gigaset/gigaset.h | 4 +- > >> drivers/isdn/gigaset/i4l.c | 12 +++--- > >> drivers/isdn/gigaset/interface.c | 10 ++--- > >> drivers/isdn/gigaset/isocdata.c| 3 ++ > >> drivers/isdn/gigaset/proc.c| 17 +--- > >> drivers/isdn/gigaset/usb-gigaset.c | 46 +++--- > >> 11 files changed, 141 insertions(+), 91 deletions(-) > >> > >> diff --git a/drivers/isdn/gigaset/asyncdata.c > >> b/drivers/isdn/gigaset/asyncdata.c > > [...] > > > > -- > > - Jeremiah Mahler -- - Jeremiah Mahler -- 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/
scsi: non atomic allocation in mempool_alloc in atomic context
Hi Christoph,
I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
a gfp_mask argument down the command setup path"):
[ 3395.328221] BUG: sleeping function called from invalid context at
mm/mempool.c:206
[ 3395.329540] in_atomic(): 1, irqs_disabled(): 0, pid: 6399, name: trinity-c531
[ 3395.331104] no locks held by trinity-c531/6399.
[ 3395.331849] Preemption disabled blk_execute_rq_nowait (block/blk-exec.c:95)
[ 3395.333145]
[ 3395.92] CPU: 5 PID: 6399 Comm: trinity-c531 Not tainted
3.19.0-rc1-next-20141226-sasha-00051-g2dd3d73 #1646
[ 3395.335266] 880608948000
880645a07548
[ 3395.337679] 9137c79d 880608948000
880645a07588
[ 3395.340220] 814ad713 9de20590 880608948000
926a166c
[ 3395.342643] Call Trace:
[ 3395.345099] dump_stack (lib/dump_stack.c:52)
[ 3395.346793] ___might_sleep (kernel/sched/core.c:7342)
[ 3395.348571] __might_sleep (kernel/sched/core.c:7308)
[ 3395.351944] mempool_alloc (mm/mempool.c:206 (discriminator 1))
[ 3395.355196] scsi_sg_alloc (drivers/scsi/scsi_lib.c:582)
[ 3395.356893] __sg_alloc_table (lib/scatterlist.c:282)
[ 3395.358844] ? sdev_disable_disk_events (drivers/scsi/scsi_lib.c:577)
[ 3395.360873] scsi_alloc_sgtable (drivers/scsi/scsi_lib.c:608)
[ 3395.362769] scsi_init_sgtable (drivers/scsi/scsi_lib.c:1087)
[ 3395.364583] ? lockdep_init_map (kernel/locking/lockdep.c:2986)
[ 3395.366354] scsi_init_io (drivers/scsi/scsi_lib.c:1122)
[ 3395.368092] ? do_init_timer (kernel/time/timer.c:669)
[ 3395.369837] scsi_setup_cmnd (drivers/scsi/scsi_lib.c:1220
drivers/scsi/scsi_lib.c:1268)
[ 3395.371743] scsi_queue_rq (drivers/scsi/scsi_lib.c:1875
drivers/scsi/scsi_lib.c:1980)
[ 3395.373471] __blk_mq_run_hw_queue (block/blk-mq.c:751)
[ 3395.375481] blk_mq_run_hw_queue (block/blk-mq.c:831)
[ 3395.377324] blk_mq_insert_request (block/blk-mq.h:92 block/blk-mq.c:974)
[ 3395.379377] ? blk_rq_map_user (block/blk-map.c:78 block/blk-map.c:142)
[ 3395.381307] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559
kernel/locking/lockdep.c:2601)
[ 3395.383485] blk_execute_rq_nowait (block/blk-exec.c:95)
[ 3395.386995] sg_common_write.isra.2 (drivers/scsi/sg.c:823)
[ 3395.388712] ? might_fault (mm/memory.c:3730)
[ 3395.390624] sg_write (drivers/scsi/sg.c:686)
[ 3395.403014] do_loop_readv_writev (fs/read_write.c:722)
[ 3395.407429] do_readv_writev (fs/read_write.c:854)
[ 3395.415486] vfs_writev (fs/read_write.c:893)
[ 3395.417116] SyS_writev (fs/read_write.c:926 fs/read_write.c:917)
[ 3395.418851] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:33)
[ 3395.420922] system_call_fastpath (arch/x86/kernel/entry_64.S:423)
Thanks,
Sasha
--
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 1/1 net-next] tipc: replace 0 by NULL for pointers
From: Fabian Frederick Date: Thu, 25 Dec 2014 12:05:50 +0100 > Fix sparse warning: > net/tipc/link.c:1924:40: warning: Using plain integer as NULL pointer > > Signed-off-by: Fabian Frederick Applied, thanks. -- 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] Drivers: isdn: gigaset: checkpatch cleanup
2014-12-31 18:49 GMT+01:00 Jeremiah Mahler : > Bas, > > On Wed, Dec 31, 2014 at 06:34:58PM +0100, Bas Peters wrote: >> Fixed many checkpatch.pl complaints, ranging from whitespace issues to >> reportedly deprecated function and macro usage. >> > One patch should fix one type of problem. This needs to be broken up > in to individual patches. > >> I have not been able to test the code as I do not have access to the >> hardware but since no new features were really added I don't think that >> should pose a problem. >> >> There are still some checkpatch complaints, particularly concerning >> potentially unnecessary 'out of memory' messages. I will provide patches >> for these complaints when I figure out the reason behind it and what to >> do about it. >> >> NOTE: This is my first patch (ever). I have attempted to follow all >> guidelines provided, but I probably will have missed some. If you have >> any comments regarding the quality of this patch or suggestions as to >> what I could do better in the future, please let me know. >> > You are ambitious. I would suggest trying a smaller patch first to > make sure you are doing everything right. With 'smaller patch', do you refer to less files at once or a different driver? Is it generally preferred to send patches that relate to the same issue (changes to a single file, grouping of patches to tackle the same issue, such as conversion of a specific function) over patch(sets) that deal with an entire driver? Thanks for the advice! > >> Signed-off-by: Bas Peters >> --- >> drivers/isdn/gigaset/asyncdata.c | 9 +++-- >> drivers/isdn/gigaset/bas-gigaset.c | 80 >> -- >> drivers/isdn/gigaset/capi.c| 5 ++- >> drivers/isdn/gigaset/common.c | 8 ++-- >> drivers/isdn/gigaset/ev-layer.c| 38 +++--- >> drivers/isdn/gigaset/gigaset.h | 4 +- >> drivers/isdn/gigaset/i4l.c | 12 +++--- >> drivers/isdn/gigaset/interface.c | 10 ++--- >> drivers/isdn/gigaset/isocdata.c| 3 ++ >> drivers/isdn/gigaset/proc.c| 17 +--- >> drivers/isdn/gigaset/usb-gigaset.c | 46 +++--- >> 11 files changed, 141 insertions(+), 91 deletions(-) >> >> diff --git a/drivers/isdn/gigaset/asyncdata.c >> b/drivers/isdn/gigaset/asyncdata.c > [...] > > -- > - Jeremiah Mahler -- 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] Drivers: isdn: gigaset: checkpatch cleanup
Bas, On Wed, Dec 31, 2014 at 06:34:58PM +0100, Bas Peters wrote: > Fixed many checkpatch.pl complaints, ranging from whitespace issues to > reportedly deprecated function and macro usage. > One patch should fix one type of problem. This needs to be broken up in to individual patches. > I have not been able to test the code as I do not have access to the > hardware but since no new features were really added I don't think that > should pose a problem. > > There are still some checkpatch complaints, particularly concerning > potentially unnecessary 'out of memory' messages. I will provide patches > for these complaints when I figure out the reason behind it and what to > do about it. > > NOTE: This is my first patch (ever). I have attempted to follow all > guidelines provided, but I probably will have missed some. If you have > any comments regarding the quality of this patch or suggestions as to > what I could do better in the future, please let me know. > You are ambitious. I would suggest trying a smaller patch first to make sure you are doing everything right. > Signed-off-by: Bas Peters > --- > drivers/isdn/gigaset/asyncdata.c | 9 +++-- > drivers/isdn/gigaset/bas-gigaset.c | 80 > -- > drivers/isdn/gigaset/capi.c| 5 ++- > drivers/isdn/gigaset/common.c | 8 ++-- > drivers/isdn/gigaset/ev-layer.c| 38 +++--- > drivers/isdn/gigaset/gigaset.h | 4 +- > drivers/isdn/gigaset/i4l.c | 12 +++--- > drivers/isdn/gigaset/interface.c | 10 ++--- > drivers/isdn/gigaset/isocdata.c| 3 ++ > drivers/isdn/gigaset/proc.c| 17 +--- > drivers/isdn/gigaset/usb-gigaset.c | 46 +++--- > 11 files changed, 141 insertions(+), 91 deletions(-) > > diff --git a/drivers/isdn/gigaset/asyncdata.c > b/drivers/isdn/gigaset/asyncdata.c [...] -- - Jeremiah Mahler -- 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 v2] sound: pci: asihpi: hpifunc.c: Remove some unused functions
At Wed, 31 Dec 2014 18:07:36 +0100, Rickard Strandqvist wrote: > > 2014-12-31 17:45 GMT+01:00 Takashi Iwai : > > > At Wed, 31 Dec 2014 17:41:33 +0100, > > Rickard Strandqvist wrote: > > > > > > 2014-12-31 17:07 GMT+01:00 Takashi Iwai : > > > > > > > At Wed, 31 Dec 2014 16:17:02 +0100, > > > > Rickard Strandqvist wrote: > > > > > > > > > > Removes some functions that are not used anywhere: > > > > > > > > See Eliot's previous reply. There will be some code changes, so this > > > > action is no-go as of now. > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > > > > > > Hi Takashi > > > > > > I have restored the function hpi_adapter_set_property() that Eliot > > wanted. > > > And I also have diff the files against the linux-next, but that there are > > > some notable differences. > > > > > > What is it you do not like about my current patch? > > > > More code changes may land in near future, so removing functions isn't > > good at all at this moment. We need to wait until the all things are > > settled down. IOW, forget about this for a while :) > > > > And please add Eliot to Cc at the next time. > > > > > > thanks, > > > > Takashi > > > > > + Eliot > > Hi > > Strange, because I ask specifically if it was just one function Eliot objected > to, and I therefore could resend the patch. In general, it's bad to do a task like this kind of cleanups during the code change is planned in future. There is more risk than gain in such a case. You can do it for the really stalling development codes, of course. Takashi -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o wrote: > > Most poeple are still using "route" and "ifconfig" instead of "ip". > Deal with it. Indeed. This whole "let's throw out the old and broken" stuff is a disease. It would have been much better (and it's still an option, as Ted points out) for the new commands to provide compatibility with what users - and scripts - have been doing for ages with the old ones. As it is, this inability for the new tools to just do what the old tools did clearly just means that not just the old tools, but all the old infrastructure, will need to be around for years to come. Thinking you can just start from a clean slate is naive, bordering on stupid. "New and improved" is only really improved if it also takes backwards compatibility into account, rather than saying "now everybody must do things the new and improved - and different - way" We've succeeded in getting rid of some old interfaces in the kernel, but it has usually been for some *really* esoteric stuff that nobody does by hand. And even then it has generally been an uphill battle, and in most cases we've ended up having the rule that new capabilities absolutely *have* to be a superset of the old, and we continue to support the old model using the new code. It's entirely possible that we might be able to cut down on the WEXT support a tiny bit by slowly removing some parts of it that nobody uses and depends on, but the whole "let's just make it a non-option" was clearly just a drug-fueled bad fantasy. Linus -- 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 net-next 00/11] Time Counter fixes and improvements
On Tue, Dec 30, 2014 at 06:32:01PM -0500, David Miller wrote: > > Series applied, thanks Richard. I got an automated email from kbuild test robot showing new warnings and errors introduced by this series. I'll follow up with fixes soon. Thanks, Richard -- 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/
But do not tell anyone
Everything could become real http://binaryperform.go2cloud.org/aff_c?offer_id=36_id=1476 No more such Info? Simply answer -- 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] Drivers: isdn: gigaset: checkpatch cleanup
Fixed many checkpatch.pl complaints, ranging from whitespace issues to
reportedly deprecated function and macro usage.
I have not been able to test the code as I do not have access to the
hardware but since no new features were really added I don't think that
should pose a problem.
There are still some checkpatch complaints, particularly concerning
potentially unnecessary 'out of memory' messages. I will provide patches
for these complaints when I figure out the reason behind it and what to
do about it.
NOTE: This is my first patch (ever). I have attempted to follow all
guidelines provided, but I probably will have missed some. If you have
any comments regarding the quality of this patch or suggestions as to
what I could do better in the future, please let me know.
Signed-off-by: Bas Peters
---
drivers/isdn/gigaset/asyncdata.c | 9 +++--
drivers/isdn/gigaset/bas-gigaset.c | 80 --
drivers/isdn/gigaset/capi.c| 5 ++-
drivers/isdn/gigaset/common.c | 8 ++--
drivers/isdn/gigaset/ev-layer.c| 38 +++---
drivers/isdn/gigaset/gigaset.h | 4 +-
drivers/isdn/gigaset/i4l.c | 12 +++---
drivers/isdn/gigaset/interface.c | 10 ++---
drivers/isdn/gigaset/isocdata.c| 3 ++
drivers/isdn/gigaset/proc.c| 17 +---
drivers/isdn/gigaset/usb-gigaset.c | 46 +++---
11 files changed, 141 insertions(+), 91 deletions(-)
diff --git a/drivers/isdn/gigaset/asyncdata.c b/drivers/isdn/gigaset/asyncdata.c
index c90dca5..6120c2b 100644
--- a/drivers/isdn/gigaset/asyncdata.c
+++ b/drivers/isdn/gigaset/asyncdata.c
@@ -25,9 +25,12 @@
*/
static inline int muststuff(unsigned char c)
{
- if (c < PPP_TRANS) return 1;
- if (c == PPP_FLAG) return 1;
- if (c == PPP_ESCAPE) return 1;
+ if (c < PPP_TRANS)
+ return 1;
+ if (c == PPP_FLAG)
+ return 1;
+ if (c == PPP_ESCAPE)
+ return 1;
/* other possible candidates: */
/* 0x91: XON with parity set */
/* 0x93: XOFF with parity set */
diff --git a/drivers/isdn/gigaset/bas-gigaset.c
b/drivers/isdn/gigaset/bas-gigaset.c
index aecec6d..c31a416 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -261,11 +261,12 @@ static inline void dump_urb(enum debuglevel level, const
char *tag,
{
#ifdef CONFIG_GIGASET_DEBUG
int i;
+
gig_dbg(level, "%s urb(0x%08lx)->{", tag, (unsigned long) urb);
if (urb) {
gig_dbg(level,
- " dev=0x%08lx, pipe=%s:EP%d/DV%d:%s, "
- "hcpriv=0x%08lx, transfer_flags=0x%x,",
+ " dev=0x%08lx, pipe=%s:EP%d/DV%d:%s,
+ hcpriv=0x%08lx, transfer_flags=0x%x,",
(unsigned long) urb->dev,
usb_pipetype_str(urb->pipe),
usb_pipeendpoint(urb->pipe), usb_pipedevice(urb->pipe),
@@ -273,27 +274,26 @@ static inline void dump_urb(enum debuglevel level, const
char *tag,
(unsigned long) urb->hcpriv,
urb->transfer_flags);
gig_dbg(level,
- " transfer_buffer=0x%08lx[%d], actual_length=%d, "
- "setup_packet=0x%08lx,",
+ " transfer_buffer=0x%08lx[%d], actual_length=%d,
+ setup_packet=0x%08lx,",
(unsigned long) urb->transfer_buffer,
urb->transfer_buffer_length, urb->actual_length,
(unsigned long) urb->setup_packet);
gig_dbg(level,
- " start_frame=%d, number_of_packets=%d, interval=%d, "
- "error_count=%d,",
+ " start_frame=%d, number_of_packets=%d, interval=%d,
+ error_count=%d,",
urb->start_frame, urb->number_of_packets, urb->interval,
urb->error_count);
gig_dbg(level,
- " context=0x%08lx, complete=0x%08lx, "
- "iso_frame_desc[]={",
+ " context=0x%08lx, complete=0x%08lx,
+ iso_frame_desc[]={",
(unsigned long) urb->context,
(unsigned long) urb->complete);
for (i = 0; i < urb->number_of_packets; i++) {
struct usb_iso_packet_descriptor *pifd
= >iso_frame_desc[i];
gig_dbg(level,
- "{offset=%u, length=%u, actual_length=%u, "
- "status=%u}",
+ "{offset=%u, length=%u, actual_length=%u,
status=%u}",
pifd->offset, pifd->length, pifd->actual_length,
pifd->status);
}
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote: > > It is unfortunately indeed. I think iwconfig and friends will never go away > although iw is a better alternative, simply because people don't like to > change their home-made scripts/tools. WIRELESS_EXT actually is largely, but > not entirely, gone in upstream drivers and what we are talking about here is > CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based > drivers through a compatibility layer. Most poeple are still using "route" and "ifconfig" instead of "ip". Deal with it. Personally, I find it much easier to use the existing commands instead of figuring all of the various subcommands, and the options to the subcommands to commands like "ip" and "iw". At least "ip help route" will give me all of the options to "ip route", where as "iw help phy" doesn't tell give me the options; instead I have to paw through 300 lines of "iw help" in order to find the command I need. So having a better user interface / help system so people can better understand how to use iw would be a great step forward. Better yet, why not hack into the "iw" command backwards compatibility so that if argv[0] is "iwlist" or "iwconfig", it provides the limited subset compatibility to the legacy commands. Then all you need to do is to convince the distributions to set up the packaging rules so that "iw" conflicts with wireless-tools, and you will be able to get everyone switched over to iw after at least seven years. Note that I said *seven* years --- there are people who try to use an enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace, with a newer kernel, and and if said users notice, and complain, Linus *will* revert the commit. (Note that I've worked at more than one company where I was forced to use an older Ubuntu LTS or RHEL distro if I wanted to connect to the intranet, and I was using bleeding edge kernels --- and if anything like that had broken, I would have complained directly to Linus, cc'ing the patch author and the wireless maintainers with the revert. And while I fortunately am not trying to do upstream development with a stable distro, be sure there are other such folks around who have to live with similar restrictions.) - Ted P.S. If you really think it's evil that users use the simpler-to-understand iwconfig/iwlist interface over the iw command line interface, if you provide full backwards compatibility for the iwconfig/iwlist commands so you can "take over" from wireless-tools, you could even have a mode which, in addition to doing what the user wants, prints a "by the way, here's the equivalent if you want to use the iw command instead". I don't see the reason of allowing users to continue to use iwconfig and iwlist, though --- face it, route and ifconfig are going to be around for a long time; why not let users use iwconfig and iwlist if it's sufficient for their needs? -- 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 repost 12/16] parisc/uaccess: fix sparse errors
On Sat, 2014-12-27 at 18:14 +0200, Michael S. Tsirkin wrote:
> On Thu, Dec 25, 2014 at 11:37:45PM +0100, Helge Deller wrote:
> > Hi Michael,
> >
> > On 12/25/2014 10:29 AM, Michael S. Tsirkin wrote:
> > >virtio wants to read bitwise types from userspace using get_user. At the
> >
> > I don't know the virtio code much yet, but does it makes sense to read
> > bitwise types?
> > Will virtio then get possible troubles because of endianess correct as well?
>
> There's no conversion: we are reading from __virtio16 __user *
> pointer into __virtio16 v value.
>
> > Do you have a code example, or the sparse error message ?
> >
> > Helge
>
> Sure. the code is upstream now.
> The warning is below.
>
> sparse warnings: (new ones prefixed by >>)
>
> >> drivers/vhost/vringh.c:554:18: sparse: cast to restricted __virtio16
>
> vim +554 drivers/vhost/vringh.c
>
>538 __virtio16
> *p, u16 val))
>539 {
>540 if (!vrh->event_indices) {
>541 /* Old-school; update flags. */
>542 if (putu16(vrh, >vring.used->flags,
>543 VRING_USED_F_NO_NOTIFY)) {
>544 vringh_bad("Setting used flags %p",
>545 >vring.used->flags);
>546 }
>547 }
>548 }
>549
>550 /* Userspace access helpers: in this case, addresses are really
> userspace. */
>551 static inline int getu16_user(const struct vringh *vrh, u16 *val,
> const __virtio16 *p)
>552 {
>553 __virtio16 v = 0;
> > 554 int rc = get_user(v, (__force __virtio16 __user *)p);
>555 *val = vringh16_to_cpu(vrh, v);
>556 return rc;
>557 }
>558
>559 static inline int putu16_user(const struct vringh *vrh, __virtio16
> *p, u16 val)
>560 {
>561 __virtio16 v = cpu_to_vringh16(vrh, val);
>562 return put_user(v, (__force __virtio16 __user *)p);
OK, parisc developers still being dense, but this does look like an
abuse of the bitwise type. bitwise is supposed to be consumed by endian
specific accessors. get/put_user have no endian tags because they
really can't do this ... the potential for width mismatch between the
user and kernel address spaces could cause havoc if people get this
wrong, so the warning looks correct to me.
If we take your proposed patch we lose the type checking on all
accessors because of the __force. Why not, instead, alter your code to
tell the kernel you know what you're doing:
__u16 v = 0;
int rc = get_user(v, (__force __u16 __user *)p);
*val = vringh16_to_cpu(vrh, (__force __virtio16)v);
return rc;
That way the accessors still warn if anyone else tries this but your
warning is gone and the code basically says you knew the u16 was really
an endianness specific virtio quantity?
James
--
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] acpi: acpica: utstring.c: Remove some unused functions
Removes some functions that are not used anywhere:
acpi_ut_strlwr() acpi_ut_safe_strncat() acpi_ut_safe_strcat()
acpi_ut_safe_strcpy() ut_convert_backslashes() acpi_ut_stricmp()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/acpi/acpica/acutils.h | 17 -
drivers/acpi/acpica/utstring.c | 157
2 files changed, 174 deletions(-)
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 486d342..8e082af 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -629,33 +629,16 @@ acpi_ut_get_resource_end_tag(union acpi_operand_object
*obj_desc, u8 **end_tag);
*/
void acpi_ut_strupr(char *src_string);
-void acpi_ut_strlwr(char *src_string);
-
-int acpi_ut_stricmp(char *string1, char *string2);
-
acpi_status acpi_ut_strtoul64(char *string, u32 base, u64 *ret_integer);
void acpi_ut_print_string(char *string, u16 max_length);
-void ut_convert_backslashes(char *pathname);
-
u8 acpi_ut_valid_acpi_name(char *name);
u8 acpi_ut_valid_acpi_char(char character, u32 position);
void acpi_ut_repair_name(char *name);
-#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
-u8 acpi_ut_safe_strcpy(char *dest, acpi_size dest_size, char *source);
-
-u8 acpi_ut_safe_strcat(char *dest, acpi_size dest_size, char *source);
-
-u8
-acpi_ut_safe_strncat(char *dest,
-acpi_size dest_size,
-char *source, acpi_size max_transfer_length);
-#endif
-
/*
* utmutex - mutex support
*/
diff --git a/drivers/acpi/acpica/utstring.c b/drivers/acpi/acpica/utstring.c
index 6dc54b3..d94d536 100644
--- a/drivers/acpi/acpica/utstring.c
+++ b/drivers/acpi/acpica/utstring.c
@@ -52,71 +52,6 @@ ACPI_MODULE_NAME("utstring")
* Non-ANSI C library functions - strlwr, strupr, stricmp, and a 64-bit
* version of strtoul.
*/
-#ifdef ACPI_ASL_COMPILER
-/***
- *
- * FUNCTION:acpi_ut_strlwr (strlwr)
- *
- * PARAMETERS: src_string - The source string to convert
- *
- * RETURN: None
- *
- * DESCRIPTION: Convert string to lowercase
- *
- * NOTE: This is not a POSIX function, so it appears here, not in utclib.c
- *
-
**/
-void acpi_ut_strlwr(char *src_string)
-{
- char *string;
-
- ACPI_FUNCTION_ENTRY();
-
- if (!src_string) {
- return;
- }
-
- /* Walk entire string, lowercasing the letters */
-
- for (string = src_string; *string; string++) {
- *string = (char)ACPI_TOLOWER(*string);
- }
-
- return;
-}
-
-/**
- *
- * FUNCTION:acpi_ut_stricmp (stricmp)
- *
- * PARAMETERS: string1 - first string to compare
- * string2 - second string to compare
- *
- * RETURN: int that signifies string relationship. Zero means strings
- * are equal.
- *
- * DESCRIPTION: Implementation of the non-ANSI stricmp function (compare
- * strings with no case sensitivity)
- *
-
**/
-
-int acpi_ut_stricmp(char *string1, char *string2)
-{
- int c1;
- int c2;
-
- do {
- c1 = tolower((int)*string1);
- c2 = tolower((int)*string2);
-
- string1++;
- string2++;
- }
- while ((c1 == c2) && (c1));
-
- return (c1 - c2);
-}
-#endif
/***
*
@@ -554,95 +489,3 @@ void acpi_ut_repair_name(char *name)
}
}
-#if defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP
-/***
- *
- * FUNCTION:ut_convert_backslashes
- *
- * PARAMETERS: pathname- File pathname string to be converted
- *
- * RETURN: Modifies the input Pathname
- *
- * DESCRIPTION: Convert all backslashes (0x5C) to forward slashes (0x2F) within
- * the entire input file pathname string.
- *
-
**/
-
-void ut_convert_backslashes(char *pathname)
-{
-
- if (!pathname) {
- return;
- }
-
- while (*pathname) {
- if (*pathname == '\\') {
- *pathname = '/';
- }
-
- pathname++;
- }
-}
-#endif
-
-#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
-/***
- *
- * FUNCTION:acpi_ut_safe_strcpy, acpi_ut_safe_strcat, acpi_ut_safe_strncat
- *
- * PARAMETERS: Adds a "DestSize" parameter to each of the standard string
- *
Re: [PATCH v2 0/3] x86: tools: shell-ify calc_run_size perl-ism
On Wed, Dec 31, 2014 at 05:43:02PM +0100, Sylvain BERTRAND wrote: > Choked while compiling linux on a lightweight system, i.e. freed from perl. > > New script tested with dash shell and bash shell. > > V2: > - chocked->choked typo > - early conversion from hexadecimal > - error messages on stderr Your patches have the same subject. Instead, each subject should describe what each patch is doing. Read Documentation/SubmittingPatches for more info. Also, do not rush in sending a new version in a day or so but wait a couple of days to give people a chance to take a look and so that you can collect all feedback. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] net: ethernet: intel: i40e: i40e_fcoe.c: Remove unused function
Remove the function i40e_rx_is_fip() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/ethernet/intel/i40e/i40e_fcoe.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
index 5d01db1..20a5bfa 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
@@ -39,15 +39,6 @@
#include "i40e_fcoe.h"
/**
- * i40e_rx_is_fip - returns true if the rx packet type is FIP
- * @ptype: the packet type field from rx descriptor write-back
- **/
-static inline bool i40e_rx_is_fip(u16 ptype)
-{
- return ptype == I40E_RX_PTYPE_L2_FIP_PAY2;
-}
-
-/**
* i40e_rx_is_fcoe - returns true if the rx packet type is FCoE
* @ptype: the packet type field from rx descriptor write-back
**/
--
1.7.10.4
--
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 v2] sound: pci: asihpi: hpifunc.c: Remove some unused functions
At Wed, 31 Dec 2014 17:41:33 +0100, Rickard Strandqvist wrote: > > 2014-12-31 17:07 GMT+01:00 Takashi Iwai : > > > At Wed, 31 Dec 2014 16:17:02 +0100, > > Rickard Strandqvist wrote: > > > > > > Removes some functions that are not used anywhere: > > > > See Eliot's previous reply. There will be some code changes, so this > > action is no-go as of now. > > > > > > thanks, > > > > Takashi > > > > > Hi Takashi > > I have restored the function hpi_adapter_set_property() that Eliot wanted. > And I also have diff the files against the linux-next, but that there are > some notable differences. > > What is it you do not like about my current patch? More code changes may land in near future, so removing functions isn't good at all at this moment. We need to wait until the all things are settled down. IOW, forget about this for a while :) And please add Eliot to Cc at the next time. thanks, Takashi -- 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 v2 2/3] x86: tools: shell-ify calc_run_size perl-ism
Fix makefile. Signed-off-by: Sylvain BERTRAND --- --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -77,7 +77,7 @@ suffix-$(CONFIG_KERNEL_LZO) := lzo suffix-$(CONFIG_KERNEL_LZ4):= lz4 RUN_SIZE = $(shell $(OBJDUMP) -h vmlinux | \ -perl $(srctree)/arch/x86/tools/calc_run_size.pl) +sh $(srctree)/arch/x86/tools/calc_run_size.sh) quiet_cmd_mkpiggy = MKPIGGY $@ cmd_mkpiggy = $(obj)/mkpiggy $< $(RUN_SIZE) > $@ || ( rm -f $@ ; false ) -- 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 v2 1/3] x86: tools: shell-ify calc_run_size perl-ism
Add the shell script. Signed-off-by: Sylvain BERTRAND --- --- arch/x86/tools/calc_run_size.sh +++ arch/x86/tools/calc_run_size.sh @@ -0,0 +1,46 @@ +#!/bin/sh +# +# Calculate the amount of space needed to run the kernel, including room for +# the .bss and .brk sections. +# +# Usage: +# objdump -h a.out | sh calc_run_size.sh + +set -e + +file_offset=0 +mem_size=0 + +while read Idx Name Size_hex VMA_hex LMA_hex File_off_hex Algn +do + if [ "$Name" = ".bss" -o "$Name" = ".brk" ]; then + Size=$((0x$Size_hex)) + File_off=$((0x$File_off_hex)) + + mem_size=$(($mem_size + $Size)) + + if [ $file_offset -eq 0 ]; then + file_offset=$File_off + elif [ $file_offset -ne $File_off ]; then + # BFD linker shows the same file offset in ELF. + # Gold linker shows them as consecutive. + if [ $(($file_offset + $mem_size)) -eq $(($File_off + $Size)) ]; then + continue + fi + + printf "file_offset: 0x%x\n" $file_offset >&2 + printf "mem_size: 0x%x\n" $mem_size >&2 + printf "offset: 0x%x\n" $File_off >&2 + printf "size: 0x%x\n" $Size >&2 + + echo ".bss and .brk are non-contiguous" >&2 + exit 1 + fi + fi +done + +if [ $file_offset -eq 0 ]; then + echo "Never found .bss or .brk file offset" >&2 + exit 1 +fi +printf "%d\n" $(($mem_size + $file_offset)) -- 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 v2 0/3] x86: tools: shell-ify calc_run_size perl-ism
Choked while compiling linux on a lightweight system, i.e. freed from perl. New script tested with dash shell and bash shell. V2: - chocked->choked typo - early conversion from hexadecimal - error messages on stderr -- Sylvain -- 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] Revert "cfg80211: make WEXT compatibility unselectable"
On Tue, 2014-12-30 at 23:52 +0100, Jiri Kosina wrote:
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>
> It's causing severe userspace breakage. Namely, all the utilities
> from wireless-utils which are relying on CONFIG_WEXT (which means
> tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
> is a 'iw' utility in newer wireless-tools, which is supposed to be
> a replacement for all the "deprecated" binaries, but it's far away
> from being massively adopted.
>
> Please see [1] for example of the userspace breakage this is causing.
>
> In addition to that, Larry Finger reports [2] that this patch is also
> causing ipw2200 driver being impossible to build.
>
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.
>
> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688
So [2] already entered mainline as commit 60220f41 ("ipw2200: select
CFG80211_WEXT"). As this revert has now been applied, I think my patch
should now be reverted too. But I don't think it's a good idea to submit
a patch, however trivial, in the last hours before new year. So I'll
have a look into this in the first days of next year.
> Signed-off-by: Jiri Kosina
> ---
> net/wireless/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> Most distributions have a CRDA package. So if unsure, say N.
>
> config CFG80211_WEXT
> - bool
> + bool "cfg80211 wireless extensions compatibility"
> depends on CFG80211
> select WEXT_CORE
> help
Paul Bolle
--
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 v2 3/3] x86: tools: shell-ify calc_run_size perl-ism
Remove perl script.
Signed-off-by: Sylvain BERTRAND
---
--- a/arch/x86/tools/calc_run_size.pl
+++ b/arch/x86/tools/calc_run_size.pl
@@ -1,39 +0,0 @@
-#!/usr/bin/perl
-#
-# Calculate the amount of space needed to run the kernel, including room for
-# the .bss and .brk sections.
-#
-# Usage:
-# objdump -h a.out | perl calc_run_size.pl
-use strict;
-
-my $mem_size = 0;
-my $file_offset = 0;
-
-my $sections=" *[0-9]+ \.(?:bss|brk) +";
-while (<>) {
- if (/^$sections([0-9a-f]+) +(?:[0-9a-f]+ +){2}([0-9a-f]+)/) {
- my $size = hex($1);
- my $offset = hex($2);
- $mem_size += $size;
- if ($file_offset == 0) {
- $file_offset = $offset;
- } elsif ($file_offset != $offset) {
- # BFD linker shows the same file offset in ELF.
- # Gold linker shows them as consecutive.
- next if ($file_offset + $mem_size == $offset + $size);
-
- printf STDERR "file_offset: 0x%lx\n", $file_offset;
- printf STDERR "mem_size: 0x%lx\n", $mem_size;
- printf STDERR "offset: 0x%lx\n", $offset;
- printf STDERR "size: 0x%lx\n", $size;
-
- die ".bss and .brk are non-contiguous\n";
- }
- }
-}
-
-if ($file_offset == 0) {
- die "Never found .bss or .brk file offset\n";
-}
-printf("%d\n", $mem_size + $file_offset);
--
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] ASoC: adi: Add missing return statement.
On 12/31/2014 05:20 PM, Andrew Jackson wrote: From: Andrew Jackson The probe routine was disabling the clock even if the system was configured successfully. Add a return statement to leave clocks enabled. Signed-off-by: Andrew Jackson Acked-by: Lars-Peter Clausen Thanks, never noticed since the clock is shared with other peripherals. --- Spotted while reviewing clock preparation sound/soc/adi/axi-i2s.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/adi/axi-i2s.c b/sound/soc/adi/axi-i2s.c index 7752860..4c23381 100644 --- a/sound/soc/adi/axi-i2s.c +++ b/sound/soc/adi/axi-i2s.c @@ -240,6 +240,8 @@ static int axi_i2s_probe(struct platform_device *pdev) if (ret) goto err_clk_disable; + return 0; + err_clk_disable: clk_disable_unprepare(i2s->clk); return ret; -- 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] ASoC: adi: Add missing return statement.
From: Andrew Jackson The probe routine was disabling the clock even if the system was configured successfully. Add a return statement to leave clocks enabled. Signed-off-by: Andrew Jackson --- Spotted while reviewing clock preparation sound/soc/adi/axi-i2s.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/adi/axi-i2s.c b/sound/soc/adi/axi-i2s.c index 7752860..4c23381 100644 --- a/sound/soc/adi/axi-i2s.c +++ b/sound/soc/adi/axi-i2s.c @@ -240,6 +240,8 @@ static int axi_i2s_probe(struct platform_device *pdev) if (ret) goto err_clk_disable; + return 0; + err_clk_disable: clk_disable_unprepare(i2s->clk); return ret; -- 1.7.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] ASoC: dwc: Remove unnecessary conditional compilation
From: Andrew Jackson
of_match_ptr is already conditionally compiled based on
CONFIG_OF so further conditional compilation is not
required. Remove conditional compilation surrounding
of_match_ptr.
Signed-off-by: Andrew Jackson
---
sound/soc/dwc/designware_i2s.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 99cf64b..a3e97b4 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -624,9 +624,7 @@ static struct platform_driver dw_i2s_driver = {
.remove = dw_i2s_remove,
.driver = {
.name = "designware-i2s",
-#ifdef CONFIG_OF
.of_match_table = of_match_ptr(dw_i2s_of_match),
-#endif
},
};
--
1.7.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/
Re: [PATCH v17 00/12] input: cyapa: instruction of cyapa patches
Dudley, On Wed, Dec 31, 2014 at 09:16:49AM +0800, Dudley Du wrote: > V17 patches have below updates, details of other updates see history list: > 1) Fix kernel oops when system booting up with finger on TP. > 2) Remove unnecessary error log that may to system. > 3) Slipt out pm sleep code into cyapa_prepare_wakeup_controls(), >remove #indefs in function body of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. > 4) Supply stubs to cyapa_gen3_ops and cyapa_gen5_ops data structure to avoid >checking for presence of various methods in ops. > 6) Fix the meanings of some comments and return error code not clear issue. [...] It has build errors :( CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/input/mouse/cyapa.o In file included from include/linux/device.h:25:0, from include/linux/i2c.h:30, from drivers/input/mouse/cyapa.c:18: drivers/input/mouse/cyapa.c:1339:21: error: ‘cyapa_runtime_suspend’ undeclared here (not in a function) SET_RUNTIME_PM_OPS(cyapa_runtime_suspend, cyapa_runtime_resume, NULL) ^ include/linux/pm.h:347:21: note: in definition of macro ‘SET_RUNTIME_PM_OPS’ .runtime_suspend = suspend_fn, \ ^ drivers/input/mouse/cyapa.c:1339:44: error: ‘cyapa_runtime_resume’ undeclared here (not in a function) SET_RUNTIME_PM_OPS(cyapa_runtime_suspend, cyapa_runtime_resume, NULL) ^ include/linux/pm.h:348:20: note: in definition of macro ‘SET_RUNTIME_PM_OPS’ .runtime_resume = resume_fn, \ ^ scripts/Makefile.build:257: recipe for target 'drivers/input/mouse/cyapa.o' failed make[3]: *** [drivers/input/mouse/cyapa.o] Error 1 scripts/Makefile.build:402: recipe for target 'drivers/input/mouse' failed make[2]: *** [drivers/input/mouse] Error 2 scripts/Makefile.build:402: recipe for target 'drivers/input' failed make[1]: *** [drivers/input] Error 2 make[1]: *** Waiting for unfinished jobs Makefile:955: recipe for target 'drivers' failed make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs -- - Jeremiah Mahler -- 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 v2] sound: pci: asihpi: hpifunc.c: Remove some unused functions
At Wed, 31 Dec 2014 16:17:02 +0100, Rickard Strandqvist wrote: > > Removes some functions that are not used anywhere: See Eliot's previous reply. There will be some code changes, so this action is no-go as of now. thanks, Takashi -- 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 2/2] kbuild: Drop support for clean-rule
On Wed, Dec 31, 2014 at 4:35 PM, Michal Marek wrote: > clean-rule has not been used since 94869f86 (kbuild: Accept absolute > paths in clean-files and introduce clean-dirs) ten years ago. > > Signed-off-by: Michal Marek Tested-by: Sedat Dilek - Sedat - > --- > scripts/Makefile.clean | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean > index 627f8cb..55c96cb 100644 > --- a/scripts/Makefile.clean > +++ b/scripts/Makefile.clean > @@ -71,9 +71,6 @@ endif > ifneq ($(strip $(__clean-dirs)),) > +$(call cmd,cleandir) > endif > -ifneq ($(strip $(clean-rule)),) > - +$(clean-rule) > -endif > @: > > > -- > 2.1.2 > -- 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 V6 00/25] Generic BMIPS kernel
2014-12-25 9:48 GMT-08:00 Kevin Cernekee : > V5->V6: Incorporate several fixes/enhancements from Jaedon Shin: > > - Fix register read/modify/write in RAC flush code. > > - Fix use of "SYS_HAS_CPU_BMIPS32_3300" Kconfig symbol. > > - Add base platform support for 7358 and 7362. > > The DTS files follow Andrew Bresticker's new per-vendor directory layout. > > This series applies on top of Linus' current head of tree. > > Patch 01 (Fix outdated use of mips_cpu_intc_init()) is REQUIRED for 3.19 > to fix a build failure seen in 3.19-rc. The other patches can > be queued for 3.20 or later. For this entire patch series: Acked-by: Florian Fainelli Thanks! -- Florian -- 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/
