linux.kernel - 26 new messages in 18 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* AlarmDev: Changing is_wakeup() to be a function to pass checkpatch - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf050cae17fdff9f?hl=en
* kernfs, sysfs, driver-core: implement synchronous self-removal - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
* perf: clarify comment regarding event merging - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/386926634b95f0d3?hl=en
* iio: tsl2563: Use the correct channel2 member - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/56e6b7f9b9c61c17?hl=en
* i2c: Re-instate body of i2c_parent_is_i2c_adapter() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eeedc92d1c25429b?hl=en
* Driver/IFC: Move Freescale IFC driver to a common driver - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/e1ab3bbaf7a7d836?hl=en
* thermal: introduce device tree parser - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/96a58763966c5219?hl=en
* driver core/platform: don't leak memory allocated for dma_mask - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/e58e38b5ab26098f?hl=en
* DAS1800: Fixing foo * bar should be foo *bar - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/3ad2131d385b9e1e?hl=en
* reciprocal_divide: correction/update of the algorithm - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/79ceff511638a29b?hl=en
* Staging: ced1401: fix coding style in ced_ioc.c - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/cf0ebd61b1e13adb?hl=en
* x86, acpi memory hotplug, add parameter to disable memory hotplug - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/fea2893681599c3e?hl=en
* cross rename v3 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2b03f04905ff68d3?hl=en
* misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c3af64c6af02e0ba?hl=en
* [v6] phylib: Add Clause 45 read/write functions - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7f6625b87d827e65?hl=en
* ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/39053332c9e18780?hl=en
* x86 Kconfig: create x86/Kconfig.virt - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/350f637b956a1ce6?hl=en
* Documentation/prctl/seccomp_filter.txt: document extensions - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e2f632c51e6112a2?hl=en

==============================================================================
TOPIC: AlarmDev: Changing is_wakeup() to be a function to pass checkpatch
http://groups.google.com/group/linux.kernel/t/cf050cae17fdff9f?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:20 pm
From: Greg KH


On Mon, Jan 13, 2014 at 08:10:36PM +0000, Joe Borg wrote:
> Signed-off-by Joe Borg <cyborg101010@gmail.com>
> ---
> drivers/staging/android/alarm-dev.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/alarm-dev.c b/drivers/staging/android/alarm-dev.c
> index 647694f..87f2a02 100644
> --- a/drivers/staging/android/alarm-dev.c
> +++ b/drivers/staging/android/alarm-dev.c
> @@ -66,13 +66,15 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
> *
> * Return: 1 if this is a wakeup alarm, otherwise 0
> */
> -static int is_wakeup(enum android_alarm_type type)
> +static int is_wakeup(enum andriod_alarm_type type)

Always build test your patches, this one wasn't.

> {
> - return (type == ANDROID_ALARM_RTC_WAKEUP ||
> - type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
> + if (type == ANDROID_ALARM_RTC_WAKEUP ||
> + type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP)
> + return 1;
> + else
> + return 0;

Why are you making this change? There is no logic change here at all.

> }
>
> -

Why remove this line?

Again, you are going to need changelog comments for any patch, please
redo them properly if you wish us to accept your patches.

thanks,

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





==============================================================================
TOPIC: kernfs, sysfs, driver-core: implement synchronous self-removal
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:20 pm
From: Tejun Heo


On Sat, Jan 11, 2014 at 01:45:13PM -0500, Tejun Heo wrote:
> Hey, Greg.
>
> On Fri, Jan 10, 2014 at 04:19:53PM -0800, Greg KH wrote:
> > > It's really late in the -rc cycle for me to take this for 3.14, but I
> > > see patch 1 is a good one to have, so I'll take that now, and queue the
> > > rest up for after 3.14-rc1 is out for 3.15. Is that ok with you, or do
> > > you have patches that depend on this series for 3.14?
> >
> > Oh nevermind, these are all good, now applied :)
>
> I don't have anything depending on the series for the up coming merge
> window so 3.15 merge window would have been fine but 3.14 merge
> windows wokrs too. :)

Greg, I'm sorry but can you please revert the whole series?
get_active() waiting while a node is deactivated has potential to lead
to deadlock and that deactivate/reactivate interface is something
fundamentally flawed and that cgroup will have to work with the
remove_self() like everybody else. IOW, I think the first posting was
correct.

I think we better defer this to the next window and I'll do the whole
thing - kernfs updates & cgroup conversion - together and then push
out patches so that I don't repeat these mistakes.

Sorry about the mess. I got tunnel-visioned thinking about cgroup
semantics too much.

Thank you.

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





==============================================================================
TOPIC: perf: clarify comment regarding event merging
http://groups.google.com/group/linux.kernel/t/386926634b95f0d3?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:30 pm
From: Cody P Schafer


On 01/10/2014 01:36 AM, Peter Zijlstra wrote:
> On Thu, Jan 09, 2014 at 03:51:31PM -0800, Cody P Schafer wrote:
>> There are actually 2 things about software events that allow us to
>> merge them: they never fail to schedule _and_ they have transaction
>> handlers we can (and do, when they are added to !sw groups) ignore. Note
>> both of these in the comment on adding sw events to !sw groups.
>
> The latter is a direct consequence of the former. Since they can always
> be scheduled, they don't need any schedulability testing, and therefore
> the transaction stuff is useless.

Right. I guess what I was getting at were the 2 types of "schedulability":
1. individual event schedulability (ie: "did add() return an error?")
2. txn schedulability (ie: "did commit_txn() return an error?")

I'm in the process of adding a pmu which guarantees #1, but not #2 (it
essentially provides access to some always-running counters which can be
atomically copied in groups). As a result, I'm teasing apart some of the
special casing done for sw events.

This will probably make a bit more sense with some better terminology on
my part and some actual code. I'll update and resend later.


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





==============================================================================
TOPIC: iio: tsl2563: Use the correct channel2 member
http://groups.google.com/group/linux.kernel/t/56e6b7f9b9c61c17?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:30 pm
From: Peter Meerwald



> Use the correct channel2 member instead of channel when dealing with sysfs
> reads/writes

> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>

as a bonus, m is renamed to mask

Acked-by: Peter Meerwald <pmeerw@pmeerw.net>

> ---
> drivers/iio/light/tsl2563.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
> index 5e5d9de..2be6df3 100644
> --- a/drivers/iio/light/tsl2563.c
> +++ b/drivers/iio/light/tsl2563.c
> @@ -460,10 +460,14 @@ static int tsl2563_write_raw(struct iio_dev *indio_dev,
> {
> struct tsl2563_chip *chip = iio_priv(indio_dev);
>
> - if (chan->channel == IIO_MOD_LIGHT_BOTH)
> + if (mask != IIO_CHAN_INFO_CALIBSCALE)
> + return -EINVAL;
> + if (chan->channel2 == IIO_MOD_LIGHT_BOTH)
> chip->calib0 = calib_from_sysfs(val);
> - else
> + else if (chan->channel2 == IIO_MOD_LIGHT_IR)
> chip->calib1 = calib_from_sysfs(val);
> + else
> + return -EINVAL;
>
> return 0;
> }
> @@ -472,14 +476,14 @@ static int tsl2563_read_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan,
> int *val,
> int *val2,
> - long m)
> + long mask)
> {
> int ret = -EINVAL;
> u32 calib0, calib1;
> struct tsl2563_chip *chip = iio_priv(indio_dev);
>
> mutex_lock(&chip->lock);
> - switch (m) {
> + switch (mask) {
> case IIO_CHAN_INFO_RAW:
> case IIO_CHAN_INFO_PROCESSED:
> switch (chan->type) {
> @@ -498,7 +502,7 @@ static int tsl2563_read_raw(struct iio_dev *indio_dev,
> ret = tsl2563_get_adc(chip);
> if (ret)
> goto error_ret;
> - if (chan->channel == 0)
> + if (chan->channel2 == IIO_MOD_LIGHT_BOTH)
> *val = chip->data0;
> else
> *val = chip->data1;
> @@ -510,7 +514,7 @@ static int tsl2563_read_raw(struct iio_dev *indio_dev,
> break;
>
> case IIO_CHAN_INFO_CALIBSCALE:
> - if (chan->channel == 0)
> + if (chan->channel2 == IIO_MOD_LIGHT_BOTH)
> *val = calib_to_sysfs(chip->calib0);
> else
> *val = calib_to_sysfs(chip->calib1);
>

--

Peter Meerwald
+43-664-2444418 (mobile)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: i2c: Re-instate body of i2c_parent_is_i2c_adapter()
http://groups.google.com/group/linux.kernel/t/eeedc92d1c25429b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:30 pm
From: Stephen Warren


From: Stephen Warren <swarren@nvidia.com>

The body of i2c_parent_is_i2c_adapter() is currently guarded by
CONFIG_I2C_MUX instead.

Among potentially other problems, this resulted in i2c_lock_adapter()
only locking I2C mux child adapters, and not the parent adapter. In
turn, this could allow inter-mingling of mux child selection and I2C
transactions, which could result in I2C transactions being directed to
the wrong I2C bus, and possibly even switching between busses in the
middle of a transaction.

One concrete issue caused by this bug was corrupted HDMI EDID reads
during boot on the NVIDIA Tegra Seaboard system, although this only
became apparent in recent linux-next, when the boot timing was changed
just enough to trigger the race condition.

Fixes: 3923172b3d70 ("i2c: reduce parent checking to a NOOP in non-I2C_MUX case")
Cc: Phil Carmody <phil.carmody@partner.samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
include/linux/i2c.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index eff50e062be8..d9c8dbd3373f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -445,7 +445,7 @@ static inline void i2c_set_adapdata(struct i2c_adapter *dev, void *data)
static inline struct i2c_adapter *
i2c_parent_is_i2c_adapter(const struct i2c_adapter *adapter)
{
-#if IS_ENABLED(I2C_MUX)
+#if IS_ENABLED(CONFIG_I2C_MUX)
struct device *parent = adapter->dev.parent;

if (parent != NULL && parent->type == &i2c_adapter_type)
--
1.8.1.5

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





==============================================================================
TOPIC: Driver/IFC: Move Freescale IFC driver to a common driver
http://groups.google.com/group/linux.kernel/t/e1ab3bbaf7a7d836?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 13 2014 1:30 pm
From: Arnd Bergmann


On Monday 13 January 2014, Scott Wood wrote:
> On Mon, 2014-01-13 at 20:45 +0100, Arnd Bergmann wrote:
> > On Monday 13 January 2014, Scott Wood wrote:
> > > On Mon, 2014-01-13 at 14:32 +0100, Arnd Bergmann wrote:
> > > > On Monday 13 January 2014, Prabhakar Kushwaha wrote:
> > > > > Freescale IFC controller has been used for mpc8xxx. It will be used
> > > > > for ARM-based SoC as well. This patch moves the driver to driver/misc
> > > > > and fix the header file includes.
> > > > >
> > > > > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > > >
> > > > No objections to the driver, but drivers/misc doesn't seem like the
> > > > right place. Why not drivers/mfd or drivers/memory?
> > >
> > > It's not a memory controller in the sense that I think most people would
> > > interpret the phrase, but I guess it's similar in function to
> > > mvebu-devbus. If drivers/memory is broad enough to cover such things,
> > > and doesn't have a memory controller subsystem that drivers are supposed
> > > to register with, then that could work.
> > >
> > > Are things in drivers/mfd expected to interact with mfd-core.c? It's
> > > not clear to me what that does or how it would be useful to the IFC
> > > code.
> >
> > Sorry, I meant mtd not mfd. mtd would make sense if the only devices
> > behind it are things like flash or sram memory.
>
> Some of the things behind it are flash, but those portions of the driver
> are already in drivers/mtd. This is just the common code.
>

What are the things that are not flash then?

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




== 2 of 3 ==
Date: Mon, Jan 13 2014 1:30 pm
From: Scott Wood


On Mon, 2014-01-13 at 22:22 +0100, Arnd Bergmann wrote:
> On Monday 13 January 2014, Scott Wood wrote:
> > On Mon, 2014-01-13 at 20:45 +0100, Arnd Bergmann wrote:
> > > On Monday 13 January 2014, Scott Wood wrote:
> > > > On Mon, 2014-01-13 at 14:32 +0100, Arnd Bergmann wrote:
> > > > > On Monday 13 January 2014, Prabhakar Kushwaha wrote:
> > > > > > Freescale IFC controller has been used for mpc8xxx. It will be used
> > > > > > for ARM-based SoC as well. This patch moves the driver to driver/misc
> > > > > > and fix the header file includes.
> > > > > >
> > > > > > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > > > >
> > > > > No objections to the driver, but drivers/misc doesn't seem like the
> > > > > right place. Why not drivers/mfd or drivers/memory?
> > > >
> > > > It's not a memory controller in the sense that I think most people would
> > > > interpret the phrase, but I guess it's similar in function to
> > > > mvebu-devbus. If drivers/memory is broad enough to cover such things,
> > > > and doesn't have a memory controller subsystem that drivers are supposed
> > > > to register with, then that could work.
> > > >
> > > > Are things in drivers/mfd expected to interact with mfd-core.c? It's
> > > > not clear to me what that does or how it would be useful to the IFC
> > > > code.
> > >
> > > Sorry, I meant mtd not mfd. mtd would make sense if the only devices
> > > behind it are things like flash or sram memory.
> >
> > Some of the things behind it are flash, but those portions of the driver
> > are already in drivers/mtd. This is just the common code.
> >
>
> What are the things that are not flash then?

FPGAs or any other random things that might get connected to it on a
custom board.

-Scott


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




== 3 of 3 ==
Date: Mon, Jan 13 2014 2:20 pm
From: Arnd Bergmann


On Monday 13 January 2014, Scott Wood wrote:
> On Mon, 2014-01-13 at 22:22 +0100, Arnd Bergmann wrote:
> > On Monday 13 January 2014, Scott Wood wrote:
> > >
> > > Some of the things behind it are flash, but those portions of the driver
> > > are already in drivers/mtd. This is just the common code.
> > >
> >
> > What are the things that are not flash then?
>
> FPGAs or any other random things that might get connected to it on a
> custom board.

Ok, that is similar to a number of other external buses then, like the
mvebu-devbus.c. I'd suggest you put it in drivers/memory.

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





==============================================================================
TOPIC: thermal: introduce device tree parser
http://groups.google.com/group/linux.kernel/t/96a58763966c5219?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:40 pm
From: Eduardo Valentin


Wei,

On 06-01-2014 22:44, Wei Ni wrote:
> On 01/06/2014 10:54 PM, Eduardo Valentin wrote:
>> * PGP Signed by an unknown key
>>
>> On 06-01-2014 09:51, Mark Rutland wrote:
>>> On Thu, Jan 02, 2014 at 05:50:06PM +0000, Matthew Longnecker wrote:
>>>>
>>>>> I think the platform driver may set governor for the thermal zone,
>>>>> so how about to add a property named as "governor",
>>>>> and parse it to tzp->governor_name,
>>>>> something like:
>>>>> ret = of_property_read_string(child, "governor", &str);
>>>>> if (ret == 0)
>>>>> if (strlen(str) < THERMAL_NAME_LENGTH)
>>>>> strcpy(tzp->governor_name, str);
>>>>>
>>>>> Thanks.
>>>>> Wei.
>>>>
>>>> DT is supposed to describe the hardware, right? The governor isn't
>>>> hardware -- it's a software control policy. On the other hand, that
>>>> control policy must be tuned according to the behaviors of the platform
>>>> hardware otherwise the system will be unstable.
>>>>
>>>> Is it appropriate to be naming the governor in DT? If so, is it equally
>>>> appropriate to describe any governor-specific parameters in DT (even
>>>> though they are pure software constructs)?
>>>
>>> The dt should be relatively static -- if the hardware doesn't change the
>>> dt shouldn't have to.
>>>
>>> The governers are not static. We can introduce new ones and throw away
>>> old ones at any time. Tuning parameters can also change at any time.
>>>
>>> I'd prefer to not have governer details described in the dt, and the
>>> choice of governer and configuration of its tuning parameters should be
>>> made at runtime somehow.
>>
>> Agreed.
>
> Yes, I think so, but the of-thermal driver handle the
> thermal_zone_device_register, and pass the "tzp" without governor_name,

In fact, it will fall into the default governor, which is step_wise, by
default config.

> so the created thermal_zone's governor will be NULL, then it can't run
> into the governor->throttle() if needed. And currently there have no

Actually, no, the tz will be set to default governor, and its throttle
call will be called.

> interface to support updating governor and configuration at runtime.
> I think it's better to initialize the governor_name when register the
> thermal zone device in the of-thermal driver.

Still, why would you need to change the governor from a in kernel
decision? There is an ABI to change the thermal zone policy based on
user(land) request. If you need to change the policy from within the
kernel, which seams to be what you are trying to propose, you need to
explain why you need it, say, by giving at least one user of this API or
explaining its use case.

>
> Thanks.
>
>>
>>>
>>> Thanks,
>>> Mark.
>>>
>>>
>>
>>
>
>
>


--
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin






==============================================================================
TOPIC: driver core/platform: don't leak memory allocated for dma_mask
http://groups.google.com/group/linux.kernel/t/e58e38b5ab26098f?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:40 pm
From: Yann Droneaud


If a dma_mask is provided as part of platform_device_info,
platform_device_register_full() allocate memory for a u64
using kmalloc().

A comment in the code state that "[t]his memory isn't freed
when the device is put".

It's never a good thing to leak memory, but there's only very
few users of platform_device_info's dma_mask, and those are mostly
"static" devices that are not going to be plugged/unplugged.

So memory leak is not really an issue, but allocating 8 bytes
through kmalloc() seems overkill, so this patch moves dma_mask
after the platform_device struct, dynamically allocated along
the name buffer.

With dma_mask part of the memory allocated for the platform_device
struct, like name buffer, it will be released with it:
no memory leak, no small allocation.

The drawback is the additional code needed to handle
dma_mask allocation:

Before (on next-20140113 with gcc-4.8):
text data bss dec hex filename
5600 472 32 6104 17d8 obj-arm/drivers/base/platform.o
5927 532 32 6491 195b obj-i386/drivers/base/platform.o
7036 960 48 8044 1f6c obj-x86_64/drivers/base/platform.o

After:
text data bss dec hex filename
5672 472 32 6176 1820 obj-arm/drivers/base/platform.o
6007 532 32 6571 19ab obj-i386/drivers/base/platform.o
7132 960 48 8140 1fcc obj-x86_64/drivers/base/platform.o

Changes from v0 [1]:
- small rewrite to squeeze the patch to a bare minimal

[1] http://lkml.kernel.org/r/1386886207-2735-1-git-send-email-ydroneaud@opteya.com

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
drivers/base/platform.c | 82 +++++++++++++++++++++++++++++++++++++------------
1 file changed, 62 insertions(+), 20 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..0741be056885 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -157,7 +157,7 @@ EXPORT_SYMBOL_GPL(platform_add_devices);

struct platform_object {
struct platform_device pdev;
- char name[1];
+ char payload[0];
};

/**
@@ -186,6 +186,25 @@ static void platform_device_release(struct device *dev)
kfree(pa);
}

+static struct platform_object *platform_object_alloc(size_t payload)
+{
+ struct platform_object *pa;
+
+ pa = kzalloc(sizeof(*pa) + payload, GFP_KERNEL);
+
+ return pa;
+}
+
+static void platform_object_init(struct platform_object *pa,
+ const char *name, int id)
+{
+ pa->pdev.name = name;
+ pa->pdev.id = id;
+ device_initialize(&pa->pdev.dev);
+ pa->pdev.dev.release = platform_device_release;
+ arch_setup_pdev_archdata(&pa->pdev);
+}
+
/**
* platform_device_alloc - create a platform device
* @name: base name of the device we're adding
@@ -198,14 +217,10 @@ struct platform_device *platform_device_alloc(const char *name, int id)
{
struct platform_object *pa;

- pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
+ pa = platform_object_alloc(strlen(name) + 1);
if (pa) {
- strcpy(pa->name, name);
- pa->pdev.name = pa->name;
- pa->pdev.id = id;
- device_initialize(&pa->pdev.dev);
- pa->pdev.dev.release = platform_device_release;
- arch_setup_pdev_archdata(&pa->pdev);
+ strcpy(pa->payload, name);
+ platform_object_init(pa, pa->payload, id);
}

return pa ? &pa->pdev : NULL;
@@ -213,6 +228,39 @@ struct platform_device *platform_device_alloc(const char *name, int id)
EXPORT_SYMBOL_GPL(platform_device_alloc);

/**
+ * platform_device_dmamask_alloc - create a platform device suitable to hold a dmamask
+ * @name: base name of the device we're adding
+ * @id: instance id
+ *
+ * Create a platform device object which can have other objects attached
+ * to it, and which will have attached objects freed when it is released.
+ */
+static struct platform_device *platform_device_dmamask_alloc(const char *name,
+ int id)
+{
+ struct platform_object *pa;
+ const size_t padding = (((offsetof(struct platform_object, payload) +
+ (__alignof__(u64) - 1)) &
+ ~(__alignof__(u64) - 1)) -
+ offsetof(struct platform_object, payload));
+
+ pa = platform_object_alloc(padding + sizeof(u64) + strlen(name) + 1);
+ if (pa) {
+ char *payload = pa->payload + padding;
+ /*
+ * Conceptually dma_mask in struct device should not be a pointer.
+ * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
+ */
+ pa->pdev.dev.dma_mask = (void *)payload;
+ payload += sizeof(u64);
+ strcpy(payload, name);
+ platform_object_init(pa, payload, id);
+ }
+
+ return pa ? &pa->pdev : NULL;
+}
+
+/**
* platform_device_add_resources - add resources to a platform device
* @pdev: platform device allocated by platform_device_alloc to add resources to
* @res: set of resources that needs to be allocated for the device
@@ -427,7 +475,12 @@ struct platform_device *platform_device_register_full(
int ret = -ENOMEM;
struct platform_device *pdev;

- pdev = platform_device_alloc(pdevinfo->name, pdevinfo->id);
+ if (!pdevinfo->dma_mask)
+ pdev = platform_device_alloc(pdevinfo->name, pdevinfo->id);
+ else
+ pdev = platform_device_dmamask_alloc(pdevinfo->name,
+ pdevinfo->id);
+
if (!pdev)
goto err_alloc;

@@ -435,17 +488,6 @@ struct platform_device *platform_device_register_full(
ACPI_COMPANION_SET(&pdev->dev, pdevinfo->acpi_node.companion);

if (pdevinfo->dma_mask) {
- /*
- * This memory isn't freed when the device is put,
- * I don't have a nice idea for that though. Conceptually
- * dma_mask in struct device should not be a pointer.
- * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
- */
- pdev->dev.dma_mask =
- kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
- if (!pdev->dev.dma_mask)
- goto err;
-
*pdev->dev.dma_mask = pdevinfo->dma_mask;
pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
}
--
1.8.4.2

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





==============================================================================
TOPIC: DAS1800: Fixing foo * bar should be foo *bar
http://groups.google.com/group/linux.kernel/t/3ad2131d385b9e1e?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 13 2014 1:40 pm
From: Greg KH


On Mon, Jan 13, 2014 at 09:23:11PM +0000, Joe Borġ wrote:
> Ok, will do the change log.
>
> Yes, it's my real name and email... I know the email address is embarrassing,
> but genuine :).
>
>
>
> Regards,
> Joseph David Borġ

There's nothing wrong with using "Joe Borġ" as your signed-off-by: line,
as that's your real name :)

thanks,

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




== 2 of 3 ==
Date: Mon, Jan 13 2014 1:50 pm
From: Joe Borg


Fixed an error flagged by checkpatch.pl, 'foo * bar should be foo *bar' in the parameters of function munge_data().

Signed-off-by Joe Borg <cyborg101010@gmail.com>
---
drivers/staging/comedi/drivers/das1800.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/das1800.c b/drivers/staging/comedi/drivers/das1800.c
index 1880038..8fb87df 100644
--- a/drivers/staging/comedi/drivers/das1800.c
+++ b/drivers/staging/comedi/drivers/das1800.c
@@ -462,7 +462,7 @@ static inline uint16_t munge_bipolar_sample(const struct comedi_device *dev,
return sample;
}

-static void munge_data(struct comedi_device *dev, uint16_t * array,
+static void munge_data(struct comedi_device *dev, uint16_t *array,
unsigned int num_elements)
{
unsigned int i;
--
1.8.5.2

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




== 3 of 3 ==
Date: Mon, Jan 13 2014 2:00 pm
From: Greg KH


On Mon, Jan 13, 2014 at 09:47:59PM +0000, Joe Borg wrote:
> Fixed an error flagged by checkpatch.pl, 'foo * bar should be foo *bar' in the parameters of function munge_data().

Please wrap your changelog comments at 72 colums, like git asks you to
when you type them in.

> Signed-off-by Joe Borg <cyborg101010@gmail.com>

No "ġ"?

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





==============================================================================
TOPIC: reciprocal_divide: correction/update of the algorithm
http://groups.google.com/group/linux.kernel/t/79ceff511638a29b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 1:50 pm
From: Hannes Frederic Sowa


This patch is a RFC and part of a series Daniel Borkmann and me want to
do when introducing prandom_u32_range{,_ro} and prandom_u32_max{,_ro}
helpers later this week.

At first Jakub Zawadzki noticed that some divisions by reciprocal_divide
were not correct:
http://www.wireshark.org/~darkjames/reciprocal-buggy.c

He could also show this with BPF:
http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c

Also: reciprocal_value and reciprocal_divide always return 0 for
divisions by 1. This is a bit worrisome as those functions also get
used in mm/slab.c and lib/flex_array.c. Bonding already seems to check
for the 1-divisor case and handles that correctly. We don't know about
other problems, yet.

I propose an correction/update of the algorithm
based on the paper "T. Granlund and P. L. Montgomery:
Division by Invariant Integers Using Multiplication"
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.2556>

The assembler implementation from Agner Fog, found here
<http://www.agner.org/optimize/asmlib.zip>, helped a lot while
implementing.

I would like to have feedback if people see problems with this patch or
have concerns about performance. I did some testing on x86-64 and found
no problems so far but did no performance evaluation, yet.

The current code does break the call-sides of reciprocal_divide. The necessary
changes will be part of the full series, then.

Thanks!
---
include/linux/reciprocal_div.h | 12 +++++++++---
lib/reciprocal_div.c | 22 ++++++++++++++++++----
2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/include/linux/reciprocal_div.h b/include/linux/reciprocal_div.h
index f9c90b3..6f17a87 100644
--- a/include/linux/reciprocal_div.h
+++ b/include/linux/reciprocal_div.h
@@ -22,11 +22,17 @@
* Should not be called before each reciprocal_divide(),
* or else the performance is slower than a normal divide.
*/
-extern u32 reciprocal_value(u32 B);

+struct reciprocal_value {
+ u32 m;
+ u8 sh1, sh2;
+};

-static inline u32 reciprocal_divide(u32 A, u32 R)
+struct reciprocal_value reciprocal_value(u32 d);
+
+static inline u32 reciprocal_divide(u32 a, struct reciprocal_value R)
{
- return (u32)(((u64)A * R) >> 32);
+ u32 t = (u32)(((u64)a * R.m) >> 32);
+ return (t + ((a - t) >> R.sh1)) >> R.sh2;
}