Re: [PATCH v2] vfs: avoid recopying file names in getname_flags

[Boqun Feng]

Ping.

This patch has been tested by 0day test bot.

Thanks,
Boqun Feng


On Thu, Mar 26, 2015 at 02:45:52AM +0800, Boqun Feng wrote:
> In the current implementation of getname_flags, a file name in the
> user-space will be recopied if it takes more space that
> EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
> the file name are already copied into kernel address space, the only
> reason why the recopy is needed is that "kname", which points to the
> string of the file name, needs to be relocated.
> 
> And the recopy can be avoided if we change the memory layout of the
> `names_cachep` allocation. By putting `struct filename` at the tail of
> the allocation instead of the head, relocation of kname is avoided.
> Once putting the struct at the tail, each byte in the user space will be
> copied only one time, so the recopy is avoided.
> 
> Of course, other functions aware of the layout of the `names_cachep`
> allocation, i.e., getname_kernel and putname also need to be modified to
> adapt to the new layout.
> 
> Since we change the layout of `names_cachep` allocation, in order to
> figure out whether kname and the struct are separate, we now need to
> check whether the file name string starts at the address
> EMBEDDED_NAME_MAX bytes before the address of the struct.  As a result,
> `iname`, which points the end of `struct filename`, is not needed
> anymore.
> 
> Signed-off-by: Boqun Feng 
> ---
> v1 --> v2:
> Rebase the patch onto the for-next branch of Al's vfs repo.
> 
> 
>  fs/namei.c | 45 -
>  include/linux/fs.h |  1 -
>  2 files changed, 28 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 7a11ec1..6d04029 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -119,7 +119,7 @@
>   * PATH_MAX includes the nul terminator --RR.
>   */
>  
> -#define EMBEDDED_NAME_MAX(PATH_MAX - offsetof(struct filename, iname))
> +#define EMBEDDED_NAME_MAX(PATH_MAX - sizeof(struct filename))
>  
>  struct filename *
>  getname_flags(const char __user *filename, int flags, int *empty)
> @@ -132,44 +132,53 @@ getname_flags(const char __user *filename, int flags, 
> int *empty)
>   if (result)
>   return result;
>  
> - result = __getname();
> - if (unlikely(!result))
> + kname = __getname();
> + if (unlikely(!kname))
>   return ERR_PTR(-ENOMEM);
>  
>   /*
>* First, try to embed the struct filename inside the names_cache
>* allocation
>*/
> - kname = (char *)result->iname;
> + result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
>   result->name = kname;
>  
>   len = strncpy_from_user(kname, filename, EMBEDDED_NAME_MAX);
>   if (unlikely(len < 0)) {
> - __putname(result);
> + __putname(kname);
>   return ERR_PTR(len);
>   }
>  
>   /*
>* Uh-oh. We have a name that's approaching PATH_MAX. Allocate a
>* separate struct filename so we can dedicate the entire
> -  * names_cache allocation for the pathname, and re-do the copy from
> +  * names_cache allocation for the pathname, and continue the copy from
>* userland.
>*/
>   if (unlikely(len == EMBEDDED_NAME_MAX)) {
> - kname = (char *)result;
> -
>   result = kzalloc(sizeof(*result), GFP_KERNEL);
>   if (unlikely(!result)) {
>   __putname(kname);
>   return ERR_PTR(-ENOMEM);
>   }
>   result->name = kname;
> - len = strncpy_from_user(kname, filename, PATH_MAX);
> + /* we can't simply add the number of rest chars we copy to len,
> +  * since strncpy_from_user may return negative to indicate
> +  * something is wrong, so we do the addition later, after
> +  * strncpy_from_user succeeds, and we know we already copy
> +  * EMBEDDED_NAME_MAX chars.
> +  */
> + len = strncpy_from_user(kname + EMBEDDED_NAME_MAX,
> + filename + EMBEDDED_NAME_MAX,
> + PATH_MAX - EMBEDDED_NAME_MAX);
> +
>   if (unlikely(len < 0)) {
>   __putname(kname);
>   kfree(result);
>   return ERR_PTR(len);
>   }
> +
> + len += EMBEDDED_NAME_MAX;
>   if (unlikely(len == PATH_MAX)) {
>   __putname(kname);
>   kfree(result);
> @@ -204,26 +213,28 @@ struct filename *
>  getname_kernel(const char * filename)
>  {
>   struct filename *result;
> + char *kname;
>   int len = strlen(filename) + 1;
>  
> - result = __getname();
> - if (unlikely(!result))
> + kname = __getname();
> + if (unlikely(!kname))
>   return ERR_PTR(-ENOMEM);
>  
>   if (len <= EMBEDDED_NAME_MAX) {
> - result->name 

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Dmitry Torokhov]

On Fri, Mar 27, 2015 at 05:43:17PM -0700, Andrew Bresticker wrote:
> Add a binding document for a generic ADC keypad.  Buttons on an ADC
> keypad are connected in a resistor ladder to an ADC.  The binding
> describes the mapping of ADC channel and voltage ranges to buttons.
> 
> Signed-off-by: Andrew Bresticker 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> ---
>  .../devicetree/bindings/input/adc-keys.txt | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
> b/Documentation/devicetree/bindings/input/adc-keys.txt
> new file mode 100644
> index 000..c9a57de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
> @@ -0,0 +1,43 @@
> +Generic ADC keypad
> +==
> +
> +Required properties:
> + - compatible: "adc-keys"
> + - poll-interval: Polling interval time in ms.
> + - io-channels: List of IIO channels used by the keypad.
> +   See ../iio/iio-bindings.txt for details.
> +
> +Optional properties:
> + - autorepeat: Enable auto-repeat.
> +
> +Each button on the ADC keypad is represented by a sub-node.
> +
> +Required sub-node properties:
> + - label: Descriptive name for the key.
> + - linux,code: Keycode to emit.
> + - channel: IIO channel (index into the 'io-channels' above) to which this
> +   button is attached.
> + - min-voltage: Minimum voltage in uV when this key is pressed.
> + - max-voltage: Maximum voltage in uV when this key is pressed.
> +
> +Optional sub-node properties:
> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) 
> if
> +   not specified.

I'd rather we have it defined explicitly in the binding, i.e. make it a
required property?

> +
> +Example:
> +
> +adc-keypad {
> + compatible = "adc-keys";
> + poll-interval = <100>;
> + io-channels = < 0>, < 1>;
> +
> + vol-up-button {
> + label = "Volume Up";
> + linux,code = ;
> + channel = <0>;
> + min-voltage = <160>;
> + max-voltage = <164>;
> + };
> +
> + ...
> +};
> -- 
> 2.2.0.rc0.207.ga3a616c
> 

-- 
Dmitry
--
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] Input: ALPS - Detect trackstick presence for v7 protocol

[Dmitry Torokhov]

On Tue, Mar 24, 2015 at 08:27:29AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 23-03-15 18:02, Pali Rohár wrote:
> >On Monday 23 March 2015 12:39:48 Hans de Goede wrote:
> >>Hi,
> >>
> >>On 22-03-15 14:46, Pali Rohár wrote:
> >>>This patch adds detection of trackstick for v7 protocol
> >>>devices. Code in this patch is used in official Dell
> >>>touchpad linux drivers for Dell models: Dell Latitude
> >>>E5250/5250, E5450/5450, E5550/5550
> >>>
> >>>Detection code and base reg for alps v3 rushmore and v7
> >>>devices is exacly same.
> >>>
> >>>Also user in bug
> >>>https://bugzilla.kernel.org/show_bug.cgi?id=94801 reported
> >>>that Toshiba Sattellite Z30-A-1DG has only alps v7 touchpad
> >>>device without trackstick and kernel reports to userspace
> >>>also redundant trackstick device.
> >>>
> >>>Signed-off-by: Pali Rohár 
> >>
> >>Looks good, but has this been tested on a laptop which
> >>actually has a v7 pad + trackstick? I would like to see this
> >>actually tested on at least one such laptop before it gets
> >>merged.
> >>
> >>Regards,
> >>
> >>Hans
> >>
> >
> >I did not tested my patch on any v7 touchpad-only laptop.
> 
> Ah, but I'm not worried about testing on a touchpad-only laptop,
> we are already reporting a trackpoint there even though there
> is none. I'm worried about breaking existing v7 using laptops
> which actually have a trackstick.
> 
> So if this is tested on a v7 laptop with trackstick, and it
> does not break the trackstick then that is good enough for me.

I wonder if Masaki might have devices with V7 and trackstick available
and could test the patch for us?

Thanks.

-- 
Dmitry
--
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] README: Update references to version 4

[Pranith Kumar]

Since we bumped the version to 4.0, let us update the references to match that 
in the
README file.

Signed-off-by: Pranith Kumar 
---
 README | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/README b/README
index a24ec89..dbe9c96 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
-Linux kernel release 3.x 
+Linux kernel release 4.x 
 
-These are the release notes for Linux version 3.  Read them carefully,
+These are the release notes for Linux version 4.  Read them carefully,
 as they tell you what this is all about, explain how to install the
 kernel, and what to do if something goes wrong. 
 
@@ -62,11 +62,11 @@ INSTALLING the kernel source:
directory where you have permissions (eg. your home directory) and
unpack it:
 
- gzip -cd linux-3.X.tar.gz | tar xvf -
+ gzip -cd linux-4.X.tar.gz | tar xvf -
 
or
 
- bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
+ bzip2 -dc linux-4.X.tar.bz2 | tar xvf -
 
Replace "X" with the version number of the latest kernel.
 
@@ -75,16 +75,16 @@ INSTALLING the kernel source:
files.  They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
 
- - You can also upgrade between 3.x releases by patching.  Patches are
+ - You can also upgrade between 4.x releases by patching.  Patches are
distributed in the traditional gzip and the newer bzip2 format.  To
install by patching, get all the newer patch files, enter the
-   top level directory of the kernel source (linux-3.X) and execute:
+   top level directory of the kernel source (linux-4.X) and execute:
 
- gzip -cd ../patch-3.x.gz | patch -p1
+ gzip -cd ../patch-4.x.gz | patch -p1
 
or
 
- bzip2 -dc ../patch-3.x.bz2 | patch -p1
+ bzip2 -dc ../patch-4.x.bz2 | patch -p1
 
Replace "x" for all versions bigger than the version "X" of your current
source tree, _in_order_, and you should be ok.  You may want to remove
@@ -92,13 +92,13 @@ INSTALLING the kernel source:
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
 
-   Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
+   Unlike patches for the 4.x kernels, patches for the 4.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
-   directly to the base 3.x kernel.  For example, if your base kernel is 3.0
-   and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1
-   and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and
-   want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is,
-   patch -R) _before_ applying the 3.0.3 patch. You can read more on this in
+   directly to the base 4.x kernel.  For example, if your base kernel is 4.0
+   and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
+   and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
+   want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
+   patch -R) _before_ applying the 4.0.3 patch. You can read more on this in
Documentation/applying-patches.txt
 
Alternatively, the script patch-kernel can be used to automate this
@@ -120,7 +120,7 @@ INSTALLING the kernel source:
 
 SOFTWARE REQUIREMENTS
 
-   Compiling and running the 3.x kernels requires up-to-date
+   Compiling and running the 4.x kernels requires up-to-date
versions of various software packages.  Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages.  Beware that using
@@ -137,12 +137,12 @@ BUILD directory for the kernel:
place for the output files (including .config).
Example:
 
- kernel source code: /usr/src/linux-3.X
+ kernel source code: /usr/src/linux-4.X
  build directory:/home/name/build/kernel
 
To configure and build the kernel, use:
 
- cd /usr/src/linux-3.X
+ cd /usr/src/linux-4.X
  make O=/home/name/build/kernel menuconfig
  make O=/home/name/build/kernel
  sudo make O=/home/name/build/kernel modules_install install
@@ -297,7 +297,7 @@ COMPILING the kernel:
LOCALVERSION can be set in the "General Setup" menu.
 
  - In order to boot your new kernel, you'll need to copy the kernel
-   image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
+   image (e.g. .../linux/arch/x86/boot/bzImage after compilation)
to the place where your regular bootable kernel is found. 
 
  - Booting a kernel directly from a floppy without the assistance of a
@@ -399,7 +399,7 @@ IF SOMETHING GOES WRONG:
 
  - Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
-   kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
+   kernel with -g; edit arch/x86/Makefile 

[PATCH] Do not use arbitrary large movablecore to calculate kernelcore

[Zhihui Zhang]

If kernelcore is not set, then we are working with a very large kernelcore
for nothing - no movable zone will be created. If kernelcore is set,
then it is not respected at all.

Signed-off-by: Zhihui Zhang 
---
 mm/page_alloc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40e2942..32bf5da 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5199,7 +5199,11 @@ static void __init find_zone_movable_pfns_for_nodes(void)
 */
required_movablecore =
roundup(required_movablecore, MAX_ORDER_NR_PAGES);
-   corepages = totalpages - required_movablecore;
+
+   if (totalpages > required_movablecore)
+   corepages = totalpages - required_movablecore;
+   else
+   corepages = 0;
 
required_kernelcore = max(required_kernelcore, corepages);
}
-- 
1.9.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/2] lib/lcm.c: lcm(n,0)=lcm(0,n) is 0, not n

[Mike Snitzer]

On Tue, Dec 9, 2014 at 4:03 PM, Rasmus Villemoes
 wrote:
> Return the mathematically correct answer when an argument is 0.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/lcm.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/lib/lcm.c b/lib/lcm.c
> index 01b3aa922dda..51cc6b13cd52 100644
> --- a/lib/lcm.c
> +++ b/lib/lcm.c
> @@ -8,9 +8,7 @@ unsigned long lcm(unsigned long a, unsigned long b)
>  {
> if (a && b)
> return (a / gcd(a, b)) * b;
> -   else if (b)
> -   return b;
> -
> -   return a;
> +   else
> +   return 0;
>  }
>  EXPORT_SYMBOL_GPL(lcm);

This change is the source of 3.19 regression for stacking device
limits, via commit 69c953c ("lib/lcm.c: lcm(n,0)=lcm(0,n) is 0, not
n").

Test:
# modprobe scsi_debug dev_size_mb=10 num_tgts=1 opt_blks=1536
# cat /sys/block/sde/queue/optimal_io_size
786432
# dmsetup create node --table "0 100 linear /dev/sde 0"

Before commit 69c953c:
# cat /sys/block/dm-5/queue/optimal_io_size
786432

After commit 69c953c:
# cat /sys/block/dm-5/queue/optimal_io_size
0

Rasmus, mathematical purity of lcm() aside, it'd have been nice if you
looked at the lcm() callers to determine whether you'd be breaking
them.

It looks like we need a new lcm_not_zero() and blk_stack_limits()
should be changed to use it, and the patch needs to cc stable.  Martin
and/or Jens, what do you think?

Mike
--
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] lib: bitmap_[empty,full]: remove code duplication

[Yury Norov]

Function 'bitmap_empty' has it's own implementation.
But it's clearly as simple as:
"find_first_bit(src, nbits) == nbits"
The same is true for 'bitmap_full'.
---
 include/linux/bitmap.h |  8 
 lib/bitmap.c   | 30 --
 2 files changed, 4 insertions(+), 34 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index be4fa5d..ea17cca 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -283,16 +283,16 @@ static inline int bitmap_empty(const unsigned long *src, 
unsigned nbits)
 {
if (small_const_nbits(nbits))
return ! (*src & BITMAP_LAST_WORD_MASK(nbits));
-   else
-   return __bitmap_empty(src, nbits);
+
+   return find_first_bit(src, nbits) == nbits;
 }
 
 static inline int bitmap_full(const unsigned long *src, unsigned int nbits)
 {
if (small_const_nbits(nbits))
return ! (~(*src) & BITMAP_LAST_WORD_MASK(nbits));
-   else
-   return __bitmap_full(src, nbits);
+
+   return find_first_zero_bit(src, nbits) == nbits;
 }
 
 static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index d456f4c1..64c0926 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -42,36 +42,6 @@
  * for the best explanations of this ordering.
  */
 
-int __bitmap_empty(const unsigned long *bitmap, unsigned int bits)
-{
-   unsigned int k, lim = bits/BITS_PER_LONG;
-   for (k = 0; k < lim; ++k)
-   if (bitmap[k])
-   return 0;
-
-   if (bits % BITS_PER_LONG)
-   if (bitmap[k] & BITMAP_LAST_WORD_MASK(bits))
-   return 0;
-
-   return 1;
-}
-EXPORT_SYMBOL(__bitmap_empty);
-
-int __bitmap_full(const unsigned long *bitmap, unsigned int bits)
-{
-   unsigned int k, lim = bits/BITS_PER_LONG;
-   for (k = 0; k < lim; ++k)
-   if (~bitmap[k])
-   return 0;
-
-   if (bits % BITS_PER_LONG)
-   if (~bitmap[k] & BITMAP_LAST_WORD_MASK(bits))
-   return 0;
-
-   return 1;
-}
-EXPORT_SYMBOL(__bitmap_full);
-
 int __bitmap_equal(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int bits)
 {
-- 
2.1.0

--
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] clk: at91: pll: fix input range validity check

[Boris Brezillon]

The PLL impose a certain input range to work correctly, but it appears that
this input range does not apply on the input clock (or parent clock) but
on the input clock after it has passed the PLL divisor.
Fix the implementation accordingly.

Cc:  # v3.14+
Signed-off-by: Boris Brezillon 
Reported-by: Jonas Andersson 
---
 drivers/clk/at91/clk-pll.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 6ec79db..cbbe403 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -173,8 +173,7 @@ static long clk_pll_get_best_div_mul(struct clk_pll *pll, 
unsigned long rate,
int i = 0;
 
/* Check if parent_rate is a valid input rate */
-   if (parent_rate < characteristics->input.min ||
-   parent_rate > characteristics->input.max)
+   if (parent_rate < characteristics->input.min)
return -ERANGE;
 
/*
@@ -187,6 +186,15 @@ static long clk_pll_get_best_div_mul(struct clk_pll *pll, 
unsigned long rate,
if (!mindiv)
mindiv = 1;
 
+   if (parent_rate > characteristics->input.max) {
+   tmpdiv = DIV_ROUND_UP(parent_rate, characteristics->input.max);
+   if (tmpdiv > PLL_DIV_MAX)
+   return -ERANGE;
+
+   if (tmpdiv > mindiv)
+   mindiv = tmpdiv;
+   }
+
/*
 * Calculate the maximum divider which is limited by PLL register
 * layout (limited by the MUL or DIV field size).
-- 
1.9.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] clk: check ->determine/round_rate() return value in clk_calc_new_rates

[Boris Brezillon]

->determine_rate() and ->round_rate() can return the closest rate to the
requested one or an error code.
clk_calc_new_rates is assuming these functions can't return a negative
value, which leads to a undefined behavior when the clk implementation
returns such an error code.
Fix this by returning NULL in case ->determine_rate() or ->round_rate()
returned an error code.

Signed-off-by: Boris Brezillon 
---
 drivers/clk/clk.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 237f23f..b59c1b4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1580,6 +1580,7 @@ static struct clk_core *clk_calc_new_rates(struct 
clk_core *clk,
unsigned long min_rate;
unsigned long max_rate;
int p_index = 0;
+   long ret;
 
/* sanity */
if (IS_ERR_OR_NULL(clk))
@@ -1595,15 +1596,23 @@ static struct clk_core *clk_calc_new_rates(struct 
clk_core *clk,
/* find the closest rate and parent clk/rate */
if (clk->ops->determine_rate) {
parent_hw = parent ? parent->hw : NULL;
-   new_rate = clk->ops->determine_rate(clk->hw, rate,
-   min_rate,
-   max_rate,
-   _parent_rate,
-   _hw);
+   ret = clk->ops->determine_rate(clk->hw, rate,
+  min_rate,
+  max_rate,
+  _parent_rate,
+  _hw);
+   if (ret < 0)
+   return NULL;
+
+   new_rate = ret;
parent = parent_hw ? parent_hw->core : NULL;
} else if (clk->ops->round_rate) {
-   new_rate = clk->ops->round_rate(clk->hw, rate,
-   _parent_rate);
+   ret = clk->ops->round_rate(clk->hw, rate,
+  _parent_rate);
+   if (ret < 0)
+   return NULL;
+
+   new_rate = ret;
if (new_rate < min_rate || new_rate > max_rate)
return NULL;
} else if (!parent || !(clk->flags & CLK_SET_RATE_PARENT)) {
-- 
1.9.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] clk: at91: usb: propagate rate modification to the parent clk

[Boris Brezillon]

The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate
modification requests to their parents.
This causes a bug when the PLLB is left uninitialized by the bootloader
(PLL multiplier set to 0, or in other words, PLL rate = 0 Hz).

Implement the determinate_rate method and propagate the change rate
request to the parent clk.

Cc:  # v3.14+
Signed-off-by: Boris Brezillon 
Reported-by: Bo Shen 
Tested-by: Bo Shen 
---
 drivers/clk/at91/clk-usb.c | 64 +++---
 1 file changed, 49 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
index a23ac0c..0b7c3e8 100644
--- a/drivers/clk/at91/clk-usb.c
+++ b/drivers/clk/at91/clk-usb.c
@@ -56,22 +56,55 @@ static unsigned long at91sam9x5_clk_usb_recalc_rate(struct 
clk_hw *hw,
return DIV_ROUND_CLOSEST(parent_rate, (usbdiv + 1));
 }
 
-static long at91sam9x5_clk_usb_round_rate(struct clk_hw *hw, unsigned long 
rate,
- unsigned long *parent_rate)
+static long at91sam9x5_clk_usb_determine_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
+ unsigned long *best_parent_rate,
+ struct clk_hw **best_parent_hw)
 {
-   unsigned long div;
+   struct clk *parent = NULL;
+   long best_rate = -EINVAL;
+   unsigned long tmp_rate;
+   int best_diff = -1;
+   int tmp_diff;
+   int i;
 
-   if (!rate)
-   return -EINVAL;
+   for (i = 0; i < __clk_get_num_parents(hw->clk); i++) {
+   int div;
 
-   if (rate >= *parent_rate)
-   return *parent_rate;
+   parent = clk_get_parent_by_index(hw->clk, i);
+   if (!parent)
+   continue;
+
+   for (div = 1; div < SAM9X5_USB_MAX_DIV + 2; div++) {
+   unsigned long tmp_parent_rate;
+
+   tmp_parent_rate = rate * div;
+   tmp_parent_rate = __clk_round_rate(parent,
+  tmp_parent_rate);
+   tmp_rate = DIV_ROUND_CLOSEST(tmp_parent_rate, div);
+   if (tmp_rate < rate)
+   tmp_diff = rate - tmp_rate;
+   else
+   tmp_diff = tmp_rate - rate;
+
+   if (best_diff < 0 || best_diff > tmp_diff) {
+   best_rate = tmp_rate;
+   best_diff = tmp_diff;
+   *best_parent_rate = tmp_parent_rate;
+   *best_parent_hw = __clk_get_hw(parent);
+   }
+
+   if (!best_diff || tmp_rate < rate)
+   break;
+   }
 
-   div = DIV_ROUND_CLOSEST(*parent_rate, rate);
-   if (div > SAM9X5_USB_MAX_DIV + 1)
-   div = SAM9X5_USB_MAX_DIV + 1;
+   if (!best_diff)
+   break;
+   }
 
-   return DIV_ROUND_CLOSEST(*parent_rate, div);
+   return best_rate;
 }
 
 static int at91sam9x5_clk_usb_set_parent(struct clk_hw *hw, u8 index)
@@ -121,7 +154,7 @@ static int at91sam9x5_clk_usb_set_rate(struct clk_hw *hw, 
unsigned long rate,
 
 static const struct clk_ops at91sam9x5_usb_ops = {
.recalc_rate = at91sam9x5_clk_usb_recalc_rate,
-   .round_rate = at91sam9x5_clk_usb_round_rate,
+   .determine_rate = at91sam9x5_clk_usb_determine_rate,
.get_parent = at91sam9x5_clk_usb_get_parent,
.set_parent = at91sam9x5_clk_usb_set_parent,
.set_rate = at91sam9x5_clk_usb_set_rate,
@@ -159,7 +192,7 @@ static const struct clk_ops at91sam9n12_usb_ops = {
.disable = at91sam9n12_clk_usb_disable,
.is_enabled = at91sam9n12_clk_usb_is_enabled,
.recalc_rate = at91sam9x5_clk_usb_recalc_rate,
-   .round_rate = at91sam9x5_clk_usb_round_rate,
+   .determine_rate = at91sam9x5_clk_usb_determine_rate,
.set_rate = at91sam9x5_clk_usb_set_rate,
 };
 
@@ -179,7 +212,8 @@ at91sam9x5_clk_register_usb(struct at91_pmc *pmc, const 
char *name,
init.ops = _usb_ops;
init.parent_names = parent_names;
init.num_parents = num_parents;
-   init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+   init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE |
+CLK_SET_RATE_PARENT;
 
usb->hw.init = 
usb->pmc = pmc;
@@ -207,7 +241,7 @@ at91sam9n12_clk_register_usb(struct at91_pmc *pmc, const 
char *name,
init.ops = _usb_ops;
init.parent_names = _name;
init.num_parents = 1;
-   init.flags = CLK_SET_RATE_GATE;
+   init.flags = CLK_SET_RATE_GATE | 

[PATCH v5 07/15] staging: rtl8723au: Remove unneeded curly braces

[M. Vefa Bicakci]

Correct a number of checkpatch.pl warnings in rtl8723au's rtw_security.c
related to the existence of unnecessary curly braces around single
statement blocks:
WARNING: braces {} are not necessary for single statement blocks

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index b85e5de5f136..e8efdcd06329 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -113,9 +113,8 @@ static void crc32_init(void)
for (i = 0; i < 256; ++i) {
k = crc32_reverseBit((u8)i);
 
-   for (c = ((u32)k) << 24, j = 8; j > 0; --j) {
+   for (c = ((u32)k) << 24, j = 8; j > 0; --j)
c = c & 0x8000 ? (c << 1) ^ CRC32_POLY : (c << 1);
-   }
 
p1 = (u8 *)_table[i];
 
@@ -264,9 +263,8 @@ static u32 secmicgetuint32(u8 *p)
s32 i;
u32 res = 0;
 
-   for (i = 0; i < 4; i++) {
+   for (i = 0; i < 4; i++)
res |= ((u32)(*p++)) << (8 * i);
-   }
 
return res;
 }
@@ -350,9 +348,8 @@ void rtw_secgetmic23a(struct mic_data *pmicdata, u8 *dst)
rtw_secmicappend23abyte23a(pmicdata, 0);
rtw_secmicappend23abyte23a(pmicdata, 0);
/*  and then zeroes until the length is a multiple of 4 */
-   while (pmicdata->nBytesInM != 0) {
+   while (pmicdata->nBytesInM != 0)
rtw_secmicappend23abyte23a(pmicdata, 0);
-   }
/*  The appendByte function has already computed the result. */
secmicputuint32(dst, pmicdata->L);
secmicputuint32(dst + 4, pmicdata->R);
@@ -888,10 +885,8 @@ static void byte_sub(u8 *in, u8 *out)
 {
int i;
 
-   for (i = 0; i < 16; i++) {
+   for (i = 0; i < 16; i++)
out[i] = sbox(in[i]);
-   }
-
 }
 
 static void shift_row(u8 *in, u8 *out)
@@ -952,9 +947,8 @@ static void mix_column(u8 *in, u8 *out)
 
for (i = 3; i > 0; i--) { /* logical shift left 1 bit */
andf7[i] = andf7[i] << 1;
-   if ((andf7[i - 1] & 0x80) == 0x80) {
+   if ((andf7[i - 1] & 0x80) == 0x80)
andf7[i] = (andf7[i] | 0x01);
-   }
}
andf7[0] = andf7[0] << 1;
andf7[0] = andf7[0] & 0xfe;
-- 
2.1.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/

[PATCH v5 01/15] staging: rtl8723au: Reformat whitespace to increase readability

[M. Vefa Bicakci]

Adjust the whitespace in the signature, local variable declaration and
initialization parts of a number of functions to increase readability
in rtl8723au's rtw_security.c.

Signed-off-by: M. Vefa Bicakci 

---

v2: Make sure that the arcfour_encrypt function's argument list is split
according to the kernel code style.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 79 +--
 1 file changed, 38 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index ea670afcc212..92882f60bc0e 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -31,11 +31,11 @@ struct arc4context {
 
 static void arcfour_init(struct arc4context *parc4ctx, u8 *key, u32 key_len)
 {
-   u32 t, u;
-   u32 keyindex;
-   u32 stateindex;
+   u32 t, u;
+   u32 keyindex;
+   u32 stateindex;
u8 *state;
-   u32 counter;
+   u32 counter;
 
state = parc4ctx->state;
parc4ctx->x = 0;
@@ -55,7 +55,8 @@ static void arcfour_init(struct arc4context *parc4ctx, u8 
*key, u32 key_len)
}
 
 }
-static u32 arcfour_byte(   struct arc4context  *parc4ctx)
+
+static u32 arcfour_byte(struct arc4context *parc4ctx)
 {
u32 x;
u32 y;
@@ -75,16 +76,13 @@ static u32 arcfour_byte(struct arc4context  
*parc4ctx)
return state[(sx + sy) & 0xff];
 }
 
-static void arcfour_encrypt(   struct arc4context  *parc4ctx,
-   u8 *dest,
-   u8 *src,
-   u32 len)
+static void arcfour_encrypt(struct arc4context *parc4ctx, u8 *dest,
+   u8 *src, u32 len)
 {
-   u32 i;
+   u32 i;
 
for (i = 0; i < len; i++)
dest[i] = src[i] ^ (unsigned char)arcfour_byte(parc4ctx);
-
 }
 
 static int bcrc32initialized;
@@ -365,7 +363,7 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
   u8 *mic_code, u8 pri)
 {
 
-   struct mic_data micdata;
+   struct mic_data micdata;
u8 priority[4]={0x0, 0x0, 0x0, 0x0};
 
rtw_secmicsetkey23a(, key);
@@ -601,21 +599,21 @@ static void phase2(u8 *rc4key, const u8 *tk, const u16 
*p1k, u16 iv16)
 int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
struct xmit_frame *pxmitframe)
 {
-   u16 pnl;
-   u32 pnh;
-   u8  rc4key[16];
-   u8   ttkey[16];
-   u8  crc[4];
-   u8   hw_hdr_offset = 0;
+   u16 pnl;
+   u32 pnh;
+   u8 rc4key[16];
+   u8 ttkey[16];
+   u8 crc[4];
+   u8 hw_hdr_offset = 0;
struct arc4context mycontext;
-   int curfragnum, length;
-   u32 prwskeylen;
-   u8  *pframe, *payload, *iv, *prwskey;
+   int curfragnum, length;
+   u32 prwskeylen;
+   u8 *pframe, *payload, *iv, *prwskey;
union pn48 dot11txpn;
-   struct  sta_info*stainfo;
-   struct  pkt_attrib   *pattrib = >attrib;
-   struct  security_priv   *psecuritypriv = >securitypriv;
-   struct  xmit_priv   *pxmitpriv = >xmitpriv;
+   struct sta_info *stainfo;
+   struct pkt_attrib *pattrib = >attrib;
+   struct security_priv *psecuritypriv = >securitypriv;
+   struct xmit_priv *pxmitpriv = >xmitpriv;
int res = _SUCCESS;
 
if (!pxmitframe->buf_addr)
@@ -708,17 +706,17 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
 {
u16 pnl;
u32 pnh;
-   u8   rc4key[16];
-   u8   ttkey[16];
-   u8  crc[4];
+   u8 rc4key[16];
+   u8 ttkey[16];
+   u8 crc[4];
struct arc4context mycontext;
-   int length;
-   u32 prwskeylen;
-   u8  *pframe, *payload, *iv, *prwskey;
+   int length;
+   u32 prwskeylen;
+   u8 *pframe, *payload, *iv, *prwskey;
union pn48 dot11txpn;
-   struct  sta_info*stainfo;
-   struct  rx_pkt_attrib *prxattrib = >attrib;
-   struct  security_priv *psecuritypriv = >securitypriv;
+   struct sta_info *stainfo;
+   struct rx_pkt_attrib *prxattrib = >attrib;
+   struct security_priv *psecuritypriv = >securitypriv;
struct sk_buff *skb = precvframe->pkt;
int res = _SUCCESS;
 
@@ -1136,8 +1134,8 @@ static void bitwise_xor(u8 *ina, u8 *inb, u8 *out)
 
 static int aes_cipher(u8 *key, uint hdrlen, u8 *pframe, uint plen)
 {
-   uintqc_exists, a4_exists, i, j, payload_remainder,
-   num_blocks, payload_index;
+   uint qc_exists, a4_exists, i, j, payload_remainder,
+num_blocks, payload_index;
u8 pn_vector[6];
u8 mic_iv[16];
u8 mic_header1[16];
@@ -1353,12 +1351,11 @@ out:
return res;
 }
 
-static int aes_decipher(u8 *key, uint  hdrlen,
-   u8 *pframe, uint plen)
+static int aes_decipher(u8 *key, uint 

[PATCH v5 13/15] staging: rtl8723au: Rework two byte array comparisons

[M. Vefa Bicakci]

Prior to this commit, rtl8723au's rtw_security.c had two instances of
byte array comparisons (for CRC checks) where the individual elements
of the byte arrays were compared one by one and an error trace would
be output if the byte arrays were determined to be different.

This commit improves the readability of the CRC verification by
placing the individual 4 bytes of each byte array into an 32-bit
unsigned integer and comparing the two resulting integers.

Thanks to Larry Finger for spotting the code style issues in the
previous version of this commit, and thanks to Joe Perches for
suggesting the use of 32-bit integer comparisons instead of byte
array comparisons.

Signed-off-by: M. Vefa Bicakci 

---

v2: Correct code style issues and compare 32-bit integers instead of
byte arrays. Update the commit message to better reflect the nature
of the changes.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 34 +++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index bcb5ea68acbe..0ed048fcb36f 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -210,7 +210,7 @@ void rtw_wep_decrypt23a(struct rtw_adapter *padapter,
 struct recv_frame *precvframe)
 {
/*  exclude ICV */
-   u8 crc[4];
+   u32 actual_crc, expected_crc;
struct arc4context mycontext;
int length;
u32 keylength;
@@ -243,16 +243,14 @@ void rtw_wep_decrypt23a(struct rtw_adapter *padapter,
arcfour_encrypt(, payload, payload, length);
 
/* calculate icv and compare the icv */
-   *((u32 *)crc) = le32_to_cpu(getcrc32(payload, length - 4));
+   actual_crc = le32_to_cpu(getcrc32(payload, length - 4));
+   expected_crc = le32_to_cpu(get_unaligned_le32([length - 4]));
 
-   if (crc[3] != payload[length - 1] || crc[2] != payload[length - 2] ||
-   crc[1] != payload[length - 3] || crc[0] != payload[length - 4]) {
+   if (actual_crc != expected_crc) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_wep_decrypt23a:icv error crc[3](%x)!= 
payload[length-1](%x) || crc[2](%x)!= payload[length-2](%x) || crc[1](%x)!= 
payload[length-3](%x) || crc[0](%x)!= payload[length-4](%x)\n",
-crc[3], payload[length - 1],
-crc[2], payload[length - 2],
-crc[1], payload[length - 3],
-crc[0], payload[length - 4]);
+"rtw_wep_decrypt23a:icv CRC mismatch: "
+"actual: %08x, expected: %08x\n",
+actual_crc, expected_crc);
}
 }
 
@@ -714,7 +712,7 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
u32 pnh;
u8 rc4key[16];
u8 ttkey[16];
-   u8 crc[4];
+   u32 actual_crc, expected_crc;
struct arc4context mycontext;
int length;
u32 prwskeylen;
@@ -771,18 +769,14 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
arcfour_init(, rc4key, 16);
arcfour_encrypt(, payload, payload, length);
 
-   *((u32 *)crc) = le32_to_cpu(getcrc32(payload, length - 4));
+   actual_crc = le32_to_cpu(getcrc32(payload, length - 4));
+   expected_crc = le32_to_cpu(get_unaligned_le32([length - 4]));
 
-   if (crc[3] != payload[length - 1] ||
-   crc[2] != payload[length - 2] ||
-   crc[1] != payload[length - 3] ||
-   crc[0] != payload[length - 4]) {
+   if (actual_crc != expected_crc) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_wep_decrypt23a:icv error crc[3](%x)!= 
payload[length-1](%x) || crc[2](%x)!= payload[length-2](%x) || crc[1](%x)!= 
payload[length-3](%x) || crc[0](%x)!= payload[length-4](%x)\n",
-crc[3], payload[length - 1],
-crc[2], payload[length - 2],
-crc[1], payload[length - 3],
-crc[0], payload[length - 4]);
+"rtw_wep_decrypt23a:icv CRC mismatch: "
+"actual: %08x, expected: %08x\n",
+actual_crc, expected_crc);
res = _FAIL;
}
 
-- 
2.1.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/

[PATCH v5 11/15] staging: rtl8723au: Adjust whitespace in and around comments

[M. Vefa Bicakci]

As the subject indicates, adjust whitespace in and around comments
in rtl8723au's rtw_security.c.

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 113 +-
 1 file changed, 57 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 31ef1bce1e2a..8e0e9fa0efdc 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -135,12 +135,12 @@ static u32 getcrc32(u8 *buf, int len)
if (bcrc32initialized == 0)
crc32_init();
 
-   crc = 0x;   /* preload shift register, per CRC-32 spec */
+   crc = 0x; /* preload shift register, per CRC-32 spec */
 
for (p = buf; len > 0; ++p, --len)
crc = crc32_table[(crc ^ *p) & 0xff] ^ (crc >> 8);
 
-   return ~crc;/* transmit complement, per CRC-32 spec */
+   return ~crc; /* transmit complement, per CRC-32 spec */
 }
 
 /* Need to consider the fragment  situation */
@@ -152,7 +152,7 @@ void rtw_wep_encrypt23a(struct rtw_adapter *padapter,
struct arc4context mycontext;
int curfragnum, length, index;
u32 keylength;
-   u8 *pframe, *payload, *iv;/* wepkey */
+   u8 *pframe, *payload, *iv; /* wepkey */
u8 wepkey[16];
u8 hw_hdr_offset = 0;
struct pkt_attrib *pattrib = >attrib;
@@ -370,15 +370,15 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
priority[0] = pri;
 
/* Michael MIC pseudo header: DA, SA, 3 x 0, Priority */
-   if (header[1]&1) {   /* ToDS == 1 */
-   rtw_secmicappend23a(, [16], 6);  /* DA */
-   if (header[1]&2)  /* From Ds == 1 */
+   if (header[1]&1) { /* ToDS == 1 */
+   rtw_secmicappend23a(, [16], 6); /* DA */
+   if (header[1]&2) /* From Ds == 1 */
rtw_secmicappend23a(, [24], 6);
else
rtw_secmicappend23a(, [10], 6);
-   } else {/* ToDS == 0 */
-   rtw_secmicappend23a(, [4], 6);   /* DA */
-   if (header[1]&2)  /* From Ds == 1 */
+   } else { /* ToDS == 0 */
+   rtw_secmicappend23a(, [4], 6); /* DA */
+   if (header[1]&2) /* From Ds == 1 */
rtw_secmicappend23a(, [16], 6);
else
rtw_secmicappend23a(, [10], 6);
@@ -400,7 +400,7 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
 #define  Hi16(v32)   ((u16)(((v32) >> 16) & 0x))
 #define  Mk16(hi, lo) ((lo) ^ (((u16)(hi)) << 8))
 
-/* select the Nth 16-bit word of the temporal key unsigned char array TK[]   */
+/* select the Nth 16-bit word of the temporal key unsigned char array TK[] */
 #define  TK16(N) Mk16(tk[2 * (N) + 1], tk[2 * (N)])
 
 /* S-box lookup: 16 bits --> 16 bits */
@@ -507,7 +507,7 @@ static void phase1(u16 *p1k, const u8 *tk, const u8 *ta, 
u32 iv32)
 {
int  i;
 
-   /* Initialize the 80 bits of P1K[] from IV32 and TA[0..5] */
+   /* Initialize the 80 bits of P1K[] from IV32 and TA[0..5] */
p1k[0]  = Lo16(iv32);
p1k[1]  = Hi16(iv32);
p1k[2]  = Mk16(ta[1], ta[0]); /* use TA[] as little-endian */
@@ -523,7 +523,7 @@ static void phase1(u16 *p1k, const u8 *tk, const u8 *ta, 
u32 iv32)
p1k[2] += _S_(p1k[1] ^ TK16((i & 1) + 4));
p1k[3] += _S_(p1k[2] ^ TK16((i & 1) + 6));
p1k[4] += _S_(p1k[3] ^ TK16((i & 1) + 0));
-   p1k[4] +=  (unsigned short)i;/* avoid 
"slide attacks" */
+   p1k[4] +=  (unsigned short) i; /* avoid "slide attacks" */
}
 
 }
@@ -554,41 +554,41 @@ static void phase1(u16 *p1k, const u8 *tk, const u8 *ta, 
u32 iv32)
 static void phase2(u8 *rc4key, const u8 *tk, const u16 *p1k, u16 iv16)
 {
int  i;
-   u16 PPK[6];  /* temporary key for mixing*/
+   u16 PPK[6]; /* temporary key for mixing*/
 
-   /* Note: all adds in the PPK[] equations below are mod 2**16 */
+   /* Note: all adds in the PPK[] equations below are mod 2**16 */
for (i = 0; i < 5; i++)
-   PPK[i] = p1k[i];/* first, copy P1K to PPK  */
+   PPK[i] = p1k[i]; /* first, copy P1K to PPK */
 
-   PPK[5] = p1k[4] + iv16; /* next,  add in IV16  */
+   PPK[5] = p1k[4] + iv16; /* next,  add in IV16 */
 
-   /* Bijective non-linear mixing of the 96 bits of PPK[0..5]   */
-   PPK[0] +=_S_(PPK[5] ^ TK16(0));   /* Mix key in each "round" */
-   PPK[1] +=_S_(PPK[0] ^ TK16(1));
-   PPK[2] +=_S_(PPK[1] ^ TK16(2));
-   PPK[3] +=_S_(PPK[2] ^ TK16(3));
-   PPK[4] +=_S_(PPK[3] ^ TK16(4));
-   PPK[5] +=_S_(PPK[4] ^ TK16(5));   /* 

[PATCH v5 02/15] staging: rtl8723au: Fix "before/around/after" whitespace issues

[M. Vefa Bicakci]

Correct a number of "space(s) required before/around/after" checkpatch.pl
issues in a number of functions in rtl8723au's rtw_security.c.

Signed-off-by: M. Vefa Bicakci 

---

v5: Correct even more whitespace issues.

v2: Correct one more whitespace issue ("length-4") in
rtw_tkip_decrypt23a.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 219 +-
 1 file changed, 113 insertions(+), 106 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 92882f60bc0e..572fcf3f936d 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -129,14 +129,14 @@ static void crc32_init(void)
 static u32 getcrc32(u8 *buf, int len)
 {
u8 *p;
-   u32  crc;
+   u32 crc;
 
if (bcrc32initialized == 0) crc32_init();
 
crc = 0x;   /* preload shift register, per CRC-32 spec */
 
for (p = buf; len > 0; ++p, --len)
-   crc = crc32_table[ (crc ^ *p) & 0xff] ^ (crc >> 8);
+   crc = crc32_table[(crc ^ *p) & 0xff] ^ (crc >> 8);
 
return ~crc;/* transmit complement, per CRC-32 spec */
 }
@@ -182,7 +182,7 @@ void rtw_wep_encrypt23a(struct rtw_adapter *padapter,
if ((curfragnum + 1) == pattrib->nr_frags) {
/* the last fragment */
length = pattrib->last_txcmdsz - pattrib->hdrlen -
-   pattrib->iv_len- pattrib->icv_len;
+   pattrib->iv_len - pattrib->icv_len;
 
*((u32 *)crc) = cpu_to_le32(getcrc32(payload, length));
 
@@ -262,8 +262,8 @@ static u32 secmicgetuint32(u8 *p)
s32 i;
u32 res = 0;
 
-   for (i = 0; i<4; i++) {
-   res |= ((u32)(*p++)) << (8*i);
+   for (i = 0; i < 4; i++) {
+   res |= ((u32)(*p++)) << (8 * i);
}
 
return res;
@@ -274,7 +274,7 @@ static void secmicputuint32(u8 *p, u32 val)
 {
long i;
 
-   for (i = 0; i<4; i++) {
+   for (i = 0; i < 4; i++) {
*p++ = (u8) (val & 0xff);
val >>= 8;
}
@@ -307,7 +307,7 @@ void rtw_secmicappend23abyte23a(struct mic_data *pmicdata, 
u8 b)
 {
 
/*  Append the byte to our word-sized buffer */
-   pmicdata->M |= ((unsigned long)b) << (8*pmicdata->nBytesInM);
+   pmicdata->M |= ((unsigned long)b) << (8 * pmicdata->nBytesInM);
pmicdata->nBytesInM++;
/*  Process the word if it is full. */
if (pmicdata->nBytesInM >= 4) {
@@ -331,7 +331,7 @@ void rtw_secmicappend23a(struct mic_data *pmicdata, u8 
*src, u32 nbytes)
 {
 
/*  This is simple */
-   while(nbytes > 0) {
+   while (nbytes > 0) {
rtw_secmicappend23abyte23a(pmicdata, *src++);
nbytes--;
}
@@ -348,12 +348,12 @@ void rtw_secgetmic23a(struct mic_data *pmicdata, u8 *dst)
rtw_secmicappend23abyte23a(pmicdata, 0);
rtw_secmicappend23abyte23a(pmicdata, 0);
/*  and then zeroes until the length is a multiple of 4 */
-   while(pmicdata->nBytesInM != 0) {
+   while (pmicdata->nBytesInM != 0) {
rtw_secmicappend23abyte23a(pmicdata, 0);
}
/*  The appendByte function has already computed the result. */
secmicputuint32(dst, pmicdata->L);
-   secmicputuint32(dst+4, pmicdata->R);
+   secmicputuint32(dst + 4, pmicdata->R);
/*  Reset to the empty message. */
secmicclear(pmicdata);
 
@@ -364,10 +364,10 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
 {
 
struct mic_data micdata;
-   u8 priority[4]={0x0, 0x0, 0x0, 0x0};
+   u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
 
rtw_secmicsetkey23a(, key);
-   priority[0]= pri;
+   priority[0] = pri;
 
/* Michael MIC pseudo header: DA, SA, 3 x 0, Priority */
if (header[1]&1) {   /* ToDS == 1 */
@@ -398,11 +398,11 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
 #define   Lo8(v16)   ((u8)((v16)   & 0x00FF))
 #define   Hi8(v16)   ((u8)(((v16) >> 8) & 0x00FF))
 #define  Lo16(v32)   ((u16)((v32)   & 0x))
-#define  Hi16(v32)   ((u16)(((v32) >>16) & 0x))
+#define  Hi16(v32)   ((u16)(((v32) >> 16) & 0x))
 #define  Mk16(hi, lo) ((lo) ^ (((u16)(hi)) << 8))
 
 /* select the Nth 16-bit word of the temporal key unsigned char array TK[]   */
-#define  TK16(N) Mk16(tk[2*(N)+1], tk[2*(N)])
+#define  TK16(N) Mk16(tk[2 * (N) + 1], tk[2 * (N)])
 
 /* S-box lookup: 16 bits --> 16 bits */
 #define _S_(v16) (Sbox1[0][Lo8(v16)] ^ Sbox1[1][Hi8(v16)])
@@ -415,7 +415,7 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
 #define RC4_KEY_SIZE 16/* 128-bit RC4KEY (104 bits unknown) */
 
 /* 2-unsigned char by 2-unsigned char subset of the full AES S-box table */
-static const unsigned short 

[PATCH v5 09/15] staging: rtl8723au: that open brace should be on the previous line

[M. Vefa Bicakci]

Correct two instances of the checkpatch.pl error indicating that the
opening curly braces should not be on new lines:
ERROR: that open brace { should be on the previous line

Signed-off-by: M. Vefa Bicakci 

---

v3: Make sure that all edited lines are at most 80 characters wide.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 63591ddeb628..2d50777b88fb 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -773,8 +773,10 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
 
*((u32 *)crc) = le32_to_cpu(getcrc32(payload, length - 4));
 
-   if (crc[3] != payload[length - 1] || crc[2] != payload[length - 2] || 
crc[1] != payload[length - 3] || crc[0] != payload[length - 4])
-   {
+   if (crc[3] != payload[length - 1] ||
+   crc[2] != payload[length - 2] ||
+   crc[1] != payload[length - 3] ||
+   crc[0] != payload[length - 4]) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
 "rtw_wep_decrypt23a:icv error crc[3](%x)!= 
payload[length-1](%x) || crc[2](%x)!= payload[length-2](%x) || crc[1](%x)!= 
payload[length-3](%x) || crc[0](%x)!= payload[length-4](%x)\n",
 crc[3], payload[length - 1],
@@ -862,8 +864,7 @@ static void next_key(u8 *key, int round)
 {
u8 rcon;
u8 sbox_key[4];
-   u8 rcon_table[12] =
-   {
+   u8 rcon_table[12] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
0x1b, 0x36, 0x36, 0x36
};
-- 
2.1.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/

[PATCH v5 15/15] staging: rtl8723au: Remove unneeded comments

[M. Vefa Bicakci]

This commit removes a number of unneeded comments. Two of the
aforementioned comments were most likely meant to aid with version
control, whereas the remaining two comments relate to (now unused)
local variable names.

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 5ef16bb30dc4..af53c92fc3a2 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -679,7 +679,7 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
 "pattrib->iv_len =%x, pattrib->icv_len =%x\n",
 pattrib->iv_len,
 pattrib->icv_len);
-   *((u32 *)crc) = cpu_to_le32(getcrc32(payload, length)); 
/* modified by Amy */
+   *((u32 *)crc) = cpu_to_le32(getcrc32(payload, length));
 
arcfour_init(, rc4key, 16);
arcfour_encrypt(, payload, payload, length);
@@ -691,7 +691,7 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
  pattrib->iv_len -
  pattrib->icv_len);
 
-   *((u32 *)crc) = cpu_to_le32(getcrc32(payload, length)); 
/* modified by Amy */
+   *((u32 *)crc) = cpu_to_le32(getcrc32(payload, length));
arcfour_init(, rc4key, 16);
arcfour_encrypt(, payload, payload, length);
arcfour_encrypt(, payload + length, crc, 4);
@@ -1285,7 +1285,7 @@ int rtw_aes_encrypt23a(struct rtw_adapter *padapter,
/* Intermediate Buffers */
int curfragnum, length;
u32 prwskeylen;
-   u8 *pframe, *prwskey; /* *payload, *iv */
+   u8 *pframe, *prwskey;
u8 hw_hdr_offset = 0;
struct sta_info *stainfo;
struct pkt_attrib *pattrib = >attrib;
@@ -1574,7 +1574,7 @@ int rtw_aes_decrypt23a(struct rtw_adapter *padapter,
struct security_priv *psecuritypriv = >securitypriv;
struct sk_buff *skb = precvframe->pkt;
int length;
-   u8 *pframe, *prwskey; /* *payload, *iv */
+   u8 *pframe, *prwskey;
int res = _SUCCESS;
 
pframe = skb->data;
-- 
2.1.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/

[PATCH v5 10/15] staging: rtl8723au: No spaces at the start of a line

[M. Vefa Bicakci]

Prior to this commit, a large block of constants used to represent
an AES S-box table were indented with spaces in rtl8723au's
rtw_security.c. Correct the checkpatch.pl warnings indicating that
spaces should not be used to indent lines:
WARNING: please, no spaces at the start of a line

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 140 +-
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 2d50777b88fb..31ef1bce1e2a 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -414,76 +414,76 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
 #define RC4_KEY_SIZE 16/* 128-bit RC4KEY (104 bits unknown) */
 
 /* 2-unsigned char by 2-unsigned char subset of the full AES S-box table */
-static const unsigned short Sbox1[2][256] =   /* Sbox for hash (can be in 
ROM) */
-{ {
-   0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154,
-   0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A,
-   0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B,
-   0x41EC, 0xB367, 0x5FFD, 0x45EA, 0x23BF, 0x53F7, 0xE496, 0x9B5B,
-   0x75C2, 0xE11C, 0x3DAE, 0x4C6A, 0x6C5A, 0x7E41, 0xF502, 0x834F,
-   0x685C, 0x51F4, 0xD134, 0xF908, 0xE293, 0xAB73, 0x6253, 0x2A3F,
-   0x080C, 0x9552, 0x4665, 0x9D5E, 0x3028, 0x37A1, 0x0A0F, 0x2FB5,
-   0x0E09, 0x2436, 0x1B9B, 0xDF3D, 0xCD26, 0x4E69, 0x7FCD, 0xEA9F,
-   0x121B, 0x1D9E, 0x5874, 0x342E, 0x362D, 0xDCB2, 0xB4EE, 0x5BFB,
-   0xA4F6, 0x764D, 0xB761, 0x7DCE, 0x527B, 0xDD3E, 0x5E71, 0x1397,
-   0xA6F5, 0xB968, 0x, 0xC12C, 0x4060, 0xE31F, 0x79C8, 0xB6ED,
-   0xD4BE, 0x8D46, 0x67D9, 0x724B, 0x94DE, 0x98D4, 0xB0E8, 0x854A,
-   0xBB6B, 0xC52A, 0x4FE5, 0xED16, 0x86C5, 0x9AD7, 0x6655, 0x1194,
-   0x8ACF, 0xE910, 0x0406, 0xFE81, 0xA0F0, 0x7844, 0x25BA, 0x4BE3,
-   0xA2F3, 0x5DFE, 0x80C0, 0x058A, 0x3FAD, 0x21BC, 0x7048, 0xF104,
-   0x63DF, 0x77C1, 0xAF75, 0x4263, 0x2030, 0xE51A, 0xFD0E, 0xBF6D,
-   0x814C, 0x1814, 0x2635, 0xC32F, 0xBEE1, 0x35A2, 0x88CC, 0x2E39,
-   0x9357, 0x55F2, 0xFC82, 0x7A47, 0xC8AC, 0xBAE7, 0x322B, 0xE695,
-   0xC0A0, 0x1998, 0x9ED1, 0xA37F, 0x4466, 0x547E, 0x3BAB, 0x0B83,
-   0x8CCA, 0xC729, 0x6BD3, 0x283C, 0xA779, 0xBCE2, 0x161D, 0xAD76,
-   0xDB3B, 0x6456, 0x744E, 0x141E, 0x92DB, 0x0C0A, 0x486C, 0xB8E4,
-   0x9F5D, 0xBD6E, 0x43EF, 0xC4A6, 0x39A8, 0x31A4, 0xD337, 0xF28B,
-   0xD532, 0x8B43, 0x6E59, 0xDAB7, 0x018C, 0xB164, 0x9CD2, 0x49E0,
-   0xD8B4, 0xACFA, 0xF307, 0xCF25, 0xCAAF, 0xF48E, 0x47E9, 0x1018,
-   0x6FD5, 0xF088, 0x4A6F, 0x5C72, 0x3824, 0x57F1, 0x73C7, 0x9751,
-   0xCB23, 0xA17C, 0xE89C, 0x3E21, 0x96DD, 0x61DC, 0x0D86, 0x0F85,
-   0xE090, 0x7C42, 0x71C4, 0xCCAA, 0x90D8, 0x0605, 0xF701, 0x1C12,
-   0xC2A3, 0x6A5F, 0xAEF9, 0x69D0, 0x1791, 0x9958, 0x3A27, 0x27B9,
-   0xD938, 0xEB13, 0x2BB3, 0x2233, 0xD2BB, 0xA970, 0x0789, 0x33A7,
-   0x2DB6, 0x3C22, 0x1592, 0xC920, 0x8749, 0xAAFF, 0x5078, 0xA57A,
-   0x038F, 0x59F8, 0x0980, 0x1A17, 0x65DA, 0xD731, 0x84C6, 0xD0B8,
-   0x82C3, 0x29B0, 0x5A77, 0x1E11, 0x7BCB, 0xA8FC, 0x6DD6, 0x2C3A,
-  },
-
-  {  /* second half of table is unsigned char-reversed version of first! */
-   0xA5C6, 0x84F8, 0x99EE, 0x8DF6, 0x0DFF, 0xBDD6, 0xB1DE, 0x5491,
-   0x5060, 0x0302, 0xA9CE, 0x7D56, 0x19E7, 0x62B5, 0xE64D, 0x9AEC,
-   0x458F, 0x9D1F, 0x4089, 0x87FA, 0x15EF, 0xEBB2, 0xC98E, 0x0BFB,
-   0xEC41, 0x67B3, 0xFD5F, 0xEA45, 0xBF23, 0xF753, 0x96E4, 0x5B9B,
-   0xC275, 0x1CE1, 0xAE3D, 0x6A4C, 0x5A6C, 0x417E, 0x02F5, 0x4F83,
-   0x5C68, 0xF451, 0x34D1, 0x08F9, 0x93E2, 0x73AB, 0x5362, 0x3F2A,
-   0x0C08, 0x5295, 0x6546, 0x5E9D, 0x2830, 0xA137, 0x0F0A, 0xB52F,
-   0x090E, 0x3624, 0x9B1B, 0x3DDF, 0x26CD, 0x694E, 0xCD7F, 0x9FEA,
-   0x1B12, 0x9E1D, 0x7458, 0x2E34, 0x2D36, 0xB2DC, 0xEEB4, 0xFB5B,
-   0xF6A4, 0x4D76, 0x61B7, 0xCE7D, 0x7B52, 0x3EDD, 0x715E, 0x9713,
-   0xF5A6, 0x68B9, 0x, 0x2CC1, 0x6040, 0x1FE3, 0xC879, 0xEDB6,
-   0xBED4, 0x468D, 0xD967, 0x4B72, 0xDE94, 0xD498, 0xE8B0, 0x4A85,
-   0x6BBB, 0x2AC5, 0xE54F, 0x16ED, 0xC586, 0xD79A, 0x5566, 0x9411,
-   0xCF8A, 0x10E9, 0x0604, 0x81FE, 0xF0A0, 0x4478, 0xBA25, 0xE34B,
-   0xF3A2, 0xFE5D, 0xC080, 0x8A05, 0xAD3F, 0xBC21, 0x4870, 0x04F1,
-   0xDF63, 0xC177, 0x75AF, 0x6342, 0x3020, 0x1AE5, 0x0EFD, 0x6DBF,
-   0x4C81, 0x1418, 0x3526, 0x2FC3, 0xE1BE, 0xA235, 0xCC88, 0x392E,
-   0x5793, 0xF255, 0x82FC, 0x477A, 0xACC8, 0xE7BA, 0x2B32, 0x95E6,
-   0xA0C0, 0x9819, 0xD19E, 0x7FA3, 0x6644, 0x7E54, 0xAB3B, 0x830B,
-   0xCA8C, 0x29C7, 0xD36B, 0x3C28, 0x79A7, 0xE2BC, 0x1D16, 0x76AD,
-   0x3BDB, 0x5664, 0x4E74, 0x1E14, 0xDB92, 0x0A0C, 0x6C48, 0xE4B8,
-   0x5D9F, 0x6EBD, 0xEF43, 0xA6C4, 0xA839, 0xA431, 0x37D3, 0x8BF2,
-   0x32D5, 0x438B, 0x596E, 0xB7DA, 0x8C01, 0x64B1, 0xD29C, 0xE049,
-   0xB4D8, 0xFAAC, 0x07F3, 0x25CF, 0xAFCA, 0x8EF4, 0xE947, 0x1810,
-   0xD56F, 0x88F0, 0x6F4A, 0x725C, 0x2438, 

[PATCH v5 14/15] staging: rtl8723au: Use __func__ in trace logs

[M. Vefa Bicakci]

Rework the trace log-related lines in rtl8723au's rtw_security.c
to use the __func__ GCC magic variable instead of hardcoding the
function names into the trace log strings. This also corrects a
copy-paste-related typo in the function named rtw_tkip_decrypt23a.

Thanks to Jes Sorensen for the suggestion to use __func__.

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 41 ++-
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 0ed048fcb36f..5ef16bb30dc4 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -248,9 +248,9 @@ void rtw_wep_decrypt23a(struct rtw_adapter *padapter,
 
if (actual_crc != expected_crc) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_wep_decrypt23a:icv CRC mismatch: "
+"%s:icv CRC mismatch: "
 "actual: %08x, expected: %08x\n",
-actual_crc, expected_crc);
+__func__, actual_crc, expected_crc);
}
 }
 
@@ -635,13 +635,13 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
 
if (stainfo == NULL) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_tkip_encrypt23a: stainfo == NULL!!!\n");
+"%s: stainfo == NULL!!!\n", __func__);
DBG_8723A("%s, psta == NUL\n", __func__);
return _FAIL;
}
 
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_tkip_encrypt23a: stainfo!= NULL!!!\n");
+"%s: stainfo!= NULL!!!\n", __func__);
 
if (!(stainfo->state & _FW_LINKED)) {
DBG_8723A("%s, psta->state(0x%x) != _FW_LINKED\n", __func__, 
stainfo->state);
@@ -733,7 +733,7 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
 >ta[0]);
if (stainfo == NULL) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_tkip_decrypt23a: stainfo == NULL!!!\n");
+"%s: stainfo == NULL!!!\n", __func__);
return _FAIL;
}
 
@@ -748,7 +748,7 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
prwskeylen = 16;
} else {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_tkip_decrypt23a: stainfo!= NULL!!!\n");
+"%s: stainfo!= NULL!!!\n", __func__);
prwskey = >dot118021x_UncstKey.skey[0];
prwskeylen = 16;
}
@@ -774,9 +774,9 @@ int rtw_tkip_decrypt23a(struct rtw_adapter *padapter,
 
if (actual_crc != expected_crc) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_wep_decrypt23a:icv CRC mismatch: "
+"%s:icv CRC mismatch: "
 "actual: %08x, expected: %08x\n",
-actual_crc, expected_crc);
+__func__, actual_crc, expected_crc);
res = _FAIL;
}
 
@@ -1313,7 +1313,7 @@ int rtw_aes_encrypt23a(struct rtw_adapter *padapter,
 
if (!stainfo) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_aes_encrypt23a: stainfo == NULL!!!\n");
+"%s: stainfo == NULL!!!\n", __func__);
DBG_8723A("%s, psta == NUL\n", __func__);
res = _FAIL;
goto out;
@@ -1324,7 +1324,7 @@ int rtw_aes_encrypt23a(struct rtw_adapter *padapter,
return _FAIL;
}
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_aes_encrypt23a: stainfo!= NULL!!!\n");
+"%s: stainfo!= NULL!!!\n", __func__);
 
if (is_multicast_ether_addr(pattrib->ra))
prwskey = 
psecuritypriv->dot118021XGrpKey[psecuritypriv->dot118021XGrpKeyid].skey;
@@ -1552,11 +1552,14 @@ static int aes_decipher(u8 *key, uint hdrlen, u8 
*pframe, uint plen)
for (i = 0; i < 8; i++) {
if (pframe[hdrlen + 8 + plen - 8 + i] != message[hdrlen + 8 + 
plen - 8 + i]) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"aes_decipher:mic check error mic[%d]: 
pframe(%x) != message(%x)\n",
-i, pframe[hdrlen + 8 + plen - 8 + i],
+"%s:mic check error mic[%d]: pframe(%x) != 
message(%x)\n",
+__func__, i,
+pframe[hdrlen + 8 + plen - 8 + i],
 message[hdrlen + 8 + plen - 8 + i]);
-   DBG_8723A("aes_decipher:mic check error mic[%d]: 
pframe(%x) != message(%x)\n",
-   

[PATCH v5 04/15] staging: rtl8723au: Fix the indentation of two lines

[M. Vefa Bicakci]

Correct the indentation of two lines in rtw_tkip_encrypt23a function in
rtl8723au's rtw_security.c.

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 9faf78bf23d8..3e79b66d0897 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -688,8 +688,8 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
arcfour_encrypt(, payload, 
payload, length);
arcfour_encrypt(, payload + 
length, crc, 4);
 
-   pframe += pxmitpriv->frag_len;
-   pframe  = PTR_ALIGN(pframe, 4);
+   pframe += pxmitpriv->frag_len;
+   pframe  = PTR_ALIGN(pframe, 4);
}
}
 
-- 
2.1.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/

[PATCH v5 08/15] staging: rtl8723au: trailing statements should be on next line

[M. Vefa Bicakci]

Correct a number of checkpatch.pl errors in rtl8723au's rtw_security.c
related to trailing statements:
ERROR: trailing statements should be on next line

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index e8efdcd06329..63591ddeb628 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -132,7 +132,8 @@ static u32 getcrc32(u8 *buf, int len)
u8 *p;
u32 crc;
 
-   if (bcrc32initialized == 0) crc32_init();
+   if (bcrc32initialized == 0)
+   crc32_init();
 
crc = 0x;   /* preload shift register, per CRC-32 spec */
 
@@ -556,8 +557,10 @@ static void phase2(u8 *rc4key, const u8 *tk, const u16 
*p1k, u16 iv16)
u16 PPK[6];  /* temporary key for mixing*/
 
/* Note: all adds in the PPK[] equations below are mod 2**16 */
-   for (i = 0; i < 5; i++) PPK[i] = p1k[i];/* first, copy P1K to PPK   
   */
-   PPK[5] = p1k[4] + iv16; /* next,  add in IV16   
   */
+   for (i = 0; i < 5; i++)
+   PPK[i] = p1k[i];/* first, copy P1K to PPK  */
+
+   PPK[5] = p1k[4] + iv16; /* next,  add in IV16  */
 
/* Bijective non-linear mixing of the 96 bits of PPK[0..5]   */
PPK[0] +=_S_(PPK[5] ^ TK16(0));   /* Mix key in each "round" */
@@ -977,7 +980,8 @@ static void aes128k128d(u8 *key, u8 *data, u8 *ciphertext)
u8 intermediateb[16];
u8 round_key[16];
 
-   for (i = 0; i < 16; i++) round_key[i] = key[i];
+   for (i = 0; i < 16; i++)
+   round_key[i] = key[i];
 
for (round = 0; round < 11; round++) {
if (round == 0) {
@@ -1061,7 +1065,8 @@ static void construct_mic_header2(u8 *mic_header2, u8 
*mpdu, int a4_exists,
 {
int i;
 
-   for (i = 0; i < 16; i++) mic_header2[i] = 0x00;
+   for (i = 0; i < 16; i++)
+   mic_header2[i] = 0x00;
 
mic_header2[0] = mpdu[16];/* A3 */
mic_header2[1] = mpdu[17];
@@ -1074,7 +1079,8 @@ static void construct_mic_header2(u8 *mic_header2, u8 
*mpdu, int a4_exists,
mic_header2[7] = 0x00; /* mpdu[23]; */
 
if (!qc_exists && a4_exists) {
-   for (i = 0; i < 6; i++) mic_header2[8+i] = mpdu[24+i];   /* A4 
*/
+   for (i = 0; i < 6; i++)
+   mic_header2[8+i] = mpdu[24+i];   /* A4 */
}
 
if (qc_exists && !a4_exists) {
@@ -1083,7 +1089,8 @@ static void construct_mic_header2(u8 *mic_header2, u8 
*mpdu, int a4_exists,
}
 
if (qc_exists && a4_exists) {
-   for (i = 0; i < 6; i++) mic_header2[8+i] = mpdu[24+i];   /* A4 
*/
+   for (i = 0; i < 6; i++)
+   mic_header2[8+i] = mpdu[24+i];   /* A4 */
 
mic_header2[14] = mpdu[30] & 0x0f;
mic_header2[15] = mpdu[31] & 0x00;
@@ -1101,7 +1108,9 @@ static void construct_ctr_preload(u8 *ctr_preload, int 
a4_exists, int qc_exists,
 {
int i = 0;
 
-   for (i = 0; i < 16; i++) ctr_preload[i] = 0x00;
+   for (i = 0; i < 16; i++)
+   ctr_preload[i] = 0x00;
+
i = 0;
 
ctr_preload[0] = 0x01;  /* flag */
-- 
2.1.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/

[PATCH v5 03/15] staging: rtl8723au: else should follow close brace

[M. Vefa Bicakci]

Correct checkpatch.pl errors in rtl8723au's rtw_security.c indicating
that an else statement should follow the closing brace of the previous
if/else if code block:
ERROR: else should follow close brace '}'

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 572fcf3f936d..9faf78bf23d8 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -376,8 +376,7 @@ void rtw_seccalctkipmic23a(u8 *key, u8 *header, u8 *data, 
u32 data_len,
rtw_secmicappend23a(, [24], 6);
else
rtw_secmicappend23a(, [10], 6);
-   }
-   else{   /* ToDS == 0 */
+   } else {/* ToDS == 0 */
rtw_secmicappend23a(, [4], 6);   /* DA */
if (header[1]&2)  /* From Ds == 1 */
rtw_secmicappend23a(, [16], 6);
@@ -678,8 +677,7 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
arcfour_encrypt(, payload, 
payload, length);
arcfour_encrypt(, payload + 
length, crc, 4);
 
-   }
-   else {
+   } else {
length = (pxmitpriv->frag_len -
  pattrib->hdrlen -
  pattrib->iv_len -
@@ -695,8 +693,7 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
}
}
 
-   }
-   else {
+   } else {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
 "rtw_tkip_encrypt23a: stainfo == NULL!!!\n");
DBG_8723A("%s, psta == NUL\n", __func__);
-- 
2.1.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/

[PATCH v5 12/15] staging: rtl8723au: suspect code indent for conditional statements

[M. Vefa Bicakci]

Correct a number of indentation-with-spaces-and-tabs issues in
rtl8723au's rtw_security.c, according to checkpatch.pl:
WARNING: suspect code indent for conditional statements

Signed-off-by: M. Vefa Bicakci 

---

v3: Make sure that all edited lines are at most 80 characters wide.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 34 +--
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 8e0e9fa0efdc..bcb5ea68acbe 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -929,9 +929,9 @@ static void mix_column(u8 *in, u8 *out)
 
for (i = 0; i < 4; i++) {
if ((in[i] & 0x80) == 0x80)
-   add1b[i] = 0x1b;
+   add1b[i] = 0x1b;
else
-   add1b[i] = 0x00;
+   add1b[i] = 0x00;
}
 
swap_halfs[0] = in[2]; /* Swap halfs */
@@ -986,21 +986,21 @@ static void aes128k128d(u8 *key, u8 *data, u8 *ciphertext)
 
for (round = 0; round < 11; round++) {
if (round == 0) {
-   xor_128(round_key, data, ciphertext);
-   next_key(round_key, round);
+   xor_128(round_key, data, ciphertext);
+   next_key(round_key, round);
} else if (round == 10) {
-   byte_sub(ciphertext, intermediatea);
-   shift_row(intermediatea, intermediateb);
-   xor_128(intermediateb, round_key, ciphertext);
+   byte_sub(ciphertext, intermediatea);
+   shift_row(intermediatea, intermediateb);
+   xor_128(intermediateb, round_key, ciphertext);
} else { /* 1 - 9 */
-   byte_sub(ciphertext, intermediatea);
-   shift_row(intermediatea, intermediateb);
-   mix_column([0], [0]);
-   mix_column([4], [4]);
-   mix_column([8], [8]);
-   mix_column([12], [12]);
-   xor_128(intermediatea, round_key, ciphertext);
-   next_key(round_key, round);
+   byte_sub(ciphertext, intermediatea);
+   shift_row(intermediatea, intermediateb);
+   mix_column([0], [0]);
+   mix_column([4], [4]);
+   mix_column([8], [8]);
+   mix_column([12], [12]);
+   xor_128(intermediatea, round_key, ciphertext);
+   next_key(round_key, round);
}
}
 
@@ -1501,7 +1501,7 @@ static int aes_decipher(u8 *key, uint hdrlen, u8 *pframe, 
uint plen)
for (j = 0; j < 16; j++)
padded_buffer[j] = 0x00;
for (j = 0; j < payload_remainder; j++)
-   padded_buffer[j] = message[payload_index++];
+   padded_buffer[j] = message[payload_index++];
bitwise_xor(aes_out, padded_buffer, chain_buffer);
aes128k128d(key, chain_buffer, aes_out);
}
@@ -1531,7 +1531,7 @@ static int aes_decipher(u8 *key, uint hdrlen, u8 *pframe, 
uint plen)
  message, pn_vector, num_blocks + 1);
 
for (j = 0; j < 16; j++)
-padded_buffer[j] = 0x00;
+   padded_buffer[j] = 0x00;
for (j = 0; j < payload_remainder; j++)
padded_buffer[j] = message[payload_index + j];
aes128k128d(key, ctr_preload, aes_out);
-- 
2.1.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/

[PATCH v5 00/15] checkpatch clean-up of rtl8723au's rtw_security.c

[M. Vefa Bicakci]

These commits address a number of checkpatch.pl warnings and errors
in rtl8723au's rtw_security.c.

Prior to this set of commits, checkpatch.pl reported the following:
total: 75 errors, 124 warnings, 1631 lines checked

After applying this set of commits, checkpatch.pl reports the following:
total: 0 errors, 22 warnings, 1635 lines checked
where the only remaining warnings relate to lines longer than 80
characters and quoted strings split across multiple lines.

There are also a number of commits which improve the code in other ways.
For example, the commit titled "Reorganize a few functions to remove
indentation" reworks two functions to make them more readable, whereas
the commit titled "Rework two byte array comparisons" reworks two CRC
verifications for the same reason, and "Use __func__ in trace logs"
avoids hardcoding function names in trace logs to increase
maintainability.

All of the commits have been verified to compile successfully via the
use of the interactive rebase feature of git.

v5: Rebased onto Greg Kroah-Hartman's staging-testing tree, on top of
the following commit
  commit f8da055aafec0483c12132554504ec683868c655
  staging: sm750fb: Change "foo * bar" style to "foo *bar"

Please see the individual commit messages for the specific changes
since v5 aside from the rebase.

v4: Rebased onto Greg Kroah-Hartman's staging-next tree, on top of
the following commit
  commit 153fe946412b5da1a8808f79d4f7f4ebfa7586b0
  staging: fbtft: Do not use binary constants

In addition, fix-up the commit messages to move the patch revision
notes below the newly added "---" markers where needed.

v3: Rebased onto Greg Kroah-Hartman's staging-next tree, on top of
the following commit
  5ec293650827122df300581c17ca1d5de03bac3d.
  Staging: dgnc: release the lock before testing for nullity

Please see the individual commit messages for the changes
since v2. In summary, the following commits have been updated:
- that open brace should be on the previous line
- suspect code indent for conditional statements

The following commit is new:
- Use __func__ in trace logs

Finally, the following commit has been removed:
- Do not initialize a static to 0

v2: Please see the individual commit messages for the changes
since v1. In summary, the following commits have been updated:
- Reformat whitespace to increase readability
- Fix "before/around/after" whitespace issues
- Rework two byte array comparisons

M. Vefa Bicakci (15):
  staging: rtl8723au: Reformat whitespace to increase readability
  staging: rtl8723au: Fix "before/around/after" whitespace issues
  staging: rtl8723au: else should follow close brace
  staging: rtl8723au: Fix the indentation of two lines
  staging: rtl8723au: Reorganize a few functions to remove indentation
  staging: rtl8723au: else is not generally useful after a return
  staging: rtl8723au: Remove unneeded curly braces
  staging: rtl8723au: trailing statements should be on next line
  staging: rtl8723au: that open brace should be on the previous line
  staging: rtl8723au: No spaces at the start of a line
  staging: rtl8723au: Adjust whitespace in and around comments
  staging: rtl8723au: suspect code indent for conditional statements
  staging: rtl8723au: Rework two byte array comparisons
  staging: rtl8723au: Use __func__ in trace logs
  staging: rtl8723au: Remove unneeded comments

 drivers/staging/rtl8723au/core/rtw_security.c | 832 +-
 1 file changed, 418 insertions(+), 414 deletions(-)

-- 
2.1.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/

[PATCH v5 05/15] staging: rtl8723au: Reorganize a few functions to remove indentation

[M. Vefa Bicakci]

Prior to this commit, functions rtw_tkip_encrypt23a and rtw_tkip_decrypt23a had
large if blocks which contained the majority of the logic in the functions.

Rework these functions so that if the negated version of the aforementioned if
blocks' conditions are true, we return from the function with _FAIL, as
expected by the calling code.

This lets us remove two levels of indentation from the functions in
question, making them more readable.

Signed-off-by: M. Vefa Bicakci 

---

v5: Move the "start to encrypt each fragment" and "start to decrypt
recvframe" comments in the refactored functions to more sensible
positions.
---
 drivers/staging/rtl8723au/core/rtw_security.c | 215 +-
 1 file changed, 107 insertions(+), 108 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index 3e79b66d0897..df7261c045fe 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -615,91 +615,90 @@ int rtw_tkip_encrypt23a(struct rtw_adapter *padapter,
struct xmit_priv *pxmitpriv = >xmitpriv;
int res = _SUCCESS;
 
+   if (pattrib->encrypt != WLAN_CIPHER_SUITE_TKIP)
+   return _FAIL;
+
if (!pxmitframe->buf_addr)
return _FAIL;
 
hw_hdr_offset = TXDESC_OFFSET;
 
pframe = pxmitframe->buf_addr + hw_hdr_offset;
-   /* 4 start to encrypt each fragment */
-   if (pattrib->encrypt == WLAN_CIPHER_SUITE_TKIP) {
-   if (pattrib->psta)
-   stainfo = pattrib->psta;
-   else {
-   DBG_8723A("%s, call rtw_get_stainfo()\n", __func__);
-   stainfo = rtw_get_stainfo23a(>stapriv,
->ra[0]);
-   }
 
-   if (stainfo != NULL) {
+   if (pattrib->psta)
+   stainfo = pattrib->psta;
+   else {
+   DBG_8723A("%s, call rtw_get_stainfo()\n", __func__);
+   stainfo = rtw_get_stainfo23a(>stapriv,
+>ra[0]);
+   }
 
-   if (!(stainfo->state & _FW_LINKED)) {
-   DBG_8723A("%s, psta->state(0x%x) != 
_FW_LINKED\n", __func__, stainfo->state);
-   return _FAIL;
-   }
+   if (stainfo == NULL) {
+   RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
+"rtw_tkip_encrypt23a: stainfo == NULL!!!\n");
+   DBG_8723A("%s, psta == NUL\n", __func__);
+   return _FAIL;
+   }
 
-   RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
-"rtw_tkip_encrypt23a: stainfo!= NULL!!!\n");
+   RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
+"rtw_tkip_encrypt23a: stainfo!= NULL!!!\n");
 
-   if (is_multicast_ether_addr(pattrib->ra))
-   prwskey = 
psecuritypriv->dot118021XGrpKey[psecuritypriv->dot118021XGrpKeyid].skey;
-   else
-   prwskey = >dot118021x_UncstKey.skey[0];
+   if (!(stainfo->state & _FW_LINKED)) {
+   DBG_8723A("%s, psta->state(0x%x) != _FW_LINKED\n", __func__, 
stainfo->state);
+   return _FAIL;
+   }
 
-   prwskeylen = 16;
+   if (is_multicast_ether_addr(pattrib->ra))
+   prwskey = 
psecuritypriv->dot118021XGrpKey[psecuritypriv->dot118021XGrpKeyid].skey;
+   else
+   prwskey = >dot118021x_UncstKey.skey[0];
 
-   for (curfragnum = 0; curfragnum < pattrib->nr_frags; 
curfragnum++) {
-   iv = pframe + pattrib->hdrlen;
-   payload = pframe + pattrib->iv_len + 
pattrib->hdrlen;
+   prwskeylen = 16;
 
-   GET_TKIP_PN(iv, dot11txpn);
+   /* 4 start to encrypt each fragment */
+   for (curfragnum = 0; curfragnum < pattrib->nr_frags; curfragnum++) {
+   iv = pframe + pattrib->hdrlen;
+   payload = pframe + pattrib->iv_len + pattrib->hdrlen;
 
-   pnl = (u16)(dot11txpn.val);
-   pnh = (u32)(dot11txpn.val>>16);
+   GET_TKIP_PN(iv, dot11txpn);
 
-   phase1((u16 *)[0], prwskey, 
>ta[0], pnh);
+   pnl = (u16)(dot11txpn.val);
+   pnh = (u32)(dot11txpn.val>>16);
 
-   phase2([0], prwskey, (u16 *)[0], 
pnl);
+   phase1((u16 *)[0], prwskey, >ta[0], pnh);
 
-   if ((curfragnum + 1) == pattrib->nr_frags) {
/* 4 the last fragment */
-   length = (pattrib->last_txcmdsz -
- pattrib->hdrlen -
-   

[PATCH v5 06/15] staging: rtl8723au: else is not generally useful after a return

[M. Vefa Bicakci]

Correct a checkpatch.pl warning regarding rtl8723au's
rtw_security.c::crc32_init pointing out that having an else statement
after a break or a return is not useful.

drivers/staging/rtl8723au/core/rtw_security.c:105:
WARNING: else is not generally useful after a break or return

Signed-off-by: M. Vefa Bicakci 
---
 drivers/staging/rtl8723au/core/rtw_security.c | 42 ++-
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_security.c 
b/drivers/staging/rtl8723au/core/rtw_security.c
index df7261c045fe..b85e5de5f136 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -99,31 +99,33 @@ static u8 crc32_reverseBit(u8 data)
 
 static void crc32_init(void)
 {
+   int i, j;
+   u32 c;
+   u8 *p, *p1;
+   u8 k;
 
if (bcrc32initialized == 1)
return;
-   else{
-   int i, j;
-   u32 c;
-   u8 *p = (u8 *), *p1;
-   u8 k;
-
-   c = 0x1234;
-
-   for (i = 0; i < 256; ++i) {
-   k = crc32_reverseBit((u8)i);
-   for (c = ((u32)k) << 24, j = 8; j > 0; --j) {
-   c = c & 0x8000 ? (c << 1) ^ CRC32_POLY : (c 
<< 1);
-   }
-   p1 = (u8 *)_table[i];
-
-   p1[0] = crc32_reverseBit(p[3]);
-   p1[1] = crc32_reverseBit(p[2]);
-   p1[2] = crc32_reverseBit(p[1]);
-   p1[3] = crc32_reverseBit(p[0]);
+
+   p = (u8 *) 
+   c = 0x1234;
+
+   for (i = 0; i < 256; ++i) {
+   k = crc32_reverseBit((u8)i);
+
+   for (c = ((u32)k) << 24, j = 8; j > 0; --j) {
+   c = c & 0x8000 ? (c << 1) ^ CRC32_POLY : (c << 1);
}
-   bcrc32initialized = 1;
+
+   p1 = (u8 *)_table[i];
+
+   p1[0] = crc32_reverseBit(p[3]);
+   p1[1] = crc32_reverseBit(p[2]);
+   p1[2] = crc32_reverseBit(p[1]);
+   p1[3] = crc32_reverseBit(p[0]);
}
+
+   bcrc32initialized = 1;
 }
 
 static u32 getcrc32(u8 *buf, int len)
-- 
2.1.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/

[PATCH] Documentation/ABI: iio: fix typo

[Martin Kepplinger]

Signed-off-by: Martin Kepplinger 
---
 Documentation/ABI/testing/sysfs-bus-iio | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 9a70c31..74a3493 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -776,7 +776,7 @@ Description:
 
 What:  /sys/.../events/in_accel_x_thresh_rising_period
 What:  /sys/.../events/in_accel_x_thresh_falling_period
-hat:   /sys/.../events/in_accel_x_roc_rising_period
+What:  /sys/.../events/in_accel_x_roc_rising_period
 What:  /sys/.../events/in_accel_x_roc_falling_period
 What:  /sys/.../events/in_accel_y_thresh_rising_period
 What:  /sys/.../events/in_accel_y_thresh_falling_period
-- 
2.1.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 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Guenter Roeck]

On 03/28/2015 03:44 PM, Paul Bolle wrote:

Guenter Roeck schreef op za 28-03-2015 om 15:20 [-0700]:

Maybe that is the plan, but it is not what is happening.
I8K selects SENSORS_DELL_SMM, so a boolean I8K forces SENSORS_DELL_SMM
to be built into the kernel.

What you suggest would work if I8K would depend on SENSORS_DELL_SMM,
but then the symbols would not be backward-compatible.


I haven't actually looked into this part of the patch, since as far as
I'm concerned this patch is broken.



You mean beyond the "ON" and the above problem ? Can you elaborate ?

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Shirish Gajera]

On Sun, Mar 29, 2015 at 12:54:45AM +0100, Richard Weinberger wrote:
> Am 29.03.2015 um 00:44 schrieb Shirish Gajera:
> > On Sat, Mar 28, 2015 at 02:35:19PM -0700, Joe Perches wrote:
> >> On Sat, 2015-03-28 at 22:22 +0100, Richard Weinberger wrote:
> >>> Am 28.03.2015 um 22:18 schrieb Joe Perches:
>  On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
> > On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera 
> >  wrote:
> >> This patch fixes the checkpatch.pl warning:
> >> []
> > Instead of blindly adding newlines to silence checkpatch.pl, what
> > about reworking the code?
> > printf("%s\n", ..) cries for a puts().
> 
>  There is no synth_puts
> >>>
> >>> So what?
> >>> Fix it! :-)
> >>
> >> Not sure that'd make the code better... ;-p
> >>
> >>> the whole code is horrible and lines other 80 chars are the *least*
> >>> problem.
> >>
> >> Dunno about how horrible it is, my guess is it works.
> >>
> >>> Submitting a patch just for the sake of silencing checkpatch.pl is a 
> >>> waste of time.
> >>> After applying this patch the driver 0 better than before.
> >>
> >> Agree with that.
> >>
> >> And truly, checkpatch is only a guide.
> >>
> >> Making the code better instead of merely style conforming
> >> should be the primary goal of patches.
> > 
> > This is my first patch.
> 
> Are you sure?
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/2015-January/013187.html
Yup, this patch never got merge because I was doing changes against
wrong repo.
> 
> > Actually on the website it's return that 
> > "Pick a warning, and try to fix it. For your first patch, only pick one
> > warning. In the future you can group multiple changes into one patch,
> > but only if you follow the PatchPhilosophy of breaking each patch into
> > logical changes."
> > 
> > My main aim is to get the patch in and get familier with the full system
> > (code checking,flow etc.). So, I am fixing simple warning.
> > 
> > If this code require changes then I can do as part of future changes.
> 
> The future is now, please address these issues now. :-)
> Again, blindly fixing checkpatch.pl warnings is worthless.
> 
> Thanks,
> //richard

Are you sure you want me to do this changes. Because it will conflict
the things written on http://kernelnewbies.org/

Thanks,
Shirish
--
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 01/10] iio: core: Introduce ENERGY channel type

[Hartmut Knaack]

Irina Tirdea schrieb am 11.01.2015 um 20:10:
> Human activity sensors report the energy burnt by the user.
> One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that computes the number of calories based on weight and step rate.
> 
> Introduce a new channel type ENERGY to export these values.
> 

Hi Irina,
annoyingly, some people decided to increase the major version number of the
kernel. Could you take care of updating your introduced instances from 3.20
to 4.0?
Thanks,

Hartmut

> Signed-off-by: Irina Tirdea 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 10 ++
>  drivers/iio/industrialio-core.c |  1 +
>  include/linux/iio/types.h   |  1 +
>  3 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 831db86..3311886 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -282,6 +282,7 @@ What: 
> /sys/bus/iio/devices/iio:deviceX/in_current_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_energy_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
> @@ -1049,6 +1050,15 @@ Description:
>   For a list of available output power modes read
>   in_accel_power_mode_available.
>  
> +What:/sys/.../iio:deviceX/in_energy_input
> +What:/sys/.../iio:deviceX/in_energy_raw
> +KernelVersion:   3.20
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to read the energy value reported by the
> + device (e.g.: human activity sensors report energy burnt by the
> + user). Units after application of scale are Joules.
> +
>  What:/sys/bus/iio/devices/iio:deviceX/store_eeprom
>  KernelVersion:   3.4.0
>  Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 69feb91..8d2c9ba 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_HUMIDITYRELATIVE] = "humidityrelative",
>   [IIO_ACTIVITY] = "activity",
>   [IIO_STEPS] = "steps",
> + [IIO_ENERGY] = "energy",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 904dcbb..26b8a1c 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -32,6 +32,7 @@ enum iio_chan_type {
>   IIO_HUMIDITYRELATIVE,
>   IIO_ACTIVITY,
>   IIO_STEPS,
> + IIO_ENERGY,
>  };
>  
>  enum iio_modifier {
> 

--
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 v4 00/15] checkpatch clean-up of rtl8723au's rtw_security.c

[M. Vefa Bicakci]

On Sat, March 28, 2015 12:52:54 Joe Perches wrote:
> On Sat, 2015-03-28 at 08:52 -0400, M. Vefa Bicakci wrote:
> > These commits address a number of checkpatch.pl warnings and errors
> > in rtl8723au's rtw_security.c.
> 
> Hello.
> 
> This is one of those patchsets that should be
> done against Greg's staging-testing branch.
> 
> There are some commits against rtl8723au in that
> branch that will conflict with your patches.

Hello Joe,

Thank you for letting me know. Given the discussion arising from the 3rd 
version of the patches, I should have used (or at least checked) the 
staging-testing branch.

I rebased the commits against the staging-testing branch and corrected 
the merge conflicts. I hope to send the 5th version of the patches out 
for review soon.

Vefa

--
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: PANIC: double fault, error_code: 0x0 in 4.0.0-rc3-2, kvm related?

[Maciej W. Rozycki]

On Wed, 18 Mar 2015, Andy Lutomirski wrote:

> > I posted the same problem to the opensuse kernel list shortly before turning
> > to LKML. There, Michal Kubecek noted:
> >
> > "I encountered a similar problem recently. The thing is, x86
> > specification says that on a double fault, RIP and RSP registers are
> > undefined, i.e. you not only can't expect them to contain values
> > corresponding to the first or second fault but you can't even expect
> > them to have any usable values at all. Unfortunately the kernel double
> > fault handler doesn't take this into account and does try to display
> > usual crash related information so that it itself does usually crash
> > when trying to show stack content (that's the show_stack_log_lvl()
> > crash).
> 
> I think that's not entirely true.  RIP is reliable for many classes of
> double faults, and we rely on that for espfix64.  The fact that hpa
> was willing to write that code strongly suggests that Intel chips at
> least really do work that way.

 A #DF won't deliberately clobber the instruction or the stack pointer.  
It's only that it may happen at a stage where either or both original 
pointers have been lost and replaced with new values already, possibly 
making them inconsistent with the corresponding segment selectors too (as 
they are not written at the same time).

 This will only happen in certain degenerate corner cases such as e.g. a 
problem with TSS (#TS) in the processing of a task gate used for taking 
the original exception, where a part of the new context has already been 
loaded before #DF resulted.  Another case will be a stack segment limit 
violation (#SS), where stack has been switched in the processing of a trap 
or interrupt gate, preventing return information and error code from being 
pushed for the original exception.  These are not conditions we'd normally 
observe in Linux.

 In other cases both the original instruction and the original stack 
pointer will have been retained.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

Am 29.03.2015 um 00:44 schrieb Shirish Gajera:
> On Sat, Mar 28, 2015 at 02:35:19PM -0700, Joe Perches wrote:
>> On Sat, 2015-03-28 at 22:22 +0100, Richard Weinberger wrote:
>>> Am 28.03.2015 um 22:18 schrieb Joe Perches:
 On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  
> wrote:
>> This patch fixes the checkpatch.pl warning:
>> []
> Instead of blindly adding newlines to silence checkpatch.pl, what
> about reworking the code?
> printf("%s\n", ..) cries for a puts().

 There is no synth_puts
>>>
>>> So what?
>>> Fix it! :-)
>>
>> Not sure that'd make the code better... ;-p
>>
>>> the whole code is horrible and lines other 80 chars are the *least*
>>> problem.
>>
>> Dunno about how horrible it is, my guess is it works.
>>
>>> Submitting a patch just for the sake of silencing checkpatch.pl is a waste 
>>> of time.
>>> After applying this patch the driver 0 better than before.
>>
>> Agree with that.
>>
>> And truly, checkpatch is only a guide.
>>
>> Making the code better instead of merely style conforming
>> should be the primary goal of patches.
> 
> This is my first patch.

Are you sure?
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2015-January/013187.html

> Actually on the website it's return that 
> "Pick a warning, and try to fix it. For your first patch, only pick one
> warning. In the future you can group multiple changes into one patch,
> but only if you follow the PatchPhilosophy of breaking each patch into
> logical changes."
> 
> My main aim is to get the patch in and get familier with the full system
> (code checking,flow etc.). So, I am fixing simple warning.
> 
> If this code require changes then I can do as part of future changes.

The future is now, please address these issues now. :-)
Again, blindly fixing checkpatch.pl warnings is worthless.

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/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Shirish Gajera]

On Sat, Mar 28, 2015 at 02:35:19PM -0700, Joe Perches wrote:
> On Sat, 2015-03-28 at 22:22 +0100, Richard Weinberger wrote:
> > Am 28.03.2015 um 22:18 schrieb Joe Perches:
> > > On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
> > >> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  
> > >> wrote:
> > >>> This patch fixes the checkpatch.pl warning:
> []
> > >> Instead of blindly adding newlines to silence checkpatch.pl, what
> > >> about reworking the code?
> > >> printf("%s\n", ..) cries for a puts().
> > > 
> > > There is no synth_puts
> > 
> > So what?
> > Fix it! :-)
> 
> Not sure that'd make the code better... ;-p
> 
> > the whole code is horrible and lines other 80 chars are the *least*
> > problem.
> 
> Dunno about how horrible it is, my guess is it works.
> 
> > Submitting a patch just for the sake of silencing checkpatch.pl is a waste 
> > of time.
> > After applying this patch the driver 0 better than before.
> 
> Agree with that.
> 
> And truly, checkpatch is only a guide.
> 
> Making the code better instead of merely style conforming
> should be the primary goal of patches.

This is my first patch.

Actually on the website it's return that 
"Pick a warning, and try to fix it. For your first patch, only pick one
warning. In the future you can group multiple changes into one patch,
but only if you follow the PatchPhilosophy of breaking each patch into
logical changes."

My main aim is to get the patch in and get familier with the full system
(code checking,flow etc.). So, I am fixing simple warning.

If this code require changes then I can do as part of future changes.

Thanks,
Shirish
--
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: [rtc-linux] Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer

[Alessandro Zummo]

On Sat, 28 Mar 2015 22:29:20 +0100
Alexandre Belloni  wrote:

> I'll keep that in mind.
> Could you give me permissions on the rtc-linux patchwork?

 Sure. Let me find the way to do it :)

-- 

 Best regards,

 Alessandro Zummo - CEO,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

--
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/

Question on ARC's thread_info

[Richard Weinberger]

Vineet,

I'm working on a patch series which touches sturct thread_info.
ARC's thread_info has the following comment:
 * - if the contents of this structure are changed, the assembly constants
 *   must also be changed

Is this still true? Unless I'm reading the code wrong that case should be
handled automatically by the asm-offsets mechanism.
So no manual fixup of magic constants should be needed.

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/

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Paul Bolle]

Guenter Roeck schreef op za 28-03-2015 om 15:20 [-0700]:
> Maybe that is the plan, but it is not what is happening.
> I8K selects SENSORS_DELL_SMM, so a boolean I8K forces SENSORS_DELL_SMM
> to be built into the kernel.
> 
> What you suggest would work if I8K would depend on SENSORS_DELL_SMM,
> but then the symbols would not be backward-compatible.

I haven't actually looked into this part of the patch, since as far as
I'm concerned this patch is broken.

Having said that, if using a second Kconfig symbol is worth the effort,
perhaps there's also enough reason to break Kconfig backward
compatibility. People shouldn't alter Kconfig symbols just because they
can, but as far as I'm aware we're on the record to not guarantee
backward compatibility for Kconfig symbols.


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/

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Pali Rohár]

On Saturday 28 March 2015 23:19:04 Steven Honeyman wrote:
> On 28 March 2015 at 22:00, Pali Rohár 
> wrote:
> > On Saturday 28 March 2015 13:54:51 Steven Honeyman wrote:
> >> i8k-virtual-0
> >> Adapter: Virtual device
> >> Processor Fan: 3171 RPM
> >> CPU:+52.0°C
> >> Ambient:+46.0°C
> >> SODIMM: +40.0°C
> >> -
> >> 
> >> Ambient and SODIMM look swapped - but it's probably just
> >> another Dell error. I really need to look at getting
> >> coreboot on this thing.
> > 
> > Both patches do not change any code. So there should not be
> > any type swapped with or without my patch.
> > 
> > Cpu type is requested via SMM in same way as it is doing old
> > DOS executable. So there can be maybe problem in DELL SMM
> > handler too or maybe just I did not understand correctly
> > assembler dump of DOS executable...
> 
> Is there some way that I can find out for you? I've got a
> Windows partition somewhere, or DOS boot disk should be easy
> enough if this program works on new hardware.
> If I knew where the sensors were placed I could cool one of
> them.
> 

Maybe DOS executable is just too old... and need to use new one. 
I extracted diagnostic application from BIOS package (EFI binary 
which show temperature in BIOS) for my laptop, but decoding 
instructions of this big graphic binary is beyond my power. But 
it looks like it calls same SMM inb/outb calls, so SMM code in 
BIOS handler was not changed.

So if you want to fix this problem, next step is to disassemble 
or understand new modern EFI diag binary...

I think it would be better to locate on which bus are sensors 
connected (smbus? isa? pci?), find out HW chips and wrote native 
kernel drivers for them...

I scanned smbus (intel controller connected on pci) on my E6440 
but there is no additional/unknown device. I have no idea where 
else could be sensor device connected and accessible (from SMM or 
kernel mode).

> On 28 March 2015 at 22:04, Pali Rohár 
> wrote:
> > I think that setting CONFIG_I8K to tristate (Y/M/N) does not
> > make sense... CONFIG_I8K just control if /proc/i8k will be
> > compiled into dell-smm-hwmon or not.
> 
> Try and select dell-smm-hwmon as a module, with i8k enabled as
> well...
> 

Got it.

> On 28 March 2015 at 22:06, Paul Bolle 
> wrote:
> > On Sat, 2015-03-28 at 22:55 +0100, Pali Rohár wrote:
> >> I have tested compilation only with out of tree make
> >> command with manual CONFIG_SENSORS_DELL_SMM and CONFIG_I8K
> >> options.
> > 
> > Not sure what you mean here. I can't get things past this
> > error:
> > drivers/hwmon/Kconfig:1721: syntax error
> > drivers/hwmon/Kconfig:1720: invalid option
> 
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1705,8 +1705,8 @@
> 
>  config SENSORS_DELL_SMM
>  tristate "Dell laptop SMM BIOS hwmon driver"
> -depends ON X86
> ----help---
> +depends on X86
> +help
>This hwmon driver adds support for reporting
> temperature of different sensors and controls the fans on
> Dell laptops via System Management Mode provided by Dell
> BIOS.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Guenter Roeck]

On 03/28/2015 03:00 PM, Pali Rohár wrote:

On Saturday 28 March 2015 13:54:51 Steven Honeyman wrote:

On 28 March 2015 at 11:04, Paul Bolle 

wrote:

On Sat, 2015-03-28 at 11:24 +0100, Pali Rohár wrote:

--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1703,6 +1703,17 @@ config SENSORS_ULTRA45

 This driver provides support for the Ultra45
 workstation environmental sensors.

+config SENSORS_DELL_SMM
+ tristate "Dell laptop SMM BIOS hwmon driver"
+ depends ON X86


How did this past your testing?


+ ---help---
+   This hwmon driver adds support for reporting
temperature of different +   sensors and controls the
fans on Dell laptops via System Management +   Mode
provided by Dell BIOS.
+
+   When option I8K is also enabled this driver
provides legacy /proc/i8k +   userspace interface for
i8kutils package.
+


It's working OK for me (after fixing the mistake pointed out
above).

[Latitude e6540]
-
coretemp-isa-
Adapter: ISA adapter
Physical id 0:  +53.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0: +51.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1: +53.0°C  (high = +84.0°C, crit = +100.0°C)

i8k-virtual-0
Adapter: Virtual device
Processor Fan: 3171 RPM
CPU:+52.0°C
Ambient:+46.0°C
SODIMM: +40.0°C
-

Ambient and SODIMM look swapped - but it's probably just
another Dell error. I really need to look at getting coreboot
on this thing.



Both patches do not change any code. So there should not be any
type swapped with or without my patch.

Cpu type is requested via SMM in same way as it is doing old DOS
executable. So there can be maybe problem in DELL SMM handler too
or maybe just I did not understand correctly assembler dump of
DOS executable...


On 28 March 2015 at 10:24, Pali Rohár 
wrote: ...


  config I8K

-   tristate "Dell laptop support"
-   select HWMON
+   bool "Dell i8k legacy laptop support"
+   select SENSORS_DELL_SMM


...


+config SENSORS_DELL_SMM
+   tristate "Dell laptop SMM BIOS hwmon driver"


The only change I'd suggest is not to change the tristate to
bool for I8K. Forcing that to bool means that
SENSORS_DELL_SMM can't be compiled as a module if the user
wishes to keep i8k hanging around "just in case". It'll
probably annoy distro kernel packagers too.


Thanks,
Steven


My idea was:

SENSORS_DELL_SMM enable/disable compilation of kernel driver
(ether statically link into kernel image or as external module)

CONFIG_I8K just enable /proc/i8k code in SENSORS_DELL_SMM -- no
additional driver, just boolean switch which has effect only iff
SENSORS_DELL_SMM is Y or M



Maybe that is the plan, but it is not what is happening.
I8K selects SENSORS_DELL_SMM, so a boolean I8K forces SENSORS_DELL_SMM
to be built into the kernel.

What you suggest would work if I8K would depend on SENSORS_DELL_SMM,
but then the symbols would not be backward-compatible.

Guenter

--
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] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Steven Honeyman]

On 28 March 2015 at 22:00, Pali Rohár  wrote:
> On Saturday 28 March 2015 13:54:51 Steven Honeyman wrote:
>> i8k-virtual-0
>> Adapter: Virtual device
>> Processor Fan: 3171 RPM
>> CPU:+52.0°C
>> Ambient:+46.0°C
>> SODIMM: +40.0°C
>> -
>>
>> Ambient and SODIMM look swapped - but it's probably just
>> another Dell error. I really need to look at getting coreboot
>> on this thing.
>>
>
> Both patches do not change any code. So there should not be any
> type swapped with or without my patch.
>
> Cpu type is requested via SMM in same way as it is doing old DOS
> executable. So there can be maybe problem in DELL SMM handler too
> or maybe just I did not understand correctly assembler dump of
> DOS executable...
>

Is there some way that I can find out for you? I've got a Windows
partition somewhere, or DOS boot disk should be easy enough if this
program works on new hardware.
If I knew where the sensors were placed I could cool one of them.


On 28 March 2015 at 22:04, Pali Rohár  wrote:
> I think that setting CONFIG_I8K to tristate (Y/M/N) does not make
> sense... CONFIG_I8K just control if /proc/i8k will be compiled
> into dell-smm-hwmon or not.

Try and select dell-smm-hwmon as a module, with i8k enabled as well...


On 28 March 2015 at 22:06, Paul Bolle  wrote:
> On Sat, 2015-03-28 at 22:55 +0100, Pali Rohár wrote:
>> I have tested compilation only with out of tree make command with
>> manual CONFIG_SENSORS_DELL_SMM and CONFIG_I8K options.
>
> Not sure what you mean here. I can't get things past this error:
> drivers/hwmon/Kconfig:1721: syntax error
> drivers/hwmon/Kconfig:1720: invalid option

--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1705,8 +1705,8 @@

 config SENSORS_DELL_SMM
 tristate "Dell laptop SMM BIOS hwmon driver"
-depends ON X86
----help---
+depends on X86
+help
   This hwmon driver adds support for reporting temperature of different
   sensors and controls the fans on Dell laptops via System Management
   Mode provided by Dell BIOS.
--
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] bpf: Suggestion on bpf syscall interface

[Daniel Borkmann]

On 03/28/2015 06:21 PM, Alexei Starovoitov wrote:

On 3/28/15 4:36 AM, He Kuang wrote:

Hi, Alexei

In our end-end IO module project, we use bpf maps to record
configurations. According to current bpf syscall interface, we
should specify map_fd to lookup/update bpf maps, so we are
restricted to do config in the same user program.


you can pass map_fd and prog_fd from one process to another via normal
scm_rights mechanism.


+1, I've just tried that out in the context of a different work and
works like a charm.


My suggestion is to export this kind of operations to sysfs, so
we can load bpf progs and config it seperately. We
implement this feature in our demo project. What's your opinion
on this?


Eventually we may use single sysfs file for lsmod-like listings, but I
definitely don't want to create parallel interface to maps via sysfs.


Yes, that would be a bad design decision. Btw, even more lightweight
for kernel-side would be to just implement .show_fdinfo() for the anon
indoes on the map/prog store and have some meta information exported
from there. You can then grab that via /proc//fdinfo/, I
would consider such a thing a slow-path operation anyway, and you would
also get the app info using it for free.


It's way too expensive and not really suitable for binary key/values.


+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/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Paul Bolle]

On Sat, 2015-03-28 at 22:55 +0100, Pali Rohár wrote:
> I have tested compilation only with out of tree make command with 
> manual CONFIG_SENSORS_DELL_SMM and CONFIG_I8K options.

Not sure what you mean here. I can't get things past this error:
drivers/hwmon/Kconfig:1721: syntax error
drivers/hwmon/Kconfig:1720: invalid option
make[1]: *** [oldconfig] Error 1
make: *** [oldconfig] Error 2

Thanks,


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/

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Pali Rohár]

On Saturday 28 March 2015 15:23:15 Guenter Roeck wrote:
> > +   ---help---
> > + This hwmon driver adds support for reporting temperature
> > of different +sensors and controls the fans on Dell
> > laptops via System Management +   Mode provided by Dell
> > BIOS.
> > +
> > + When option I8K is also enabled this driver provides
> > legacy /proc/i8k +userspace interface for i8kutils
> > package.
> > +
> 
> Please add this in alphabetic order.
> 

ok

> >   if ACPI
> >   
> >   comment "ACPI drivers"
> > 
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index 1c3e458..9eec614 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -155,7 +155,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) +=
> > w83l785ts.o
> > 
> >   obj-$(CONFIG_SENSORS_W83L786NG)   += w83l786ng.o
> >   obj-$(CONFIG_SENSORS_WM831X)  += wm831x-hwmon.o
> >   obj-$(CONFIG_SENSORS_WM8350)  += wm8350-hwmon.o
> > 
> > -obj-$(CONFIG_I8K)  += dell-smm-hwmon.o
> > +obj-$(CONFIG_SENSORS_DELL_SMM) += dell-smm-hwmon.o
> 
> Same here.
> 

ok

> > -   proc_i8k = proc_create("i8k", 0, NULL, _fops);
> > -   if (!proc_i8k)
> > +   if (!proc_create("i8k", 0, NULL, _fops))
> > 
> > return -ENOENT;
> 
> I would prefer not to fail here but report a warning.
> This is no longer a fatal condition.
> 

ok, no problem

> 
> Can you move all the conditional functions and global
> variables together under a single #ifdef ? That should
> include functions to create the proc entries, and shim
> functions for the same if I8K is not configured.
> 

ok, I will move procfs code to one location.

> Also, the #ifdef would not cover the case where I8K is
> configured as module (there is no reason to force it to
> bool). You should use "#if IS_ENABLED(CONFIG_I8K)" instead.
> 

I think that setting CONFIG_I8K to tristate (Y/M/N) does not make 
sense... CONFIG_I8K just control if /proc/i8k will be compiled 
into dell-smm-hwmon or not.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Pali Rohár]

On Saturday 28 March 2015 13:54:51 Steven Honeyman wrote:
> On 28 March 2015 at 11:04, Paul Bolle  
wrote:
> > On Sat, 2015-03-28 at 11:24 +0100, Pali Rohár wrote:
> >> --- a/drivers/hwmon/Kconfig
> >> +++ b/drivers/hwmon/Kconfig
> >> @@ -1703,6 +1703,17 @@ config SENSORS_ULTRA45
> >> 
> >> This driver provides support for the Ultra45
> >> workstation environmental sensors.
> >> 
> >> +config SENSORS_DELL_SMM
> >> + tristate "Dell laptop SMM BIOS hwmon driver"
> >> + depends ON X86
> > 
> > How did this past your testing?
> > 
> >> + ---help---
> >> +   This hwmon driver adds support for reporting
> >> temperature of different +   sensors and controls the
> >> fans on Dell laptops via System Management +   Mode
> >> provided by Dell BIOS.
> >> +
> >> +   When option I8K is also enabled this driver
> >> provides legacy /proc/i8k +   userspace interface for
> >> i8kutils package.
> >> +
> 
> It's working OK for me (after fixing the mistake pointed out
> above).
> 
> [Latitude e6540]
> -
> coretemp-isa-
> Adapter: ISA adapter
> Physical id 0:  +53.0°C  (high = +84.0°C, crit = +100.0°C)
> Core 0: +51.0°C  (high = +84.0°C, crit = +100.0°C)
> Core 1: +53.0°C  (high = +84.0°C, crit = +100.0°C)
> 
> i8k-virtual-0
> Adapter: Virtual device
> Processor Fan: 3171 RPM
> CPU:+52.0°C
> Ambient:+46.0°C
> SODIMM: +40.0°C
> -
> 
> Ambient and SODIMM look swapped - but it's probably just
> another Dell error. I really need to look at getting coreboot
> on this thing.
> 

Both patches do not change any code. So there should not be any 
type swapped with or without my patch.

Cpu type is requested via SMM in same way as it is doing old DOS 
executable. So there can be maybe problem in DELL SMM handler too 
or maybe just I did not understand correctly assembler dump of 
DOS executable...

> On 28 March 2015 at 10:24, Pali Rohár 
> wrote: ...
> 
> >  config I8K
> > 
> > -   tristate "Dell laptop support"
> > -   select HWMON
> > +   bool "Dell i8k legacy laptop support"
> > +   select SENSORS_DELL_SMM
> 
> ...
> 
> > +config SENSORS_DELL_SMM
> > +   tristate "Dell laptop SMM BIOS hwmon driver"
> 
> The only change I'd suggest is not to change the tristate to
> bool for I8K. Forcing that to bool means that
> SENSORS_DELL_SMM can't be compiled as a module if the user
> wishes to keep i8k hanging around "just in case". It'll
> probably annoy distro kernel packagers too.
> 
> 
> Thanks,
> Steven

My idea was:

SENSORS_DELL_SMM enable/disable compilation of kernel driver 
(ether statically link into kernel image or as external module)

CONFIG_I8K just enable /proc/i8k code in SENSORS_DELL_SMM -- no 
additional driver, just boolean switch which has effect only iff 
SENSORS_DELL_SMM is Y or M

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Pali Rohár]

On Saturday 28 March 2015 12:04:20 Paul Bolle wrote:
> On Sat, 2015-03-28 at 11:24 +0100, Pali Rohár wrote:
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1703,6 +1703,17 @@ config SENSORS_ULTRA45
> > 
> >   This driver provides support for the Ultra45 workstation
> >   environmental sensors.
> > 
> > +config SENSORS_DELL_SMM
> > +   tristate "Dell laptop SMM BIOS hwmon driver"
> > +   depends ON X86
> 
> How did this past your testing?
> 

Hello,

I have tested compilation only with out of tree make command with 
manual CONFIG_SENSORS_DELL_SMM and CONFIG_I8K options.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 3/5] dmaengine: bcm2835-dma: Fix memory leak when stopping a running transfer

[Peter Ujfalusi]

Thanks,

On 03/28/2015 05:57 AM, Stephen Warren wrote:
> On 03/27/2015 05:35 AM, Peter Ujfalusi wrote:
>> The vd->node is removed from the lists when the transfer started so the
>> vchan_get_all_descriptors() will not find it. This results memory leak.
> 
> Acked-by: Stephen Warren 
> (I'm just assuming the explanation makes sense and is correct; more of a
> not-a-NAK so it doesn't look like a lack of response!)

I can not debug the bcm2835-dma driver, but the exact same pattern existed in
edma and omap-dma driver and they both leaked the edesc in a same predictable
fashion. I just checked the virt-dma users and sent the fixes for the ones
which had the same flow of events.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Joe Perches]

On Sat, 2015-03-28 at 22:22 +0100, Richard Weinberger wrote:
> Am 28.03.2015 um 22:18 schrieb Joe Perches:
> > On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
> >> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  
> >> wrote:
> >>> This patch fixes the checkpatch.pl warning:
[]
> >> Instead of blindly adding newlines to silence checkpatch.pl, what
> >> about reworking the code?
> >> printf("%s\n", ..) cries for a puts().
> > 
> > There is no synth_puts
> 
> So what?
> Fix it! :-)

Not sure that'd make the code better... ;-p

> the whole code is horrible and lines other 80 chars are the *least*
> problem.

Dunno about how horrible it is, my guess is it works.

> Submitting a patch just for the sake of silencing checkpatch.pl is a waste of 
> time.
> After applying this patch the driver 0 better than before.

Agree with that.

And truly, checkpatch is only a guide.

Making the code better instead of merely style conforming
should be the primary goal of patches.

--
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: [rtc-linux] Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer

[Alexandre Belloni]

Hi Alessandro,

On 25/03/2015 at 23:58:09 +0100, Alessandro Zummo wrote :
>  A few things I consider important:
> 
>  - a driver for a new hardware usually causes no harm to the subsystem
> 
>  - a patch for an existing driver should be approved by the original author,
>  if possible. there are a few chips out there that are quite rare or
>  have multiple wiring configuration and break very easily.
> 

I'll keep that in mind.

Could you give me permissions on the rtc-linux patchwork?

thanks!

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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] staging: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

Am 28.03.2015 um 22:18 schrieb Joe Perches:
> On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
>> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  
>> wrote:
>>> This patch fixes the checkpatch.pl warning:
> 
> []
> 
>>> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> []
>>> @@ -423,7 +423,8 @@ static void announce_edge(struct vc_data *vc, int 
>>> msg_id)
>>> if (spk_bleeps & 1)
>>> bleep(spk_y);
>>> if ((spk_bleeps & 2) && (msg_id < edge_quiet))
>>> -   synth_printf("%s\n", spk_msg_get(MSG_EDGE_MSGS_START + 
>>> msg_id - 1));
>>> +   synth_printf("%s\n",
>>> +   spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 1));
>>
>> Instead of blindly adding newlines to silence checkpatch.pl, what
>> about reworking the code?
>> printf("%s\n", ..) cries for a puts().
> 
> There is no synth_puts

So what?
Fix it! :-)

>>> @@ -1131,7 +1132,8 @@ static void spkup_write(const char *in_buf, int count)
>>> if (in_count > 2 && rep_count > 2) {
>>> if (last_type & CH_RPT) {
>>> synth_printf(" ");
>>> -   synth_printf(spk_msg_get(MSG_REPEAT_DESC2), 
>>> ++rep_count);
>>> +   synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
>>> +   ++rep_count);
>>> synth_printf(" ");
>>
>> This printf stuff looks odd. synth_printf() seems to take a format
>> string, in this case the format string
>> is returned by spk_msg_get(), smells like a format string bug.
> 
> Nope, but it would be nicer to avoid these spk_msg_get
> functions for the indices that are used with printf style
> formatting.
> 
>>> }
>>> rep_count = 0;
>>> @@ -1847,7 +1849,8 @@ static void speakup_win_set(struct vc_data *vc)
>>> win_right = spk_x;
>>> }
>>> snprintf(info, sizeof(info), 
>>> spk_msg_get(MSG_WINDOW_BOUNDARY),
>>> -(win_start) ? spk_msg_get(MSG_END) : 
>>> spk_msg_get(MSG_START),
>>> +(win_start) ?
>>> +   spk_msg_get(MSG_END) : 
>>> spk_msg_get(MSG_START),
>>>  (int)spk_y + 1, (int)spk_x + 1);
>>
>> Same here. Also please resolve the ?: mess.
> 
> I don't think there's a ?: mess, but the code looks wrong.  
> 
>   win_start ? MSG_END : MSG_START

Face it, the whole code is horrible and lines other 80 chars are the *least*
problem.
Submitting a patch just for the sake of silencing checkpatch.pl is a waste of 
time.
After applying this patch the driver 0 better than before.

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/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Joe Perches]

On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  
> wrote:
> > This patch fixes the checkpatch.pl warning:

[]

> > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
[]
> > @@ -423,7 +423,8 @@ static void announce_edge(struct vc_data *vc, int 
> > msg_id)
> > if (spk_bleeps & 1)
> > bleep(spk_y);
> > if ((spk_bleeps & 2) && (msg_id < edge_quiet))
> > -   synth_printf("%s\n", spk_msg_get(MSG_EDGE_MSGS_START + 
> > msg_id - 1));
> > +   synth_printf("%s\n",
> > +   spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 1));
> 
> Instead of blindly adding newlines to silence checkpatch.pl, what
> about reworking the code?
> printf("%s\n", ..) cries for a puts().

There is no synth_puts

> > @@ -1131,7 +1132,8 @@ static void spkup_write(const char *in_buf, int count)
> > if (in_count > 2 && rep_count > 2) {
> > if (last_type & CH_RPT) {
> > synth_printf(" ");
> > -   synth_printf(spk_msg_get(MSG_REPEAT_DESC2), 
> > ++rep_count);
> > +   synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
> > +   ++rep_count);
> > synth_printf(" ");
> 
> This printf stuff looks odd. synth_printf() seems to take a format
> string, in this case the format string
> is returned by spk_msg_get(), smells like a format string bug.

Nope, but it would be nicer to avoid these spk_msg_get
functions for the indices that are used with printf style
formatting.

> > }
> > rep_count = 0;
> > @@ -1847,7 +1849,8 @@ static void speakup_win_set(struct vc_data *vc)
> > win_right = spk_x;
> > }
> > snprintf(info, sizeof(info), 
> > spk_msg_get(MSG_WINDOW_BOUNDARY),
> > -(win_start) ? spk_msg_get(MSG_END) : 
> > spk_msg_get(MSG_START),
> > +(win_start) ?
> > +   spk_msg_get(MSG_END) : 
> > spk_msg_get(MSG_START),
> >  (int)spk_y + 1, (int)spk_x + 1);
> 
> Same here. Also please resolve the ?: mess.

I don't think there's a ?: mess, but the code looks wrong.  

win_start ? MSG_END : MSG_START

sure looks backwards.


--
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 PATCH 00/11] an introduction of library operating system for Linux (LibOS)

[Richard Weinberger]

Am 27.03.2015 um 16:17 schrieb Antti Kantee:
> Let me try to offer some insight.  I've been working on something similar in 
> mainline NetBSD for almost 8 years now, so in addition to ideas popping into 
> my head I've also tested
> them out in the real world.  I do think that all operating systems should be 
> structured to support a lib mode, and hopefully integrating Hajime's work 
> into Linux will get on the
> right track.

IMHO it depends on the maintenance burden.
Linux source changes magnitudes faster than NetBSD's.

>> What about putting libos into tools/testing/ and make it much more generic 
>> and framework alike.
>> With more generic I mean that libos could be a stubbing framework for the 
>> kernel.
>> i.e. you specify the subsystem you want to test/stub and the framework helps 
>> you doing so.
>> A lot of the stubs you're placing in arch/lib could be auto-generated as the
>> vast majority of all kernel methods you stub are no-ops which call only 
>> lib_assert(false).
>>
>> Using that approach only very few kernel core components have to be 
>> duplicated and
>> actually implemented by hand.
>> Hence, less maintenance overhead and libos is not broken all the time.
> 
> Stubbing things might be the way to get things initially rolling, but you 
> don't want to aim for that or spend energy on fancy ways to do it. 
> Autogenerating stubs only means that
> the libos will build, not that it won't be broken.  Figuring out how to make 
> the libos as close to zero-maintenance as possible is indeed the trick.
> 
> What I ended up doing is coining the term "anykernel architecture", which 
> simply means that in addition to the monolithic architecture, the kernel can 
> now be used as in exokernel,
> microkernel, multikernel, etc. (which are really just different frontends for 
> the lib mode).  I'd recommend diving head-first into the issue and thinking 
> "how can we adjust the
> kernel architecture to support the libos mode" instead of "how can we tip-toe 
> around the kernel and invent clever ways to stub things".  The anykernel is 
> not really that different
> from a monolithic kernel once you figure out which bits are important, and 
> support will not require a whole lot of "duplicated" code.  There are 
> practically no stubs in the NetBSD
> implementation; somewhere between 0 and 20 depending on what you count as a 
> stub.  There is a few thousand lines of "duplicated" code, the majority of 
> which is a direct result of
> the rump kernel (which is the name of the libos mode) running on top of an 
> external thread scheduler, so that code from the monolithic kernel doesn't 
> apply.

I agree that this would be nice but without actual patches I'm very doubtful.

> Continuous testing is paramount.  Running the kernel as a lib provides an 
> unparalleled method for testing most of the kernel.  It will improve testing 
> capabilities dramatically,
> and on the flipside it will keep the libos working.  Everyone wins.

If it can be done cheap, yes. But our in-kernel tests improved over the years a 
lot.
Now have lockdep, KASan, kmemleak, etc. to find *real-world* issues and the 
need for stubbed testing
decreases.

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/

[PATCH 2/3] rtc: __rtc_read_time: reduce log level

[Aaro Koskinen]

__rtc_read_time logs should be debug logs instead of error logs.

For example, when the RTC clock is not set, it's not really useful
to print a kernel error log every time someone tries to read the clock:

~ # hwclock -r
[  604.508263] rtc rtc0: read_time: fail to read
hwclock: RTC_RD_TIME: Invalid argument

If there's a real error, it's likely that lower level or higher level
code will tell it anyway. Make these logs debug logs, and also print
the error code for the read failure.

Signed-off-by: Aaro Koskinen 
---
 drivers/rtc/interface.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 37215cf..c786818 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -31,13 +31,14 @@ static int __rtc_read_time(struct rtc_device *rtc, struct 
rtc_time *tm)
memset(tm, 0, sizeof(struct rtc_time));
err = rtc->ops->read_time(rtc->dev.parent, tm);
if (err < 0) {
-   dev_err(>dev, "read_time: fail to read\n");
+   dev_dbg(>dev, "read_time: fail to read: %d\n",
+   err);
return err;
}
 
err = rtc_valid_tm(tm);
if (err < 0)
-   dev_err(>dev, "read_time: rtc_time isn't valid\n");
+   dev_dbg(>dev, "read_time: rtc_time isn't valid\n");
}
return err;
 }
-- 
2.2.0

--
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/3] rtc: hctosys: use function name in the error log

[Aaro Koskinen]

Use function name in the error log instead of __FILE__.

Signed-off-by: Aaro Koskinen 
---
 drivers/rtc/hctosys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 6c719f2..7748a61 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -33,7 +33,7 @@ static int __init rtc_hctosys(void)
 
if (rtc == NULL) {
pr_err("%s: unable to open rtc device (%s)\n",
-   __FILE__, CONFIG_RTC_HCTOSYS_DEVICE);
+   __func__, CONFIG_RTC_HCTOSYS_DEVICE);
goto err_open;
}
 
-- 
2.2.0

--
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 1/3] rtc: initialize rtc name early

[Aaro Koskinen]

In some error cases RTC name is used before it is initialized:

rtc-rs5c372 0-0032: clock needs to be set
rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.6
rtc (null): read_time: fail to read
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

Fix by initializing the name early.

Signed-off-by: Aaro Koskinen 
---
 drivers/rtc/class.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 472a5ad..014ecbc 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -225,15 +225,15 @@ struct rtc_device *rtc_device_register(const char *name, 
struct device *dev,
rtc->pie_timer.function = rtc_pie_update_irq;
rtc->pie_enabled = 0;
 
+   strlcpy(rtc->name, name, RTC_DEVICE_NAME_SIZE);
+   dev_set_name(>dev, "rtc%d", id);
+
/* Check to see if there is an ALARM already set in hw */
err = __rtc_read_alarm(rtc, );
 
if (!err && !rtc_valid_tm())
rtc_initialize_alarm(rtc, );
 
-   strlcpy(rtc->name, name, RTC_DEVICE_NAME_SIZE);
-   dev_set_name(>dev, "rtc%d", id);
-
rtc_dev_prepare(rtc);
 
err = device_register(>dev);
-- 
2.2.0

--
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/

alx: Wake-on-LAN with Qualcomm Atheros QCA8171

[MegaBrutal]

Hi Johannes,

I have an ASRock B85M motherboard with Qualcomm Atheros QCA8171 NIC.

In dmesg, I see the NIC is claimed by your alx driver:
[0.530351] alx :04:00.0 eth0: Qualcomm Atheros AR816x/AR817x
Ethernet [xx:xx:xx:xx:xx:xx]

In lspci, the NIC shows up like this:
04:00.0 Ethernet controller: Qualcomm Atheros QCA8171 Gigabit Ethernet (rev 10)

While the motherboard manufacturer advertises the board supports
Wake-on-LAN, and I enabled it in BIOS, I can't activate it with
ethtool.

See what happens when I try:


root@vmhost:~# ethtool p3p1
Settings for p3p1:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes:  Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Current message level: 0x60e4 (24804)
   link ifup rx_err tx_err hw wol
Link detected: yes


root@vmhost:~# ethtool -s p3p1 wol g
Cannot get current wake-on-lan settings: Operation not supported
  not setting wol


I'm wondering if it's because of the driver. I see alx is a relatively
new driver, and probably WOL support is not yet implemented. I'd like
to know if this is the case, or otherwise what might be the reason why
I can't use the Wake-on-LAN feature?

Thanks for your help in advance!


Regards,
MegaBrutal
--
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 0/3] mfd: menelaus: couple simple cleanups

[Aaro Koskinen]

Hi,

I came across these while trying to start DT conversion for menelaus
(http://marc.info/?t=14197028735=1=2).

While the DT work failed and is still pending, I think it's still worth
to apply these as they are independent and they remove some cruft
from the tree.

A.

Aaro Koskinen (3):
  mfd: menelaus: delete omap_has_menelaus
  mfd: menelaus: drop support for SW controller VCORE
  mfd: menelaus: use macro for magic number

 drivers/mfd/menelaus.c   | 25 +
 include/linux/mfd/menelaus.h |  7 ---
 2 files changed, 1 insertion(+), 31 deletions(-)

-- 
2.2.0

--
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 1/3] mfd: menelaus: delete omap_has_menelaus

[Aaro Koskinen]

Delete unused macro.

Signed-off-by: Aaro Koskinen 
---
 include/linux/mfd/menelaus.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index f097e89..a1e12bf3 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -38,10 +38,4 @@ extern int menelaus_set_vcore_hw(unsigned int roof_mV, 
unsigned int floor_mV);
 
 extern int menelaus_set_regulator_sleep(int enable, u32 val);
 
-#if defined(CONFIG_ARCH_OMAP2) && defined(CONFIG_MENELAUS)
-#define omap_has_menelaus()1
-#else
-#define omap_has_menelaus()0
-#endif
-
 #endif
-- 
2.2.0

--
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/3] mfd: menelaus: use macro for magic number

[Aaro Koskinen]

Use macro to check a register bit.

Signed-off-by: Aaro Koskinen 
---
 drivers/mfd/menelaus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 917fa86..c2ca665 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1216,7 +1216,7 @@ static int menelaus_probe(struct i2c_client *client,
err = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (err < 0)
goto fail;
-   if (err & BIT(7))
+   if (err & VCORE_CTRL1_HW_NSW)
menelaus->vcore_hw_mode = 1;
else
menelaus->vcore_hw_mode = 0;
-- 
2.2.0

--
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 2/3] mfd: menelaus: drop support for SW controller VCORE

[Aaro Koskinen]

Drop support for SW controlled VCORE, nobody uses it.

Signed-off-by: Aaro Koskinen 
---
 drivers/mfd/menelaus.c   | 23 ---
 include/linux/mfd/menelaus.h |  1 -
 2 files changed, 24 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9f01aef..917fa86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -532,29 +532,6 @@ static const struct menelaus_vtg_value vcore_values[] = {
{ 1450, 18 },
 };
 
-int menelaus_set_vcore_sw(unsigned int mV)
-{
-   int val, ret;
-   struct i2c_client *c = the_menelaus->client;
-
-   val = menelaus_get_vtg_value(mV, vcore_values,
-ARRAY_SIZE(vcore_values));
-   if (val < 0)
-   return -EINVAL;
-
-   dev_dbg(>dev, "Setting VCORE to %d mV (val 0x%02x)\n", mV, val);
-
-   /* Set SW mode and the voltage in one go. */
-   mutex_lock(_menelaus->lock);
-   ret = menelaus_write_reg(MENELAUS_VCORE_CTRL1, val);
-   if (ret == 0)
-   the_menelaus->vcore_hw_mode = 0;
-   mutex_unlock(_menelaus->lock);
-   msleep(1);
-
-   return ret;
-}
-
 int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
 {
int fval, rval, val, ret;
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index a1e12bf3..9e85ac0 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -24,7 +24,6 @@ extern int menelaus_set_vaux(unsigned int mV);
 extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
 extern int menelaus_set_slot_sel(int enable);
 extern int menelaus_get_slot_pin_states(void);
-extern int menelaus_set_vcore_sw(unsigned int mV);
 extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV);
 
 #define EN_VPLL_SLEEP  (1 << 7)
-- 
2.2.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera  wrote:
> This patch fixes the checkpatch.pl warning:
> WARNING: line over 80 characters
>
> All line over 80 characters in driver/staging/speakup/* are fixed.
>
> Signed-off-by: Shirish Gajera 
> ---
>  drivers/staging/speakup/main.c   | 9 ++---
>  drivers/staging/speakup/serialio.h   | 3 ++-
>  drivers/staging/speakup/speakup.h| 6 --
>  drivers/staging/speakup/speakup_decext.c | 6 --
>  drivers/staging/speakup/speakup_decpc.c  | 6 --
>  drivers/staging/speakup/spk_types.h  | 3 ++-
>  6 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 1249f91..c955976 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -423,7 +423,8 @@ static void announce_edge(struct vc_data *vc, int msg_id)
> if (spk_bleeps & 1)
> bleep(spk_y);
> if ((spk_bleeps & 2) && (msg_id < edge_quiet))
> -   synth_printf("%s\n", spk_msg_get(MSG_EDGE_MSGS_START + msg_id 
> - 1));
> +   synth_printf("%s\n",
> +   spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 1));

Instead of blindly adding newlines to silence checkpatch.pl, what
about reworking the code?
printf("%s\n", ..) cries for a puts().

>  }
>
>  static void speak_char(u_char ch)
> @@ -1131,7 +1132,8 @@ static void spkup_write(const char *in_buf, int count)
> if (in_count > 2 && rep_count > 2) {
> if (last_type & CH_RPT) {
> synth_printf(" ");
> -   synth_printf(spk_msg_get(MSG_REPEAT_DESC2), 
> ++rep_count);
> +   synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
> +   ++rep_count);
> synth_printf(" ");

This printf stuff looks odd. synth_printf() seems to take a format
string, in this case the format string
is returned by spk_msg_get(), smells like a format string bug.

> }
> rep_count = 0;
> @@ -1847,7 +1849,8 @@ static void speakup_win_set(struct vc_data *vc)
> win_right = spk_x;
> }
> snprintf(info, sizeof(info), spk_msg_get(MSG_WINDOW_BOUNDARY),
> -(win_start) ? spk_msg_get(MSG_END) : 
> spk_msg_get(MSG_START),
> +(win_start) ?
> +   spk_msg_get(MSG_END) : spk_msg_get(MSG_START),
>  (int)spk_y + 1, (int)spk_x + 1);

Same here. Also please resolve the ?: mess.

> }
> synth_printf("%s\n", info);
> diff --git a/drivers/staging/speakup/serialio.h 
> b/drivers/staging/speakup/serialio.h
> index 317bb84..1b39921 100644
> --- a/drivers/staging/speakup/serialio.h
> +++ b/drivers/staging/speakup/serialio.h
> @@ -34,6 +34,7 @@ struct old_serial_port {
>  #define SPK_TIMEOUT 100
>  #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
>
> -#define spk_serial_tx_busy() ((inb(speakup_info.port_tts + UART_LSR) & 
> BOTH_EMPTY) != BOTH_EMPTY)
> +#define spk_serial_tx_busy() \
> +   ((inb(speakup_info.port_tts + UART_LSR) & BOTH_EMPTY) != BOTH_EMPTY)

This makro is ugly in many ways.
Why can't this be an static inline function without a dependency on
global state?

>
>  #endif
> diff --git a/drivers/staging/speakup/speakup.h 
> b/drivers/staging/speakup/speakup.h
> index 898dce5..a7f4962 100644
> --- a/drivers/staging/speakup/speakup.h
> +++ b/drivers/staging/speakup/speakup.h
> @@ -61,10 +61,12 @@ extern struct st_var_header *spk_get_var_header(enum 
> var_id_t var_id);
>  extern struct st_var_header *spk_var_header_by_name(const char *name);
>  extern struct punc_var_t *spk_get_punc_var(enum var_id_t var_id);
>  extern int spk_set_num_var(int val, struct st_var_header *var, int how);
> -extern int spk_set_string_var(const char *page, struct st_var_header *var, 
> int len);
> +extern int spk_set_string_var(const char *page, struct st_var_header *var,
> +   int len);
>  extern int spk_set_mask_bits(const char *input, const int which, const int 
> how);
>  extern special_func spk_special_handler;
> -extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch, 
> u_short key);
> +extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch,
> +   u_short key);
>  extern int synth_init(char *name);
>  extern void synth_release(void);
>
> diff --git a/drivers/staging/speakup/speakup_decext.c 
> b/drivers/staging/speakup/speakup_decext.c
> index 2b772f8..e0b5db9 100644
> --- a/drivers/staging/speakup/speakup_decext.c
> +++ b/drivers/staging/speakup/speakup_decext.c
> @@ -207,10 +207,12 @@ static void do_catch_up(struct spk_synth *synth)
> if (time_after_eq(jiffies, jiff_max)) {
> if (!in_escape)
> 

Re: d63e2e1f3df breaks sparc/T5-8

[Yinghai Lu]

On Sat, Mar 28, 2015 at 7:48 AM, David Ahern  wrote:
> On 3/27/15 11:26 PM, Yinghai Lu wrote:
>>

>>
>> looks like the offset for mem64 is not right.
>>
>> Please try attached v2.

still have problem.

[139295.760918] pci_sun4v f02dbcfc: PCI host bridge to bus :00
[139295.831448] pci_bus :00: root bus resource [io
0x8040-0x80400fff] (bus address [0x-0xfff])
[139295.958623] pci_bus :00: root bus resource [mem
0x8000-0x80007eff] (bus address [0x-0x7eff])
[139296.091392] pci_bus :00: root bus resource [mem
0x8001-0x8007] (bus address [0x1-0x7])
[139296.225779] pci_bus :00: root bus resource [bus 00-77]
...
[139298.092814] pci :05:00.0: can't claim BAR 0 [mem
0x8001-0x80011fff]: no compatible bridge window
[139298.215949] pci :06:00.0: can't claim BAR 7 [mem
0x800110204000-0x800110303fff 64bit]: no compatible bridge window
[139298.346479] pci :06:00.0: can't claim BAR 10 [mem
0x800110304000-0x800110403fff 64bit]: no compatible bridge window
[139298.476953] pci :06:00.1: can't claim BAR 7 [mem
0x800110408000-0x800110507fff 64bit]: no compatible bridge window
[139298.607105] pci :06:00.1: can't claim BAR 10 [mem
0x80011080-0x8001108f 64bit]: no compatible bridge window
[139298.739341] pci :07:00.0: can't claim BAR 1 [mem
0x80012000-0x80012000]: no compatible bridge window
[139298.862467] pci :07:00.0: can't claim BAR 3 [mem
0x80012004-0x80012007]: no compatible bridge window

Can you append "ofpci_debug=1" in boot command line?

So we can check if the bridge get 64 bus from the of layer.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: speakup: Fix warning of line over 80 characters.

[Shirish Gajera]

This patch fixes the checkpatch.pl warning:
WARNING: line over 80 characters

All line over 80 characters in driver/staging/speakup/* are fixed.

Signed-off-by: Shirish Gajera 
---
 drivers/staging/speakup/main.c   | 9 ++---
 drivers/staging/speakup/serialio.h   | 3 ++-
 drivers/staging/speakup/speakup.h| 6 --
 drivers/staging/speakup/speakup_decext.c | 6 --
 drivers/staging/speakup/speakup_decpc.c  | 6 --
 drivers/staging/speakup/spk_types.h  | 3 ++-
 6 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 1249f91..c955976 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -423,7 +423,8 @@ static void announce_edge(struct vc_data *vc, int msg_id)
if (spk_bleeps & 1)
bleep(spk_y);
if ((spk_bleeps & 2) && (msg_id < edge_quiet))
-   synth_printf("%s\n", spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 
1));
+   synth_printf("%s\n",
+   spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 1));
 }
 
 static void speak_char(u_char ch)
@@ -1131,7 +1132,8 @@ static void spkup_write(const char *in_buf, int count)
if (in_count > 2 && rep_count > 2) {
if (last_type & CH_RPT) {
synth_printf(" ");
-   synth_printf(spk_msg_get(MSG_REPEAT_DESC2), 
++rep_count);
+   synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
+   ++rep_count);
synth_printf(" ");
}
rep_count = 0;
@@ -1847,7 +1849,8 @@ static void speakup_win_set(struct vc_data *vc)
win_right = spk_x;
}
snprintf(info, sizeof(info), spk_msg_get(MSG_WINDOW_BOUNDARY),
-(win_start) ? spk_msg_get(MSG_END) : 
spk_msg_get(MSG_START),
+(win_start) ?
+   spk_msg_get(MSG_END) : spk_msg_get(MSG_START),
 (int)spk_y + 1, (int)spk_x + 1);
}
synth_printf("%s\n", info);
diff --git a/drivers/staging/speakup/serialio.h 
b/drivers/staging/speakup/serialio.h
index 317bb84..1b39921 100644
--- a/drivers/staging/speakup/serialio.h
+++ b/drivers/staging/speakup/serialio.h
@@ -34,6 +34,7 @@ struct old_serial_port {
 #define SPK_TIMEOUT 100
 #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
 
-#define spk_serial_tx_busy() ((inb(speakup_info.port_tts + UART_LSR) & 
BOTH_EMPTY) != BOTH_EMPTY)
+#define spk_serial_tx_busy() \
+   ((inb(speakup_info.port_tts + UART_LSR) & BOTH_EMPTY) != BOTH_EMPTY)
 
 #endif
diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index 898dce5..a7f4962 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -61,10 +61,12 @@ extern struct st_var_header *spk_get_var_header(enum 
var_id_t var_id);
 extern struct st_var_header *spk_var_header_by_name(const char *name);
 extern struct punc_var_t *spk_get_punc_var(enum var_id_t var_id);
 extern int spk_set_num_var(int val, struct st_var_header *var, int how);
-extern int spk_set_string_var(const char *page, struct st_var_header *var, int 
len);
+extern int spk_set_string_var(const char *page, struct st_var_header *var,
+   int len);
 extern int spk_set_mask_bits(const char *input, const int which, const int 
how);
 extern special_func spk_special_handler;
-extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch, u_short 
key);
+extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch,
+   u_short key);
 extern int synth_init(char *name);
 extern void synth_release(void);
 
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 2b772f8..e0b5db9 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -207,10 +207,12 @@ static void do_catch_up(struct spk_synth *synth)
if (time_after_eq(jiffies, jiff_max)) {
if (!in_escape)
spk_serial_out(PROCSPEECH);
-   spin_lock_irqsave(_info.spinlock, 
flags);
+   spin_lock_irqsave(_info.spinlock,
+   flags);
jiffy_delta_val = jiffy_delta->u.n.value;
delay_time_val = delay_time->u.n.value;
-   spin_unlock_irqrestore(_info.spinlock, 
flags);
+   spin_unlock_irqrestore(_info.spinlock,
+   flags);
schedule_timeout(msecs_to_jiffies
 (delay_time_val));
  

Re: d63e2e1f3df breaks sparc/T5-8

[Yinghai Lu]

On Sat, Mar 28, 2015 at 11:16 AM, David Miller  wrote:
> PCI addresses being 64-bit or not is an attribute of the PCI
> controller and the geography of the bridges behind it, not the
> cpu architecture.

Good point. We should add one choice in pci subsystem Kconfig.

Thanks

Yinghai
--
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 v4 00/15] checkpatch clean-up of rtl8723au's rtw_security.c

[Joe Perches]

On Sat, 2015-03-28 at 08:52 -0400, M. Vefa Bicakci wrote:
> These commits address a number of checkpatch.pl warnings and errors
> in rtl8723au's rtw_security.c.

Hello.

This is one of those patchsets that should be
done against Greg's staging-testing branch.

There are some commits against rtl8723au in that
branch that will conflict with your patches.


--
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: [virtio-dev] Re: [PATCH v5] Add virtio-input driver.

[Michael S. Tsirkin]

On Thu, Mar 26, 2015 at 01:10:40PM +0100, Michael S. Tsirkin wrote:
> On Thu, Mar 26, 2015 at 11:49:25AM +0100, Gerd Hoffmann wrote:
> > virtio-input is basically evdev-events-over-virtio, so this driver isn't
> > much more than reading configuration from config space and forwarding
> > incoming events to the linux input layer.
> > 
> > Signed-off-by: Gerd Hoffmann 
> 
> Still a bit worried about using input.h as host/guest
> interface (can't we use some formal standard, e.g. USB HID?),
> but I'll let Rusty decide that.
> 
> Otherwise mostly looks good. One nit below.

Forgot to include:
Acked-by: Michael S. Tsirkin 


> 
> > ---
> 
> Could you pls include changelog in the future?
> You are sending multiple versions per day and it's hard to keep up.
> 
> > +static unsigned int features[] = {
> > +   /* none */
> > +};
> 
> An empty line wouldn't hurt here about variable definition.
> 
> > +static struct virtio_device_id id_table[] = {
> > +   { VIRTIO_ID_INPUT, VIRTIO_DEV_ANY_ID },
> > +   { 0 },
> > +};
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
--
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: d63e2e1f3df breaks sparc/T5-8

[David Miller]

From: Yinghai Lu 
Date: Fri, 27 Mar 2015 16:57:23 -0700

> On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu  wrote:
>> On Thu, Mar 26, 2015 at 4:27 PM, David Ahern  wrote:
> 
>> Also please make sure your config have
>>
>> CONFIG_PCI_DEBUG=y
>>
>> and capture serial console with "debug ignore_loglevel", so we check if
>> pci :00:01.0 really have resource assigned.
> 
> Please check attached patch and send out boot log with above config.

PCI addresses being 64-bit or not is an attribute of the PCI
controller and the geography of the bridges behind it, not the
cpu architecture.
--
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] show nohz_full cpus in sysfs

[Frederic Weisbecker]

On Sat, Mar 28, 2015 at 12:15:56PM -0400, Rik van Riel wrote:
> On 03/28/2015 12:02 PM, Frederic Weisbecker wrote:
> > 2015-03-27 22:50 GMT+01:00  :
> >> From: Rik van Riel 
> >>
> >> Currently there is no way to query which CPUs are in nohz_full
> >> mode from userspace.
> > 
> > Well you can watch dmesg | grep NO_HZ
> > But surely sysfs is more convenient from an app.
> > 
> > I guess it's ok, as long as it's strictly Read Only. Here it seems to
> > be the case. And it's not chmod'able, right?
> 
> I followed the other code for files in that directory.
> 
> Quick testing shows that the cpu info files in
> /sys/devices/system/cpu are chmoddable, but writing
> to them fails with -EIO because there is no function
> set up to handle writes. So yeah, read only :)

Perfect :-)
--
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/

Private Placement

[Peter C]

Hello,

I have a proposal for you.It has to with investing in your Company. kindly get 
back to me with  a reconfirmation of your company name, area of specialization, 
address and your position in the Company. Upon your response ,I shall forward 
you comprehensive details.

Best Regard.
Peter 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: [RFC] bpf: Suggestion on bpf syscall interface

[Alexei Starovoitov]

On 3/28/15 4:36 AM, He Kuang wrote:

Hi, Alexei

In our end-end IO module project, we use bpf maps to record
configurations. According to current bpf syscall interface, we
should specify map_fd to lookup/update bpf maps, so we are
restricted to do config in the same user program.


you can pass map_fd and prog_fd from one process to another via normal
scm_rights mechanism.


My suggestion is to export this kind of operations to sysfs, so
we can load bpf progs and config it seperately. We
implement this feature in our demo project. What's your opinion
on this?


Eventually we may use single sysfs file for lsmod-like listings, but I
definitely don't want to create parallel interface to maps via sysfs.
It's way too expensive and not really suitable for binary key/values.


--
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] mm/memblock: add debug output for the memblock_add

[Alexander Kuleshov]

memblock_reserve function calls memblock_reserve_region which
prints debugging information if 'memblock=debug' passed to the
command line. This patch adds the same behaviour, but for the 
memblock_add function.

Signed-off-by: Alexander Kuleshov 
---
 mm/memblock.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 252b77b..c7b8306 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -580,10 +580,24 @@ int __init_memblock memblock_add_node(phys_addr_t base, 
phys_addr_t size,
return memblock_add_range(, base, size, nid, 0);
 }
 
+static int __init_memblock memblock_add_region(phys_addr_t base,
+   phys_addr_t size,
+   int nid,
+   unsigned long flags)
+{
+   struct memblock_type *_rgn = 
+
+   memblock_dbg("memblock_memory: [%#016llx-%#016llx] flags %#02lx %pF\n",
+(unsigned long long)base,
+(unsigned long long)base + size - 1,
+flags, (void *)_RET_IP_);
+
+   return memblock_add_range(_rgn, base, size, nid, flags);
+}
+
 int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
 {
-   return memblock_add_range(, base, size,
-  MAX_NUMNODES, 0);
+   return memblock_add_region(base, size, MAX_NUMNODES, 0);
 }
 
 /**
-- 
2.3.3.611.g09038fc.dirty

--
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] powerpc/83xx: add support for mpc8306

[Filip Brozovic]

Add chip specific initialization for the MPC8306.

Signed-off-by: Filip Brozovic 
---
 arch/powerpc/platforms/83xx/Kconfig   |  8 
 arch/powerpc/platforms/83xx/mpc83xx.h |  4 
 arch/powerpc/platforms/83xx/usb.c | 14 +++---
 arch/powerpc/platforms/Kconfig| 10 ++
 arch/powerpc/sysdev/qe_lib/qe.c   | 15 ++-
 drivers/gpio/Kconfig  |  6 +++---
 6 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/Kconfig 
b/arch/powerpc/platforms/83xx/Kconfig
index 2bdc8c8..904991d 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -113,6 +113,14 @@ config KMETER1
 
 endif
 
+# used for gpio
+config PPC_MPC830x
+   bool
+   select ARCH_WANT_OPTIONAL_GPIOLIB
+
+config PPC_MPC8306
+   bool
+
 # used for usb & gpio
 config PPC_MPC831x
bool
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h 
b/arch/powerpc/platforms/83xx/mpc83xx.h
index 0cf74d7..4f21fb9 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -21,6 +21,8 @@
 
 /* system i/o configuration register low */
 #define MPC83XX_SICRL_OFFS 0x114
+#define MPC8306_SICRL_USB_MASK 0x003C
+#define MPC8306_SICRL_USB_ULPI 0x
 #define MPC834X_SICRL_USB_MASK 0x6000
 #define MPC834X_SICRL_USB0 0x2000
 #define MPC834X_SICRL_USB1 0x4000
@@ -35,6 +37,8 @@
 
 /* system i/o configuration register high */
 #define MPC83XX_SICRH_OFFS 0x118
+#define MPC8306_SICRH_USB_MASK 0x0F00F300
+#define MPC8306_SICRH_USB_ULPI 0x
 #define MPC8308_SICRH_USB_MASK 0x000c
 #define MPC8308_SICRH_USB_ULPI 0x0004
 #define MPC834X_SICRH_USB_UTMI 0x0002
diff --git a/arch/powerpc/platforms/83xx/usb.c 
b/arch/powerpc/platforms/83xx/usb.c
index 5c31d82..a9db44b 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -99,7 +99,7 @@ int mpc834x_usb_cfg(void)
 }
 #endif /* CONFIG_PPC_MPC834x */
 
-#ifdef CONFIG_PPC_MPC831x
+#if defined(CONFIG_PPC_MPC8306) || defined(CONFIG_PPC_MPC831x)
 int mpc831x_usb_cfg(void)
 {
u32 temp;
@@ -128,6 +128,7 @@ int mpc831x_usb_cfg(void)
/* Configure clock */
immr_node = of_get_parent(np);
if (immr_node && (of_device_is_compatible(immr_node, 
"fsl,mpc8315-immr") ||
+   of_device_is_compatible(immr_node, "fsl,mpc8306-immr") 
||
of_device_is_compatible(immr_node, "fsl,mpc8308-immr")))
clrsetbits_be32(immap + MPC83XX_SCCR_OFFS,
MPC8315_SCCR_USB_MASK,
@@ -139,7 +140,14 @@ int mpc831x_usb_cfg(void)
 
/* Configure pin mux for ULPI.  There is no pin mux for UTMI */
if (prop && !strcmp(prop, "ulpi")) {
-   if (of_device_is_compatible(immr_node, "fsl,mpc8308-immr")) {
+   if (of_device_is_compatible(immr_node, "fsl,mpc8306-immr")) {
+   clrsetbits_be32(immap + MPC83XX_SICRL_OFFS,
+   MPC8306_SICRL_USB_MASK,
+   MPC8306_SICRL_USB_ULPI);
+   clrsetbits_be32(immap + MPC83XX_SICRH_OFFS,
+   MPC8306_SICRH_USB_MASK,
+   MPC8306_SICRH_USB_ULPI);
+   } else if (of_device_is_compatible(immr_node, 
"fsl,mpc8308-immr")) {
clrsetbits_be32(immap + MPC83XX_SICRH_OFFS,
MPC8308_SICRH_USB_MASK,
MPC8308_SICRH_USB_ULPI);
@@ -210,7 +218,7 @@ out:
of_node_put(np);
return ret;
 }
-#endif /* CONFIG_PPC_MPC831x */
+#endif /* CONFIG_PPC_MPC8306 || CONFIG_PPC_MPC831x */
 
 #ifdef CONFIG_PPC_MPC837x
 int mpc837x_usb_cfg(void)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 391b3f6..ecb7cad 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -296,6 +296,16 @@ config QE_GPIO
  Say Y here if you're going to use hardware that connects to the
  QE GPIOs.
 
+config QE_8306
+   bool "MPC8306 QE support"
+   depends on QUICC_ENGINE
+   default y if PPC_MPC8306
+   help
+ The QUICC Engine in the MPC8306 does not support all SNUM threads.
+
+ Say Y here only if you wish to build a kernel for a machine with an
+ MPC8306.
+
 config CPM2
bool "Enable support for the CPM2 (Communications Processor Module)"
depends on (FSL_SOC_BOOKE && PPC32) || 8260
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index c2518cd..f967ff6 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -278,12 +278,17 @@ static void qe_snums_init(void)
0xF4, 0xF5, 0xFC, 0xFD,
};
static const u8 snum_init_46[] = {

Re: [PATCH] clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC

[Krzysztof Kozlowski]

2015-03-27 17:27 GMT+01:00 Bartlomiej Zolnierkiewicz :
> Commit 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK
> down feature") enabled ARMCLK down feature on all Exynos4
> SoCs.  Unfortunately on Exynos4210 SoC ARMCLK down feature
> causes a lockup when ondemand cpufreq governor is used.
> Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs.
>
> This patch was tested on:
> - Exynos4210 SoC based Trats board
> - Exynos4210 SoC based Origen board
> - Exynos4412 SoC based Trats2 board
> - Exynos4412 SoC based Odroid-U3 board
>
> Cc: Krzysztof Kozlowski 
> Cc: Daniel Drake 
> Cc: Tomasz Figa 
> Cc: Kukjin Kim 
> Fixes: 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature")
> Cc:  # v3.17+
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/clk/samsung/clk-exynos4.c |   11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
--
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 PATCH] perf tui: Annotate entries in callchains

[Arnaldo Carvalho de Melo]

Em Fri, Mar 27, 2015 at 04:05:03PM -0700, Stephane Eranian escreveu:
> On Mon, Mar 23, 2015 at 9:56 AM, Arnaldo Carvalho de Melo wrote:
> > Le 23 mars 2015 13:49:24 GMT-03:00, Stephane Eranian  a 
> > écrit :
> >>On Sun, Mar 22, 2015 at 5:27 PM, Namhyung Kim 
> >>> Did you play with acme/perf/core not tip/perf/core?  I got same
> >>> problem but then I realize it's not the Arnaldo's tree.  When I
> >>> changed to acme/perf/core the problem disappeared. :)

> >>I was only trying it with tip.git. The patch looke simple enough to
> >>apply to tip.git but clearly it relies on some other infrastructure
> >>changes which I don't know about. In my case =, I care about getting
> >>this feature in tip.git or older versions of perf.

> > It is all in tip.git by now.

> >>> But unfortunately I got this segfault instead..

> > Needs a patch that is in perf/urgent

> If I pull tip.git now. Does it have what is needed to work?

Yes, it should, but you may hit the bug Namhyumg reported, fixed in:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/tools/perf/util/annotate.c?id=3995614d9b0320e10ce202836c8477e1bcf1a2d4

perf annotate: Fix fallback to unparsed disassembler line



Humm, by tip.git you mean tip.git/master?  /me checks...

[acme@ssdandy linux]$ git log --oneline tip/master
tools/perf/util/annotate.c | head -5
571564babaa3 Merge branch 'perf/core'
2c7da8c590ad perf annotate: Allow annotation for decompressed kernel modules
<--
3995614d9b03 perf annotate: Fix fallback to unparsed disassembler line
48000a1aed74 perf tools: Remove EOL whitespaces
0fb9f2aab738 perf annotate: Fix memory leaks in LOCK handling
[acme@ssdandy linux]$

Yeah, it is there, should have everything you need.

- Arnaldo
--
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][PATCH 09/10] v4l: Export enums used by tracepoints to user space

[Steven Rostedt]

On Sat, 28 Mar 2015 21:00:29 +0800
Xie XiuQi  wrote:

> On 2015/3/28 5:37, Steven Rostedt wrote:
> 
> >  #define show_field(field)  \
> > -   __print_symbolic(field, \
> > -   { V4L2_FIELD_ANY,   "ANY" },\
> > -   { V4L2_FIELD_NONE,  "NONE" },   \
> > -   { V4L2_FIELD_TOP,   "TOP" },\
> > -   { V4L2_FIELD_BOTTOM,"BOTTOM" }, \
> > -   { V4L2_FIELD_INTERLACED,"INTERLACED" }, \
> > -   { V4L2_FIELD_SEQ_TB,"SEQ_TB" }, \
> > -   { V4L2_FIELD_SEQ_BT,"SEQ_BT" }, \
> > -   { V4L2_FIELD_ALTERNATE, "ALTERNATE" },  \
> > -   { V4L2_FIELD_INTERLACED_TB, "INTERLACED_TB" },  \
> > -   { V4L2_FIELD_INTERLACED_BT, "INTERLACED_BT" })
> > +   __print_symbolic(field, SHOW_FIELD
> 
> Hi Steve,
> 
> It is missing a right bracket ')' here.
> 

Yep, I haven't run these through my full test suite yet. I only did
some basic tests (and haven't compiled all the modules yet). Wu's
autobot picked up this error.

-- Steve
--
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] show nohz_full cpus in sysfs

[Rik van Riel]

On 03/28/2015 12:02 PM, Frederic Weisbecker wrote:
> 2015-03-27 22:50 GMT+01:00  :
>> From: Rik van Riel 
>>
>> Currently there is no way to query which CPUs are in nohz_full
>> mode from userspace.
> 
> Well you can watch dmesg | grep NO_HZ
> But surely sysfs is more convenient from an app.
> 
> I guess it's ok, as long as it's strictly Read Only. Here it seems to
> be the case. And it's not chmod'able, right?

I followed the other code for files in that directory.

Quick testing shows that the cpu info files in
/sys/devices/system/cpu are chmoddable, but writing
to them fails with -EIO because there is no function
set up to handle writes. So yeah, read only :)

-- 
All rights reversed
--
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] show nohz_full cpus in sysfs

[Frederic Weisbecker]

2015-03-27 22:50 GMT+01:00  :
> From: Rik van Riel 
>
> Currently there is no way to query which CPUs are in nohz_full
> mode from userspace.

Well you can watch dmesg | grep NO_HZ
But surely sysfs is more convenient from an app.

I guess it's ok, as long as it's strictly Read Only. Here it seems to
be the case. And it's not chmod'able, right?
--
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/2] thermal: hisilicon: add new hisilicon thermal sensor driver

[Xinwei Kong]

On 2015年03月28日 08:58, YiPing Xu wrote:

在 2015/3/27 16:30, Xinwei Kong 写道:



On 2015/3/26 17:14, YiPing Xu wrote:

在 2015/3/25 15:50, Xinwei Kong 写道:

From: kongxinwei 

This patch adds the support for hisilicon thermal sensor, within
hisilicon SoC. there will register sensors for thermal framework
and use device tree to bind cooling device.

Signed-off-by: Leo Yan 
Signed-off-by: kongxinwei 
---
   drivers/thermal/Kconfig|   8 +
   drivers/thermal/Makefile   |   1 +
   drivers/thermal/hisi_thermal.c | 526
+
   3 files changed, 535 insertions(+)
   create mode 100644 drivers/thermal/hisi_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index af40db0..81aee01 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,6 +136,14 @@ config THERMAL_EMULATION
 because userland can easily disable the thermal policy by
simply
 flooding this sysfs node with low temperature values.

+config HISI_THERMAL
+tristate "Hisilicon thermal driver"
+depends on ARCH_HISI && CPU_THERMAL && OF
+help
+  Enable this to plug hisilicon's thermal sensor driver into
the Linux
+  thermal framework. cpufreq is used as the cooling device to
throttle
+  CPUs when the passive trip is crossed.
+
   config IMX_THERMAL
   tristate "Temperature sensor driver for Freescale i.MX SoCs"
   depends on CPU_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index fa0dc48..08ae7ac 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal/
   obj-$(CONFIG_INT340X_THERMAL)  += int340x_thermal/
   obj-$(CONFIG_ST_THERMAL)+= st/
   obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra_soctherm.o
+obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
diff --git a/drivers/thermal/hisi_thermal.c
b/drivers/thermal/hisi_thermal.c
new file mode 100644
index 000..8edf83a
--- /dev/null
+++ b/drivers/thermal/hisi_thermal.c


are you sure all the SOCs in hisilicon use the same thermal IP ?

if not, this driver should not use the "hisi_" prefix.


We can use this hisi thermal driver framework to satisfy diff thermal
IP, all of SoC will use this drvier by adding a struct about diff IP.
We may talk about hisi thermal diff IP how to satisfy this driver.

Thanks
Xinwei




@@ -0,0 +1,526 @@
+/*
+ * Hisilicon thermal sensor driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Copyright (c) 2014-2015 Linaro Limited.
+ *
+ * Xinwei Kong 
+ * Leo Yan 
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define TEMP0_LAG(0x0)
+#define TEMP0_TH(0x4)
+#define TEMP0_RST_TH(0x8)
+#define TEMP0_CFG(0xC)
+#define TEMP0_EN(0x10)
+#define TEMP0_INT_EN(0x14)
+#define TEMP0_INT_CLR(0x18)
+#define TEMP0_RST_MSK(0x1C)
+#define TEMP0_RAW_INT(0x20)
+#define TEMP0_MSK_INT(0x24)
+#define TEMP0_VALUE(0x28)
+
+#define HISI_TEMP_BASE(-60)
+#define HISI_TEMP_RESET(10)
+#define HISI_TEMP_PASSIVE(85000)
+
+#define HISI_MAX_SENSORS4
+
+struct hisi_thermal_sensor {
+struct hisi_thermal_data *thermal;
+struct thermal_zone_device *tzd;
+const struct thermal_trip *trip;
+
+uint32_t id;
+uint32_t thres_temp, reset_temp;
+};
+
+struct hisi_thermal_data {
+struct platform_device *pdev;
+struct clk *clk;
+
+int irq, irq_bind_sensor;
+bool irq_enabled;
+
+unsigned int sensors_num;
+long sensor_temp[HISI_MAX_SENSORS];
+struct hisi_thermal_sensor sensors[HISI_MAX_SENSORS];
+
+void __iomem *regs;
+};
+
+static DEFINE_SPINLOCK(thermal_lock);
+


"thermal_lock" should be defined in "hisi_thermal_data" to
support multi device instance.



ok,good comments


+/* in millicelsius */
+static inline int _step_to_temp(int step)
+{
+/*
+ * Every step equals (1 * 200) / 255 celsius, and finally
+ * need convert to millicelsius.
+ */
+return (HISI_TEMP_BASE + (step * 200 / 255)) * 1000;
+}
+
+static inline int _temp_to_step(int temp)
+{
+return ((temp / 1000 - HISI_TEMP_BASE) * 255 / 200);
+}
+
+static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data
*data,
+ struct 

Re: [PATCH v1 1/2] thermal: hisilicon: add new hisilicon thermal sensor driver

[Xinwei Kong]

On 2015年03月28日 08:58, YiPing Xu wrote:

在 2015/3/27 16:30, Xinwei Kong 写道:



On 2015/3/26 17:14, YiPing Xu wrote:

在 2015/3/25 15:50, Xinwei Kong 写道:

From: kongxinwei 

This patch adds the support for hisilicon thermal sensor, within
hisilicon SoC. there will register sensors for thermal framework
and use device tree to bind cooling device.

Signed-off-by: Leo Yan 
Signed-off-by: kongxinwei 
---
   drivers/thermal/Kconfig|   8 +
   drivers/thermal/Makefile   |   1 +
   drivers/thermal/hisi_thermal.c | 526
+
   3 files changed, 535 insertions(+)
   create mode 100644 drivers/thermal/hisi_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index af40db0..81aee01 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,6 +136,14 @@ config THERMAL_EMULATION
 because userland can easily disable the thermal policy by
simply
 flooding this sysfs node with low temperature values.

+config HISI_THERMAL
+tristate "Hisilicon thermal driver"
+depends on ARCH_HISI && CPU_THERMAL && OF
+help
+  Enable this to plug hisilicon's thermal sensor driver into
the Linux
+  thermal framework. cpufreq is used as the cooling device to
throttle
+  CPUs when the passive trip is crossed.
+
   config IMX_THERMAL
   tristate "Temperature sensor driver for Freescale i.MX SoCs"
   depends on CPU_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index fa0dc48..08ae7ac 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal/
   obj-$(CONFIG_INT340X_THERMAL)  += int340x_thermal/
   obj-$(CONFIG_ST_THERMAL)+= st/
   obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra_soctherm.o
+obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
diff --git a/drivers/thermal/hisi_thermal.c
b/drivers/thermal/hisi_thermal.c
new file mode 100644
index 000..8edf83a
--- /dev/null
+++ b/drivers/thermal/hisi_thermal.c


are you sure all the SOCs in hisilicon use the same thermal IP ?

if not, this driver should not use the "hisi_" prefix.


We can use this hisi thermal driver framework to satisfy diff thermal
IP, all of SoC will use this drvier by adding a struct about diff IP.
We may talk about hisi thermal diff IP how to satisfy this driver.

Thanks
Xinwei




@@ -0,0 +1,526 @@
+/*
+ * Hisilicon thermal sensor driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Copyright (c) 2014-2015 Linaro Limited.
+ *
+ * Xinwei Kong 
+ * Leo Yan 
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define TEMP0_LAG(0x0)
+#define TEMP0_TH(0x4)
+#define TEMP0_RST_TH(0x8)
+#define TEMP0_CFG(0xC)
+#define TEMP0_EN(0x10)
+#define TEMP0_INT_EN(0x14)
+#define TEMP0_INT_CLR(0x18)
+#define TEMP0_RST_MSK(0x1C)
+#define TEMP0_RAW_INT(0x20)
+#define TEMP0_MSK_INT(0x24)
+#define TEMP0_VALUE(0x28)
+
+#define HISI_TEMP_BASE(-60)
+#define HISI_TEMP_RESET(10)
+#define HISI_TEMP_PASSIVE(85000)
+
+#define HISI_MAX_SENSORS4
+
+struct hisi_thermal_sensor {
+struct hisi_thermal_data *thermal;
+struct thermal_zone_device *tzd;
+const struct thermal_trip *trip;
+
+uint32_t id;
+uint32_t thres_temp, reset_temp;
+};
+
+struct hisi_thermal_data {
+struct platform_device *pdev;
+struct clk *clk;
+
+int irq, irq_bind_sensor;
+bool irq_enabled;
+
+unsigned int sensors_num;
+long sensor_temp[HISI_MAX_SENSORS];
+struct hisi_thermal_sensor sensors[HISI_MAX_SENSORS];
+
+void __iomem *regs;
+};
+
+static DEFINE_SPINLOCK(thermal_lock);
+


"thermal_lock" should be defined in "hisi_thermal_data" to
support multi device instance.



ok,good comments


+/* in millicelsius */
+static inline int _step_to_temp(int step)
+{
+/*
+ * Every step equals (1 * 200) / 255 celsius, and finally
+ * need convert to millicelsius.
+ */
+return (HISI_TEMP_BASE + (step * 200 / 255)) * 1000;
+}
+
+static inline int _temp_to_step(int temp)
+{
+return ((temp / 1000 - HISI_TEMP_BASE) * 255 / 200);
+}
+
+static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data
*data,
+ struct 

Re: [PATCH 2/2] phy: driver for Conexant Digicolor internal USB PHY

[Marek Vasut]

On Friday, March 27, 2015 at 05:36:29 AM, Baruch Siach wrote:
> Add a driver for the USB PHY on the Conexant CX92755 SoC, from the
> Digicolor series of SoCs. The PHY is connected to the on-chip chipidea
> usb2 host.
> 
> The hardware is somewhat similar to the phy-mxs-usb.c usb_phy, but it is
> different enough to merit its own driver. Also, this driver uses the
> generic phy infrastructure.

Hi,

the register set looks very similar to MXS one indeed. How is it different 
please ?

The driver looks OK.

Best regards,
Marek Vasut
--
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] x86, ia32entry: Use sysretl to return from sysenter

[Andy Lutomirski]

On Mar 28, 2015 1:35 AM, "Ingo Molnar"  wrote:
>
>
> * Andy Lutomirski  wrote:
>
> > Sysexit is scary on 64-bit kernels -- sysexit must be invoked with
> > usergs and IRQs on.  That means that we rely on sti to correctly
> > mask interrupts for one instruction.  This is okay by itself, but
> > the semantics with respect to NMIs are unclear.
>
> At least judging by profiling output I think NMIs observe the STI
> window of one instruction non-execution as well. (But I'm not 100%
> sure.)
>
> > Avoid the whole issue by using sysretl instead.  For background,
> > Intel CPUs don't allow syscall from compat mode, but they do allow
> > sysret back to compat mode.  Go figure.
> >
> > Oddly this seems to be 30 cycles or so faster.  Avoiding popfq and
> > sti will account for under half of that, I think, so my best guess
> > is that Intel just optimizes sysret much better than sysexit.
> >
> > Cc: sta...@vger.kernel.org
>
> I like it, but no way is this automatic -stable material ... if proven
> upstream we can forward it as a fix for SYSEXIT fragility, but not
> automatically, IMHO.

Agreed.  I wish we had a Stable-after-a-long-soak tag.

--Andy
--
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 4/4] [SMB3] Fix coverity warning

[Shirish Pargaonkar]

Looks correct.

Acked-by: Shirish Pargaonkar 

On Fri, Mar 27, 2015 at 12:28 AM, Steve French  wrote:
> Coverity reports a warning for referencing the beginning of the
> SMB2/SMB3 frame using the ProtocolId field as an array. Although
> it works the same either way, this patch should quiet the warning
> and might be a little clearer.
>
> Reported by Coverity (CID 741269)
>
> Signed-off-by: Steve French 
> ---
>  fs/cifs/smb2misc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
> index 689f035..22dfdf1 100644
> --- a/fs/cifs/smb2misc.c
> +++ b/fs/cifs/smb2misc.c
> @@ -322,7 +322,7 @@ smb2_get_data_area_len(int *off, int *len, struct 
> smb2_hdr *hdr)
>
> /* return pointer to beginning of data area, ie offset from SMB start 
> */
> if ((*off != 0) && (*len != 0))
> -   return hdr->ProtocolId + *off;
> +   return (char *)(>ProtocolId[0]) + *off;
> else
> return NULL;
>  }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" 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 v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Grant Likely]

On Wed, 25 Mar 2015 11:38:43 +
, Will Deacon 
 wrote:
> On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
> > On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
> > > On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> > > > On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> > > > wrote:
> > > > > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP 
> > > > > > code,
> > > > > > I am working on it, I do not think it should be a blocking point, 
> > > > > > patch
> > > > > > coming asap on top of your series.
> > > > > 
> > > > > Well, I don't really want to merge the series without those patches 
> > > > > so I
> > > > > do think it blocks the code from getting into mainline.
> > > > 
> > > > Really? It's a pretty minor duplication problem and it's been identified
> > > > as something requiring refactoring to both the ACPI and DT code. It
> > > > isn't at all dangerous. Why is this a blocking point?
> > > 
> > > Because I don't really see a valid excuse not to get this right first time
> > > around. Lorenzo already has patches on top, so we just need a co-ordinated
> > > review effort.
> > > 
> > > I wouldn't accept another patch series that needed minor rework (which by
> > > its very nature is easily addressed), so why should ACPI be treated any
> > > differently?
> > 
> > Not ACPI, but this particular patchset I think.  The problem is that it has
> > already been reviewed and ACKed by multiple people and it would be a shame
> > to require all of those people to do their reviews once again because of
> > that minor rework (which arguably can be done on top of the patchset just
> > fine).
> > 
> > Of course, if the minor rework in question would not involve the need to
> > review things once again, then I agree that it'd be better to do it upfront,
> > but otherwise there's a good reason not to.
> 
> Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
> that Hanjun rework the current set! What I *am* asking for is that they go
> into mainline with Lorenzo's patches on top, which means that his series [1]
> needs some review (and I plan to look at it later today).

Okay, thanks for the clarification.

g.

--
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/2] of: base: add function to get highest id of an alias stem

[Grant Likely]

On Wed, 18 Mar 2015 13:46:31 +0100
, Wolfram Sang 
 wrote:
> On Thu, Mar 12, 2015 at 05:17:58PM +0100, Wolfram Sang wrote:
> > I2C supports adding adapters using either a dynamic or fixed id. The
> > latter is provided by aliases in the DT case. To prevent id collisions
> > of those two types, install this function which gives us the highest
> > fixed id, so we can then let the dynamically created ones come after
> > this highest number.
> > 
> > Signed-off-by: Wolfram Sang 
> 
> Applied to for-next, thanks!

Looks good to me to. Thanks for doing this. It should also be useful for
other devices.

g.

--
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 0/5] Update the OF unittest and some small fix

[Grant Likely]

On Tue, 24 Mar 2015 23:43:43 -0500
, Rob Herring 
 wrote:
> On Wed, Mar 11, 2015 at 3:36 AM, Wang Long  wrote:
> > This series patches do some small fixes in drivers/of/unittest.c,
> > and update the Documenttion.
> >
> > At last, replace selftest with unittest in the c, dtsi
> > and binding files.
> >
> > * v2 <- v1:
> > - According to Gaurav's advice. make the rename
> > file patch correctly.
> >
> > Wang Long (5):
> >   of/unittest: remove the duplicate of_changeset_init
> >   of/unittest: Fix the wrong expected value in
> > of_selftest_property_string
> >   Documentation: update the of_selftest.txt
> >   Documentation: rename of_selftest.txt to of_unittest.txt
> >   of/unittest: replace 'selftest' with 'unittest'
> 
> I've applied the series. Thanks.

Hmmm, I neglected to update my git tree before getting on an airplane
and merging patches. I may have pushed out conflicts to my tree. If I've
done so, then I'll fix it up this weekend.

g.

--
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: d63e2e1f3df breaks sparc/T5-8

[David Ahern]

On 3/27/15 11:26 PM, Yinghai Lu wrote:

On Fri, Mar 27, 2015 at 8:45 PM, David Ahern  wrote:

On 3/27/15 9:19 PM, Yinghai Lu wrote:


Good. But we still have annoying warning about "no compatible window".

Please try attached patch that support 64bit pci mem space for sparc.

BTW, looks like you still do not have   CONFIG_PCI_DEBUG=y in your
.config.
otherwise we should more verbose print out.
Or did you have DYNAMIC_DEBUG enabled ?
If it is that case, can you remove that?



done. attached.



ok, we are almost there.

[99510.956337] pci_sun4v f02dbcfc: PCI host bridge to bus :00
[99511.025812] pci_bus :00: root bus resource [io
0x8040-0x80400fff] (bus address [0x-0xfff])
[99511.151039] pci_bus :00: root bus resource [mem
0x8000-0x80007eff] (bus address [0x-0x7eff])
[99511.282693] pci_bus :00: root bus resource [mem
0x8001-0x8007] (bus address [0x-0x6])
[99511.414878] pci_bus :00: root bus resource [bus 00-77]


looks like the offset for mem64 is not right.

Please try attached v2.




sshlab root@ca-qasparc24 dmesg
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.36.2 2014/10/24 08:15'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.0.0-rc5+ (root@ca-qasparc24) (gcc version 4.4.7 
20120313 (Red Hat 4.4.7-4.0.9) (GCC) ) #1 SMP Sat Mar 28 10:35:16 EDT 2015
[0.00] debug: skip boot console de-registration.
[0.00] debug: ignoring loglevel setting.
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:10:e0:35:15:f6
[0.00] MM: PAGE_OFFSET is 0xfff8 (max_phys_bits == 47)
[0.00] MM: VMALLOC [0x0001 --> 0x0006]
[0.00] MM: VMEMMAP [0x0006 --> 0x000c]
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 1478490 bytes of memory.
[0.00] MDESC: Size is 774368 bytes.
[0.00] PLATFORM: banner-name [SPARC T5-8]
[0.00] PLATFORM: name [ORCL,SPARC-T5-8]
[0.00] PLATFORM: hostid [863515f6]
[0.00] PLATFORM: serial# [003515f6]
[0.00] PLATFORM: stick-frequency [3b9aca00]
[0.00] PLATFORM: mac-address [10e03515f6]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout [3153600 ms]
[0.00] PLATFORM: max-cpus [1024]
[0.00] Allocated 81920 bytes for kernel page tables.
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x3040-0x]
[0.00]   Normal   [mem 0x-0x383fffd11fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x3040-0x003fddee]
[0.00]   node   0: [mem 0x003fddef6000-0x003fddef7fff]
[0.00]   node   1: [mem 0x0800-0x083f]
[0.00]   node   2: [mem 0x1000-0x103f]
[0.00]   node   3: [mem 0x1800-0x183f]
[0.00]   node   4: [mem 0x2000-0x203f]
[0.00]   node   5: [mem 0x2800-0x283f]
[0.00]   node   6: [mem 0x3000-0x303f]
[0.00]   node   7: [mem 0x3800-0x383fffcddfff]
[0.00]   node   7: [mem 0x383fffcee000-0x383fffd11fff]
[0.00] Initmem setup node 0 [mem 0x3040-0x003fddef7fff]
[0.00] On node 0 totalpages: 33385849
[0.00]   Normal zone: 293431 pages used for memmap
[0.00]   Normal zone: 33385849 pages, LIFO batch:15
[0.00] Initmem setup node 1 [mem 0x0800-0x083f]
[0.00] On node 1 totalpages: 33554432
[0.00]   Normal zone: 294912 pages used for memmap
[0.00]   Normal zone: 33554432 pages, LIFO batch:15
[0.00] Initmem setup node 2 [mem 0x1000-0x103f]
[0.00] On node 2 totalpages: 33554432
[0.00]   Normal zone: 294912 pages used for memmap
[0.00]   Normal zone: 33554432 pages, LIFO batch:15
[0.00] Initmem setup node 3 [mem 0x1800-0x183f]
[0.00] On node 3 totalpages: 33554432
[0.00]   Normal zone: 294912 pages used for memmap
[0.00]   Normal zone: 33554432 pages, LIFO batch:15
[0.00] Initmem setup node 4 [mem 0x2000-0x203f]
[0.00] On node 4 totalpages: 33554432
[0.00]   Normal zone: 294912 pages used for memmap
[0.00]   Normal zone: 33554432 pages, LIFO 

Re: [PATCH 1/2] hwmon: Rename i8k driver to dell-smm-hwmon and move it to hwmon tree

[Guenter Roeck]

On 03/28/2015 03:24 AM, Pali Rohár wrote:

This commit moves i8k driver to hwmon tree under name dell-smm-hwmon which is
better name then abbreviation i8k. For backward compatibility is added macro
MODULE_ALIAS("i8k") so modprobe will load driver also old name i8k. CONFIG_I8K
compile option was not changed.

This commit also adds me as maintainer of this new dell-smm-hwmon driver.

Signed-off-by: Pali Rohár 


Looks ok to me, so I'll be happy to take it for 4.1 if Greg agrees.

I thought about moving the I8K configuration option as well. Not really sure
what to do there. Greg, any opinion ?
It would have to reside outside the HWMON block of drivers/hwmon/Kconfig if
we move it.

We also can drop me as explicit maintainer - I am on the hook from the hwmon 
side
anyway, and we don't need to step on each other's foot for this driver.

Thanks,
Guenter


---
  MAINTAINERS|3 +-
  drivers/char/Makefile  |1 -
  drivers/char/i8k.c | 1005 ---
  drivers/hwmon/Makefile |1 +
  drivers/hwmon/dell-smm-hwmon.c | 1007 
  5 files changed, 1010 insertions(+), 1007 deletions(-)
  delete mode 100644 drivers/char/i8k.c
  create mode 100644 drivers/hwmon/dell-smm-hwmon.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 88c09ca..bf5bb05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3064,8 +3064,9 @@ F:drivers/platform/x86/dell-laptop.c

  DELL LAPTOP SMM DRIVER
  M:Guenter Roeck 
+M: Pali Rohár 
  S:Maintained
-F: drivers/char/i8k.c
+F: drivers/hwmon/dell-smm-hwmon.c
  F:include/uapi/linux/i8k.h

  DELL SYSTEMS MANAGEMENT BASE DRIVER (dcdbas)
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index d06cde26..1d9cf00 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -36,7 +36,6 @@ else
obj-$(CONFIG_NVRAM) += nvram.o
  endif
  obj-$(CONFIG_TOSHIBA) += toshiba.o
-obj-$(CONFIG_I8K)  += i8k.o
  obj-$(CONFIG_DS1620)  += ds1620.o
  obj-$(CONFIG_HW_RANDOM)   += hw_random/
  obj-$(CONFIG_PPDEV)   += ppdev.o
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
deleted file mode 100644
index 24cc4ed..000
--- a/drivers/char/i8k.c
+++ /dev/null
@@ -1,1005 +0,0 @@
-/*
- * i8k.c -- Linux driver for accessing the SMM BIOS on Dell laptops.
- *
- * Copyright (C) 2001  Massimo Dal Zotto 
- *
- * Hwmon integration:
- * Copyright (C) 2011  Jean Delvare 
- * Copyright (C) 2013, 2014  Guenter Roeck 
- * Copyright (C) 2014  Pali Rohár 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define I8K_SMM_FN_STATUS  0x0025
-#define I8K_SMM_POWER_STATUS   0x0069
-#define I8K_SMM_SET_FAN0x01a3
-#define I8K_SMM_GET_FAN0x00a3
-#define I8K_SMM_GET_SPEED  0x02a3
-#define I8K_SMM_GET_FAN_TYPE   0x03a3
-#define I8K_SMM_GET_NOM_SPEED  0x04a3
-#define I8K_SMM_GET_TEMP   0x10a3
-#define I8K_SMM_GET_TEMP_TYPE  0x11a3
-#define I8K_SMM_GET_DELL_SIG1  0xfea3
-#define I8K_SMM_GET_DELL_SIG2  0xffa3
-
-#define I8K_FAN_MULT   30
-#define I8K_FAN_MAX_RPM3
-#define I8K_MAX_TEMP   127
-
-#define I8K_FN_NONE0x00
-#define I8K_FN_UP  0x01
-#define I8K_FN_DOWN0x02
-#define I8K_FN_MUTE0x04
-#define I8K_FN_MASK0x07
-#define I8K_FN_SHIFT   8
-
-#define I8K_POWER_AC   0x05
-#define I8K_POWER_BATTERY  0x01
-
-static DEFINE_MUTEX(i8k_mutex);
-static char bios_version[4];
-static struct device *i8k_hwmon_dev;
-static u32 i8k_hwmon_flags;
-static uint i8k_fan_mult = I8K_FAN_MULT;
-static uint i8k_pwm_mult;
-static uint i8k_fan_max = I8K_FAN_HIGH;
-
-#define I8K_HWMON_HAVE_TEMP1   (1 << 0)
-#define I8K_HWMON_HAVE_TEMP2   (1 << 1)
-#define I8K_HWMON_HAVE_TEMP3   (1 << 2)
-#define I8K_HWMON_HAVE_TEMP4   (1 << 3)
-#define I8K_HWMON_HAVE_FAN1(1 << 4)
-#define I8K_HWMON_HAVE_FAN2(1 << 5)
-
-MODULE_AUTHOR("Massimo Dal Zotto (d...@debian.org)");
-MODULE_DESCRIPTION("Driver for accessing SMM BIOS on Dell laptops");
-MODULE_LICENSE("GPL");
-
-static bool force;
-module_param(force, bool, 0);
-MODULE_PARM_DESC(force, "Force loading without checking for supported models");
-
-static bool ignore_dmi;
-module_param(ignore_dmi, bool, 0);

Re: [PATCH 3/4] [SMB3] Fix dereference before null check warning

[Shirish Pargaonkar]

Looks correct.

Acked-by: Shirish Pargaonkar 

On Fri, Mar 27, 2015 at 12:28 AM, Steve French  wrote:
> null tcon is not likely in these paths in current
> code, but obviously it does clarify the code to
> check for null (if at all) before derefrencing
> rather than after.
>
> Reported by Coverity (CID 1042666)
>
> Signed-off-by: Steve French 
> ---
>  fs/cifs/smb2pdu.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 1b906de..78b329f 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1218,7 +1218,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> struct smb2_ioctl_req *req;
> struct smb2_ioctl_rsp *rsp;
> struct TCP_Server_Info *server;
> -   struct cifs_ses *ses = tcon->ses;
> +   struct cifs_ses *ses;
> struct kvec iov[2];
> int resp_buftype;
> int num_iovecs;
> @@ -1233,6 +1233,11 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> if (plen)
> *plen = 0;
>
> +   if (tcon)
> +   ses = tcon->ses;
> +   else
> +   return -EIO;
> +
> if (ses && (ses->server))
> server = ses->server;
> else
> @@ -1296,14 +1301,12 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
>
> if ((rc != 0) && (rc != -EINVAL)) {
> -   if (tcon)
> -   cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> +   cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> goto ioctl_exit;
> } else if (rc == -EINVAL) {
> if ((opcode != FSCTL_SRV_COPYCHUNK_WRITE) &&
> (opcode != FSCTL_SRV_COPYCHUNK)) {
> -   if (tcon)
> -   cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> +   cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> goto ioctl_exit;
> }
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" 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 2/4] [CIFS] Don't ignore errors on encrypting password in SMBTcon

[Shirish Pargaonkar]

Looks correct, although we could just goto a label at the end of this
function which
does the same.

Acked-by: Shirish Pargaonkar 


On Fri, Mar 27, 2015 at 12:28 AM, Steve French  wrote:
> Although unlikely to fail (and tree connect does not commonly send
> a password since SECMODE_USER is the default for most servers)
> do not ignore errors on SMBNTEncrypt in SMB Tree Connect.
>
> Reported by Coverity (CID 1226853)
>
> Signed-off-by: Steve French 
> ---
>  fs/cifs/connect.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 4cb8450..cdb1aaf 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -3696,6 +3696,12 @@ CIFSTCon(const unsigned int xid, struct cifs_ses *ses,
>  #endif /* CIFS_WEAK_PW_HASH */
> rc = SMBNTencrypt(tcon->password, ses->server->cryptkey,
> bcc_ptr, nls_codepage);
> +   if (rc) {
> +   cifs_dbg(FYI, "%s Can't generate NTLM rsp. Error: 
> %d\n",
> +__func__, rc);
> +   cifs_buf_release(smb_buffer);
> +   return rc;
> +   }
>
> bcc_ptr += CIFS_AUTH_RESP_SIZE;
> if (ses->capabilities & CAP_UNICODE) {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" 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 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Guenter Roeck]

On 03/28/2015 03:24 AM, Pali Rohár wrote:

This patch splits CONFIG_I8K compile option to SENSORS_DELL_SMM and CONFIG_I8K.
Option SENSORS_DELL_SMM is now used to enable compilation of dell-smm-hwmon
driver and old CONFIG_I8K option to enable /proc/i8k interface in driver.

So this change allows to compile dell-smm-hwmon driver without legacy /proc/i8k
interface which is needed only for old Dell Inspirion models or for userspace
i8kutils package.

For backward compatibility when CONFIG_I8K is enabled then also SENSORS_DELL_SMM
is enabled and so driver dell-smm-hwmon (with /proc/i8k) is compiled.

Signed-off-by: Pali Rohár 
---
  arch/x86/Kconfig   |   25 +
  drivers/hwmon/Kconfig  |   11 +++
  drivers/hwmon/Makefile |2 +-
  drivers/hwmon/dell-smm-hwmon.c |   20 
  4 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..8d0266b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1063,24 +1063,17 @@ config TOSHIBA
  Say N otherwise.

  config I8K
-   tristate "Dell laptop support"
-   select HWMON
+   bool "Dell i8k legacy laptop support"


tristate and still "select HWMON".


+   select SENSORS_DELL_SMM
---help---
- This adds a driver to safely access the System Management Mode
- of the CPU on the Dell Inspiron 8000. The System Management Mode
- is used to read cpu temperature and cooling fan status and to
- control the fans on the I8K portables.
+ This options enables legacy /proc/i8k userspace interface in
+ dell-smm-hwmon driver. Character file /proc/i8k reports power and
+ hotkey status on old Dell laptops (like Dell Inspiron 8000) via
+ System Management Mode provided by Dell BIOS. This /proc/i8k interface
+ is also used by userspace package i8kutils to control laptop fans.

- This driver has been tested only on the Inspiron 8000 but it may
- also work with other Dell laptops. You can force loading on other
- models by passing the parameter `force=1' to the module. Use at
- your own risk.
-
- For information on utilities to make use of this driver see the
- I8K Linux utilities web site at:
- 
-
- Say Y if you intend to run this kernel on a Dell Inspiron 8000.
+ Say Y if you intend to run this kernel on old Dell laptops or want to
+ use userspace package i8kutils.
  Say N otherwise.

  config X86_REBOOTFIXUPS
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 110fade..86eeb7d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1703,6 +1703,17 @@ config SENSORS_ULTRA45
  This driver provides support for the Ultra45 workstation environmental
  sensors.

+config SENSORS_DELL_SMM
+   tristate "Dell laptop SMM BIOS hwmon driver"
+   depends ON X86


Wondering as well .. .did you test this ?


+   ---help---
+ This hwmon driver adds support for reporting temperature of different
+ sensors and controls the fans on Dell laptops via System Management
+ Mode provided by Dell BIOS.
+
+ When option I8K is also enabled this driver provides legacy /proc/i8k
+ userspace interface for i8kutils package.
+

Please add this in alphabetic order.


  if ACPI

  comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 1c3e458..9eec614 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -155,7 +155,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
  obj-$(CONFIG_SENSORS_W83L786NG)   += w83l786ng.o
  obj-$(CONFIG_SENSORS_WM831X)  += wm831x-hwmon.o
  obj-$(CONFIG_SENSORS_WM8350)  += wm8350-hwmon.o
-obj-$(CONFIG_I8K)  += dell-smm-hwmon.o
+obj-$(CONFIG_SENSORS_DELL_SMM) += dell-smm-hwmon.o


Same here.



  obj-$(CONFIG_PMBUS)   += pmbus/

diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 2b04e4f..e9661dc 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -81,7 +81,7 @@ static uint i8k_fan_max = I8K_FAN_HIGH;

  MODULE_AUTHOR("Massimo Dal Zotto (d...@debian.org)");
  MODULE_AUTHOR("Pali Rohár ");
-MODULE_DESCRIPTION("Driver for accessing SMM BIOS on Dell laptops");
+MODULE_DESCRIPTION("Dell laptop SMM BIOS hwmon driver");
  MODULE_LICENSE("GPL");
  MODULE_ALIAS("i8k");

@@ -93,6 +93,7 @@ static bool ignore_dmi;
  module_param(ignore_dmi, bool, 0);
  MODULE_PARM_DESC(ignore_dmi, "Continue probing hardware even if DMI data does not 
match");

+#ifdef CONFIG_I8K
  static bool restricted;
  module_param(restricted, bool, 0);
  MODULE_PARM_DESC(restricted, "Allow fan control if SYS_ADMIN capability set");
@@ -100,6 +101,7 @@ MODULE_PARM_DESC(restricted, "Allow fan control if SYS_ADMIN 
capability set");
  static bool 

kcalloc/kmalloc_array could BUILD_BUG_ON for too-big constant arguments (was Re: [PATCH] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc)

[Jeff Epler]

The following is a sketch of how a macro kcalloc could BUILD_BUG_ON for
overflows of two compile-time operands, or call "kcalloc_variable" for
nonconstant arguments.  Tested on gcc 4.7.2 only, since it's what I had to
hand.  I didn't do any testing beyond checking that fn2 didn't build, and that
fn1/3 had plausible-looking code on x86_64.

typedef unsigned long size_t;
#define SIZE_MAX (~(size_t)0)
typedef int gfp_t;
extern void *kzalloc(size_t n, gfp_t flags);
extern void *kcalloc_variable(size_t n, size_t size, gfp_t flags);
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))

#define kcalloc(n, size, flags) \
__builtin_choose_expr(__builtin_constant_p((n) | (size)), \
( \
BUILD_BUG_ON((n) > SIZE_MAX / (size)), \
kzalloc((n) * (size), (flags)) \
), kcalloc_variable((n), (size), (flags)))


void fn1() { kcalloc(3, 3, 0); }
//void fn2() { kcalloc(2, ~(size_t)0, 0); }// compile-time BUILD_BUG_ON
void fn3(int i) { kcalloc(2, i, 0); }

Jeff
--
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] [SMB3] Fix warning on uninitialized buftype

[Shirish Pargaonkar]

Looks correct.

Acked-by: Shirish Pargaonkar 

On Fri, Mar 27, 2015 at 12:27 AM, Steve French  wrote:
> Pointed out by coverity analyzer.  resp_buftype is
> not initialized in one path which can rarely log
> a spurious warning (buf is null so there will
> not be a problem with freeing data, but if buf_type
> were randomly set to wrong value could log a warning)
>
> Reported by Coverity (CID 1269144)
>
> Signed-off-by: Steve French 
> ---
>  fs/cifs/smb2pdu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 3417340..1b906de 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -2114,7 +2114,7 @@ SMB2_query_directory(const unsigned int xid, struct 
> cifs_tcon *tcon,
> struct kvec iov[2];
> int rc = 0;
> int len;
> -   int resp_buftype;
> +   int resp_buftype = CIFS_NO_BUFFER;
> unsigned char *bufptr;
> struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" 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 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

[Guenter Roeck]

On 03/28/2015 05:54 AM, Steven Honeyman wrote:

On 28 March 2015 at 11:04, Paul Bolle  wrote:

On Sat, 2015-03-28 at 11:24 +0100, Pali Rohár wrote:

--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1703,6 +1703,17 @@ config SENSORS_ULTRA45
 This driver provides support for the Ultra45 workstation environmental
 sensors.

+config SENSORS_DELL_SMM
+ tristate "Dell laptop SMM BIOS hwmon driver"
+ depends ON X86


How did this past your testing?


+ ---help---
+   This hwmon driver adds support for reporting temperature of different
+   sensors and controls the fans on Dell laptops via System Management
+   Mode provided by Dell BIOS.
+
+   When option I8K is also enabled this driver provides legacy /proc/i8k
+   userspace interface for i8kutils package.
+


It's working OK for me (after fixing the mistake pointed out above).

[Latitude e6540]
-
coretemp-isa-
Adapter: ISA adapter
Physical id 0:  +53.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0: +51.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1: +53.0°C  (high = +84.0°C, crit = +100.0°C)

i8k-virtual-0
Adapter: Virtual device
Processor Fan: 3171 RPM
CPU:+52.0°C
Ambient:+46.0°C
SODIMM: +40.0°C
-

Ambient and SODIMM look swapped - but it's probably just another Dell
error. I really need to look at getting coreboot on this thing.

On 28 March 2015 at 10:24, Pali Rohár  wrote:
...

  config I8K
-   tristate "Dell laptop support"
-   select HWMON
+   bool "Dell i8k legacy laptop support"
+   select SENSORS_DELL_SMM

...

+config SENSORS_DELL_SMM
+   tristate "Dell laptop SMM BIOS hwmon driver"


The only change I'd suggest is not to change the tristate to bool for
I8K. Forcing that to bool means that SENSORS_DELL_SMM can't be
compiled as a module if the user wishes to keep i8k hanging around
"just in case". It'll probably annoy distro kernel packagers too.



Agreed. It also still needs to select HWMON (SENSORS_DELL_SMM is
only visible if HWMON is selected).

Guenter

--
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] show nohz_full cpus in sysfs

[Mike Galbraith]

On Sat, 2015-03-28 at 09:35 -0400, Rik van Riel wrote:

> It can be used by programs like irqbalance to avoid binding IRQs
> to isolated or nohz_full CPUs, by libvirt to know which CPUs do
> not get load balancing of SCHED_OTHER tasks, etc...

Ok, other system packages learning to avoid these does make good sense.

-Mike


--
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/2] Input: Add binding document for a generic ADC keypad

[Jonathan Cameron]

On 28/03/15 00:43, Andrew Bresticker wrote:
> Add a binding document for a generic ADC keypad.  Buttons on an ADC
> keypad are connected in a resistor ladder to an ADC.  The binding
> describes the mapping of ADC channel and voltage ranges to buttons.
> 
> Signed-off-by: Andrew Bresticker 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 

Just thinking about this, what options do we have for how such a keypad might
be wired.  The interesting cases are the more than one key at a time ones.

If that happens, then we end up with a voltage that should allow us to 
work out which combination of keys is pressed.

http://en.wikipedia.org/wiki/Resistor_ladder

The binding as it stands only works for single keys being pressed at a time
(I think!)

Do we want to make it flexible enough to cope with multiple keys?
I guess we'd need to model the common resistor ladder forms and provide
a way of specifying the different setups in the device tree.

J
> ---
>  .../devicetree/bindings/input/adc-keys.txt | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
> b/Documentation/devicetree/bindings/input/adc-keys.txt
> new file mode 100644
> index 000..c9a57de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
> @@ -0,0 +1,43 @@
> +Generic ADC keypad
> +==
> +
> +Required properties:
> + - compatible: "adc-keys"
> + - poll-interval: Polling interval time in ms.
> + - io-channels: List of IIO channels used by the keypad.
> +   See ../iio/iio-bindings.txt for details.
> +
> +Optional properties:
> + - autorepeat: Enable auto-repeat.
> +
> +Each button on the ADC keypad is represented by a sub-node.
> +
> +Required sub-node properties:
> + - label: Descriptive name for the key.
> + - linux,code: Keycode to emit.
> + - channel: IIO channel (index into the 'io-channels' above) to which this
> +   button is attached.
> + - min-voltage: Minimum voltage in uV when this key is pressed.
> + - max-voltage: Maximum voltage in uV when this key is pressed.
> +
> +Optional sub-node properties:
> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) 
> if
> +   not specified.
> +
> +Example:
> +
> +adc-keypad {
> + compatible = "adc-keys";
> + poll-interval = <100>;
> + io-channels = < 0>, < 1>;
> +
> + vol-up-button {
> + label = "Volume Up";
> + linux,code = ;
> + channel = <0>;
> + min-voltage = <160>;
> + max-voltage = <164>;
> + };
> +
> + ...
> +};
> 

--
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] Input: Add driver for a generic ADC keypad

[Jonathan Cameron]

On 28/03/15 00:43, Andrew Bresticker wrote:
> Add a polled input driver for a keypad in which the buttons are connected
> in resistor ladders to an ADC.  The IIO framework is used to claim and
> read the ADC channels.
> 
> Signed-off-by: Andrew Bresticker 
The IIO side of things looks fine.
> ---
>  drivers/input/keyboard/Kconfig|  13 ++
>  drivers/input/keyboard/Makefile   |   1 +
>  drivers/input/keyboard/adc-keys.c | 291 
> ++
>  3 files changed, 305 insertions(+)
>  create mode 100644 drivers/input/keyboard/adc-keys.c
> 
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index a89ba7c..bbaff9e 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -12,6 +12,19 @@ menuconfig INPUT_KEYBOARD
>  
>  if INPUT_KEYBOARD
>  
> +config KEYBOARD_ADC
> + tristate "ADC Keypad"
> + depends on IIO
> + select INPUT_POLLDEV
> + help
> +   This driver supports generic ADC keypads using IIO.
> +
> +   Say Y here if your device has buttons connected in a resistor ladder
> +   to an ADC.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called adc-keys.
> +
>  config KEYBOARD_ADP5520
>   tristate "Keypad Support for ADP5520 PMIC"
>   depends on PMIC_ADP5520
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 4707678..888fa62 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -4,6 +4,7 @@
>  
>  # Each configuration option enables a list of files.
>  
> +obj-$(CONFIG_KEYBOARD_ADC)   += adc-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5520)   += adp5520-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5588)   += adp5588-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5589)   += adp5589-keys.o
> diff --git a/drivers/input/keyboard/adc-keys.c 
> b/drivers/input/keyboard/adc-keys.c
> new file mode 100644
> index 000..1b9bcad
> --- /dev/null
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -0,0 +1,291 @@
> +/*
> + * ADC keypad driver
> + *
> + * Copyright (C) 2015 Google, Inc.
> + *
> + * Based on /drivers/input/keybaord/gpio_keys_polled.c:
> + *  Copyright (C) 2007-2010 Gabor Juhos 
> + *  Copyright (C) 2010 Nuno Goncalves 
> + *
> + * 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 
> +
> +struct adc_key {
> + const char *desc;
> + unsigned int type;
> + unsigned int code;
> + unsigned int min_uV;
> + unsigned int max_uV;
> +};
> +
> +struct adc_chan_map {
> + struct adc_key *keys;
> + unsigned int num_keys;
> + int last_key;
> +};
> +
> +struct adc_keypad {
> + struct device *dev;
> + struct input_polled_dev *poll_dev;
> + unsigned int poll_interval;
> + bool autorepeat;
> + struct iio_channel *iio_chans;
> + unsigned int num_chans;
> + struct adc_chan_map *chan_map;
> +};
> +
> +static void adc_keypad_poll_chan(struct adc_keypad *keypad, unsigned int 
> chan)
> +{
> + struct adc_chan_map *chan_map = >chan_map[chan];
> + struct input_dev *input = keypad->poll_dev->input;
> + struct adc_key *key;
> + unsigned int adc_uV;
> + int ret, val, i;
> +
> + ret = iio_read_channel_processed(>iio_chans[chan], );
> + if (ret < 0) {
> + dev_err(keypad->dev, "Failed to read ADC: %d\n", ret);
> + return;
> + }
> + adc_uV = val * 1000;
> +
> + for (i = 0; i < chan_map->num_keys; i++) {
> + if (adc_uV >= chan_map->keys[i].min_uV &&
> + adc_uV <= chan_map->keys[i].max_uV)
> + break;
> + }
> + if (i >= chan_map->num_keys)
> + i = -1;
> +
> + if (i != chan_map->last_key) {
> + if (chan_map->last_key >= 0) {
> + key = _map->keys[chan_map->last_key];
> + input_event(input, key->type, key->code, 0);
> + }
> + if (i >= 0) {
> + key = _map->keys[i];
> + input_event(input, key->type, key->code, 1);
> + }
> + input_sync(input);
> + chan_map->last_key = i;
> + }
> +}
> +
> +static void adc_keypad_poll(struct input_polled_dev *poll_dev)
> +{
> + struct adc_keypad *keypad = poll_dev->private;
> + unsigned int i;
> +
> + for (i = 0; i < keypad->num_chans; i++)
> + adc_keypad_poll_chan(keypad, i);
> +}
> +
> +static int adc_keypad_of_parse_chan(struct adc_keypad *keypad,
> + unsigned int chan)
> +{
> + struct device_node *child, *np = keypad->dev->of_node;
> + struct adc_key *keys;
> + unsigned int i = 0;
> + int ret;
> +

[GIT PULL] x86 fix

[Ingo Molnar]

Linus,

Please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

   # HEAD: b3494a4ab20f6bdf74cdf2badf7918bb65ee8a00 x86/asm/entry: Check for 
syscall exit work with IRQs disabled

Fix x86 syscall exit code bug that resulted in spurious non-execution 
of TIF-driven user-return worklets, causing big trouble for things 
like KVM that rely on user notifiers for correctness of their vcpu 
model, causing crashes like double faults.

 Thanks,

Ingo

-->
Andy Lutomirski (1):
  x86/asm/entry: Check for syscall exit work with IRQs disabled


 arch/x86/kernel/entry_64.S | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 1d74d161687c..2babb393915e 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -364,12 +364,21 @@ GLOBAL(system_call_after_swapgs)
  * Has incomplete stack frame and undefined top of stack.
  */
 ret_from_sys_call:
-   testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
-   jnz int_ret_from_sys_call_fixup /* Go the the slow path */
-
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
+
+   /*
+* We must check ti flags with interrupts (or at least preemption)
+* off because we must *never* return to userspace without
+* processing exit work that is enqueued if we're preempted here.
+* In particular, returning to userspace with any of the one-shot
+* flags (TIF_NOTIFY_RESUME, TIF_USER_RETURN_NOTIFY, etc) set is
+* very bad.
+*/
+   testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   jnz int_ret_from_sys_call_fixup /* Go the the slow path */
+
CFI_REMEMBER_STATE
/*
 * sysretq will re-enable interrupts:
@@ -386,7 +395,7 @@ GLOBAL(system_call_after_swapgs)
 
 int_ret_from_sys_call_fixup:
FIXUP_TOP_OF_STACK %r11, -ARGOFFSET
-   jmp int_ret_from_sys_call
+   jmp int_ret_from_sys_call_irqs_off
 
/* Do syscall tracing */
 tracesys:
@@ -432,6 +441,7 @@ GLOBAL(system_call_after_swapgs)
 GLOBAL(int_ret_from_sys_call)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
+int_ret_from_sys_call_irqs_off:
movl $_TIF_ALLWORK_MASK,%edi
/* edi: mask to check */
 GLOBAL(int_with_check)
--
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/

[GIT PULL] timer fixes

[Ingo Molnar]

Linus,

Please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-urgent-for-linus

   # HEAD: 6e206020324c50a95486f6b279a53512febed92d clocksource/drivers/sun5i: 
Fix cpufreq interaction with sched_clock()

Two clocksource driver fixes, and an idle loop RCU warning fix.

 Thanks,

Ingo

-->
Maxime Ripard (1):
  clocksource/drivers/sun5i: Fix cpufreq interaction with sched_clock()

Preeti U Murthy (1):
  timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop

Richard Weinberger (1):
  clocksource/drivers: Fix various !CONFIG_HAS_IOMEM build errors


 drivers/clocksource/Kconfig  |  3 +++
 drivers/clocksource/timer-sun5i.c|  7 ---
 kernel/time/tick-broadcast-hrtimer.c | 11 +--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 68161f7a07d6..a0b036ccb118 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -192,6 +192,7 @@ config SYS_SUPPORTS_EM_STI
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
default SYS_SUPPORTS_SH_CMT
help
  This enables build of a clocksource and clockevent driver for
@@ -201,6 +202,7 @@ config SH_TIMER_CMT
 config SH_TIMER_MTU2
bool "Renesas MTU2 timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
default SYS_SUPPORTS_SH_MTU2
help
  This enables build of a clockevent driver for the Multi-Function
@@ -210,6 +212,7 @@ config SH_TIMER_MTU2
 config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
default SYS_SUPPORTS_SH_TMU
help
  This enables build of a clocksource and clockevent driver for
diff --git a/drivers/clocksource/timer-sun5i.c 
b/drivers/clocksource/timer-sun5i.c
index 5dcbf90b8015..58597fbcc046 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -137,11 +136,6 @@ static struct irqaction sun5i_timer_irq = {
.dev_id = _clockevent,
 };
 
-static u64 sun5i_timer_sched_read(void)
-{
-   return ~readl(timer_base + TIMER_CNTVAL_LO_REG(1));
-}
-
 static void __init sun5i_timer_init(struct device_node *node)
 {
struct reset_control *rstc;
@@ -172,7 +166,6 @@ static void __init sun5i_timer_init(struct device_node 
*node)
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
   timer_base + TIMER_CTL_REG(1));
 
-   sched_clock_register(sun5i_timer_sched_read, 32, rate);
clocksource_mmio_init(timer_base + TIMER_CNTVAL_LO_REG(1), node->name,
  rate, 340, 32, clocksource_mmio_readl_down);
 
diff --git a/kernel/time/tick-broadcast-hrtimer.c 
b/kernel/time/tick-broadcast-hrtimer.c
index eb682d5c697c..6aac4beedbbe 100644
--- a/kernel/time/tick-broadcast-hrtimer.c
+++ b/kernel/time/tick-broadcast-hrtimer.c
@@ -49,6 +49,7 @@ static void bc_set_mode(enum clock_event_mode mode,
  */
 static int bc_set_next(ktime_t expires, struct clock_event_device *bc)
 {
+   int bc_moved;
/*
 * We try to cancel the timer first. If the callback is on
 * flight on some other cpu then we let it handle it. If we
@@ -60,9 +61,15 @@ static int bc_set_next(ktime_t expires, struct 
clock_event_device *bc)
 * restart the timer because we are in the callback, but we
 * can set the expiry time and let the callback return
 * HRTIMER_RESTART.
+*
+* Since we are in the idle loop at this point and because
+* hrtimer_{start/cancel} functions call into tracing,
+* calls to these functions must be bound within RCU_NONIDLE.
 */
-   if (hrtimer_try_to_cancel() >= 0) {
-   hrtimer_start(, expires, HRTIMER_MODE_ABS_PINNED);
+   RCU_NONIDLE(bc_moved = (hrtimer_try_to_cancel() >= 0) ?
+   !hrtimer_start(, expires, HRTIMER_MODE_ABS_PINNED) :
+   0);
+   if (bc_moved) {
/* Bind the "device" to the cpu */
bc->bound_on = smp_processor_id();
} else if (bc->bound_on == smp_processor_id()) {
--
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/

[GIT PULL] scheduler fix

[Ingo Molnar]

Linus,

Please pull the latest sched-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
sched-urgent-for-linus

   # HEAD: 746db9443ea57fd9c059f62c4bfbf41cf224fe13 sched: Fix RLIMIT_RTTIME 
when PI-boosting to RT

A single sched/rt corner case fix for RLIMIT_RTIME correctness.

 Thanks,

Ingo

-->
Brian Silverman (1):
  sched: Fix RLIMIT_RTTIME when PI-boosting to RT


 kernel/sched/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f0f831e8a345..62671f53202a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3034,6 +3034,8 @@ void rt_mutex_setprio(struct task_struct *p, int prio)
} else {
if (dl_prio(oldprio))
p->dl.dl_boosted = 0;
+   if (rt_prio(oldprio))
+   p->rt.timeout = 0;
p->sched_class = _sched_class;
}
 
--
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] vmstat: Avoid waking up idle-cpu to service shepherd work

[Peter Zijlstra]

On Sat, Mar 28, 2015 at 05:27:23PM +0530, viresh kumar wrote:
> So probably we need to make 'base' aligned to 8 bytes ?

Yeah, something like the below (at the very end) should ensure the thing
is cacheline aligned, that should give us a fair few bits.

> So, what you are suggesting is something like this (untested):

> @@ -1202,6 +1208,7 @@ static inline void __run_timers(struct tvec_base *base)
> timer_stats_account_timer(timer);
> 
> base->running_timer = timer;
> +   tbase_set_running(timer->base);
> detach_expired_timer(timer, base);
> 
> if (irqsafe) {
> @@ -1216,6 +1223,7 @@ static inline void __run_timers(struct tvec_base *base)
> }
> }
> base->running_timer = NULL;
> +   tbase_clear_running(timer->base);
> spin_unlock_irq(>lock);
>  }

That's broken. You need to clear running on all the timers you set it
on. Furthermore, you need to revalidate timer->base == base after
call_timer_fn().

Something like so:

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d3f5c504939..489ce182f8ec 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1213,6 +1213,21 @@ static inline void __run_timers(struct tvec_base *base)
call_timer_fn(timer, fn, data);
spin_lock_irq(>lock);
}
+
+   if (unlikely(timer->base != base)) {
+   unsigned long flags;
+   struct tvec_base *tbase;
+
+   spin_unlock(>lock);
+
+   tbase = lock_timer_base(timer, );
+   tbase_clear_running(timer->base);
+   spin_unlock(>lock);
+
+   spin_lock(>lock);
+   } else {
+   tbase_clear_running(timer->base);
+   }
}
}
base->running_timer = NULL;

Also, once you have tbase_running, we can take base->running_timer out
altogether.

> Now there are few issues I see here (Sorry if they are all imaginary):
> - In case a timer re-arms itself from its handler and is migrated from CPU A 
> to B, what
>   happens if the re-armed timer fires before the first handler finishes ? 
> i.e. timer->fn()
>   hasn't finished running on CPU A and it has fired again on CPU B. Wouldn't 
> this expose
>   us to a lot of other problems? It wouldn't be serialized to itself anymore ?

What I said above.

> - Because the timer has migrated to another CPU, the locking in __run_timers()
>   needs to be fixed. And that will make it complicated ..

Hardly.

>   - __run_timer() doesn't lock bases of other CPUs, and it has to do it now..

Yep, but rarely.

>   - We probably need to take locks of both local CPU and the one to which 
> timer migrated.

Nope, or rather, not at the same time. That's what the NULL magic buys
us.

> - Its possible now that there can be more than one running timer for a base, 
> which wasn't
>   true earlier. Not sure if it will break something.

Only if you messed it up real bad :-)

---
 kernel/time/timer.c | 36 
 1 file changed, 8 insertions(+), 28 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d3f5c504939..c8c45bf50b2e 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -93,6 +93,7 @@ struct tvec_base {
 struct tvec_base boot_tvec_bases;
 EXPORT_SYMBOL(boot_tvec_bases);
 static DEFINE_PER_CPU(struct tvec_base *, tvec_bases) = _tvec_bases;
+static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
 
 /* Functions below help us manage 'deferrable' flag */
 static inline unsigned int tbase_get_deferrable(struct tvec_base *base)
@@ -1534,46 +1535,25 @@ EXPORT_SYMBOL(schedule_timeout_uninterruptible);
 
 static int init_timers_cpu(int cpu)
 {
-   int j;
-   struct tvec_base *base;
+   struct tvec_base *base = per_cpu(tvec_bases, cpu);
static char tvec_base_done[NR_CPUS];
+   int j;
 
if (!tvec_base_done[cpu]) {
static char boot_done;
 
-   if (boot_done) {
-   /*
-* The APs use this path later in boot
-*/
-   base = kzalloc_node(sizeof(*base), GFP_KERNEL,
-   cpu_to_node(cpu));
-   if (!base)
-   return -ENOMEM;
-
-   /* Make sure tvec_base has TIMER_FLAG_MASK bits free */
-   if (WARN_ON(base != tbase_get_base(base))) {
-   kfree(base);
-   return -ENOMEM;
-   }
-   per_cpu(tvec_bases, cpu) = base;
+   if (!boot_done) {
+  

[PATCH] Documentation: usb: serial: fixed how to provide vendor and product id

[Marek Belisko]

From: "H. Nikolaus Schaller" 

While trying to test the Pyra GSM/GPS/3G module I had reconfigured
the USB interface by mistake and therefore needed to run a different
USB driver than CSC-ACM. It turned out that I need the "usbserial" driver.

This file is an official description how to use it:
Documentation/usb/usb-serial.txt

But it is outdated. The parameters vendor= and product= are no longer
available since ca. 3.12 which means that documentation is lagging behind
quite some time.

Here was the solution:

https://bbs.archlinux.org/viewtopic.php?id=175499

  insmod usbserial vendor=0x product=0x

becomes (first  is vendor, second is product)

  modprobe usbserial
  echo   >/sys/bus/usb-serial/drivers/generic/new_id

This patch changes the documentation file as needed.

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Marek Belisko 
---
 Documentation/usb/usb-serial.txt | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 947fa62..9f184d8 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -466,11 +466,13 @@ Generic Serial driver
   is required of your device is that it has at least one bulk in endpoint,
   or one bulk out endpoint. 
   
-  To enable the generic driver to recognize your device, build the driver
-  as a module and load it by the following invocation:
-   insmod usbserial vendor=0x product=0x
-  where the  is replaced with the hex representation of your device's
-  vendor id and product id.
+  To enable the generic driver to recognize your device, configure
+  USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the
+  following invocation:
+   modprobe usbserial
+   echo   >/sys/bus/usb-serial/drivers/generic/new_id
+  where the the first  is replaced with the hex representation of your
+  device's vendor id and the second  by the product id.
 
   This driver has been successfully used to connect to the NetChip USB
   development board, providing a way to develop USB firmware without
-- 
1.9.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/