Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc()
Hello Andrew,
On 2015-11-24 오전 7:52, Andrew Morton wrote:
> On Mon, 23 Nov 2015 15:21:15 +0900 Kyeongdon Kim
> wrote:
>
>> When we're using LZ4 multi compression streams for zram swap,
>> we found out page allocation failure message in system running test.
>> That was not only once, but a few(2 - 5 times per test).
>> Also, some failure cases were continually occurring to try allocation
>> order 3.
>>
>> In order to make parallel compression private data, we should call
>> kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
>> 2/3 size memory to allocate in that time, page allocation fails.
>> This patch makes to use vmalloc() as fallback of kmalloc(), this
>> prevents page alloc failure warning.
>>
>> After using this, we never found warning message in running test, also
>> It could reduce process startup latency about 60-120ms in each case.
>>
>> ...
>>
>> --- a/drivers/block/zram/zcomp_lz4.c
>> +++ b/drivers/block/zram/zcomp_lz4.c
>> @@ -10,17 +10,25 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "zcomp_lz4.h"
>>
>> static void *zcomp_lz4_create(void)
>> {
>> - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
>> + void *ret;
>> +
>> + ret = kzalloc(LZ4_MEM_COMPRESS,
>> + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
>> + if (!ret)
>> + ret = vzalloc(LZ4_MEM_COMPRESS);
>> + return ret;
>> }
>
> What's the reasoning behind the modification to the gfp flags?
>
> It clears __GFP_FS, __GFP_IO and even __GFP_WAIT. I suspect the latter
> two (at least) can be retained. And given that vmalloc() uses
> GFP_KERNEL, what's the point in clearing those flags for the kmalloc()
> case?
>
> If this change (or something like it) remains in place, it should have
> a comment which fully explains the reasons, please.
Sorry for the delay in replying,
I just tried to remove that warning message. If there are more rightable
gfp flags(like a code in Minchan's patch), we can use it.
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()
On Tue, Nov 24, 2015 at 04:36:36PM +0900, Sergey Senozhatsky wrote: > On (11/24/15 16:03), Minchan Kim wrote: > > > > Good question. > > > > Actually, failure of allocation came from backend->create as Kyeongdon's > > comment because it requires order-3 allocation which is very fragile > > in embedded system recenlty(Android, webOS. That's why Joonsoo are solving > > the trouble by fixing compaction part). Otherwise, other kmalloc/vmalloc > > stuff in our example would be almost no trouble in real practice(Of course, > > if you says it might, you're absolutely right. It could fail but I think > > it's *really* rare in real practice). > > > > More concern is order-1 allocation rather than kmalloc/vmalloc. > > I've got lots of allocation failure reports from product team until now > > and frankly speaking, I don't get such order-1 fail report until now. > > I guess the reason is that system is almost trobule due to heavy > > fragmentation > > before the notice such failure. > > > > So, I think if we solve order-3 allocation in backend->create, > > above problem will be almost solved. > > hm, ok, may be. > but the question whether we want to waste pages on additional streams > (especially, e.g. if we already have, say, 10 streams) is still valid. > a more intuitive here is to release some unneeded streams, not to increase > our pressure allocating new ones. well, at least it seems to be so. > those pages can be used by zsmalloc, for example. I think your claim make sense if the failure comes from high memory pressure but order-3 alloc failure even if there are lots of order-0 free pages in my experience is easy to encouter so I think it doesn't mean memory pressure but just memory fragmentation. > > > > and I'd prefer it to be a bit different -- use likely path first and > > > avoid an assignment in unlikely path. > > > > Personally, I like one return case unless other is really better for > > performance. I have trained it for Andrew, I belive. :) > > But if you don't like this by performance reason, I will add unlikely > > for vmalloc path. If you hate it just by personal preferenece, please > > I want to stick my code. > > no, I don't hate it. Thanks! > > > > ... and add GFP_NOIO to both kzalloc() and __vmalloc(). > > > > I can add it. The harmness is really ignorable but as I mentioned > > at reply of Andrew, what's the benefit with GFP_NOIO? > > We couldn't make forward progress with __GFP_RECLAIM in reclaim > > context. > > aha, I probably missed that out. > (well, and, technically, things can change). My speaking came from MM internal knowledge so I accept your concern. if you prefer like GFP_NOIO, I will use it in next spin which makes reader less confused. Thanks! > > -ss -- Kind regards, Minchan Kim -- 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: MPT2SAS boot fail... due to silently loosing the driver
Send a patch so we can understand what you mean :) -- 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: MPT2SAS boot fail... due to silently loosing the driver
On 11/24/2015 08:51 AM, Christoph Hellwig wrote: > I wonder what the "classic" way to such transitions is. Adding a mpt2 > option that just selects mpt3 sound easy, but might be very confusing. > Personally, I would rename everything to 'mptXsas', and have the original options map onto that. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Tue, Nov 24, 2015 at 02:06:09PM +0800, dawei chien wrote:
> Hi Sascha,
>
> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct
> > mtk_thermal *mt)
> > +{
> > + struct nvmem_cell *cell;
> > + u32 *buf;
> > + size_t len;
> > + int i, ret;
> > + /* Start with default values */
> > + mt->adc_ge = 512;
> > + for (i = 0; i < MT8173_NUM_SENSORS; i++)
> > + mt->vts[i] = 260;
> > + mt->degc_cali = 40;
> > + mt->o_slope = 0;
> > +
> > + cell = nvmem_cell_get(dev, "calibration-data");
> > + if (IS_ERR(cell)) {
> > + if (PTR_ERR(cell) == -EPROBE_DEFER)
> > + return PTR_ERR(cell);
> > + return 0;
> > + }
> > +
> > + buf = (u32 *)nvmem_cell_read(cell, );
> > +
> > + nvmem_cell_put(cell);
> > +
> > + if (IS_ERR(buf))
> > + return PTR_ERR(buf);
> > +
> > + if (len < 3 * sizeof(u32)) {
> > + dev_warn(dev, "invalid calibration data\n");
> > + ret = -EINVAL;
> > + goto out;
> > + }
>
> ret would not be assigned if the length of calibration data is correct.
> Otherwise,
gcc does a increasingly bad job when it comes to warn about
uninitialized variables :(
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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/
[LINUX PATCH] iio: xadc: fix for extended name remains same issue
If we read channel details based on the device tree entry; channel’s scan_index
and channel’s address were overwritten by scan_index and address of channel
based on device tree. But extended name were remaining same because of which
sysfs entry names were continuous.
So this patch takes care of the above issue by updating 'channels' structure
inside xadc_parse_dt() function with the help of 'xadc_channels' structure
so that every channel's parameters will be updated properly. Also for the
sake of simplicity this patch updates default values for extend_name.
Signed-off-by: Ranjit Waghmode
---
drivers/iio/adc/xilinx-xadc-core.c | 52 +-
1 file changed, 23 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/adc/xilinx-xadc-core.c
b/drivers/iio/adc/xilinx-xadc-core.c
index a221f73..b3f158f 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1015,23 +1015,23 @@ static const struct iio_chan_spec xadc_channels[] = {
XADC_CHAN_VOLTAGE(5, 7, XADC_REG_VCCO_DDR, "vccoddr", true),
XADC_CHAN_VOLTAGE(6, 12, XADC_REG_VREFP, "vrefp", false),
XADC_CHAN_VOLTAGE(7, 13, XADC_REG_VREFN, "vrefn", false),
- XADC_CHAN_VOLTAGE(8, 11, XADC_REG_VPVN, NULL, false),
- XADC_CHAN_VOLTAGE(9, 16, XADC_REG_VAUX(0), NULL, false),
- XADC_CHAN_VOLTAGE(10, 17, XADC_REG_VAUX(1), NULL, false),
- XADC_CHAN_VOLTAGE(11, 18, XADC_REG_VAUX(2), NULL, false),
- XADC_CHAN_VOLTAGE(12, 19, XADC_REG_VAUX(3), NULL, false),
- XADC_CHAN_VOLTAGE(13, 20, XADC_REG_VAUX(4), NULL, false),
- XADC_CHAN_VOLTAGE(14, 21, XADC_REG_VAUX(5), NULL, false),
- XADC_CHAN_VOLTAGE(15, 22, XADC_REG_VAUX(6), NULL, false),
- XADC_CHAN_VOLTAGE(16, 23, XADC_REG_VAUX(7), NULL, false),
- XADC_CHAN_VOLTAGE(17, 24, XADC_REG_VAUX(8), NULL, false),
- XADC_CHAN_VOLTAGE(18, 25, XADC_REG_VAUX(9), NULL, false),
- XADC_CHAN_VOLTAGE(19, 26, XADC_REG_VAUX(10), NULL, false),
- XADC_CHAN_VOLTAGE(20, 27, XADC_REG_VAUX(11), NULL, false),
- XADC_CHAN_VOLTAGE(21, 28, XADC_REG_VAUX(12), NULL, false),
- XADC_CHAN_VOLTAGE(22, 29, XADC_REG_VAUX(13), NULL, false),
- XADC_CHAN_VOLTAGE(23, 30, XADC_REG_VAUX(14), NULL, false),
- XADC_CHAN_VOLTAGE(24, 31, XADC_REG_VAUX(15), NULL, false),
+ XADC_CHAN_VOLTAGE(8, 11, XADC_REG_VPVN, "vpvn", false),
+ XADC_CHAN_VOLTAGE(9, 16, XADC_REG_VAUX(0), "vaux0", false),
+ XADC_CHAN_VOLTAGE(10, 17, XADC_REG_VAUX(1), "vaux1", false),
+ XADC_CHAN_VOLTAGE(11, 18, XADC_REG_VAUX(2), "vaux2", false),
+ XADC_CHAN_VOLTAGE(12, 19, XADC_REG_VAUX(3), "vaux3", false),
+ XADC_CHAN_VOLTAGE(13, 20, XADC_REG_VAUX(4), "vaux4", false),
+ XADC_CHAN_VOLTAGE(14, 21, XADC_REG_VAUX(5), "vaux5", false),
+ XADC_CHAN_VOLTAGE(15, 22, XADC_REG_VAUX(6), "vaux6", false),
+ XADC_CHAN_VOLTAGE(16, 23, XADC_REG_VAUX(7), "vaux7", false),
+ XADC_CHAN_VOLTAGE(17, 24, XADC_REG_VAUX(8), "vaux8", false),
+ XADC_CHAN_VOLTAGE(18, 25, XADC_REG_VAUX(9), "vaux9", false),
+ XADC_CHAN_VOLTAGE(19, 26, XADC_REG_VAUX(10), "vaux10", false),
+ XADC_CHAN_VOLTAGE(20, 27, XADC_REG_VAUX(11), "vaux11", false),
+ XADC_CHAN_VOLTAGE(21, 28, XADC_REG_VAUX(12), "vaux12", false),
+ XADC_CHAN_VOLTAGE(22, 29, XADC_REG_VAUX(13), "vaux13", false),
+ XADC_CHAN_VOLTAGE(23, 30, XADC_REG_VAUX(14), "vaux14", false),
+ XADC_CHAN_VOLTAGE(24, 31, XADC_REG_VAUX(15), "vaux15", false),
};
static const struct iio_info xadc_info = {
@@ -1056,7 +1056,7 @@ static int xadc_parse_dt(struct iio_dev *indio_dev,
struct device_node *np,
unsigned int *conf)
{
struct xadc *xadc = iio_priv(indio_dev);
- struct iio_chan_spec *channels, *chan;
+ struct iio_chan_spec *channels;
struct device_node *chan_node, *child;
unsigned int num_channels;
const char *external_mux;
@@ -1104,7 +1104,6 @@ static int xadc_parse_dt(struct iio_dev *indio_dev,
struct device_node *np,
return -ENOMEM;
num_channels = 9;
- chan = [9];
chan_node = of_get_child_by_name(np, "xlnx,channels");
if (chan_node) {
@@ -1114,22 +1113,17 @@ static int xadc_parse_dt(struct iio_dev *indio_dev,
struct device_node *np,
break;
}
+ channels[num_channels] = xadc_channels[reg + 9];
+ channels[num_channels].channel = num_channels - 1;
+
ret = of_property_read_u32(child, "reg", );
if (ret || reg > 16)
continue;
if (of_property_read_bool(child, "xlnx,bipolar"))
- chan->scan_type.sign = 's';
-
- if (reg == 0) {
- chan->scan_index = 11;
- chan->address = XADC_REG_VPVN;
-
Re: MPT2SAS boot fail... due to silently loosing the driver
I wonder what the "classic" way to such transitions is. Adding a mpt2 option that just selects mpt3 sound easy, but might be very confusing. -- 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: + arc-convert-to-dma_map_ops.patch added to -mm tree
Hi Vineet, the original version went through the buildbot, which succeeded. It seems like the official buildbot does not support arc, and might benefit from helping to set up an arc environment. However in the meantime Guenther send me output from his buildbot and I sent a fix for arc. -- 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] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC
On 2015/11/23 17:40, Lucas Stach wrote: Am Montag, den 23.11.2015, 22:07 +0800 schrieb Bai Ping: The i.MX7Dual/Solo is a new series of the i.MX SOC family. The existing cpufreq driver for 'i.MX6' or 'cpufreq-dt' can NOT match the requirement of this new SOC. This patch adds the cpufreq driver for i.MX7Dual/Solo. So, what are those requirements, which could not be matched with cpufreq-dt? We should really try to not add another cpufreq driver. the requirement is the PLL1 used to source the CPU core clock can NOT change frequency on the fly, during the PLL1 frequency change, not clock output from this PLL1 in a short time. this will lead to glitch to the core clock. so before we change the PLL1's frequency, we must switch the CPU core clock to another clock source, after the PLL1 frequency has been changed, we switch back core clock to PLL1. I don't see anything special in here. A single regulator and some clocks needing to be controlled in the right way. That's already handled for i.MX5 with cpufreq-dt. Please look up how it is done there and try to do it the same way for MX7, or provide substantial information why it couldn't be done. I have checked the i.MX5 cpufreq, As on i.MX5, no need to take care of the PLL's frequency change flow, so the cpufreq-dt is the best one to support cpufreq. But on i.MX7, the PLL design is not the same as on i.MX5, additional steps needed in CPU frequency changing flow. the issue that can NOT be tackled by cpufreq-dt is additional step used by PLL frequency change. BR Jacky Bai Regards, Lucas -- 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 v4] i2c: taos-evm: replace simple_strtoul by kstrtou8
The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtou8.
Reviewed-by: Jean Delvare
Tested-by: Jean Delvare
Signed-off-by: LABBE Corentin
---
drivers/i2c/busses/i2c-taos-evm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-taos-evm.c
b/drivers/i2c/busses/i2c-taos-evm.c
index 4c7fc2d..210ca82 100644
--- a/drivers/i2c/busses/i2c-taos-evm.c
+++ b/drivers/i2c/busses/i2c-taos-evm.c
@@ -130,7 +130,13 @@ static int taos_smbus_xfer(struct i2c_adapter *adapter,
u16 addr,
return 0;
} else {
if (p[0] == 'x') {
- data->byte = simple_strtol(p + 1, NULL, 16);
+ /*
+* Voluntarily dropping error code of kstrtou8 since all
+* error code that it could return are invalid according
+* to Documentation/i2c/fault-codes.
+*/
+ if (kstrtou8(p + 1, 16, >byte))
+ return -EPROTO;
return 0;
}
}
--
2.4.10
--
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: [LINUX PATCH] iio: xadc: fix for extended name remains same issue
On 11/24/2015 07:17 AM, Ranjit Waghmode wrote: > If we read channel details based on the device tree entry; channel’s > scan_index > and channel’s address were overwritten by scan_index and address of channel > based on device tree. But extended name were remaining same because of which > sysfs entry names were continuous. I don't understand this part. Those channels don't have a extended name, they are always NULL. Those are added as part of this patch as well, but the patch description makes it sound like it is a fix for a existing issue. > > So this patch takes care of the above issue by updating 'channels' structure > inside xadc_parse_dt() function with the help of 'xadc_channels' structure > so that every channel's parameters will be updated properly. Also for the > sake of simplicity this patch updates default values for extend_name. We can't really do that, that would break existing applications. And to be honest I don't think regular channels should have a extended name. -- 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 v4] i2c: taos-evm: replace simple_strtoul by kstrto
Hello Change since v3 - Added reviewed-by and tested-by - Fix Capital letter and missing dot in the comment. Changes since v2 - removed err variable - fix a spelling issue Changes since v1 - drop the return code of kstrtou8 and return -EPROTO as suggested by Jean Delvare - Added a comment on the return code drop Regards LABBE Corentin (1): i2c: taos-evm: replace simple_strtoul by kstrtou8 drivers/i2c/busses/i2c-taos-evm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.4.10 -- 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] thermal: ti-soc-thermal: fix error check
On Mon, Nov 23, 2015 at 03:25:43PM -0800, Eduardo Valentin wrote:
> On Mon, Nov 23, 2015 at 06:24:41PM +0530, Sudip Mukherjee wrote:
> > We were only checking if data is not NULL but
> > ti_bandgap_get_sensor_data() can return NULL or ERR_PTR.
>
> Do you have a fail case? Can you please send the logs too?
>
> >
> > Signed-off-by: Sudip Mukherjee
> > ---
> > drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> > b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> > index b213a12..d76bb7c 100644
> > --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> > +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> > @@ -365,7 +365,7 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp,
> > int id)
> >
> > data = ti_bandgap_get_sensor_data(bgp, id);
> >
> > - if (data && data->ti_thermal) {
> > + if (!IS_ERR_OR_NULL(data) && data->ti_thermal) {
>
> I don t really see the need for this as we always
> ti_bandgap_set_sensor_data with a valid pointer, never with a ERR PTR.
> So, it would be either valid or NULL.
ERR_PTR is not coming from ti_bandgap_set_sensor_data(). In
ti_bandgap_get_sensor_data() if ti_bandgap_validate() fails then it
returns ERR_PTR(ret). So just by checking for NULL we are not checking
for any error return from ti_bandgap_validate().
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] x86/RAS: Remove mce.usable_addr
From: Borislav Petkov
It is useless and we can use the function instead. Besides, mcelog(8)
hasn't managed to make use of it yet. So kill it.
Signed-off-by: Borislav Petkov
Acked-by: Tony Luck
---
arch/x86/include/uapi/asm/mce.h | 2 +-
arch/x86/kernel/cpu/mcheck/mce.c | 12
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/uapi/asm/mce.h b/arch/x86/include/uapi/asm/mce.h
index 03429da2fa80..2184943341bf 100644
--- a/arch/x86/include/uapi/asm/mce.h
+++ b/arch/x86/include/uapi/asm/mce.h
@@ -16,7 +16,7 @@ struct mce {
__u8 cpuvendor;/* cpu vendor as encoded in system.h */
__u8 inject_flags; /* software inject flags */
__u8 severity;
- __u8 usable_addr;
+ __u8 pad;
__u32 cpuid;/* CPUID 1 EAX */
__u8 cs; /* code segment */
__u8 bank; /* machine check bank */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 6531cb46803c..fb8b1db7b150 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -484,7 +484,7 @@ static int srao_decode_notifier(struct notifier_block *nb,
unsigned long val,
if (!mce)
return NOTIFY_DONE;
- if (mce->usable_addr && (mce->severity == MCE_AO_SEVERITY)) {
+ if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
pfn = mce->addr >> PAGE_SHIFT;
memory_failure(pfn, MCE_VECTOR, 0);
}
@@ -610,12 +610,9 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
severity = mce_severity(, mca_cfg.tolerant, NULL, false);
- if (severity == MCE_DEFERRED_SEVERITY && memory_error()) {
- if (m.status & MCI_STATUS_ADDRV) {
+ if (severity == MCE_DEFERRED_SEVERITY && memory_error())
+ if (m.status & MCI_STATUS_ADDRV)
m.severity = severity;
- m.usable_addr = mce_usable_address();
- }
- }
/*
* Don't get the IP here because it's unlikely to
@@ -623,7 +620,7 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
*/
if (!(flags & MCP_DONTLOG) && !mca_cfg.dont_log_ce)
mce_log();
- else if (m.usable_addr) {
+ else if (mce_usable_address()) {
/*
* Although we skipped logging this, we still want
* to take action. Add to the pool so the registered
@@ -1091,7 +1088,6 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
/* assuming valid severity level != 0 */
m.severity = severity;
- m.usable_addr = mce_usable_address();
mce_log();
--
2.3.5
--
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/4] x86/mce: Do not enter deferred errors into the generic pool twice
From: Tony Luck
We used to have a special ring buffer for deferred errors that was used
to mark problem pages. We replaced that with a generic pool. Then later
converted mce_log() to also use the same pool. As a result, we end up
adding all deferred errors to the pool twice.
Rearrange this code. Make sure to set the m.severity and m.usable_addr
fields for deferred errors. Then if flags and mca_cfg.dont_log_ce mean
we call mce_log() we are done, because that will add this entry to the
generic pool.
If we skipped mce_log(), then we still want to take action for the
deferred error, so add to the pool.
Change the name of the boolean "error_logged" to "error_seen", we should
set it whether of not we logged an error because the return value from
machine_check_poll() is used to decide whether storms have subsided or
not.
Reported-by: Gong Chen
Signed-off-by: Tony Luck
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: linux-edac
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/3165a4989dcb45fc0306438d40d0cf2ace429c4c.1447280215.git.tony.l...@intel.com
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/mcheck/mce.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c5b0d562dbf5..6531cb46803c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -567,7 +567,7 @@ DEFINE_PER_CPU(unsigned, mce_poll_count);
*/
bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b)
{
- bool error_logged = false;
+ bool error_seen = false;
struct mce m;
int severity;
int i;
@@ -601,6 +601,8 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
(m.status & (mca_cfg.ser ? MCI_STATUS_S : MCI_STATUS_UC)))
continue;
+ error_seen = true;
+
mce_read_aux(, i);
if (!(flags & MCP_TIMESTAMP))
@@ -608,17 +610,10 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
severity = mce_severity(, mca_cfg.tolerant, NULL, false);
- /*
-* In the cases where we don't have a valid address after all,
-* do not add it into the ring buffer.
-*/
if (severity == MCE_DEFERRED_SEVERITY && memory_error()) {
if (m.status & MCI_STATUS_ADDRV) {
m.severity = severity;
m.usable_addr = mce_usable_address();
-
- if (!mce_gen_pool_add())
- mce_schedule_work();
}
}
@@ -626,9 +621,16 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
* Don't get the IP here because it's unlikely to
* have anything to do with the actual error location.
*/
- if (!(flags & MCP_DONTLOG) && !mca_cfg.dont_log_ce) {
- error_logged = true;
+ if (!(flags & MCP_DONTLOG) && !mca_cfg.dont_log_ce)
mce_log();
+ else if (m.usable_addr) {
+ /*
+* Although we skipped logging this, we still want
+* to take action. Add to the pool so the registered
+* notifiers will see it.
+*/
+ if (!mce_gen_pool_add())
+ mce_schedule_work();
}
/*
@@ -644,7 +646,7 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
sync_core();
- return error_logged;
+ return error_seen;
}
EXPORT_SYMBOL_GPL(machine_check_poll);
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] x86/mce: Make usable address checks Intel-only
From: Borislav Petkov
The MCi_MISC bitfield definitions mce_usable_address() checks are
Intel-only. Make them so.
While at it, move mce_usable_address() up, before all its callers and
get rid of the forward declaration.
Signed-off-by: Borislav Petkov
Acked-by: Tony Luck
---
arch/x86/kernel/cpu/mcheck/mce.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index e00e85ab7387..3865e95cc5ec 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -114,7 +114,6 @@ static struct work_struct mce_work;
static struct irq_work mce_irq_work;
static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
-static int mce_usable_address(struct mce *m);
/*
* CPU/chipset specific EDAC code can register a notifier call here to print
@@ -475,6 +474,28 @@ static void mce_report_event(struct pt_regs *regs)
irq_work_queue(_irq_work);
}
+/*
+ * Check if the address reported by the CPU is in a format we can parse.
+ * It would be possible to add code for most other cases, but all would
+ * be somewhat complicated (e.g. segment offset would require an instruction
+ * parser). So only support physical addresses up to page granuality for now.
+ */
+static int mce_usable_address(struct mce *m)
+{
+ if (!(m->status & MCI_STATUS_MISCV) || !(m->status & MCI_STATUS_ADDRV))
+ return 0;
+
+ /* Checks after this one are Intel-specific: */
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return 1;
+
+ if (MCI_MISC_ADDR_LSB(m->misc) > PAGE_SHIFT)
+ return 0;
+ if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
+ return 0;
+ return 1;
+}
+
static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
void *data)
{
@@ -930,23 +951,6 @@ reset:
return ret;
}
-/*
- * Check if the address reported by the CPU is in a format we can parse.
- * It would be possible to add code for most other cases, but all would
- * be somewhat complicated (e.g. segment offset would require an instruction
- * parser). So only support physical addresses up to page granuality for now.
- */
-static int mce_usable_address(struct mce *m)
-{
- if (!(m->status & MCI_STATUS_MISCV) || !(m->status & MCI_STATUS_ADDRV))
- return 0;
- if (MCI_MISC_ADDR_LSB(m->misc) > PAGE_SHIFT)
- return 0;
- if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
- return 0;
- return 1;
-}
-
static void mce_clear_state(unsigned long *toclear)
{
int i;
--
2.3.5
--
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/4] RAS stuff for tip:x86/ras
From: Borislav Petkov Hi Ingo, here a couple of small fixes for x86/ras for 4.5. Please apply, thanks. Borislav Petkov (3): x86/RAS: Remove mce.usable_addr x86/mce: Add the missing memory error check on AMD x86/mce: Make usable address checks Intel-only Tony Luck (1): x86/mce: Do not enter deferred errors into the generic pool twice arch/x86/include/uapi/asm/mce.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 82 2 files changed, 43 insertions(+), 41 deletions(-) -- 2.3.5 -- 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: [PATH RESEND v2 03/10] tty: xuartps: Always enable transmitter in start_tx
Hi Peter, On 23.11.2015 21:00, Peter Hurley wrote: > Hi Michal, > > On 11/23/2015 02:05 AM, Michal Simek wrote: >> All these tests looks very interesting. Do you have any any >> work-in-progress repo with other tests? It will be good to run all of >> them to validate our drivers. > > I haven't upstreamed these yet, but I plan to do so soon, along with > tty core, pty, n_tty i/o, termios, and torture tests and some basic tools. great. Can you please keep me in the loop? Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] x86/mce: Add the missing memory error check on AMD
From: Borislav Petkov
We simply need to look at the extended error code when detecting whether
the error is of type memory.
Signed-off-by: Borislav Petkov
Acked-by: Tony Luck
---
arch/x86/kernel/cpu/mcheck/mce.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index fb8b1db7b150..e00e85ab7387 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -522,10 +522,10 @@ static bool memory_error(struct mce *m)
struct cpuinfo_x86 *c = _cpu_data;
if (c->x86_vendor == X86_VENDOR_AMD) {
- /*
-* coming soon
-*/
- return false;
+ /* ErrCodeExt[20:16] */
+ u8 xec = (m->status >> 16) & 0x1f;
+
+ return (xec == 0x0 || xec == 0x8);
} else if (c->x86_vendor == X86_VENDOR_INTEL) {
/*
* Intel SDM Volume 3B - 15.9.2 Compound Error Codes
--
2.3.5
--
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 0/3] ARM: OMAP2+ McASP(3) support for DRA7xx family
Tony, On 11/12/2015 08:00 PM, Tony Lindgren wrote: > * Peter Ujfalusi [15 23:33]: >> Hi Tony, >> >> Changes since v3: >> - rebased on mainline's HEAD >> - Added Tested-by from Felipe >> - Added Acked-by from Paul for the hwmod patches >> >> Changes since v2: >> - DTS patch added which is needed because of the clock handling changes >> >> Felip Balbi reported that linux-next is broken right now since the DTS part >> of >> the earlier series has been applied, but we do not have the mcasp hwmod in >> the >> kernel: >> ... >> [0.181029] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3' >> ... >> [6.121072] davinci-mcasp 48468000.mcasp: _od_fail_runtime_resume: FIXME: >> missing hwmod/omap_dev info >> [6.130790] [ cut here ] >> [6.135643] WARNING: CPU: 0 PID: 244 at drivers/bus/omap_l3_noc.c:147 >> l3_interrupt_handler+0x220/0x34c() >> [6.145576] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 >> (Read): Data Access in User mode during Functional access > > > Thanks applying all three into omap-for-v4.4/fixes. Do you know when these patches are going to be merged to mainline? 4.4-rc2 is out, but it does not include them. -- 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] mm/compaction: __compact_pgdat() code cleanuup
On Tue, Nov 24, 2015 at 03:24:42PM +0900, Joonsoo Kim wrote:
> This patch uses is_via_compact_memory() to distinguish direct compaction.
> And it also reduces indentation on compaction_defer_reset
> by filtering failure case. There is no functional change.
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/compaction.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index de3e1e7..2b1a15e 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1658,14 +1658,17 @@ static void __compact_pgdat(pg_data_t *pgdat, struct
> compact_control *cc)
> !compaction_deferred(zone, cc->order))
> compact_zone(zone, cc);
>
> - if (cc->order > 0) {
> - if (zone_watermark_ok(zone, cc->order,
> - low_wmark_pages(zone), 0, 0))
> - compaction_defer_reset(zone, cc->order, false);
> - }
> -
> VM_BUG_ON(!list_empty(>freepages));
> VM_BUG_ON(!list_empty(>migratepages));
> +
> + if (is_via_compact_memory(cc->order))
> + continue;
> +
> + if (!zone_watermark_ok(zone, cc->order,
> + low_wmark_pages(zone), 0, 0))
> + continue;
> +
> + compaction_defer_reset(zone, cc->order, false);
> }
> }
This makes more sense,
Acked-by: Yaowei Bai
>
> --
> 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: [RFD] CAT user space interface revisited
On Wed, Nov 18, 2015 at 07:25:03PM +0100, Thomas Gleixner wrote: > > Let's look at partitioning itself. We have two options: > >1) Per task partitioning > >2) Per CPU partitioning > > So far we only talked about #1, but I think that #2 has a value as > well. Let me give you a simple example. I would second this. In practice per CPU partitioning is useful for realtime as well. And I can see three possible solutions: 1) What you suggested below, to address both problems in one framework. But I wonder if it would end with too complex. 2) Achieve per CPU partitioning with per task partitioning. For example, if current CAT patch can solve the kernel threads problem, together with CPU pinning, we then can set a same CBM for all the tasks/kernel threads run on an isolated CPU. 3) I wonder if it feasible to separate the two requirements? For example, divides the work into three components: rdt-base, per task interface (current cgroup interface/IOCTL or something) and per CPU interface. The two interfaces are exclusive and selected at build time. One thing to reject this option would be even with per CPU partitioning, we still need per task partitioning, in that case we will go to option 1) again. Thanks, Chao -- 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: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors into the genpool.
On Tue, Nov 24, 2015 at 12:19:18AM +, Luck, Tony wrote: > > Also, two more fixes I've done while injecting in a kvm guest I'm > > sending as a reply to this message. Will inject on a real box too. > > Ok ... applied those two on top of my "UNTESTED" patch and injected an error > to force a UCNA log. Ok, what error type is that in EINJ nomenclature? I had only /sys/kernel/debug/apei/einj/available_error_type:0x0002 Processor Uncorrectable non-fatal /sys/kernel/debug/apei/einj/available_error_type:0x0008 Memory Correctable /sys/kernel/debug/apei/einj/available_error_type:0x0010 Memory Uncorrectable non-fatal and I would've guessed it is the 0x10 type, i.e., the memory uncorrectable which is non-fatal - assuming here - but that one got promoted to a #MC on my box. The processor uncorrectable didn't want to inject due to missing EINJ instruction 0x5 or so... > Everything looked ok. Just one copy on the console and in > /var/log/mcelog (actually logs from bank7 and bank3 ... but that was > expected from this test). Good. > So my patch is tested, and take this > > Acked-by: Tony Luck for your two additional patches. Thanks! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- 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 tools: Introduce perf_thread for backtrace
Hi Jiri,
On Fri, Nov 20, 2015 at 10:29:48AM +0100, Jiri Olsa wrote:
> On Fri, Nov 20, 2015 at 03:03:03PM +0900, Namhyung Kim wrote:
> > Backtrace is a crucial info for debugging. And upcoming refcnt
> > tracking facility also wants to use it.
> >
> > So instead of relying on glibc's backtrace_symbols[_fd] which misses
> > some (static) functions , use our own symbol searching mechanism. To
> > do that, add perf_thread global variable to keep its maps and symbols.
> >
> > The backtrace output from TUI is changed like below. (I made a key
> > action to generate a segfault for testing):
> >
> > Before:
> > perf: Segmentation fault
> > backtrace
> > perf[0x544a8b]
> > /usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
> > perf[0x54041b]
> > perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
> > perf(cmd_report+0x1d20)[0x43cb10]
> > perf[0x487073]
> > perf(main+0x62f)[0x42cb1f]
> > /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
> > perf(_start+0x29)[0x42cc39]
> > [0x0]
> >
> > After:
> > perf: Segmentation fault
> > backtrace
> > perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
> > perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
> > cmd_report(+0x1d20) in perf [0x43cb50]
> > run_builtin(+0x53) in perf [0x4870b3]
> > main(+0x634) in perf [0x42cb54]
> > __libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
> > _start(+0x29) in perf [0x42cc79]
> > [0x0]
>
> nice idea!
>
> SNIP
>
> > +
> > +void create_perf_thread(void)
> > +{
> > + struct perf_tool tool = {
> > + .comm = perf_event__process_comm,
> > + .mmap = perf_event__process_mmap,
> > + .mmap2 = perf_event__process_mmap2,
> > + };
> > + struct thread_map *tm;
> > + struct machine *machine;
> > + int pid = getpid();
> > +
> > + machine = machine__new_host();
> > + if (machine == NULL)
> > + return;
> > +
> > + tm = thread_map__new_dummy();
> > + if (tm == NULL) {
> > + machine__delete(machine);
> > + return;
> > + }
>
> I think we could treat errors the usual way in here..
> if fail to alloc this early, something is terribly wrong anyway
OK, I'll change it to return error code and let perf fail with it.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()
On (11/24/15 16:03), Minchan Kim wrote: > > Good question. > > Actually, failure of allocation came from backend->create as Kyeongdon's > comment because it requires order-3 allocation which is very fragile > in embedded system recenlty(Android, webOS. That's why Joonsoo are solving > the trouble by fixing compaction part). Otherwise, other kmalloc/vmalloc > stuff in our example would be almost no trouble in real practice(Of course, > if you says it might, you're absolutely right. It could fail but I think > it's *really* rare in real practice). > > More concern is order-1 allocation rather than kmalloc/vmalloc. > I've got lots of allocation failure reports from product team until now > and frankly speaking, I don't get such order-1 fail report until now. > I guess the reason is that system is almost trobule due to heavy fragmentation > before the notice such failure. > > So, I think if we solve order-3 allocation in backend->create, > above problem will be almost solved. hm, ok, may be. but the question whether we want to waste pages on additional streams (especially, e.g. if we already have, say, 10 streams) is still valid. a more intuitive here is to release some unneeded streams, not to increase our pressure allocating new ones. well, at least it seems to be so. those pages can be used by zsmalloc, for example. > > and I'd prefer it to be a bit different -- use likely path first and > > avoid an assignment in unlikely path. > > Personally, I like one return case unless other is really better for > performance. I have trained it for Andrew, I belive. :) > But if you don't like this by performance reason, I will add unlikely > for vmalloc path. If you hate it just by personal preferenece, please > I want to stick my code. no, I don't hate it. > > ... and add GFP_NOIO to both kzalloc() and __vmalloc(). > > I can add it. The harmness is really ignorable but as I mentioned > at reply of Andrew, what's the benefit with GFP_NOIO? > We couldn't make forward progress with __GFP_RECLAIM in reclaim > context. aha, I probably missed that out. (well, and, technically, things can change). -ss -- 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 tools: Introduce perf_thread for backtrace
On Mon, Nov 23, 2015 at 06:39:36PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Nov 20, 2015 at 03:03:03PM +0900, Namhyung Kim escreveu: > > Backtrace is a crucial info for debugging. And upcoming refcnt > > tracking facility also wants to use it. > > > > So instead of relying on glibc's backtrace_symbols[_fd] which misses > > some (static) functions , use our own symbol searching mechanism. To > > do that, add perf_thread global variable to keep its maps and symbols. > > > > The backtrace output from TUI is changed like below. (I made a key > > action to generate a segfault for testing): > > This is a really nice use of what we have, I guess we could simplify > things further, not having to create a struct machine, as we have just > one thread, and we're not interested in kernel addresses, so no need for > kmaps, etc. Yes, I thought about it. But as adding the perf thread to an existing machine can affect other thread(s), I didn't do it. Maybe we can set the perf threads' machine pointer in a hacky way without adding the thread into the machine, but I'd rather not doing that too because it's fragile and current code is simple enough IMHO. > > But as-is it already looks better than what we were using :-) > > I'll try testing it further and will probably switch to using it if > nobody voices any problem we haven't realised with such approach. Thank you! Namhyung -- 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] libertas: fix possible NULL dereference
On Tue, Nov 24, 2015 at 01:43:38AM +0200, Andy Shevchenko wrote: > On Mon, Nov 23, 2015 at 2:32 PM, Sudip Mukherjee > wrote: > > We were dereferencing cmd first and checking for NULL later. Lets first > > check for NULL. > > However the patch is valid due to reducing error prone part, the > commit message seems wrong. I will send v2 with modified commit message. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: quirks: Fix another ELAN touchscreen
On Mon, 2015-11-23 at 18:37 +0100, Adrien Vergé wrote: > > Makes one wonder however whether we shouldn't be applying > ALWAYS_POLL to > > all ELAN devices by default anyway. > > True! But I don't want to risk breaking anything on other models in > this patch. ALWAYS_POLL just extends an existing behavior. The chances of breaking anything are slim. I'd go for the approach based on the vendor ID. Regards Oliver -- 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 v5 5/8] watchdog: Simplify update_worker
Hi Uwe, On 11/23/2015 11:13 PM, Uwe Kleine-König wrote: Hello, On Sun, Nov 22, 2015 at 07:21:02PM -0800, Guenter Roeck wrote: Drop 'cancel' parameter; simply cancel worker unconditionally if not needed. Signed-off-by: Guenter Roeck This is a good change, but given that watchdog_update_worker is introduced in this series it should be squashed accordingly. As I tried to explain, I didn't squash it because, even though I could not find any trouble with it, I am still not sure if it may cause trouble or not. As such, I found it better to keep it separate to make it easier to revert it _if_, as unlikely as it may be, it should be needed. Ultimately I'd like to get some input from Wim on this. Thanks, 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: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace
Hi Arnaldo and Masami, On Fri, Nov 20, 2015 at 09:10:44AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Nov 20, 2015 at 09:05:23AM +, 平松雅巳 / HIRAMATU，MASAMI escreveu: > > >From: Namhyung Kim [mailto:namhy...@kernel.org] > > > > > >Backtrace is a crucial info for debugging. And upcoming refcnt > > >tracking facility also wants to use it. > > > > > >So instead of relying on glibc's backtrace_symbols[_fd] which misses > > >some (static) functions , use our own symbol searching mechanism. To > > >do that, add perf_thread global variable to keep its maps and symbols. > > > > Hmm, I doubt that this can work for debugging situation, because > > sometimes backtrace facilities has to debug itself by itself. > > That is a valid point, possibly we can have both and when we think that > the code we rely on for resolving symbols has issues, activate the > other, more expensive, binutils/elfutils spawned command line utilities > to do compare the results? Yeah, that's a possible solution. We can start by using our own, and if there's a certain amount of failure in symbol resolving, then fallback to glibc's backtrace_symbols + addr2line. > > > For the some (static) functions, I'd rather like to use glibc's > > backtrace_symbols and addr2line or even with raw address for > > reliability... I also printed the raw addresses in case of doubts, so you could verify its correctness. :) And IMHO, if something is severely broken, we might not rely on glibc too. Having said that, I agree with your concern and it needs the fallback method for possible malfunction. But I guess it'd work quite well for most cases so it's worth trying to convert using it. I'll work on the fallback method then.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/3] ASoC: fsl_esai: spba clock is needed by esai device
ESAI need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to ESAI registers.
Signed-off-by: Shengjiu Wang
---
Documentation/devicetree/bindings/sound/fsl,esai.txt | 5 +
sound/soc/fsl/fsl_esai.c | 13 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt
b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index d3b6b5f..cd3ee5d 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -27,6 +27,11 @@ Required properties:
derive HCK, SCK and FS.
"fsys"The system clock derived from ahb clock used to
derive HCK, SCK and FS.
+ "spba"The spba clock is required when ESAI is placed as a
+ bus slave of the Shared Peripheral Bus and when two
+ or more bus masters (CPU, DMA or DSP) try to access
+ it. This property is optional depending on the SoC
+ design.
- fsl,fifo-depth : The number of elements in the transmit and receive
FIFOs. This number is the maximum allowed value for
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 504e731..4d7589c 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -35,6 +35,7 @@
* @coreclk: clock source to access register
* @extalclk: esai clock source to derive HCK, SCK and FS
* @fsysclk: system clock source to derive HCK, SCK and FS
+ * @spbaclk: SPBA clock (optional, depending on SoC design)
* @fifo_depth: depth of tx/rx FIFO
* @slot_width: width of each DAI slot
* @slots: number of slots
@@ -54,6 +55,7 @@ struct fsl_esai {
struct clk *coreclk;
struct clk *extalclk;
struct clk *fsysclk;
+ struct clk *spbaclk;
u32 fifo_depth;
u32 slot_width;
u32 slots;
@@ -469,6 +471,9 @@ static int fsl_esai_startup(struct snd_pcm_substream
*substream,
ret = clk_prepare_enable(esai_priv->coreclk);
if (ret)
return ret;
+ ret = clk_prepare_enable(esai_priv->spbaclk);
+ if (ret)
+ goto err_spbaclk;
if (!IS_ERR(esai_priv->extalclk)) {
ret = clk_prepare_enable(esai_priv->extalclk);
if (ret)
@@ -499,6 +504,8 @@ err_fsysclk:
if (!IS_ERR(esai_priv->extalclk))
clk_disable_unprepare(esai_priv->extalclk);
err_extalck:
+ clk_disable_unprepare(esai_priv->spbaclk);
+err_spbaclk:
clk_disable_unprepare(esai_priv->coreclk);
return ret;
@@ -564,6 +571,7 @@ static void fsl_esai_shutdown(struct snd_pcm_substream
*substream,
clk_disable_unprepare(esai_priv->fsysclk);
if (!IS_ERR(esai_priv->extalclk))
clk_disable_unprepare(esai_priv->extalclk);
+ clk_disable_unprepare(esai_priv->spbaclk);
clk_disable_unprepare(esai_priv->coreclk);
}
@@ -819,6 +827,11 @@ static int fsl_esai_probe(struct platform_device *pdev)
dev_warn(>dev, "failed to get fsys clock: %ld\n",
PTR_ERR(esai_priv->fsysclk));
+ esai_priv->spbaclk = devm_clk_get(>dev, "spba");
+ if (IS_ERR(esai_priv->spbaclk))
+ dev_warn(>dev, "failed to get spba clock: %ld\n",
+ PTR_ERR(esai_priv->spbaclk));
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "no irq for node %s\n", pdev->name);
--
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 v3 0/5] Make cpuid <-> nodeid mapping persistent.
On 11/24/2015 06:04 AM, Tejun Heo wrote: Hello, On Thu, Nov 19, 2015 at 12:22:10PM +0800, Tang Chen wrote: [Solution] There are four mappings in the kernel: 1. nodeid (logical node id) <-> pxm 2. apicid (physical cpu id) <-> nodeid 3. cpuid (logical cpu id) <-> apicid 4. cpuid (logical cpu id) <-> nodeid 1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <-> pxm mapping is setup at boot time. This mapping is persistent, won't change. 2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at boot time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is also persistent. 3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is allocated, lower ids first, and released at CPU hotremove time, reused for other hotadded CPUs. So this mapping is not persistent. 4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and cleared at CPU hotremove time. As a result of 3, this mapping is not persistent. To fix this problem, we establish cpuid <-> nodeid mapping for all the possible cpus at boot time, and make it persistent. And according to init_cpu_to_node(), cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <-> apicid mapping. So the key point is obtaining all cpus' apicid. I don't know much about acpi so can't actually review the patches but the overall approach looks good to me. Thank you, TJ. Will test it recently. Thanks. -- This message has been scanned for viruses and dangerous content by Fujitsu, and is believed to be clean. -- 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 v5 1/8] watchdog: Introduce hardware maximum timeout in watchdog core
Hello Guenter, On Sun, Nov 22, 2015 at 07:20:58PM -0800, Guenter Roeck wrote: > Introduce an optional hardware maximum timeout in the watchdog core. > The hardware maximum timeout can be lower than the maximum timeout. > > Drivers can set the maximum hardware timeout value in the watchdog data > structure. If the configured timeout exceeds the maximum hardware timeout, > the watchdog core enables a timer function to assist sending keepalive > requests to the watchdog driver. > > Cc: Timo Kokkonen > Signed-off-by: Guenter Roeck Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 v5 5/8] watchdog: Simplify update_worker
Hello, On Sun, Nov 22, 2015 at 07:21:02PM -0800, Guenter Roeck wrote: > Drop 'cancel' parameter; simply cancel worker unconditionally > if not needed. > > Signed-off-by: Guenter Roeck This is a good change, but given that watchdog_update_worker is introduced in this series it should be squashed accordingly. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: smtpe-ts: better way of using of_property_read_u32()
On 24-11-15, 12:36, Saurabh Sengar wrote:
> better way of using of_property_read_u32(), helps remove one variable
> and many 'if' conditions
>
> Signed-off-by: Saurabh Sengar
> ---
> drivers/input/touchscreen/stmpe-ts.c | 29 ++---
> 1 file changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/input/touchscreen/stmpe-ts.c
> b/drivers/input/touchscreen/stmpe-ts.c
> index e414d43..51abe62 100644
> --- a/drivers/input/touchscreen/stmpe-ts.c
> +++ b/drivers/input/touchscreen/stmpe-ts.c
> @@ -268,27 +268,18 @@ static void stmpe_ts_get_platform_info(struct
> platform_device *pdev,
> struct stmpe_touch *ts)
> {
> struct device_node *np = pdev->dev.of_node;
> - u32 val;
>
> if (np) {
> - if (!of_property_read_u32(np, "st,sample-time", ))
> - ts->sample_time = val;
> - if (!of_property_read_u32(np, "st,mod-12b", ))
> - ts->mod_12b = val;
> - if (!of_property_read_u32(np, "st,ref-sel", ))
> - ts->ref_sel = val;
> - if (!of_property_read_u32(np, "st,adc-freq", ))
> - ts->adc_freq = val;
> - if (!of_property_read_u32(np, "st,ave-ctrl", ))
> - ts->ave_ctrl = val;
> - if (!of_property_read_u32(np, "st,touch-det-delay", ))
> - ts->touch_det_delay = val;
> - if (!of_property_read_u32(np, "st,settling", ))
> - ts->settling = val;
> - if (!of_property_read_u32(np, "st,fraction-z", ))
> - ts->fraction_z = val;
> - if (!of_property_read_u32(np, "st,i-drive", ))
> - ts->i_drive = val;
> + of_property_read_u32(np, "st,sample-time", >sample_time);
> + of_property_read_u32(np, "st,mod-12b", >mod_12b);
> + of_property_read_u32(np, "st,ref-sel", >ref_sel);
> + of_property_read_u32(np, "st,adc-freq", >adc_freq);
> + of_property_read_u32(np, "st,ave-ctrl", >ave_ctrl);
> + of_property_read_u32(np, "st,touch-det-delay",
> + >touch_det_delay);
> + of_property_read_u32(np, "st,settling", >settling = val);
> + of_property_read_u32(np, "st,fraction-z", >fraction_z);
> + of_property_read_u32(np, "st,i-drive", >i_drive);
NAK.
You just broke it, all the pointers you passed were of type u8 *..
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams
On Tue, Nov 24, 2015 at 03:00:37PM +0900, Sergey Senozhatsky wrote:
> [..]
> > static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
> > {
> > - struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_KERNEL);
> > + struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> > if (!zstrm)
> > return NULL;
> >
> > @@ -85,7 +85,7 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp
> > *comp)
> > * allocate 2 pages. 1 for compressed data, plus 1 extra for the
> > * case when compressed size is larger than the original one
> > */
> > - zstrm->buffer = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> > 1);
> > + zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
> > if (!zstrm->private || !zstrm->buffer) {
> > zcomp_strm_free(comp, zstrm);
> > zstrm = NULL;
>
> hm... this is not enough.
> we allocate
>
> stream GFP_NOIO
> stream private GFP_KERNEL still old flags
> stream buffer
>
> so my patch was something like this:
Oops, I missed that. Sorry.
I will include it in next spin.
Thanks!
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()
On Tue, Nov 24, 2015 at 03:42:49PM +0900, Sergey Senozhatsky wrote:
> On (11/24/15 15:12), Sergey Senozhatsky wrote:
> > [..]
> > > static void *zcomp_lz4_create(void)
> > > {
> > > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
> > > + void *ret;
> > > +
> > > + /*
> > > +* This function could be called in swapout/fs write path
> > > +* so we couldn't use GFP_FS|IO. And it assumes we already
> > > +* have at least one stream in zram initialization so we
> > > +* don't do best effort to allocate more stream in here.
> > > +* A default stream will work well without further multiple
> > > +* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
> > > +*/
> > > + ret = kzalloc(LZ4_MEM_COMPRESS,
> > > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
> > > + if (!ret)
> > > + ret = __vmalloc(LZ4_MEM_COMPRESS,
> > > + __GFP_NORETRY|__GFP_NOWARN|
> > > + __GFP_NOMEMALLOC|__GFP_ZERO,
> > > + PAGE_KERNEL);
> > > + return ret;
> > > }
> > [..]
> >
> > so this change is still questionable. is there a real value in having
> > a vmalloc() fallback in the middle of allocations sequence:
> >
> > zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> > ^^^ ok, can fail here
> >
>
> oh, and by the way, we still can get a warning from this guy. so NOWARN in
> ->create() only is not enough, should be propogated to zstrm alloc too.
> so is __get_free_pages() (that was not in the original patch).
>
> so pass nowarn everywhere.
>
> perhaps something like (__GFP_NORETRY... hm...):
Yep. zcomp_strm_alloc has several allocation side and they have used
different flags so in our discussion, there are a few time mistakes to
miss so I want to pass gfp_t from client to zcomp_strm_alloc and
all of allocation sites in zcomp_strm_alloc use the flag consistenly
like my [3/3].
Thanks.
>
> ---
>
> drivers/block/zram/zcomp.c | 6 --
> drivers/block/zram/zcomp_lz4.c | 3 ++-
> drivers/block/zram/zcomp_lzo.c | 3 ++-
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index c536177..c0d02d5 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -76,7 +76,8 @@ static void zcomp_strm_free(struct zcomp *comp, struct
> zcomp_strm *zstrm)
> */
> static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
> {
> - struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> + struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO |
> + __GFP_NORETRY | __GFP_NOWARN | __GFP_NOMEMALLOC);
> if (!zstrm)
> return NULL;
>
> @@ -85,7 +86,8 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp
> *comp)
>* allocate 2 pages. 1 for compressed data, plus 1 extra for the
>* case when compressed size is larger than the original one
>*/
> - zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
> + zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_NOWARN |
> + __GFP_ZERO, 1);
> if (!zstrm->private || !zstrm->buffer) {
> zcomp_strm_free(comp, zstrm);
> zstrm = NULL;
> diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
> index ee44b51..dbeee93 100644
> --- a/drivers/block/zram/zcomp_lz4.c
> +++ b/drivers/block/zram/zcomp_lz4.c
> @@ -15,7 +15,8 @@
>
> static void *zcomp_lz4_create(void)
> {
> - return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO);
> + return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> + __GFP_NOWARN | __GFP_NOMEMALLOC);
> }
>
> static void zcomp_lz4_destroy(void *private)
> diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
> index 683ce04..19c0857 100644
> --- a/drivers/block/zram/zcomp_lzo.c
> +++ b/drivers/block/zram/zcomp_lzo.c
> @@ -15,7 +15,8 @@
>
> static void *lzo_create(void)
> {
> - return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO);
> + return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> + __GFP_NOWARN | __GFP_NOMEMALLOC);
> }
>
> static void lzo_destroy(void *private)
--
Kind regards,
Minchan Kim
--
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] Input: smtpe-ts: better way of using of_property_read_u32()
better way of using of_property_read_u32(), helps remove one variable
and many 'if' conditions
Signed-off-by: Saurabh Sengar
---
drivers/input/touchscreen/stmpe-ts.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/stmpe-ts.c
b/drivers/input/touchscreen/stmpe-ts.c
index e414d43..51abe62 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -268,27 +268,18 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
struct stmpe_touch *ts)
{
struct device_node *np = pdev->dev.of_node;
- u32 val;
if (np) {
- if (!of_property_read_u32(np, "st,sample-time", ))
- ts->sample_time = val;
- if (!of_property_read_u32(np, "st,mod-12b", ))
- ts->mod_12b = val;
- if (!of_property_read_u32(np, "st,ref-sel", ))
- ts->ref_sel = val;
- if (!of_property_read_u32(np, "st,adc-freq", ))
- ts->adc_freq = val;
- if (!of_property_read_u32(np, "st,ave-ctrl", ))
- ts->ave_ctrl = val;
- if (!of_property_read_u32(np, "st,touch-det-delay", ))
- ts->touch_det_delay = val;
- if (!of_property_read_u32(np, "st,settling", ))
- ts->settling = val;
- if (!of_property_read_u32(np, "st,fraction-z", ))
- ts->fraction_z = val;
- if (!of_property_read_u32(np, "st,i-drive", ))
- ts->i_drive = val;
+ of_property_read_u32(np, "st,sample-time", >sample_time);
+ of_property_read_u32(np, "st,mod-12b", >mod_12b);
+ of_property_read_u32(np, "st,ref-sel", >ref_sel);
+ of_property_read_u32(np, "st,adc-freq", >adc_freq);
+ of_property_read_u32(np, "st,ave-ctrl", >ave_ctrl);
+ of_property_read_u32(np, "st,touch-det-delay",
+ >touch_det_delay);
+ of_property_read_u32(np, "st,settling", >settling = val);
+ of_property_read_u32(np, "st,fraction-z", >fraction_z);
+ of_property_read_u32(np, "st,i-drive", >i_drive);
}
}
--
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 V3 3/3] ASoC: fsl_asrc: spba clock is needed by asrc device
ASRC need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to ASRC registers
Signed-off-by: Shengjiu Wang
---
Documentation/devicetree/bindings/sound/fsl,asrc.txt | 5 +
sound/soc/fsl/fsl_asrc.c | 10 ++
sound/soc/fsl/fsl_asrc.h | 2 ++
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
index b93362a..3e26a94 100644
--- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
@@ -25,6 +25,11 @@ Required properties:
"mem" Peripheral access clock to access registers.
"ipg" Peripheral clock to driver module.
"asrck_<0-f>" Clock sources for input and output clock.
+ "spba"The spba clock is required when ASRC is placed as a
+ bus slave of the Shared Peripheral Bus and when two
+ or more bus masters (CPU, DMA or DSP) try to access
+ it. This property is optional depending on the SoC
+ design.
- big-endian: If this property is absent, the little endian
mode
will be in use as default. Otherwise, the big endian
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 9f087d4..800828e 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -859,6 +859,10 @@ static int fsl_asrc_probe(struct platform_device *pdev)
return PTR_ERR(asrc_priv->ipg_clk);
}
+ asrc_priv->spba_clk = devm_clk_get(>dev, "spba");
+ if (IS_ERR(asrc_priv->spba_clk))
+ dev_warn(>dev, "failed to get spba clock\n");
+
for (i = 0; i < ASRC_CLK_MAX_NUM; i++) {
sprintf(tmp, "asrck_%x", i);
asrc_priv->asrck_clk[i] = devm_clk_get(>dev, tmp);
@@ -939,6 +943,9 @@ static int fsl_asrc_runtime_resume(struct device *dev)
ret = clk_prepare_enable(asrc_priv->ipg_clk);
if (ret)
goto disable_mem_clk;
+ ret = clk_prepare_enable(asrc_priv->spba_clk);
+ if (ret)
+ goto disable_ipg_clk;
for (i = 0; i < ASRC_CLK_MAX_NUM; i++) {
ret = clk_prepare_enable(asrc_priv->asrck_clk[i]);
if (ret)
@@ -950,6 +957,8 @@ static int fsl_asrc_runtime_resume(struct device *dev)
disable_asrck_clk:
for (i--; i >= 0; i--)
clk_disable_unprepare(asrc_priv->asrck_clk[i]);
+ clk_disable_unprepare(asrc_priv->spba_clk);
+disable_ipg_clk:
clk_disable_unprepare(asrc_priv->ipg_clk);
disable_mem_clk:
clk_disable_unprepare(asrc_priv->mem_clk);
@@ -963,6 +972,7 @@ static int fsl_asrc_runtime_suspend(struct device *dev)
for (i = 0; i < ASRC_CLK_MAX_NUM; i++)
clk_disable_unprepare(asrc_priv->asrck_clk[i]);
+ clk_disable_unprepare(asrc_priv->spba_clk);
clk_disable_unprepare(asrc_priv->ipg_clk);
clk_disable_unprepare(asrc_priv->mem_clk);
diff --git a/sound/soc/fsl/fsl_asrc.h b/sound/soc/fsl/fsl_asrc.h
index 4aed63c..68802cd 100644
--- a/sound/soc/fsl/fsl_asrc.h
+++ b/sound/soc/fsl/fsl_asrc.h
@@ -426,6 +426,7 @@ struct fsl_asrc_pair {
* @paddr: physical address to the base address of registers
* @mem_clk: clock source to access register
* @ipg_clk: clock source to drive peripheral
+ * @spba_clk: SPBA clock (optional, depending on SoC design)
* @asrck_clk: clock sources to driver ASRC internal logic
* @lock: spin lock for resource protection
* @pair: pair pointers
@@ -442,6 +443,7 @@ struct fsl_asrc {
unsigned long paddr;
struct clk *mem_clk;
struct clk *ipg_clk;
+ struct clk *spba_clk;
struct clk *asrck_clk[ASRC_CLK_MAX_NUM];
spinlock_t lock;
--
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/3] zram: try vmalloc() after kmalloc()
On Tue, Nov 24, 2015 at 03:12:58PM +0900, Sergey Senozhatsky wrote:
> [..]
> > static void *zcomp_lz4_create(void)
> > {
> > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
> > + void *ret;
> > +
> > + /*
> > +* This function could be called in swapout/fs write path
> > +* so we couldn't use GFP_FS|IO. And it assumes we already
> > +* have at least one stream in zram initialization so we
> > +* don't do best effort to allocate more stream in here.
> > +* A default stream will work well without further multiple
> > +* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
> > +*/
> > + ret = kzalloc(LZ4_MEM_COMPRESS,
> > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
> > + if (!ret)
> > + ret = __vmalloc(LZ4_MEM_COMPRESS,
> > + __GFP_NORETRY|__GFP_NOWARN|
> > + __GFP_NOMEMALLOC|__GFP_ZERO,
> > + PAGE_KERNEL);
> > + return ret;
> > }
> [..]
>
> so this change is still questionable. is there a real value in having
> a vmalloc() fallback in the middle of allocations sequence:
>
> zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> ^^^ ok, can fail here
>
> zstrm->zstrm->private = comp->backend->create();
> ^^^ kzalloc() and vmalloc() fallback ??
>
> zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
> ^^^ can fail here again.
>
> can you please comment on this?
Good question.
Actually, failure of allocation came from backend->create as Kyeongdon's
comment because it requires order-3 allocation which is very fragile
in embedded system recenlty(Android, webOS. That's why Joonsoo are solving
the trouble by fixing compaction part). Otherwise, other kmalloc/vmalloc
stuff in our example would be almost no trouble in real practice(Of course,
if you says it might, you're absolutely right. It could fail but I think
it's *really* rare in real practice).
More concern is order-1 allocation rather than kmalloc/vmalloc.
I've got lots of allocation failure reports from product team until now
and frankly speaking, I don't get such order-1 fail report until now.
I guess the reason is that system is almost trobule due to heavy fragmentation
before the notice such failure.
So, I think if we solve order-3 allocation in backend->create,
above problem will be almost solved.
>
>
> and I'd prefer it to be a bit different -- use likely path first and
> avoid an assignment in unlikely path.
Personally, I like one return case unless other is really better for
performance. I have trained it for Andrew, I belive. :)
But if you don't like this by performance reason, I will add unlikely
for vmalloc path. If you hate it just by personal preferenece, please
I want to stick my code.
> ... and add GFP_NOIO to both kzalloc() and __vmalloc().
I can add it. The harmness is really ignorable but as I mentioned
at reply of Andrew, what's the benefit with GFP_NOIO?
We couldn't make forward progress with __GFP_RECLAIM in reclaim
context.
>
> and there is no __GFP_HIGHMEM in __vmalloc() call?
Good to have. Thanks for the hint!
Thanks.
>
> something like this:
>
> ---
>
>
> ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> __GFP_NOWARN | __GFP_NOMEMALLOC);
> if (ret)
> return ret;
>
> return __vmalloc(LZ4_MEM_COMPRESS,
> GFP_NOIO | __GFP_NOWARN | __GFP_HIGHMEM | __GFP_ZERO,
> PAGE_KERNEL);
>
>
> -ss
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/3] add spba clock for fsl audio IP
add spba clock for fsl audio IP Changes in V3 - update the comments for clock description. Shengjiu Wang (3): ASoC: fsl_esai: spba clock is needed by esai device ASoC: fsl_spdif: spba clk is needed by spdif device ASoC: fsl_asrc: spba clock is needed by asrc device Documentation/devicetree/bindings/sound/fsl,asrc.txt | 5 + Documentation/devicetree/bindings/sound/fsl,esai.txt | 5 + Documentation/devicetree/bindings/sound/fsl,spdif.txt | 5 + sound/soc/fsl/fsl_asrc.c | 10 ++ sound/soc/fsl/fsl_asrc.h | 2 ++ sound/soc/fsl/fsl_esai.c | 13 + sound/soc/fsl/fsl_spdif.c | 15 +++ 7 files changed, 55 insertions(+) -- 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 V3 2/3] ASoC: fsl_spdif: spba clk is needed by spdif device
SPDIF need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to SPDIF registers.
Signed-off-by: Shengjiu Wang
---
Documentation/devicetree/bindings/sound/fsl,spdif.txt | 5 +
sound/soc/fsl/fsl_spdif.c | 15 +++
2 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index b5ee32e..4ca39dd 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -27,6 +27,11 @@ Required properties:
Transceiver Clock Diagram" of SoC reference manual.
It can also be referred to TxClk_Source bit of
register SPDIF_STC.
+ "spba"The spba clock is required when SPDIF is placed as a
+ bus slave of the Shared Peripheral Bus and when two
+ or more bus masters (CPU, DMA or DSP) try to access
+ it. This property is optional depending on the SoC
+ design.
- big-endian: If this property is absent, the native endian
mode
will be in use as default, or the big endian mode
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 28a8823..64e2a1f 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -88,6 +88,7 @@ struct spdif_mixer_control {
* @rxclk: rx clock sources for capture
* @coreclk: core clock for register access via DMA
* @sysclk: system clock for rx clock rate measurement
+ * @spbaclk: SPBA clock (optional, depending on SoC design)
* @dma_params_tx: DMA parameters for transmit channel
* @dma_params_rx: DMA parameters for receive channel
*/
@@ -106,6 +107,7 @@ struct fsl_spdif_priv {
struct clk *rxclk;
struct clk *coreclk;
struct clk *sysclk;
+ struct clk *spbaclk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
/* regcache for SRPC */
@@ -474,6 +476,12 @@ static int fsl_spdif_startup(struct snd_pcm_substream
*substream,
return ret;
}
+ ret = clk_prepare_enable(spdif_priv->spbaclk);
+ if (ret) {
+ dev_err(>dev, "failed to enable spba clock\n");
+ goto err_spbaclk;
+ }
+
ret = spdif_softreset(spdif_priv);
if (ret) {
dev_err(>dev, "failed to soft reset\n");
@@ -515,6 +523,8 @@ disable_txclk:
for (i--; i >= 0; i--)
clk_disable_unprepare(spdif_priv->txclk[i]);
err:
+ clk_disable_unprepare(spdif_priv->spbaclk);
+err_spbaclk:
clk_disable_unprepare(spdif_priv->coreclk);
return ret;
@@ -548,6 +558,7 @@ static void fsl_spdif_shutdown(struct snd_pcm_substream
*substream,
spdif_intr_status_clear(spdif_priv);
regmap_update_bits(regmap, REG_SPDIF_SCR,
SCR_LOW_POWER, SCR_LOW_POWER);
+ clk_disable_unprepare(spdif_priv->spbaclk);
clk_disable_unprepare(spdif_priv->coreclk);
}
}
@@ -1261,6 +1272,10 @@ static int fsl_spdif_probe(struct platform_device *pdev)
return PTR_ERR(spdif_priv->coreclk);
}
+ spdif_priv->spbaclk = devm_clk_get(>dev, "spba");
+ if (IS_ERR(spdif_priv->spbaclk))
+ dev_warn(>dev, "no spba clock in devicetree\n");
+
/* Select clock source for rx/tx clock */
spdif_priv->rxclk = devm_clk_get(>dev, "rxtx1");
if (IS_ERR(spdif_priv->rxclk)) {
--
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/9] IB: add a proper completion queue abstraction
On Mon, Nov 23, 2015 at 06:35:28PM -0800, Caitlin Bestler wrote: > Is it possible for an IB HCA to transmit a response on a QP and not > in that packet or a previous packet acknowledge something that it > has delivered to the user? AFAIK, the rules of ack coalescing do not interact with the send side. Even if they did, that is the wrong place to look at. We must look at the receiver. Ordered ack,data on the wire may suffer a packet loss and the ack may not reach the reciever. In this case can the reciever detect the lost ack and not progress the data? For IB, it cannot. The ack sequencing is part of the transmitters recv FSM, and does not interact with the send FSM. I feel this a deliberate IB design choice to be simple and efficient in hardware. > My recollection of the IB verbs is that they were unlikely to have > overlooked something like that. If it did slip through then there > should be an errata. verbs reflects the wire protocol and the wire protocol has no way to create a linkage between the send and recv sides of a RC QP. It is not a spec bug, there is no errata. > But regardless of specification lawyering, is this an implementation > issue. All IB implementations have no choice but to act this way - the wire protocol provides no way to guarentee ack vs data sequencing at the receiver, so there is simply no way to guarentee the sendq advances strictly causally with the recvq. > Are there actual HCAs that make this mistake? All IB HCAs have this behavior and require apps to see a send CQ completion before making any statements about the state of the send Q or buffers handed over to the HCA. Tom and I have seen this in real systems under proper stress conditions. [Which is why I am so certain about this, because when I first hit it years ago I dug into the spec and figured out it was not a HW bug I was looking at] This is a direct consequence of how IB runs the ACK protocol. Jason -- 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: crash tool - problem with new Xen linear virtual mapped sparse p2m list
On 23/11/15 21:18, Daniel Kiper wrote: > Hi all, > > Some time ago Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8 > (xen: switch to linear virtual mapped sparse p2m list) introduced linear > virtual mapped sparse p2m list. It fixed some issues, however, it broke > crash tool too. I tried to fix this issue but the problem looks more > difficult than I expected. > > Let's focus on "crash vmcore vmlinux". vmcore file was generated from dom0. > "crash vmcore xen-syms" works without any issue. > > At first sight problem looks simple. Just add a function which reads p2m list > from vmcore and voila. I have done it. Then another issue arisen. > > Please take a look at following backtrace: > > #24426 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24427 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, > mfn=1299707) at kernel.c:9050 > #24428 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at > kernel.c:8867 > #24429 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 > #24430 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) > at x86_64.c:1997 > #24431 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) > at x86_64.c:1887 > #24432 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, > paddr=0x7fff51c7c100, verbose=0) at memory.c:2900 > #24433 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24434 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, > mfn=1299707) at kernel.c:9050 > #24435 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at > kernel.c:8867 > #24436 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 > #24437 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) > at x86_64.c:1997 > #24438 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) > at x86_64.c:1887 > #24439 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, > paddr=0x7fff51c7ca60, verbose=0) at memory.c:2900 > #24440 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24441 0x0050f746 in __xen_pvops_m2p_vma (machine=6364917760, > mfn=1553935) at kernel.c:9050 > #24442 0x0050edb7 in __xen_m2p (machine=6364917760, mfn=1553935) at > kernel.c:8867 > #24443 0x0050e948 in xen_m2p (machine=6364917760) at kernel.c:8796 > #2 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) > at x86_64.c:1997 > #24445 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) > at x86_64.c:1887 > #24446 0x0048d708 in kvtop (tc=0x0, kvaddr=18446744072099176512, > paddr=0x7fff51c7d3c0, verbose=0) at memory.c:2900 > #24447 0x0048b0f6 in readmem (addr=18446744072099176512, memtype=1, > buffer=0xfbb500, size=768, > type=0x8fd772 "module struct", error_handle=6) at memory.c:2157 > #24448 0x004fb0ab in module_init () at kernel.c:3355 > > As you can see module_init() calls readmem() which attempts to read virtual > address > which lies outside of kernel text mapping (0x8000 - > 0xa000). > In this case addr=18446744072099176512 == 0xa003a040 which is known > as module > mapping space. readmem() needs physical address, so, it calls kvtop() then > kvtop() > calls x86_64_kvtop(). x86_64_kvtop() is not able to easily calculate, using > simple > arithmetic like in case of kernel text mapping space, physical address from > virtual > address. Hence it calls x86_64_kvtop_xen_wpt() to calculate it by traversing > page > tables. x86_64_kvtop_xen_wpt() needs to do some m2p translation so it calls > xen_m2p() > which calls __xen_m2p() and finally it calls __xen_pvops_m2p_vma() (my > function which > tries to read linear virtual mapped sparse p2m list). Then > __xen_pvops_m2p_vma() calls > readmem() which tries to read addr=18446683600570023936 == 0xc900 > which > is VMA used for m2p list. Well, once again physical address must be > calculated by > traversing page tables. However, this requires access to m2p list which leads > to > another readmem() call. Starting from here we are in the loop. After > thousands of > repetitions crash dies due to stack overflow. Not nice... :-((( > > Do we have any viable fix for this issue? I considered a few but I have not > found
Re: [PATCH v7 0/6] Build and support rk3036 SoC platform
OK, Thanks Heiko. :-) On 2015年11月24日 08:03, Heiko Stübner wrote: Hi Xing Zheng, Am Donnerstag, 5. November 2015, 15:33:54 schrieb Xing Zheng: Hi, We need to support rk3036 soc platform via upstream, there are some primary parts for the initial release of minimum system: dts, clk-pll, smp, and clock tree for rk3036, and additional, we can use these startup and run to init processs. [...] after talking with Mike and agreeing that I'm again taking the regular clock patches to them, I've applied all of this to appropriate branches. I did some cosmetics, as explained below. Xing Zheng (6): dt-bindings: add documentation of rk3036 clock controller clk: rockchip: add dt-binding header for rk3036 clk: rockchip: add new pll-type for rk3036 and similar socs - wrapped some overly long lines, otherwise this is similar to what Stephen already took for the rk3066-pll-type. clk: rockchip: add clock controller for rk3036 ARM: dts: rockchip: add core rk3036 dts - split off the evb into a separate patch - reordered some nodes (please order by the address (the @) - reordered some properties - fixed the gic cpu masks ARM: dts: enable smp for rk3036 folded into the core dtsi addition Please take a final look at [0] to make sure I didn't mess up anything. Thanks Heiko [0] https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-clk/next https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-armsoc/dts32 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] ARM: dts: sun8i: Add SID node
On Tue, Nov 24, 2015 at 2:38 PM, Maxime Ripard
wrote:
> On Tue, Nov 24, 2015 at 11:13:13AM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Mon, Nov 23, 2015 at 8:43 PM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Mon, Nov 23, 2015 at 09:02:48AM +0100, Josef Gajdusek wrote:
>> >> Add a node describing the Security ID memory to the
>> >> Allwinner H3 .dtsi file.
>> >>
>> >> Signed-off-by: Josef Gajdusek
>> >> ---
>> >> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>> >> 1 file changed, 7 insertions(+)
>> >>
>> >> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>> >> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> >> index 0faa38a..58de718 100644
>> >> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> >> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> >> @@ -359,6 +359,13 @@
>> >> #size-cells = <0>;
>> >> };
>> >>
>> >> + sid: eeprom@01c14000 {
>> >> + compatible = "allwinner,sun4i-a10-sid";
>> >> + reg = <0x01c14000 0x400>;
>> >
>> > The datasheet says it's 256 bytes wide, while the size here is of 1kB,
>> > is it intentional?
>>
>> My H3 datasheet (v1.1) says its 1 kB wide.
>
> Is it? in the Security ID section, it is said to be 2kb == 256B wide.
Right. I was looking at the memory map. Maybe it's sparsely mapped?
I guess we'll know soon.
ChenYu
>> It'd be nice if Allwinner actually listed the "usable" E-fuse
>> offsets and widths, instead of having us dig through the SDK code.
>
> Yep.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, 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 RESEND 06/16] mfd: add TI LMU driver
On 11/24/2015 11:35 AM, Kim, Milo wrote:
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(lmu->regmap, reg, );
+ if (ret < 0)
+ return ret;
+
+ *read = (u8)val;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ti_lmu_read_byte);
It doesn't get much more simple than this.
What's the purpose of abstracting it?
+int ti_lmu_write_byte(struct ti_lmu *lmu, u8 reg, u8 data)
+{
+ return regmap_write(lmu->regmap, reg, data);
+}
+EXPORT_SYMBOL_GPL(ti_lmu_write_byte);
+
+int ti_lmu_update_bits(struct ti_lmu *lmu, u8 reg, u8 mask, u8 data)
+{
+ return regmap_update_bits(lmu->regmap, reg, mask, data);
+}
+EXPORT_SYMBOL_GPL(ti_lmu_update_bits);
Okay, I lied, it does get more simple.
Seems like abstraction for the sake of abstraction here.
Feel free to try and convince me otherwise.
The main reason was that LMU MFD core provides consistent register
access among LMU drivers like ti-lmu-backlight, leds-lm3633,
lm363x-regulator and ti-lmu-fault-monitor('ti-lmu-hwmon' will be changed
to this in the 2nd patch).
However, LMU register helpers are exactly same as regmap interface
except using ti_lmu data structure. So let me replace them with regmap
functions. Thanks for pointing this out.
I just realized LMU MFD core helpers also provide module dependencies by
using EXPORT_SYMBOL_GPL().
# modprobe -D ti-lmu-backlight
insmod /lib/modules//kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules//kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules//kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules//kernel/drivers/video/backlight/ti-lmu-backlight.ko
# modprobe -D ti-lmu-fault-monitor
insmod /lib/modules//kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules//kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules//kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules//kernel/drivers/mfd/ti-lmu-fault-monitor.ko
# modprobe -D lm363x-regulator
insmod /lib/modules//kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules//kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules//kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules//kernel/drivers/regulator/lm363x-regulator.ko
# modprobe -D leds-lm3633
insmod /lib/modules//kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules//kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules//kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules//kernel/drivers/leds/leds-lm3633.ko
ti-lmu.ko should be loaded first because it has hardware enable pin
control code. Four other drivers have dependency on this module. Without
EXPORT_SYMBOL_GPL(), this dependency will be gone like below.
# modprobe -D ti-lmu-backlight
insmod /lib/modules//kernel/drivers/video/backlight/ti-lmu-backlight.ko
# modprobe -D ti-lmu-fault-monitor
insmod /lib/modules//kernel/drivers/mfd/ti-lmu-fault-monitor.ko
# modprobe -D lm363x-regulator
insmod /lib/modules//kernel/drivers/regulator/lm363x-regulator.ko
# modprobe -D leds-lm3633
insmod /lib/modules//kernel/drivers/leds/leds-lm3633.ko
If LMU MFD core module is not loaded and other modules call regmap
helpers, then loaded drivers will not work because hardware is not
enabled yet.
So I'd like to keep LMU MFD helpers for module dependencies.
Additionally, I'll modify 'ti_lmu_read_byte()' as follows.
int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
{
return regmap_read(lmu->regmap, reg, (unsigned int *)read);
}
EXPORT_SYMBOL_GPL(ti_lmu_read_byte);
Please let me know if you have better idea.
Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()
On (11/24/15 15:12), Sergey Senozhatsky wrote:
> [..]
> > static void *zcomp_lz4_create(void)
> > {
> > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
> > + void *ret;
> > +
> > + /*
> > +* This function could be called in swapout/fs write path
> > +* so we couldn't use GFP_FS|IO. And it assumes we already
> > +* have at least one stream in zram initialization so we
> > +* don't do best effort to allocate more stream in here.
> > +* A default stream will work well without further multiple
> > +* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
> > +*/
> > + ret = kzalloc(LZ4_MEM_COMPRESS,
> > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
> > + if (!ret)
> > + ret = __vmalloc(LZ4_MEM_COMPRESS,
> > + __GFP_NORETRY|__GFP_NOWARN|
> > + __GFP_NOMEMALLOC|__GFP_ZERO,
> > + PAGE_KERNEL);
> > + return ret;
> > }
> [..]
>
> so this change is still questionable. is there a real value in having
> a vmalloc() fallback in the middle of allocations sequence:
>
> zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> ^^^ ok, can fail here
>
oh, and by the way, we still can get a warning from this guy. so NOWARN in
->create() only is not enough, should be propogated to zstrm alloc too.
so is __get_free_pages() (that was not in the original patch).
so pass nowarn everywhere.
perhaps something like (__GFP_NORETRY... hm...):
---
drivers/block/zram/zcomp.c | 6 --
drivers/block/zram/zcomp_lz4.c | 3 ++-
drivers/block/zram/zcomp_lzo.c | 3 ++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index c536177..c0d02d5 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -76,7 +76,8 @@ static void zcomp_strm_free(struct zcomp *comp, struct
zcomp_strm *zstrm)
*/
static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
{
- struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
+ struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO |
+ __GFP_NORETRY | __GFP_NOWARN | __GFP_NOMEMALLOC);
if (!zstrm)
return NULL;
@@ -85,7 +86,8 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
* allocate 2 pages. 1 for compressed data, plus 1 extra for the
* case when compressed size is larger than the original one
*/
- zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
+ zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_NOWARN |
+ __GFP_ZERO, 1);
if (!zstrm->private || !zstrm->buffer) {
zcomp_strm_free(comp, zstrm);
zstrm = NULL;
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index ee44b51..dbeee93 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -15,7 +15,8 @@
static void *zcomp_lz4_create(void)
{
- return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO);
+ return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
+ __GFP_NOWARN | __GFP_NOMEMALLOC);
}
static void zcomp_lz4_destroy(void *private)
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index 683ce04..19c0857 100644
--- a/drivers/block/zram/zcomp_lzo.c
+++ b/drivers/block/zram/zcomp_lzo.c
@@ -15,7 +15,8 @@
static void *lzo_create(void)
{
- return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO);
+ return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
+ __GFP_NOWARN | __GFP_NOMEMALLOC);
}
static void lzo_destroy(void *private)
--
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] clk: imx: add 'is_prepared' clk_ops callback for pllv3 clk
On Tue, Nov 03, 2015 at 02:06:09AM +0800, Bai Ping wrote:
> Add 'is_prepared' callback function for pllv3 type clk to make sure when
> the system is bootup, the unused clk is in a known state to match the
> prepare count info.
>
> Signed-off-by: Bai Ping
Please resend the patch with following clk maintainers and list on copy.
Also remember to add Lucas' Reviewed-by: tag.
COMMON CLK FRAMEWORK
M: Michael Turquette
M: Stephen Boyd
L: linux-...@vger.kernel.org
Shawn
> ---
> drivers/clk/imx/clk-pllv3.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 6addf8f..c05c43d 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -97,6 +97,16 @@ static void clk_pllv3_unprepare(struct clk_hw *hw)
> writel_relaxed(val, pll->base);
> }
>
> +static int clk_pllv3_is_prepared(struct clk_hw *hw)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> +
> + if (readl_relaxed(pll->base) & BM_PLL_LOCK)
> + return 1;
> +
> + return 0;
> +}
> +
> static unsigned long clk_pllv3_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
> @@ -139,6 +149,7 @@ static int clk_pllv3_set_rate(struct clk_hw *hw, unsigned
> long rate,
> static const struct clk_ops clk_pllv3_ops = {
> .prepare= clk_pllv3_prepare,
> .unprepare = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
> .recalc_rate= clk_pllv3_recalc_rate,
> .round_rate = clk_pllv3_round_rate,
> .set_rate = clk_pllv3_set_rate,
> @@ -193,6 +204,7 @@ static int clk_pllv3_sys_set_rate(struct clk_hw *hw,
> unsigned long rate,
> static const struct clk_ops clk_pllv3_sys_ops = {
> .prepare= clk_pllv3_prepare,
> .unprepare = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
> .recalc_rate= clk_pllv3_sys_recalc_rate,
> .round_rate = clk_pllv3_sys_round_rate,
> .set_rate = clk_pllv3_sys_set_rate,
> @@ -265,6 +277,7 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw,
> unsigned long rate,
> static const struct clk_ops clk_pllv3_av_ops = {
> .prepare= clk_pllv3_prepare,
> .unprepare = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
> .recalc_rate= clk_pllv3_av_recalc_rate,
> .round_rate = clk_pllv3_av_round_rate,
> .set_rate = clk_pllv3_av_set_rate,
> @@ -279,6 +292,7 @@ static unsigned long clk_pllv3_enet_recalc_rate(struct
> clk_hw *hw,
> static const struct clk_ops clk_pllv3_enet_ops = {
> .prepare= clk_pllv3_prepare,
> .unprepare = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
> .recalc_rate= clk_pllv3_enet_recalc_rate,
> };
>
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] ARM: dts: sun8i: Add SID node
On Tue, Nov 24, 2015 at 11:13:13AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Nov 23, 2015 at 8:43 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Mon, Nov 23, 2015 at 09:02:48AM +0100, Josef Gajdusek wrote:
> >> Add a node describing the Security ID memory to the
> >> Allwinner H3 .dtsi file.
> >>
> >> Signed-off-by: Josef Gajdusek
> >> ---
> >> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> index 0faa38a..58de718 100644
> >> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> @@ -359,6 +359,13 @@
> >> #size-cells = <0>;
> >> };
> >>
> >> + sid: eeprom@01c14000 {
> >> + compatible = "allwinner,sun4i-a10-sid";
> >> + reg = <0x01c14000 0x400>;
> >
> > The datasheet says it's 256 bytes wide, while the size here is of 1kB,
> > is it intentional?
>
> My H3 datasheet (v1.1) says its 1 kB wide.
Is it? in the Security ID section, it is said to be 2kb == 256B wide.
> It'd be nice if Allwinner actually listed the "usable" E-fuse
> offsets and widths, instead of having us dig through the SDK code.
Yep.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2 1/5] ARM: dts: sun8i: Add SID node
On Mon, Nov 23, 2015 at 07:24:40PM -0800, Sugar Wu wrote: > I will give you the right widths as soon. Great, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH] mm/compaction: __compact_pgdat() code cleanuup
This patch uses is_via_compact_memory() to distinguish direct compaction.
And it also reduces indentation on compaction_defer_reset
by filtering failure case. There is no functional change.
Signed-off-by: Joonsoo Kim
---
mm/compaction.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index de3e1e7..2b1a15e 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1658,14 +1658,17 @@ static void __compact_pgdat(pg_data_t *pgdat, struct
compact_control *cc)
!compaction_deferred(zone, cc->order))
compact_zone(zone, cc);
- if (cc->order > 0) {
- if (zone_watermark_ok(zone, cc->order,
- low_wmark_pages(zone), 0, 0))
- compaction_defer_reset(zone, cc->order, false);
- }
-
VM_BUG_ON(!list_empty(>freepages));
VM_BUG_ON(!list_empty(>migratepages));
+
+ if (is_via_compact_memory(cc->order))
+ continue;
+
+ if (!zone_watermark_ok(zone, cc->order,
+ low_wmark_pages(zone), 0, 0))
+ continue;
+
+ compaction_defer_reset(zone, cc->order, false);
}
}
--
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] mm/vmstat: retrieve more accurate vmstat value
When I tested compaction in low memory condition, I found that
my benchmark is stuck in congestion_wait() at shrink_inactive_list().
This stuck last for 1 sec and after then it can escape. More investigation
shows that it is due to stale vmstat value. vmstat is updated every 1 sec
so it is stuck for 1 sec.
I guess that it is caused by updating NR_ISOLATED_XXX. In direct
reclaim/compaction, it would isolate some pages. After some processing,
they are returned to lru or freed and NR_ISOLATED_XXX is adjusted so
it should be recover to zero. But, it would be possible that some
updatings are appiled to global but some are applied only to per cpu
variable. In this case, zone_page_state() would return stale value so
it can be stuck.
This problem can be solved by adjusting zone_page_state() with this
cpu's vmstat value. It's sub-optimal because the other task in other cpu
can be stuck due to stale vmstat value but, at least, it can solve
some usecases without adding much overhead so I think that it is worth
to doing it. With this change, I can't find any stuck in my test.
Signed-off-by: Joonsoo Kim
---
include/linux/vmstat.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 62af0f8..7c84896 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -133,6 +133,9 @@ static inline unsigned long zone_page_state(struct zone
*zone,
{
long x = atomic_long_read(>vm_stat[item]);
#ifdef CONFIG_SMP
+ long diff = this_cpu_read(zone->pageset->vm_stat_diff[item]);
+
+ x += diff;
if (x < 0)
x = 0;
#endif
--
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 v5 0/4] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
Hi Kishon, > From: Yoshihiro Shimoda > Sent: Tuesday, October 20, 2015 5:58 PM > > This patch is based on the latest linux-phy / next branch. > (commit id = 0f8669e343982ac66f4420335777cb5456b8abb0) Would you review this patch set? I confirmed the patch set could apply the latest linux-phy / next branch correctly. (commit id = 8005c49d9aea74d382f474ce11afbbc7d7130bec) Best regards, Yoshihiro Shimoda > Changes from v4: > - Modify Kconfig to "depends on OF && ARCH_SHMOBILE". > - Modify Kconfig to "select GENERIC_PHY" instead of "depends on > GENERIC_PHY". > - Modify device tree documentation about "reg" of example. > - Remove spinlock handling because phy-core driver calls mutex_lock(). > - Change valiable name to val instead of tmp. > - Remove dev_set_drvdata. > - Use dev_vdbg() instead of dev_dbg(). > - Change rcar_gen3_device_recognition()'s condition as one line. > - Remove unnecessary value in rcar_gen3_phy_usb2_probe(). > - Modify MAINTAINERS about this driver. > > Changes from v3: > - Shorten structure names to avoid new line if we add a long function name. > - Add ID/VBUS pin detection for peripheral mode. > > Changes from v2: > - Modify Kconfig to add "depends on OF" and "depends on ARCH_SHMOBILE". > - Add more information in the dt document. > - Change reg-names from "usb2" to "usb2_host". > > Changes from v1: > - Revise some typos. > - Remove using clk API to enable/disable the clocks. > (In other words, this driver expects to enable/disable the clocks by > Runtime PM API by the phy-core driver.) > - Remove an unnecessary header file (asm/cmpxchg.h). > > Yoshihiro Shimoda (4): > phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver > phy: rcar-gen3-usb2: change the mode to OTG on the combined channel > phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection > MAINTAINERS: add Renesas usb2 phy driver > > .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 39 +++ > MAINTAINERS| 6 + > drivers/phy/Kconfig| 7 + > drivers/phy/Makefile | 1 + > drivers/phy/phy-rcar-gen3-usb2.c | 380 > + > 5 files changed, 433 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt > create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c > > -- > 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/3] zram: try vmalloc() after kmalloc()
[..]
> static void *zcomp_lz4_create(void)
> {
> - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
> + void *ret;
> +
> + /*
> +* This function could be called in swapout/fs write path
> +* so we couldn't use GFP_FS|IO. And it assumes we already
> +* have at least one stream in zram initialization so we
> +* don't do best effort to allocate more stream in here.
> +* A default stream will work well without further multiple
> +* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
> +*/
> + ret = kzalloc(LZ4_MEM_COMPRESS,
> + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
> + if (!ret)
> + ret = __vmalloc(LZ4_MEM_COMPRESS,
> + __GFP_NORETRY|__GFP_NOWARN|
> + __GFP_NOMEMALLOC|__GFP_ZERO,
> + PAGE_KERNEL);
> + return ret;
> }
[..]
so this change is still questionable. is there a real value in having
a vmalloc() fallback in the middle of allocations sequence:
zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
^^^ ok, can fail here
zstrm->zstrm->private = comp->backend->create();
^^^ kzalloc() and vmalloc() fallback ??
zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
^^^ can fail here again.
can you please comment on this?
and I'd prefer it to be a bit different -- use likely path first and
avoid an assignment in unlikely path.
... and add GFP_NOIO to both kzalloc() and __vmalloc().
and there is no __GFP_HIGHMEM in __vmalloc() call?
something like this:
---
ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
__GFP_NOWARN | __GFP_NOMEMALLOC);
if (ret)
return ret;
return __vmalloc(LZ4_MEM_COMPRESS,
GFP_NOIO | __GFP_NOWARN | __GFP_HIGHMEM | __GFP_ZERO,
PAGE_KERNEL);
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
Hi Sascha, On Wed, 2015-11-18 at 09:24 +0100, Sascha Hauer wrote: > This adds support for the Mediatek thermal controller found on MT8173 > and likely other SoCs. > The controller is a bit special. It does not have its own ADC, instead > it controls the on-SoC AUXADC via AHB bus accesses. For this reason > we need the physical address of the AUXADC. Also it controls a mux > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. > > Signed-off-by: Sascha Hauer > --- > drivers/thermal/Kconfig | 8 + > drivers/thermal/Makefile | 1 + > drivers/thermal/mtk_thermal.c | 623 > ++ > 3 files changed, 632 insertions(+) > create mode 100644 drivers/thermal/mtk_thermal.c > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index 5aabc4b..503448a 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL > Thermal reporting device will provide temperature reading, > programmable trip points and other information. > > +config MTK_THERMAL > + tristate "Temperature sensor driver for mediatek SoCs"Why does ret > value didn't set to 0 during this function. This function of return value > would be not 0 with valid calibration data. > + depends on ARCH_MEDIATEK || COMPILE_TEST > + default y > + help > + Enable this option if you want to have support for thermal management > + controller present in Mediatek SoCs > + > menu "Texas Instruments thermal drivers" > depends on ARCH_HAS_BANDGAP || COMPILE_TEST > source "drivers/thermal/ti-soc-thermal/Kconfig" > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile > index 26f1608..5f979e7 100644 > --- a/drivers/thermal/Makefile > +++ b/drivers/thermal/Makefile > @@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o > obj-$(CONFIG_ST_THERMAL) += st/ > obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o > obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o > +obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c > new file mode 100644 > index 000..0bdf38d > --- /dev/null > +++ b/drivers/thermal/mtk_thermal.c > @@ -0,0 +1,623 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Hanyi Wu > + * Sascha Hauer > + * > + * 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 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. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* AUXADC Registers */ > +#define AUXADC_CON0_V0x000 > +#define AUXADC_CON1_V0x004 > +#define AUXADC_CON1_SET_V0x008 > +#define AUXADC_CON1_CLR_V0x00c > +#define AUXADC_CON2_V0x010 > +#define AUXADC_DATA(channel) (0x14 + (channel) * 4) > +#define AUXADC_MISC_V0x094 > + > +#define AUXADC_CON1_CHANNEL(x) BIT(x) > + > +#define APMIXED_SYS_TS_CON1 0x604 > + > +/* Thermal Controller Registers */ > +#define TEMP_MONCTL0 0x000 > +#define TEMP_MONCTL1 0x004 > +#define TEMP_MONCTL2 0x008 > +#define TEMP_MONIDET00x014 > +#define TEMP_MONIDET10x018 > +#define TEMP_MSRCTL0 0x038 > +#define TEMP_AHBPOLL 0x040 > +#define TEMP_AHBTO 0x044 > +#define TEMP_ADCPNP0 0x048 > +#define TEMP_ADCPNP1 0x04c > +#define TEMP_ADCPNP2 0x050 > +#define TEMP_ADCPNP3 0x0b4 > + > +#define TEMP_ADCMUX 0x054 > +#define TEMP_ADCEN 0x060 > +#define TEMP_PNPMUXADDR 0x064 > +#define TEMP_ADCMUXADDR 0x068 > +#define TEMP_ADCENADDR 0x074 > +#define TEMP_ADCVALIDADDR0x078 > +#define TEMP_ADCVOLTADDR 0x07c > +#define TEMP_RDCTRL 0x080 > +#define TEMP_ADCVALIDMASK0x084 > +#define TEMP_ADCVOLTAGESHIFT 0x088 > +#define TEMP_ADCWRITECTRL0x08c > +#define TEMP_MSR00x090Hi Sascha, > +#define TEMP_MSR10x094 > +#define TEMP_MSR20x098 > +#define TEMP_MSR30x0B8 > + > +#define TEMP_SPARE0 0x0f0 > + > +#define PTPCORESEL 0x400 > + > +#define TEMP_MONCTL1_PERIOD_UNIT(x) ((x) & 0x3ff) > + > +#define TEMP_MONCTL2_FILTER_INTERVAL(x) (((x) & 0x3ff)) << 16 > +#define TEMP_MONCTL2_SENSOR_INTERVAL(x) ((x) & 0x3ff) > + > +#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)(x) > + > +#define
Re: linux-next: build failure after merge of the drm-panel tree
On Mon, Nov 23, 2015 at 4:38 PM, Stephen Rothwell wrote:
> Hi Thierry,
>
> After merging the drm-panel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c: In function
> 'wuxga_nt_panel_on':
> drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c:65:8: error: implicit
> declaration of function 'mipi_dsi_turn_on_peripheral'
> [-Werror=implicit-function-declaration]
> ret = mipi_dsi_turn_on_peripheral(dsi);
> ^
> drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c: In function
> 'wuxga_nt_panel_disable':
> drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c:79:2: error: implicit
> declaration of function 'mipi_dsi_shutdown_peripheral'
> [-Werror=implicit-function-declaration]
> mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
> ^
>
> Caused by commit
>
> 086ceb6b42ca ("drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel")
>
> I have used the version of the drm-panel tree from next-20151123 for today.
>
Thierry,
This means that patch 1 of the series was not picked up. It can be
found here: https://patchwork.kernel.org/patch/7530121/
Regards,
Bjorn
--
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] pinctrl: uniphier: rework UniPhier pinctrl entries in Kconfig
There is a plan to support more pinctrl drivers for this SoC family. Move the driver entries into a sub menu by using "menuconfig". Also, add the missing dependency "depends on OF && MFD_SYSCON". Signed-off-by: Masahiro Yamada --- drivers/pinctrl/uniphier/Kconfig | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig index ad90707..7abd614 100644 --- a/drivers/pinctrl/uniphier/Kconfig +++ b/drivers/pinctrl/uniphier/Kconfig @@ -1,32 +1,35 @@ -if ARCH_UNIPHIER - -config PINCTRL_UNIPHIER - bool +menuconfig PINCTRL_UNIPHIER + bool "UniPhier SoC pinctrl drivers" + depends on ARCH_UNIPHIER + depends on OF && MFD_SYSCON + default y select PINMUX select GENERIC_PINCONF +if PINCTRL_UNIPHIER + config PINCTRL_UNIPHIER_PH1_LD4 tristate "UniPhier PH1-LD4 SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y config PINCTRL_UNIPHIER_PH1_PRO4 tristate "UniPhier PH1-Pro4 SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y config PINCTRL_UNIPHIER_PH1_SLD8 tristate "UniPhier PH1-sLD8 SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y config PINCTRL_UNIPHIER_PH1_PRO5 tristate "UniPhier PH1-Pro5 SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y config PINCTRL_UNIPHIER_PROXSTREAM2 tristate "UniPhier ProXstream2 SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y config PINCTRL_UNIPHIER_PH1_LD6B tristate "UniPhier PH1-LD6b SoC pinctrl driver" - select PINCTRL_UNIPHIER + default y endif -- 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: BUG: Unable to handle kernel paging request for data at address __percpu_counter_add
On 11/24/2015 02:43 AM, Tejun Heo wrote: Hello, On Thu, Nov 19, 2015 at 03:54:35PM +0530, Raghavendra K T wrote: While I was creating thousands of docker container on a power8 baremetal (config: 4.3.0 kernel 1TB RAM, 20core (=160 cpu) system. After creating around 5600 container I have hit below problem. [This is looking similar to https://bugzilla.kernel.org/show_bug.cgi?id=101011, but kernel had Revert "ext4: remove block_device_ejected" (bdfe0cbd746aa9) since it is 4.3.0 tagged kernel] Any hints on how to go about the fix. Please let me know if you think any more information needed. docker daemon is device mapper based. (and it took a day to recreate the problem) [ by disabling CONFIG_BLK_CGROUP and CONFIG_CGROUP_WRITEBACK I am able to create 10k containers without any problem] Could be the same problem that Ilya is trying to fix. ie. blkdev i_wb pointing to a stale wb. Can you please see whether the following patch resolves the issue? http://lkml.kernel.org/g/1448054554-24138-1-git-send-email-idryo...@gmail.com Thanks Tejun for the pointer. Will check if the patch resolves the issue. (reproduction takes loong time.. so it may take some time to report back). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams
[..]
> static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
> {
> - struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_KERNEL);
> + struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
> if (!zstrm)
> return NULL;
>
> @@ -85,7 +85,7 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp
> *comp)
> * allocate 2 pages. 1 for compressed data, plus 1 extra for the
> * case when compressed size is larger than the original one
> */
> - zstrm->buffer = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 1);
> + zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
> if (!zstrm->private || !zstrm->buffer) {
> zcomp_strm_free(comp, zstrm);
> zstrm = NULL;
hm... this is not enough.
we allocate
stream GFP_NOIO
stream private GFP_KERNEL still old flags
stream buffer
so my patch was something like this:
---
drivers/block/zram/zcomp.c | 4 ++--
drivers/block/zram/zcomp_lz4.c | 2 +-
drivers/block/zram/zcomp_lzo.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 5cb13ca..c536177 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -76,7 +76,7 @@ static void zcomp_strm_free(struct zcomp *comp, struct
zcomp_strm *zstrm)
*/
static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
{
- struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_KERNEL);
+ struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
if (!zstrm)
return NULL;
@@ -85,7 +85,7 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
* allocate 2 pages. 1 for compressed data, plus 1 extra for the
* case when compressed size is larger than the original one
*/
- zstrm->buffer = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 1);
+ zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
if (!zstrm->private || !zstrm->buffer) {
zcomp_strm_free(comp, zstrm);
zstrm = NULL;
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index f2afb7e..ee44b51 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -15,7 +15,7 @@
static void *zcomp_lz4_create(void)
{
- return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
+ return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO);
}
static void zcomp_lz4_destroy(void *private)
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index da1bc47..683ce04 100644
--- a/drivers/block/zram/zcomp_lzo.c
+++ b/drivers/block/zram/zcomp_lzo.c
@@ -15,7 +15,7 @@
static void *lzo_create(void)
{
- return kzalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL);
+ return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO);
}
static void lzo_destroy(void *private)
--
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 v5 0/6] MT8173 IOMMU SUPPORT
On Fri, 2015-10-23 at 11:26 +0200, Joerg Roedel wrote: > On Thu, Oct 22, 2015 at 12:40:02PM +0800, Yong Wu wrote: > > But the mtk-iommu depend on the drivers/memory/mtk-smi.c(mtk-iommu > > has called a function of the mtk-smi). > > So if there is dependence here, How should we do to merge them? > > I can surely merge mtk-smi too, if it gets proper Reviewed-by and > Acked-by tags from the maintainer(s). > > > Joerg > Hi Joerg, About the driver/memory/, We don't know who is his maintainer. MAINTAINERS file don't have drivers/memory maintainer. >From the history in drivers/memory/ it looks like most of the drivers land with an ack from the architecture maintainer. And Matthias Brugger is our "ARM/Mediatek SoC support" maintainer. Then do you mean that we need Matthias's ACK or whom others? By the way, I will send the next version after Robin reposting Short-descriptor. maybe in next week. -- 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] ARM: dts: qcom: msm8974: Add i2c8 node
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index acd4cdb9c934..777adb9204c7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -331,6 +331,17 @@
interrupts = <0 208 0>;
};
+ blsp_i2c8: i2c@f9964000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9964000 0x1000>;
+ interrupts = <0 102 IRQ_TYPE_NONE>;
+ clocks = < GCC_BLSP2_QUP2_I2C_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
+ clock-names = "core", "iface";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
blsp_i2c11: i2c@f9967000 {
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Add rules for Qualcomm dts files
Make the get_maintainer script pick up the proper maintainers for the Qualcomm dts files. Signed-off-by: Bjorn Andersson --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index bcf40fdc8178..a11764c15b62 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1406,6 +1406,8 @@ M:David Brown L: linux-arm-...@vger.kernel.org L: linux-...@vger.kernel.org S: Maintained +F: arch/arm/boot/dts/qcom-*.dts +F: arch/arm/boot/dts/qcom-*.dtsi F: arch/arm/mach-qcom/ F: drivers/soc/qcom/ F: drivers/tty/serial/msm_serial.h -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net: Generalise wq_has_sleeper helper
On Wed, Nov 11, 2015 at 05:48:29PM +0800, Herbert Xu wrote:
>
> BTW, the networking folks found this years ago and even added
> helpers to deal with this. See for example wq_has_sleeper in
> include/net/sock.h. It would be good if we can move some of
> those helpers into wait.h instead.
Here is a patch against net-next which makes the wq_has_sleeper
helper available to non-next users:
---8<---
The memory barrier in the helper wq_has_sleeper is needed by just
about every user of waitqueue_active. This patch generalises it
by making it take a wait_queue_head_t directly. The existing
helper is renamed to skwq_has_sleeper.
Signed-off-by: Herbert Xu
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 0aa6fdf..fb99f30 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -106,7 +106,7 @@ static void aead_wmem_wakeup(struct sock *sk)
rcu_read_lock();
wq = rcu_dereference(sk->sk_wq);
- if (wq_has_sleeper(wq))
+ if (skwq_has_sleeper(wq))
wake_up_interruptible_sync_poll(>wait, POLLIN |
POLLRDNORM |
POLLRDBAND);
@@ -157,7 +157,7 @@ static void aead_data_wakeup(struct sock *sk)
rcu_read_lock();
wq = rcu_dereference(sk->sk_wq);
- if (wq_has_sleeper(wq))
+ if (skwq_has_sleeper(wq))
wake_up_interruptible_sync_poll(>wait, POLLOUT |
POLLRDNORM |
POLLRDBAND);
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index af31a0e..0e6702e 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -238,7 +238,7 @@ static void skcipher_wmem_wakeup(struct sock *sk)
rcu_read_lock();
wq = rcu_dereference(sk->sk_wq);
- if (wq_has_sleeper(wq))
+ if (skwq_has_sleeper(wq))
wake_up_interruptible_sync_poll(>wait, POLLIN |
POLLRDNORM |
POLLRDBAND);
@@ -288,7 +288,7 @@ static void skcipher_data_wakeup(struct sock *sk)
rcu_read_lock();
wq = rcu_dereference(sk->sk_wq);
- if (wq_has_sleeper(wq))
+ if (skwq_has_sleeper(wq))
wake_up_interruptible_sync_poll(>wait, POLLOUT |
POLLRDNORM |
POLLRDBAND);
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 1e1bf9f..bd1157f 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -107,6 +107,50 @@ static inline int waitqueue_active(wait_queue_head_t *q)
return !list_empty(>task_list);
}
+/**
+ * wq_has_sleeper - check if there are any waiting processes
+ * @wq: wait queue head
+ *
+ * Returns true if wq has waiting processes
+ *
+ * The purpose of the wq_has_sleeper and sock_poll_wait is to wrap the memory
+ * barrier call. They were added due to the race found within the tcp code.
+ *
+ * Consider following tcp code paths:
+ *
+ * CPU1 CPU2
+ *
+ * sys_selectreceive packet
+ * ... ...
+ * __add_wait_queueupdate tp->rcv_nxt
+ * ... ...
+ * tp->rcv_nxt check sock_def_readable
+ * ... {
+ * schedule rcu_read_lock();
+ * wq = rcu_dereference(sk->sk_wq);
+ * if (wq && waitqueue_active(>wait))
+ * wake_up_interruptible(>wait)
+ * ...
+ * }
+ *
+ * The race for tcp fires when the __add_wait_queue changes done by CPU1 stay
+ * in its cache, and so does the tp->rcv_nxt update on CPU2 side. The CPU1
+ * could then endup calling schedule and sleep forever if there are no more
+ * data on the socket.
+ *
+ */
+static inline bool wq_has_sleeper(wait_queue_head_t *wq)
+{
+ /* We need to be sure we are in sync with the
+* add_wait_queue modifications to the wait queue.
+*
+* This memory barrier should be paired with one on the
+* waiting side.
+*/
+ smp_mb();
+ return waitqueue_active(wq);
+}
+
extern void add_wait_queue(wait_queue_head_t *q, wait_queue_t *wait);
extern void add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t *wait);
extern void remove_wait_queue(wait_queue_head_t *q, wait_queue_t *wait);
diff --git a/include/net/sock.h b/include/net/sock.h
index bbf7c2c..4a6e9b6 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1879,46 +1880,14 @@ static inline bool sk_has_allocations(const struct sock
*sk)
}
/**
- * wq_has_sleeper - check if there are any waiting processes
+ * skwq_has_sleeper -
[PATCH] pwm: berlin: Add PM support
This patch adds S2R support for berlin pwm driver.
Signed-off-by: Jisheng Zhang
---
drivers/pwm/pwm-berlin.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-berlin.c b/drivers/pwm/pwm-berlin.c
index 6510812..2afdb40 100644
--- a/drivers/pwm/pwm-berlin.c
+++ b/drivers/pwm/pwm-berlin.c
@@ -27,10 +27,20 @@
#define BERLIN_PWM_TCNT0xc
#define BERLIN_PWM_MAX_TCNT 65535
+#define NUM_PWM_CHANNEL4 /* berlin PWM channels
*/
+
+struct berlin_pwm_context {
+ u32 enable;
+ u32 ctrl;
+ u32 duty;
+ u32 tcnt;
+};
+
struct berlin_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
void __iomem *base;
+ struct berlin_pwm_context ctx[NUM_PWM_CHANNEL];
};
static inline struct berlin_pwm_chip *to_berlin_pwm_chip(struct pwm_chip *chip)
@@ -176,7 +186,7 @@ static int berlin_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = >dev;
pwm->chip.ops = _pwm_ops;
pwm->chip.base = -1;
- pwm->chip.npwm = 4;
+ pwm->chip.npwm = NUM_PWM_CHANNEL;
pwm->chip.can_sleep = true;
pwm->chip.of_xlate = of_pwm_xlate_with_flags;
pwm->chip.of_pwm_n_cells = 3;
@@ -204,12 +214,57 @@ static int berlin_pwm_remove(struct platform_device *pdev)
return ret;
}
+#ifdef CONFIG_PM_SLEEP
+static int berlin_pwm_suspend(struct device *dev)
+{
+ int i;
+ struct berlin_pwm_chip *pwm = dev_get_drvdata(dev);
+
+ for (i = 0; i < pwm->chip.npwm; i++) {
+ struct berlin_pwm_context *ctx = >ctx[i];
+
+ ctx->enable = berlin_pwm_readl(pwm, i, BERLIN_PWM_ENABLE);
+ ctx->ctrl = berlin_pwm_readl(pwm, i, BERLIN_PWM_CONTROL);
+ ctx->duty = berlin_pwm_readl(pwm, i, BERLIN_PWM_DUTY);
+ ctx->tcnt = berlin_pwm_readl(pwm, i, BERLIN_PWM_TCNT);
+ }
+ clk_disable_unprepare(pwm->clk);
+
+ return 0;
+}
+
+static int berlin_pwm_resume(struct device *dev)
+{
+ int i;
+ struct berlin_pwm_chip *pwm = dev_get_drvdata(dev);
+
+ clk_prepare_enable(pwm->clk);
+ for (i = 0; i < pwm->chip.npwm; i++) {
+ struct berlin_pwm_context *ctx = >ctx[i];
+
+ berlin_pwm_writel(pwm, i, ctx->ctrl, BERLIN_PWM_CONTROL);
+ berlin_pwm_writel(pwm, i, ctx->duty, BERLIN_PWM_DUTY);
+ berlin_pwm_writel(pwm, i, ctx->tcnt, BERLIN_PWM_TCNT);
+ berlin_pwm_writel(pwm, i, ctx->enable, BERLIN_PWM_ENABLE);
+ }
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(berlin_pwm_pm_ops, berlin_pwm_suspend,
+berlin_pwm_resume);
+#define BERLIN_PWM_PM_OPS (_pwm_pm_ops)
+#else
+#define BERLIN_PWM_PM_OPS NULL
+#endif
+
static struct platform_driver berlin_pwm_driver = {
.probe = berlin_pwm_probe,
.remove = berlin_pwm_remove,
.driver = {
.name = "berlin-pwm",
.of_match_table = berlin_pwm_match,
+ .pm = BERLIN_PWM_PM_OPS,
},
};
module_platform_driver(berlin_pwm_driver);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] optimize 64-by-32 ddivision for constant divisors on 32-bit machines
On Mon, 23 Nov 2015, Arnd Bergmann wrote:
> On Monday 23 November 2015 11:04:33 Nicolas Pitre wrote:
> >
> > OK... I'm able to "fix" the build with:
> >
> > diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
> > index 163f77999e..d246c4c801 100644
> > --- a/include/asm-generic/div64.h
> > +++ b/include/asm-generic/div64.h
> > @@ -206,7 +206,7 @@ extern uint32_t __div64_32(uint64_t *dividend, uint32_t
> > divisor);
> > uint32_t __rem; \
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> > if (__builtin_constant_p(__base) && \
> > - is_power_of_2(__base)) {\
> > + is_power_of_2(__base) && __base != 0) { \
> > __rem = (n) & (__base - 1); \
> > (n) >>= ilog2(__base); \
> > } else if (__div64_const32_is_OK && \
> >
> > What doesn't make sense to me is the fact that is_power_of_2() is
> > defined as:
> >
> > static inline __attribute__((const))
> > bool is_power_of_2(unsigned long n)
> > {
> > return (n != 0 && ((n & (n - 1)) == 0));
> > }
> >
> > So the test for zero is already in there.
> >
> > And adding BUILD_BUG_ON(__builtin_constant_p(__base) && __base == 0)
> > before the if doesn't trig either.
>
> I've seen similarly messed up situations with PROFILE_ALL_BRANCHES
> before, I think it's got something to do with how __builtin_constant_p()
> is used inside of the __trace_if() macro, and how gcc sometimes falls
> back to treating variables as not-really-constant based on context.
>
> To gcc, __builtin_constant_p is just best-effort, and they don't care
> about returning false sometimes if they catch most cases in practice.
OK... I produced a minimal test case. I think gcc is screwed. And it is
not a question of __builtin_constant_p being best effort. The resulting
code is plain wrong where a variable is suddenly turned into a constant
of value 0. Any random modification to various part of the code just
makes it disappear but I didn't check the disassembly to see if it is
then correct.
And the good news(tm) is that the same bug is triggered with x86 gcc as
well.
Please try the attached test case.
Nicolas
gcc_testcase.tgz
Description: application/gzip
Re: [PATCH v1] mm: hugetlb: fix hugepage memory leak caused by wrong reserve count
On Fri, Nov 20, 2015 at 01:56:18PM -0800, Mike Kravetz wrote: > On 11/19/2015 11:57 PM, Hillf Danton wrote: > >> > >> When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back to > >> alloc_buddy_huge_page() to directly create a hugepage from the buddy > >> allocator. > >> In that case, however, if alloc_buddy_huge_page() succeeds we don't > >> decrement > >> h->resv_huge_pages, which means that successful hugetlb_fault() returns > >> without > >> releasing the reserve count. As a result, subsequent hugetlb_fault() might > >> fail > >> despite that there are still free hugepages. > >> > >> This patch simply adds decrementing code on that code path. > > In general, I agree with the patch. If we allocate a huge page via the > buddy allocator and that page will be used to satisfy a reservation, then > we need to decrement the reservation count. > > As Hillf mentions, this code is not exactly the same in linux-next. > Specifically, there is the new call to take the memory policy of the > vma into account when calling the buddy allocator. I do not think, > this impacts your proposed change but you may want to test with that > in place. > > >> > >> I reproduced this problem when testing v4.3 kernel in the following > >> situation: > >> - the test machine/VM is a NUMA system, > >> - hugepage overcommiting is enabled, > >> - most of hugepages are allocated and there's only one free hugepage > >> which is on node 0 (for example), > >> - another program, which calls set_mempolicy(MPOL_BIND) to bind itself to > >> node 1, tries to allocate a hugepage, > > I am curious about this scenario. When this second program attempts to > allocate the page, I assume it creates a reservation first. Is this > reservation before or after setting mempolicy? If the mempolicy was set > first, I would have expected the reservation to allocate a page on > node 1 to satisfy the reservation. My testing called set_mempolicy() at first then called mmap(), but things didn't change if I reordered them, because currently hugetlb reservation is not NUMA-aware. Thanks, Naoya Horiguchi-- 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/
[lkp] [genirq/msi] 460ec9d780: 8.5% unixbench.score
O O O OO | 6.8e+07 ++| | | 6.6e+07 ++ .*| | **.*** *.* * .**.*| 6.4e+07 **. *.* .**.* .* + *.* .**. *.**. **. *.* .**.* + * * | * * * * ** * * * *| 6.2e+07 +++ [*] bisect-good sample [O] bisect-bad sample To reproduce: git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Thanks, Ying Huang --- LKP_SERVER: inn LKP_CGI_PORT: 80 LKP_CIFS_PORT: 139 testcase: unixbench default-monitors: wait: activate-monitor kmsg: uptime: iostat: vmstat: numa-numastat: numa-vmstat: numa-meminfo: proc-vmstat: proc-stat: interval: 10 meminfo: slabinfo: interrupts: lock_stat: latency_stats: softirqs: bdi_dev_mapping: diskstats: nfsstat: cpuidle: cpufreq-stats: turbostat: pmeter: sched_debug: interval: 60 cpufreq_governor: default-watchdogs: oom-killer: watchdog: commit: 460ec9d78057bf462f5b5cd0a140e32252d81405 model: Nehalem memory: 4G nr_cpu: 8 hdd_partitions: swap_partitions: rootfs_partition: netconsole_port: 6671 category: benchmark unixbench: test: context1 queue: bisect testbox: nhm-white2 tbox_group: nhm-white2 kconfig: x86_64-rhel enqueue_time: 2015-11-23 15:41:21.037230310 +08:00 id: 2ef6fc6d2e09a582e9740c5c45466d2db21dc54a user: lkp compiler: gcc-4.9 head_commit: 6e6e68bdb87c92710611a4ab9a9a8e85cfe34100 base_commit: 8005c49d9aea74d382f474ce11afbbc7d7130bec branch: linux-devel/devel-hourly-2015112221 rootfs: debian-x86_64-2015-02-07.cgz result_root: "/result/unixbench/context1/nhm-white2/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/460ec9d78057bf462f5b5cd0a140e32252d81405/0" job_file: "/lkp/scheduled/nhm-white2/bisect_unixbench-context1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-460ec9d78057bf462f5b5cd0a140e32252d81405-20151123-70997-qe2i1m-0.yaml" max_uptime: 1310.02002 initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz" bootloader_append: - root=/dev/ram0 - user=lkp - job=/lkp/scheduled/nhm-white2/bisect_unixbench-context1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-460ec9d78057bf462f5b5cd0a140e32252d81405-20151123-70997-qe2i1m-0.yaml - ARCH=x86_64 - kconfig=x86_64-rhel - branch=linux-devel/devel-hourly-2015112221 - commit=460ec9d78057bf462f5b5cd0a140e32252d81405 - BOOT_IMAGE=/pkg/linux/x86_64-rhel/gcc-4.9/460ec9d78057bf462f5b5cd0a140e32252d81405/vmlinuz-4.4.0-rc1-4-g460ec9d - max_uptime=1310 - RESULT_ROOT=/result/unixbench/context1/nhm-white2/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/460ec9d78057bf462f5b5cd0a140e32252d81405/0 - LKP_SERVER=inn - |2- earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz" modules_initrd: "/pkg/linux/x86_64-rhel/gcc-4.9/460ec9d78057bf462f5b5cd0a140e32252d81405/modules.cgz" bm_initrd: "/osimage/deps/debian-x86_64-2015-02-07.cgz/lkp.cgz,/osimage/deps/debian-x86_64-2015-02-07.cgz/run-ipconfig.cgz,/osimage/deps/debian-x86_64-2015-02-07.cgz/turbostat.cgz,/lkp/benchmarks/turbostat.cgz,/lkp/benchmarks/unixbench.cgz" repeat_to: 2 kernel: "/pkg/linux/x86_64-rhel/gcc-4.9/460ec9d78057bf462f5b5cd0a140e32252d81405/vmlinuz-4.4.0-rc1-4-g460ec9d" dequeue_time: 2015-11-23 16:42:57.708515091 +08:00 job_state: finished loadavg: 6.94 3.10 1.18 1/169 4571 start_time: '1448268201' end_time: '1448268462' version: "/lkp/lkp/.src-20151120-223843" reproduce.sh Description: Bourne shell script
Re: [PATCH 34/37] perf hists browser: Support flat callchains
On Mon, Nov 23, 2015 at 04:16:48PM +0100, Frederic Weisbecker wrote:
> On Thu, Nov 19, 2015 at 02:53:20PM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Namhyung Kim
> >
> > The flat callchain mode is to print all chains in a single, simple
> > hierarchy so make it easy to see.
> >
> > Currently perf report --tui doesn't show flat callchains properly. With
> > flat callchains, only leaf nodes are added to the final rbtree so it
> > should show entries in parent nodes. To do that, add parent_val list to
> > struct callchain_node and show them along with the (normal) val list.
> >
> > For example, consider following callchains with '-g graph'.
> >
> > $ perf report -g graph
> > - 39.93% swapper [kernel.vmlinux] [k] intel_idle
> >intel_idle
> >cpuidle_enter_state
> >cpuidle_enter
> >call_cpuidle
> > - cpu_startup_entry
> > 28.63% start_secondary
> > - 11.30% rest_init
> > start_kernel
> > x86_64_start_reservations
> > x86_64_start_kernel
> >
> > Before:
> > $ perf report -g flat
> > - 39.93% swapper [kernel.vmlinux] [k] intel_idle
> >28.63% start_secondary
> > - 11.30% rest_init
> > start_kernel
> > x86_64_start_reservations
> > x86_64_start_kernel
> >
> > After:
> > $ perf report -g flat
> > - 39.93% swapper [kernel.vmlinux] [k] intel_idle
> > - 28.63% intel_idle
> > cpuidle_enter_state
> > cpuidle_enter
> > call_cpuidle
> > cpu_startup_entry
> > start_secondary
> > - 11.30% intel_idle
> > cpuidle_enter_state
> > cpuidle_enter
> > call_cpuidle
> > cpu_startup_entry
> > start_kernel
> > x86_64_start_reservations
> > x86_64_start_kernel
> >
> > Signed-off-by: Namhyung Kim
> > Tested-by: Arnaldo Carvalho de Melo
> > Tested-by: Brendan Gregg
> > Cc: Andi Kleen
> > Cc: David Ahern
> > Cc: Frederic Weisbecker
> > Cc: Jiri Olsa
> > Cc: Kan Liang
> > Cc: Peter Zijlstra
> > Link:
> > http://lkml.kernel.org/r/1447047946-1691-8-git-send-email-namhy...@kernel.org
> > Signed-off-by: Arnaldo Carvalho de Melo
> > ---
>
> [...]
>
> > +int callchain_node__make_parent_list(struct callchain_node *node)
> > +{
> > + struct callchain_node *parent = node->parent;
> > + struct callchain_list *chain, *new;
> > + LIST_HEAD(head);
> > +
> > + while (parent) {
> > + list_for_each_entry_reverse(chain, >val, list) {
> > + new = malloc(sizeof(*new));
> > + if (new == NULL)
> > + goto out;
> > + *new = *chain;
> > + new->has_children = false;
> > + list_add_tail(>list, );
> > + }
> > + parent = parent->parent;
> > + }
> > +
> > + list_for_each_entry_safe_reverse(chain, new, , list)
> > + list_move_tail(>list, >parent_val);
> > +
> > + if (!list_empty(>parent_val)) {
> > + chain = list_first_entry(>parent_val, struct
> > callchain_list, list);
> > + chain->has_children = rb_prev(>rb_node) ||
> > rb_next(>rb_node);
> > +
> > + chain = list_first_entry(>val, struct callchain_list,
> > list);
> > + chain->has_children = false;
>
> I'm a bit puzzled with this, can't we rewind through the parents on printing
> or adding
> to the flat rbtree instead of having this parent_val field?
Yes, this code is to simplify things on parent nodes. Maybe we could
go up to parents and print the callchain list there as you said.
However, problem I think is how to handle 'has_children' information
on parents. That info controls folding status of each callchain. As
the info is in the struct callchain_list and flat or folded callchain
mode require the info should be in the top-most entry, I cannot share
entries in parent nodes.
Thus I simply copied callchain lists in parents to leaf nodes. Yes,
it will consume some memory but can simplify the code.
Thank you for your review anyway!
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iio: mma8452: add freefall detection for Freescale's accelerometers
Am 2015-11-17 um 20:24 schrieb Martin Kepplinger:
> Am 2015-11-14 um 20:03 schrieb Jonathan Cameron:
>> On 14/11/15 18:45, Martin Kepplinger wrote:
>>> Am 2015-11-14 um 19:03 schrieb Jonathan Cameron:
On 11/11/15 18:38, Martin Kepplinger wrote:
> This adds freefall event detection to the supported devices. It adds
> the in_accel_x_mag_falling_en iio event attribute, which activates
> freefall mode.
>
> In freefall mode, the current acceleration values of all activated axis
> are added and if the *sum* falls *under* the threshold specified
> (in_accel_mag_falling_value), the appropriate IIO event code
> is generated.
>
> By enabling freefall mode (in_accel_x_mag_falling_en)
> all 3 axis are enabled too as this describes a classic freefall
> detection. Of course the user is free to disable one or more directions.
>
> The values of rising and falling versions of various sysfs files are
> shared, which is compliant to the IIO specification.
>
> This is what the sysfs "events" directory for these devices looks
> like after this change:
>
> -rw-r--r--4096 Oct 23 08:45 in_accel_mag_falling_period
> -rw-r--r--4096 Oct 23 08:45 in_accel_mag_falling_value
> -rw-r--r--4096 Oct 23 08:45 in_accel_mag_rising_period
> -rw-r--r--4096 Oct 23 08:45 in_accel_mag_rising_value
> -r--r--r--4096 Oct 23 08:45 in_accel_scale
> -rw-r--r--4096 Oct 23 08:45 in_accel_x_mag_falling_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_x_mag_falling_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_x_mag_rising_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_y_mag_falling_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_y_mag_rising_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_z_mag_falling_en
> -rw-r--r--4096 Oct 23 08:45 in_accel_z_mag_rising_en
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
>
Looks pretty good to me (other than obviously the bits Lars already
picked up on!)
My only real comment was that you could do the rest of the combined
possibilities whilst you are here (if you want to!) You've
picked the mostly obviously useful one though so maybe leave it
at that.
>>>
>>> I'm not sure what you mean. There is only in_accel_x_mag_falling_en
>>> documented. So my guess was to have this to enable freefall mode, taking
>>> into account the currently enabled falling axis
>>> (in_accel_x_mag_falling_en, ...).
>> Sure, but the set of modifiers allows for
>> in_accel_x_mag_falling_* etc and they aren't documented in this particular
>> form simply because no driver has used them yet ;)
>>
>
>
>
> I don't see how to do it in iio_event_spec only. Could you point me in
> the right direction, could well be I overlook something...
>
> I *can* add a channel for freefall purposes, something like:
>
> static const struct iio_chan_spec mma8653_channels[] = {
> MMA8652_CHANNEL(IIO_MOD_X, idx_axis_x, 10),
> MMA8652_CHANNEL(IIO_MOD_Y, idx_axis_y, 10),
> MMA8652_CHANNEL(IIO_MOD_Z, idx_axis_z, 10),
> MMA8652_CHANNEL(IIO_MOD_X_AND_Y_AND_Z, idx_axis_xyz, 10),
> IIO_CHAN_SOFT_TIMESTAMP(idx_timestamp),
> };
>
>
> just as an example, but then of course I get more than just events: In
> the device-directory:
>
> in_accel_x_calibbias
> in_accel_x_raw
> in_accel_x_calibbias
> in_accel_x_raw
> in_accel_y_calibbias
> in_accel_y_raw
> in_accel_z_calibbias
> in_accel_z_raw
>
>
> calibbias and raw are not (really) available for x I could
> calculate a "raw" value, but calibbias doesn't make sense here. ...But
> again, maybe I'm on the wrong path!!
>
> thanks a lot!
>
> martin
>
Would this be the way to go? And just not support the generated file
that don't apply?
thanks,
martin
--
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: Linus tree git problems self-modifying code?
Also, the 4.3 build on i386 is LOADED with wanrings about variables being used that are not initialized. I can post that too but the list is pretty big. Just build it and its obvious. Jeff On 11/23/15, Jeffrey Merkey wrote: > If you checkout 4.3 the build it on i386 the following files show up > as modified and tracked after the build completes. I can roll the > files back but isn't this broken? This does mess up my git sync. > > [root@aya linux]# > [root@aya linux]# > [root@aya linux]# git status -s > D arch/arm/boot/dts/include/dt-bindings > D arch/arm64/boot/dts/include/dt-bindings > D arch/metag/boot/dts/include/dt-bindings > D arch/mips/boot/dts/include/dt-bindings > D arch/powerpc/boot/dts/include/dt-bindings > T tools/testing/selftests/powerpc/copyloops/copyuser_64.S > T tools/testing/selftests/powerpc/copyloops/copyuser_power7.S > T tools/testing/selftests/powerpc/copyloops/memcpy_64.S > T tools/testing/selftests/powerpc/copyloops/memcpy_power7.S > T tools/testing/selftests/powerpc/primitives/asm/asm-compat.h > T tools/testing/selftests/powerpc/primitives/word-at-a-time.h > T tools/testing/selftests/powerpc/stringloops/memcmp_64.S > T tools/testing/selftests/powerpc/vphn/vphn.c > T tools/testing/selftests/powerpc/vphn/vphn.h > [root@aya linux]# > [root@aya linux]# > [root@aya linux]# > > 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 31/37] perf callchain: Add count fields to struct callchain_node
Hi Frederic, On Mon, Nov 23, 2015 at 03:35:30PM +0100, Frederic Weisbecker wrote: > Namhyung, > > On Thu, Nov 19, 2015 at 02:53:17PM -0300, Arnaldo Carvalho de Melo wrote: > > From: Namhyung Kim > > > > It's to track the count of occurrences of the callchains. > > Please explain why you do something like this in the changelog, even just a > single > line to tell which feature is going to use this and why. > > No need to resend just for that, it's just for future patches. OK, I'll keep in mind that. This patch is a preparation for supporting different callchain value output style. Instead of current percent output, it could have period or count with this change. Thanks, Namhyung -- 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: Linux 4.3 kallsyms_lookup_name not returning per_cpu symbol values
Got to the bottom of this one. bug closed.
Jeff
On 11/18/15, Jeffrey Merkey wrote:
> kallsyms_lookup_name is not returning per_cpu symbols when called.
> The symbols show up when you run something with the kallsyms_iter
> struct but not through the regular interface. I have looked through
> the code and I am not able to determine with certainty if its designed
> this way or just busted. Any help with this would be appreciated.
>
> The following code does display the per_cpu symbols, they just don't
> seem to show up when called from kallsyms_lookup_name.
>
>
> struct kallsym_iter mdb_iter;
> int mdb_kallsyms(char *str, int (*print)(char *s, ...))
> {
> register loff_t pos = 0;
> register struct kallsym_iter *iter = _iter;
>
> if (!print)
>return 0;
>
> // set to beginning of the kallsyms list
> reset_iter(iter, 0);
> while (1)
> {
>// search the kallsyms list
>if (!update_iter(iter, pos++))
> break;
>
>if (!iter->name[0])
> continue;
>
>// if an exclusion search was specified, skip non-matching entries
>if (str && *str && !strstr(iter->name, str))
> continue;
>
>if (iter->module_name[0])
>{
> if (print("%0*lx %c %s [%s]\n", (int)(2*sizeof(void*)),
> iter->value, iter->type, iter->name,
> iter->module_name))
> return 1;
>}
>else
>{
> if (print("%0*lx %c %s\n", (int)(2*sizeof(void*)),
> iter->value, iter->type, iter->name))
> return 1;
>}
> }
> return 0;
> }
> EXPORT_SYMBOL_GPL(mdb_kallsyms);
>
--
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/
Linus tree git problems self-modifying code?
If you checkout 4.3 the build it on i386 the following files show up as modified and tracked after the build completes. I can roll the files back but isn't this broken? This does mess up my git sync. [root@aya linux]# [root@aya linux]# [root@aya linux]# git status -s D arch/arm/boot/dts/include/dt-bindings D arch/arm64/boot/dts/include/dt-bindings D arch/metag/boot/dts/include/dt-bindings D arch/mips/boot/dts/include/dt-bindings D arch/powerpc/boot/dts/include/dt-bindings T tools/testing/selftests/powerpc/copyloops/copyuser_64.S T tools/testing/selftests/powerpc/copyloops/copyuser_power7.S T tools/testing/selftests/powerpc/copyloops/memcpy_64.S T tools/testing/selftests/powerpc/copyloops/memcpy_power7.S T tools/testing/selftests/powerpc/primitives/asm/asm-compat.h T tools/testing/selftests/powerpc/primitives/word-at-a-time.h T tools/testing/selftests/powerpc/stringloops/memcmp_64.S T tools/testing/selftests/powerpc/vphn/vphn.c T tools/testing/selftests/powerpc/vphn/vphn.h [root@aya linux]# [root@aya linux]# [root@aya linux]# 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 v1] mm: hugetlb: fix hugepage memory leak caused by wrong reserve count
On Fri, Nov 20, 2015 at 02:26:38PM -0800, Andrew Morton wrote:
> On Fri, 20 Nov 2015 15:57:21 +0800 "Hillf Danton"
> wrote:
>
> > >
> > > When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back to
> > > alloc_buddy_huge_page() to directly create a hugepage from the buddy
> > > allocator.
> > > In that case, however, if alloc_buddy_huge_page() succeeds we don't
> > > decrement
> > > h->resv_huge_pages, which means that successful hugetlb_fault() returns
> > > without
> > > releasing the reserve count. As a result, subsequent hugetlb_fault()
> > > might fail
> > > despite that there are still free hugepages.
> > >
> > > This patch simply adds decrementing code on that code path.
> > >
> > > I reproduced this problem when testing v4.3 kernel in the following
> > > situation:
> > > - the test machine/VM is a NUMA system,
> > > - hugepage overcommiting is enabled,
> > > - most of hugepages are allocated and there's only one free hugepage
> > > which is on node 0 (for example),
> > > - another program, which calls set_mempolicy(MPOL_BIND) to bind itself to
> > > node 1, tries to allocate a hugepage,
> > > - the allocation should fail but the reserve count is still hold.
> > >
> > > Signed-off-by: Naoya Horiguchi
> > > Cc: [3.16+]
> > > ---
> > > - the reason why I set stable target to "3.16+" is that this patch can be
> > > applied easily/automatically on these versions. But this bug seems to be
> > > old one, so if you are interested in backporting to older kernels,
> > > please let me know.
> > > ---
> > > mm/hugetlb.c |5 -
> > > 1 files changed, 4 insertions(+), 1 deletions(-)
> > >
> > > diff --git v4.3/mm/hugetlb.c v4.3_patched/mm/hugetlb.c
> > > index 9cc7734..77c518c 100644
> > > --- v4.3/mm/hugetlb.c
> > > +++ v4.3_patched/mm/hugetlb.c
> > > @@ -1790,7 +1790,10 @@ struct page *alloc_huge_page(struct vm_area_struct
> > > *vma,
> > > page = alloc_buddy_huge_page(h, NUMA_NO_NODE);
> > > if (!page)
> > > goto out_uncharge_cgroup;
> > > -
> > > + if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) {
> > > + SetPagePrivate(page);
> > > + h->resv_huge_pages--;
> > > + }
> >
> > I am wondering if this patch was prepared against the next tree.
>
> It's against 4.3.
Hi Hillf, Andrew,
That's right, this was against 4.3, and I agree with the adjustment
for next as done below.
> Here's the version I have, against current -linus:
>
> ---
> a/mm/hugetlb.c~mm-hugetlb-fix-hugepage-memory-leak-caused-by-wrong-reserve-count
> +++ a/mm/hugetlb.c
> @@ -1886,7 +1886,10 @@ struct page *alloc_huge_page(struct vm_a
> page = __alloc_buddy_huge_page_with_mpol(h, vma, addr);
> if (!page)
> goto out_uncharge_cgroup;
> -
> + if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) {
> + SetPagePrivate(page);
> + h->resv_huge_pages--;
> + }
> spin_lock(_lock);
> list_move(>lru, >hugepage_activelist);
> /* Fall through */
>
> It needs a careful re-review and, preferably, retest please.
I retested and made sure that the fix works on next-20151123.
Thanks,
Naoya Horiguchi
> Probably when Greg comes to merge this he'll hit problems and we'll
> need to provide him with the against-4.3 patch.
> --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [lkp] [direct] e594571852: xfstests.generic.299.fail
Jan Kara writes:
> Hello,
>
> On Mon 23-11-15 16:29:25, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> git://internal_merge_and_test_tree
>> revert-e594571852b03a5503ba48edd718462e99bf238e-e594571852b03a5503ba48edd718462e99bf238e
>> commit e594571852b03a5503ba48edd718462e99bf238e ("direct-io: Fix negative
>> return from dio read beyond eof")
>
> Do you have the file:
>
> /lkp/benchmarks/xfstests/results//generic/299.full
>
> produced by the failed test? Thanks!
I found we have this feature in our test scripts already, just need to
fix a bug in script, but that is just done yesterday! Please check the
299.full attached.
Best Regards,
Huang, Ying
299.full
Description: Binary data
Re: [PATCH] zram/zcomp: use GFP_NOIO to allocate streams
On (11/24/15 13:13), Minchan Kim wrote: > First of all, Thanks for the summary and proposal. sure :) > I think GFP_NOIO critical part(ie, your lockdep fix patch) should > go to -stable so it should stand alone. > > About vmalloc, I like that. Just problem was gfp and we can > pass it from upper layer so I believe it makes code looks clean > and solve differnt gfp problem. doing vmalloc() after kmalloc in general looks ok, but the thing is that kmalloc()->vmalloc() fallback does not mean that stream allocation will end up being successful, because right after ->private we need to allocate ->buffer via __get_free_pages() and that thing can fail. so trying harder in comp->backend->create() is just half of what we need. but the question is -- do we have a really big reason to fallback in ->private allocation? we are quite prepared to handle that allocation failure and I tend to think that in low memory condition it's probably better to avoid stealing pages for additional streams; one stream is just enough, if we are lucky to have more than one stream by that time -- then fine. > Please look at my patchset I just sent. I'll take a look once I receive them (not in my inbox yet). -ss -- 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 8/8] Use __kernel_long_t in struct mq_attr
On Fri, Dec 27, 2013 at 02:14:24PM -0800, H.J. Lu wrote:
> Both x32 and x86-64 use the same struct mq_attr for system calls. But
> x32 long is 32-bit. This patch replaces long with __kernel_long_t in
> struct mq_attr.
>
> Signed-off-by: H.J. Lu
> ---
> include/uapi/linux/mqueue.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/mqueue.h b/include/uapi/linux/mqueue.h
> index 8b5a796..d0a2b8e 100644
> --- a/include/uapi/linux/mqueue.h
> +++ b/include/uapi/linux/mqueue.h
> @@ -23,11 +23,11 @@
> #define MQ_BYTES_MAX 819200
>
> struct mq_attr {
> - longmq_flags; /* message queue flags */
> - longmq_maxmsg; /* maximum number of messages */
> - longmq_msgsize; /* maximum message size */
> - longmq_curmsgs; /* number of messages currently queued */
> - long__reserved[4]; /* ignored for input, zeroed for output */
> + __kernel_long_t mq_flags; /* message queue flags
> */
> + __kernel_long_t mq_maxmsg; /* maximum number of messages
> */
> + __kernel_long_t mq_msgsize; /* maximum message size
> */
> + __kernel_long_t mq_curmsgs; /* number of messages currently queued
> */
> + __kernel_long_t __reserved[4]; /* ignored for input, zeroed for output
> */
> };
>
> /*
This breaks userspace, please #include
before using __kernel_long_t.
--
ldv
pgpnSs0iZClaI.pgp
Description: PGP signature
Re: [PATCH -mm v2] mm: add page_check_address_transhuge helper
Hello,
On (11/20/15 12:31), Vladimir Davydov wrote:
[..]
> - if (ptep_clear_flush_young_notify(vma, address, pte)) {
> - /*
> - * Don't treat a reference through a sequentially read
> - * mapping as such. If the page has been used in
> - * another mapping, we will catch it; if this other
> - * mapping is already gone, the unmap path will have
> - * set PG_referenced or activated the page.
> - */
> - if (likely(!(vma->vm_flags & VM_SEQ_READ)))
> + if (pte) {
> + if (ptep_clear_flush_young_notify(vma, address, pte)) {
> + /*
> + * Don't treat a reference through a sequentially read
> + * mapping as such. If the page has been used in
> + * another mapping, we will catch it; if this other
> + * mapping is already gone, the unmap path will have
> + * set PG_referenced or activated the page.
> + */
> + if (likely(!(vma->vm_flags & VM_SEQ_READ)))
> + referenced++;
> + }
> + pte_unmap(pte);
> + } else {
> + if (pmdp_clear_flush_young_notify(vma, address, pmd))
> referenced++;
> }
# CONFIG_TRANSPARENT_HUGEPAGE is not set
x86_64, 4.4.0-rc2-mm1
mm/built-in.o: In function `page_referenced_one':
rmap.c:(.text+0x32070): undefined reference to `pmdp_clear_flush_young'
-ss
--
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] i2c: cadence: Move to sensible power management
On Tue, Nov 24, 2015 at 12:17 AM, Sören Brinkmann wrote: > On Sat, 2015-11-21 at 07:00PM +0530, Shubhrajyoti Datta wrote: >> On Thu, Oct 29, 2015 at 8:27 PM, Shubhrajyoti Datta >> wrote: >> > On Wed, Oct 28, 2015 at 9:48 PM, Sören Brinkmann >> > wrote: >> >> Hi Shubhrajyoti, >> >> >> >> >> >> On Wed, 2015-10-28 at 12:56PM +0530, Shubhrajyoti Datta wrote: >> >>> Currently the clocks are enabled at probe and disabled at remove. >> >>> Which keeps the clocks enabled even if no transaction is going on. >> >>> This patch enables the clocks at the start of transfer and disables >> >>> after it. >> >>> >> >>> Also adapts to runtime pm. >> >>> Remove xi2c->suspended and use pm runtime status instead. >> >>> >> >>> converts dev pm to const to silence a checkpatch warning. >> >>> >> >>> Signed-off-by: Shubhrajyoti Datta >> >> >> >> To me, this looks all good. Just one small concern below. >> > >> > Thanks for the review. >> Soren , >> Do are you ok with the change or do you want me to resend without the >> suspended flag change. > > I'm always for removing code that is not needed. If things are tested > and well and work without throwing any warnings I'm OK with it. It should be also having a suspended book-keeping in the driver is not needed the pm does that for us. I will spilt the patch and resend. Thanks, > > Sören -- 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/
linux-next: Tree for Nov 24
Hi all, Changes since 20151123: The net-next tree gained a conflict against the net tree. The drm-panel tree gained a build failure so I used the version from next-20151123. Non-merge commits (relative to Linus' tree): 2366 2981 files changed, 92039 insertions(+), 35632 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (a2931547eee1 Merge tag 'linux-kselftest-4.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4) Merging arm-current/fixes (28fa99b7645a ARM: wire up mlock2 syscall) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (1451ad03fac3 powerpc: Wire up sys_mlock2()) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (3d1a54e801b6 net/hsr: fix a warning message) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (086f332167d6 netfilter: nf_tables: add clone interface to expression operations) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (5ff3ca288894 mac80211: don't teardown sdata on sdata stop) Merging sound-current/for-linus (196543d54574 ALSA: hda - Apply HP headphone fixups more generically) Merging pci-current/for-linus (8005c49d9aea Linux 4.4-rc1) Merging driver-core.current/driver-core-linus (8005c49d9aea Linux 4.4-rc1) Merging tty.current/tty-linus (bd63acf9e9a6 serial: export fsl8250_handle_irq) Merging usb.current/usb-linus (19cd80a21482 usblp: do not set TASK_INTERRUPTIBLE before lock) Merging usb-gadget-fixes/fixes (f74875dc3613 usb: dwc2: fix kernel oops during driver probe) Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon flash loader USB ID) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (1ec218373b8e Linux 4.4-rc2) Merging char-misc.current/char-misc-linus (1ec218373b8e Linux 4.4-rc2) Merging input-current/for-linus (0c6da0733bff Input: parkbd - clear unused function pointers) Merging crypto-current/master (79960943fdc1 crypto: talitos - Fix timing leak in ESP ICV verification) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (2ce47b44b25d selftests/seccomp: Get page size from sysconf) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging ftrace-fixes/for-next-urgent (6224be
Re: [PATCH 3/3] clk: split of_clk_get_parent_name() into two functions
Hi Stephen,
2015-11-22 14:44 GMT+09:00 Masahiro Yamada :
> Hi Stephen,
>
>
> 2015-11-21 9:37 GMT+09:00 Stephen Boyd :
>> On 11/20, Masahiro Yamada wrote:
>>> Currently, there is no function to get the clock name of the given
>>> node. Create a new helper function, of_clk_get_name(). This is
>>> useful to get the clock name where "clock-indices" property is used.
>>>
>>> of_clk_get_name(): get the clock name in the given node
>>> of_clk_get_parent_name(): get the name of the parent clock
>>>
>>> Signed-off-by: Masahiro Yamada
>>> ---
>>>
>>> I want to use of_clk_get_name() for my clk drivers for my SoCs,
>>> which I will submit later.
>>>
>>> I found this helper function is useful.
>>
>> I don't see how this is useful. Is the new driver so generic it
>> doesn't know what clocks it's outputting? We've been trying to
>> move people away from using clock-output-names, so most likely
>> this sort of information should be conveyed from DT via the
>> compatible string and a table in the driver that matches up the
>> compatible string with the list of clock names.
>
>
> What I implemented in my driver was:
>
> [1] Use the clock names built in the driver, if "clock-output-names"
> is missing in the DT.
>
> [2] If "clock-output-names" is specified, the driver overrides
> the clock names, respecting the "clock-output-names".
>
>
> The following is a snippet from my driver code.
>
>
> /*
> * update the clock name with the one provided by
> * clock-output-names property, if exists
> */
> new_name = of_clk_get_name(np, index);
> if (new_name)
> init_data[i].name = new_name;
> else
> pr_info("DT does not specify output name for %s[%d]\n",
> np->name, index);
>
>
> I read the Documentation/devicetree/bindings/clock-bindings.txt
> before I stared my driver development.
>
> I did not know we are deprecating the "clock-output-names".
> (Should it be mentioned in the clock-bindings.txt?)
Please let me clarify the driver implementation guideline.
[1] Do not add "clock-output-names" in new device trees.
[2] New clock drivers should not rely on "clock-output-names" at all.
Is this correct?
--
Best Regards
Masahiro Yamada
--
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: + arc-convert-to-dma_map_ops.patch added to -mm tree
On Wednesday 18 November 2015 03:08 AM, a...@linux-foundation.org wrote:
> The patch titled
> Subject: arc: convert to dma_map_ops
> has been added to the -mm tree. Its filename is
> arc-convert-to-dma_map_ops.patch
>
> This patch should soon appear at
> http://ozlabs.org/~akpm/mmots/broken-out/arc-convert-to-dma_map_ops.patch
> and later at
> http://ozlabs.org/~akpm/mmotm/broken-out/arc-convert-to-dma_map_ops.patch
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Christoph Hellwig
> Subject: arc: convert to dma_map_ops
>
> Signed-off-by: Christoph Hellwig
> Cc: Vineet Gupta
> Signed-off-by: Andrew Morton
> ---
>
> arch/arc/Kconfig |1
> arch/arc/include/asm/dma-mapping.h | 187 ---
> arch/arc/mm/dma.c | 151 +++--
> 3 files changed, 109 insertions(+), 230 deletions(-)
>
> diff -puN arch/arc/Kconfig~arc-convert-to-dma_map_ops arch/arc/Kconfig
> --- a/arch/arc/Kconfig~arc-convert-to-dma_map_ops
> +++ a/arch/arc/Kconfig
> @@ -38,6 +38,7 @@ config ARC
> select OF_EARLY_FLATTREE
> select PERF_USE_VMALLOC
> select HAVE_DEBUG_STACKOVERFLOW
> + select HAVE_DMA_ATTRS
>
> config TRACE_IRQFLAGS_SUPPORT
> def_bool y
> diff -puN arch/arc/include/asm/dma-mapping.h~arc-convert-to-dma_map_ops
> arch/arc/include/asm/dma-mapping.h
> --- a/arch/arc/include/asm/dma-mapping.h~arc-convert-to-dma_map_ops
> +++ a/arch/arc/include/asm/dma-mapping.h
> @@ -11,192 +11,13 @@
> #ifndef ASM_ARC_DMA_MAPPING_H
> #define ASM_ARC_DMA_MAPPING_H
>
> -#include
> -#include
> +extern struct dma_map_ops arc_dma_ops;
>
> -void *dma_alloc_noncoherent(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t gfp);
> -
> -void dma_free_noncoherent(struct device *dev, size_t size, void *vaddr,
> - dma_addr_t dma_handle);
> -
> -void *dma_alloc_coherent(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t gfp);
> -
> -void dma_free_coherent(struct device *dev, size_t size, void *kvaddr,
> -dma_addr_t dma_handle);
> -
> -/* drivers/base/dma-mapping.c */
> -extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> -void *cpu_addr, dma_addr_t dma_addr, size_t size);
> -extern int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
> - void *cpu_addr, dma_addr_t dma_addr,
> - size_t size);
> -
> -#define dma_mmap_coherent(d, v, c, h, s) dma_common_mmap(d, v, c, h, s)
> -#define dma_get_sgtable(d, t, v, h, s) dma_common_get_sgtable(d, t, v, h, s)
> -
> -/*
> - * streaming DMA Mapping API...
> - * CPU accesses page via normal paddr, thus needs to explicitly made
> - * consistent before each use
> - */
> -
> -static inline void __inline_dma_cache_sync(unsigned long paddr, size_t size,
> -enum dma_data_direction dir)
> -{
> - switch (dir) {
> - case DMA_FROM_DEVICE:
> - dma_cache_inv(paddr, size);
> - break;
> - case DMA_TO_DEVICE:
> - dma_cache_wback(paddr, size);
> - break;
> - case DMA_BIDIRECTIONAL:
> - dma_cache_wback_inv(paddr, size);
> - break;
> - default:
> - pr_err("Invalid DMA dir [%d] for OP @ %lx\n", dir, paddr);
> - }
> -}
> -
> -void __arc_dma_cache_sync(unsigned long paddr, size_t size,
> - enum dma_data_direction dir);
> -
> -#define _dma_cache_sync(addr, sz, dir) \
> -do { \
> - if (__builtin_constant_p(dir)) \
> - __inline_dma_cache_sync(addr, sz, dir); \
> - else\
> - __arc_dma_cache_sync(addr, sz, dir);\
> -}\
> -while (0);
> -
> -static inline dma_addr_t
> -dma_map_single(struct device *dev, void *cpu_addr, size_t size,
> -enum dma_data_direction dir)
> -{
> - _dma_cache_sync((unsigned long)cpu_addr, size, dir);
> - return (dma_addr_t)cpu_addr;
> -}
> -
> -static inline void
> -dma_unmap_single(struct device *dev, dma_addr_t dma_addr,
> - size_t size, enum dma_data_direction dir)
> -{
> -}
> -
> -static inline dma_addr_t
> -dma_map_page(struct device *dev, struct page *page,
> - unsigned long
Re: lapic_suspend/lapic_resume wrong?
Hi Juergen, [auto build test ERROR on v4.4-rc2] [also build test ERROR on next-20151123] [cannot apply to tip/x86/core] url: https://github.com/0day-ci/linux/commits/Juergen-Gross/lapic_suspend-lapic_resume-wrong/20151123-155328 config: arm64-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): drivers/xen/events/events_base.c: In function 'xen_allocate_irq_gsi': >> drivers/xen/events/events_base.c:424:2: error: implicit declaration of >> function 'nr_legacy_irqs' [-Werror=implicit-function-declaration] if (gsi < nr_legacy_irqs()) ^ cc1: some warnings being treated as errors vim +/nr_legacy_irqs +424 drivers/xen/events/events_base.c 418 * space. 419 */ 420 if (xen_pv_domain() && !xen_initial_domain()) 421 return xen_allocate_irq_dynamic(); 422 423 /* Legacy IRQ descriptors are already allocated by the arch. */ > 424 if (gsi < nr_legacy_irqs()) 425 irq = gsi; 426 else 427 irq = irq_alloc_desc_at(gsi, -1); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH] zram/zcomp: use GFP_NOIO to allocate streams
Hi Sergey, On Tue, Nov 24, 2015 at 10:29:27AM +0900, Sergey Senozhatsky wrote: > Cc Kyeongdon > > On (11/23/15 16:47), Andrew Morton wrote: > [..] > > > > Doesn't make a lot of sense to me. We use a weakened gfp for the > > kmalloc and if that fails, fall into vmalloc() using the stronger gfp > > anyway. > > Sir, you are right. that was "fixed" in my patch (but I definitely should > have been more attentive when I reviewed Kyeongdon's patch and that was > a mistake to address this in my patch) > > I didn't spot it until I replaced vzalloc() with __vmalloc() working on > my GFP_NOIO patch: > > + return __vmalloc(LZ4_MEM_COMPRESS, > + GFP_NOIO | __GFP_NOWARN | __GFP_HIGHMEM | __GFP_ZERO, > + PAGE_KERNEL); > > > but I agree that we have created a mess already. > > > Perhaps it makes sense for higher-order allocations: we don't want to > > thrash around trying to create an order-2 page - we'd prefer to give up > > and fall into vmalloc to do a bunch of order-0 allocations. > > > > But this argument holds for 1000 other kmalloc->vmalloc allocation > > attempts - what's special about this one? > > > > And whatever is the reason for this peculiar setup, > > > > a) where's the proof that the change is actually beneficial? > > b) let's get a good code comment in place so that future readers are not > >similarly puzzled. > > or > > c) start anew (hopefully Minchan and Kyeongdon are with me) > > > Per Kyeongdon's comment > > :When we're using LZ4 multi compression streams for zram swap, > :we found out page allocation failure message in system running test. > :That was not only once, but a few(2 - 5 times per test). > :Also, some failure cases were continually occurring to try allocation > :order 3. > : > :In order to make parallel compression private data, we should call > :kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order > : 2/3 size memory to allocate in that time, page allocation fails. > :This patch makes to use vmalloc() as fallback of kmalloc(), this > :prevents page alloc failure warning. > > > so (what I missed in the first place) is that the patch does not really > prevent page alloc failures warnings, because vmalloc() is still free to > warn us on every failed allocation. second, vmalloc() can fail and, thus, > we still will go down the 'do not attempt to allocate any memory anymore, > just wait for available stream to become idle'. > > > so my proposal > > patch 1: > a) switch to GFP_NOIO in critical parts (OR remove entirely remove the > 'dynamic' stream creation functionality. IOW, do not allocate compression > streams from IO path, wait for and use available streams). > > patch 2: > b) do not fallback to vmalloc (we are prepared to handle kmalloc failures) > c) add NOWARN to kmalloc (just to reduce the warning pressure) > > > well, (b) and (c), technically, can be merged with (a) but I have no > objections to have it as a separate patch. > > > > what do you guys think? First of all, Thanks for the summary and proposal. I think GFP_NOIO critical part(ie, your lockdep fix patch) should go to -stable so it should stand alone. About vmalloc, I like that. Just problem was gfp and we can pass it from upper layer so I believe it makes code looks clean and solve differnt gfp problem. Please look at my patchset I just sent. Thanks a lot! -- 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: [V5 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
Hi,
> On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote:
> > If panic on NMI happens just after panic() on the same CPU, panic()
> > is recursively called. As the result, it stalls after failing to
> > acquire panic_lock.
> >
> > To avoid this problem, don't call panic() in NMI context if
> > we've already entered panic().
> >
> > V4:
> > - Improve comments in io_check_error() and panic()
> >
> > V3:
> > - Introduce nmi_panic() macro to reduce code duplication
> > - In the case of panic on NMI, don't return from NMI handlers
> > if another cpu already panicked
> >
> > V2:
> > - Use atomic_cmpxchg() instead of current spin_trylock() to
> > exclude concurrent accesses to the panic routines
> > - Don't introduce no-lock version of panic()
> >
> > Signed-off-by: Hidehiro Kawai
> > Cc: Andrew Morton
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Peter Anvin"
> > Cc: Peter Zijlstra
> > Cc: Michal Hocko
> > ---
> > arch/x86/kernel/nmi.c | 16
> > include/linux/kernel.h | 13 +
> > kernel/panic.c | 15 ---
> > kernel/watchdog.c |2 +-
> > 4 files changed, 38 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
> > index 697f90d..5131714 100644
> > --- a/arch/x86/kernel/nmi.c
> > +++ b/arch/x86/kernel/nmi.c
> > @@ -231,7 +231,7 @@ pci_serr_error(unsigned char reason, struct pt_regs
> > *regs)
> > #endif
> >
> > if (panic_on_unrecovered_nmi)
> > - panic("NMI: Not continuing");
> > + nmi_panic("NMI: Not continuing");
> >
> > pr_emerg("Dazed and confused, but trying to continue\n");
> >
> > @@ -255,8 +255,16 @@ io_check_error(unsigned char reason, struct pt_regs
> > *regs)
> > reason, smp_processor_id());
> > show_regs(regs);
> >
> > - if (panic_on_io_nmi)
> > - panic("NMI IOCK error: Not continuing");
> > + if (panic_on_io_nmi) {
> > + nmi_panic("NMI IOCK error: Not continuing");
>
> Btw, that panic_on_io_nmi seems undocumented in
> Documentation/sysctl/kernel.txt. Care to document it, please, as a
> separate patch?
Sure. I'll post a documentation patch for it in a separate patch.
Because panic_on_io_nmi has been available since relatively old days,
I didn't check it.
> > +
> > + /*
> > +* If we return from nmi_panic(), it means we have received
> > +* NMI while processing panic(). So, simply return without
> > +* a delay and re-enabling NMI.
> > +*/
> > + return;
> > + }
> >
> > /* Re-enable the IOCK line, wait for a few seconds */
> > reason = (reason & NMI_REASON_CLEAR_MASK) | NMI_REASON_CLEAR_IOCHK;
> > @@ -297,7 +305,7 @@ unknown_nmi_error(unsigned char reason, struct pt_regs
> > *regs)
> >
> > pr_emerg("Do you have a strange power saving mode enabled?\n");
> > if (unknown_nmi_panic || panic_on_unrecovered_nmi)
> > - panic("NMI: Not continuing");
> > + nmi_panic("NMI: Not continuing");
> >
> > pr_emerg("Dazed and confused, but trying to continue\n");
> > }
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index 350dfb0..480a4fd 100644
> > --- a/include/linux/kernel.h
> > +++ b/include/linux/kernel.h
> > @@ -445,6 +445,19 @@ extern int sysctl_panic_on_stackoverflow;
> >
> > extern bool crash_kexec_post_notifiers;
> >
> > +extern atomic_t panic_cpu;
>
> This needs a comment explaining what this variable is and what it
> denotes.
OK, I'll do that in the next version.
>
> > +
> > +/*
> > + * A variant of panic() called from NMI context.
> > + * If we've already panicked on this cpu, return from here.
> > + */
> > +#define nmi_panic(fmt, ...)
> > \
> > + do {\
> > + int this_cpu = raw_smp_processor_id(); \
> > + if (atomic_cmpxchg(_cpu, -1, this_cpu) != this_cpu) \
> > + panic(fmt, ##__VA_ARGS__); \
> > + } while (0)
> > +
> > /*
> > * Only to be used by arch init code. If the user over-wrote the default
> > * CONFIG_PANIC_TIMEOUT, honor it.
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 4579dbb..24ee2ea 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -61,6 +61,8 @@ void __weak panic_smp_self_stop(void)
> > cpu_relax();
> > }
> >
> > +atomic_t panic_cpu = ATOMIC_INIT(-1);
> > +
> > /**
> > * panic - halt the system
> > * @fmt: The text string to print
> > @@ -71,17 +73,17 @@ void __weak panic_smp_self_stop(void)
> > */
> > void panic(const char *fmt, ...)
> > {
> > - static DEFINE_SPINLOCK(panic_lock);
> > static char buf[1024];
> > va_list args;
> > long i, i_next = 0;
> > int state = 0;
> > + int old_cpu, this_cpu;
> >
> > /*
> > * Disable local interrupts. This will prevent panic_smp_self_stop
>
Re: [PATCH] pcnet32: fix a logic error with pci_set_dma_mask
On Wed, Oct 21, 2015 at 09:01:26PM -0700, Don Fry wrote: > On Mon, 2015-10-12 at 05:38 -0700, David Miller wrote: > > From: Geliang Tang > > Date: Fri, 9 Oct 2015 03:45:39 -0700 > > > > > pcnet32 can't work on my machine recently. It says "architecture > > > does not support 32bit PCI busmaster DMA". There is a logic error > > > in it: pci_set_dma_mask() return 0 means return successfully. > > > > > > Signed-off-by: Geliang Tang > > > > This driver doesn't call pci_set_dma_mask() in any of my tree(s). > I failed. My system with pcnet32 boards was down with a dead power > supply and a visual review was not good enough. I missed that > pci_dma_supported returns 1 on success and pci_set_dma_mask returns 0 on > success. The original patch needs to have the ! removed as Geliang Tang > points out. > > Acked-by: Don Fry Hi: It has been a month since I submitted this patch. I'm wondering is it still valid and wether it will be applied? A recent commit targeting at the same problem (commit 1a47de6 various: fix pci_set_dma_mask return value checking) has been applied. But my commit, which I reported and submitted earlier, hasn't been applied. I'd like to know if there's anything wrong with it? Thank you! - Geliang Tang -- 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/
[RFC 3/3] zram: pass gfp from zcomp frontend to backend
Each zcomp backend uses own gfp flag but it's pointless
because the context they could be called is driven by upper
layer(ie, zcomp frontend). As well, zcomp frondend could
call them in different context. One context(ie, zram init part)
is it should be better to make sure successful allocation
other context(ie, further stream allocation part for accelarating
I/O speed) is just optional so let's pass gfp down from driver
(ie, zcomp frontend) like normal MM convention.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zcomp.c | 24
drivers/block/zram/zcomp.h | 2 +-
drivers/block/zram/zcomp_lz4.c | 10 +++---
drivers/block/zram/zcomp_lzo.c | 10 +++---
4 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index c536177..77a7819 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -74,18 +74,18 @@ static void zcomp_strm_free(struct zcomp *comp, struct
zcomp_strm *zstrm)
* allocate new zcomp_strm structure with ->private initialized by
* backend, return NULL on error
*/
-static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
+static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp, gfp_t flags)
{
- struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
+ struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), flags);
if (!zstrm)
return NULL;
- zstrm->private = comp->backend->create();
+ zstrm->private = comp->backend->create(flags);
/*
* allocate 2 pages. 1 for compressed data, plus 1 extra for the
* case when compressed size is larger than the original one
*/
- zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
+ zstrm->buffer = (void *)__get_free_pages(flags | __GFP_ZERO, 1);
if (!zstrm->private || !zstrm->buffer) {
zcomp_strm_free(comp, zstrm);
zstrm = NULL;
@@ -120,8 +120,16 @@ static struct zcomp_strm *zcomp_strm_multi_find(struct
zcomp *comp)
/* allocate new zstrm stream */
zs->avail_strm++;
spin_unlock(>strm_lock);
-
- zstrm = zcomp_strm_alloc(comp);
+ /*
+* This function could be called in swapout/fs write path
+* so we couldn't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
+*/
+ zstrm = zcomp_strm_alloc(comp, __GFP_NORETRY|__GFP_NOWARN|
+ __GFP_NOMEMALLOC|__GFP_ZERO);
if (!zstrm) {
spin_lock(>strm_lock);
zs->avail_strm--;
@@ -209,7 +217,7 @@ static int zcomp_strm_multi_create(struct zcomp *comp, int
max_strm)
zs->max_strm = max_strm;
zs->avail_strm = 1;
- zstrm = zcomp_strm_alloc(comp);
+ zstrm = zcomp_strm_alloc(comp, GFP_KERNEL);
if (!zstrm) {
kfree(zs);
return -ENOMEM;
@@ -259,7 +267,7 @@ static int zcomp_strm_single_create(struct zcomp *comp)
comp->stream = zs;
mutex_init(>strm_lock);
- zs->zstrm = zcomp_strm_alloc(comp);
+ zs->zstrm = zcomp_strm_alloc(comp, GFP_KERNEL);
if (!zs->zstrm) {
kfree(zs);
return -ENOMEM;
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 46e2b9f..b7d2a4b 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -33,7 +33,7 @@ struct zcomp_backend {
int (*decompress)(const unsigned char *src, size_t src_len,
unsigned char *dst);
- void *(*create)(void);
+ void *(*create)(gfp_t flags);
void (*destroy)(void *private);
const char *name;
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index 928bd72..659c4ec 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -15,7 +15,7 @@
#include "zcomp_lz4.h"
-static void *zcomp_lz4_create(void)
+static void *zcomp_lz4_create(gfp_t flags)
{
void *ret;
@@ -27,13 +27,9 @@ static void *zcomp_lz4_create(void)
* A default stream will work well without further multiple
* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
*/
- ret = kzalloc(LZ4_MEM_COMPRESS,
- __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
+ ret = kmalloc(LZ4_MEM_COMPRESS, flags);
if (!ret)
- ret = __vmalloc(LZ4_MEM_COMPRESS,
- __GFP_NORETRY|__GFP_NOWARN|
-
[PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams
From: Sergey Senozhatsky
We can end up allocating a new compression stream with GFP_KERNEL
from within the IO path, which may result is nested (recursive) IO
operations. That can introduce problems if the IO path in question
is a reclaimer, holding some locks that will deadlock nested IOs.
Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.
An example:
[ 747.233722] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
[ 747.233724] git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 747.233725] (jbd2_handle){+.+.?.}, at: []
start_this_handle+0x4ca/0x555
[ 747.233733] {IN-RECLAIM_FS-W} state was registered at:
[ 747.233735] [] __lock_acquire+0x8da/0x117b
[ 747.233738] [] lock_acquire+0x10c/0x1a7
[ 747.233740] [] start_this_handle+0x52d/0x555
[ 747.233742] [] jbd2__journal_start+0xb4/0x237
[ 747.233744] [] __ext4_journal_start_sb+0x108/0x17e
[ 747.233748] [] ext4_dirty_inode+0x32/0x61
[ 747.233750] [] __mark_inode_dirty+0x16b/0x60c
[ 747.233754] [] iput+0x11e/0x274
[ 747.233757] [] __dentry_kill+0x148/0x1b8
[ 747.233759] [] shrink_dentry_list+0x274/0x44a
[ 747.233761] [] prune_dcache_sb+0x4a/0x55
[ 747.233763] [] super_cache_scan+0xfc/0x176
[ 747.233767] []
shrink_slab.part.14.constprop.25+0x2a2/0x4d3
[ 747.233770] [] shrink_zone+0x74/0x140
[ 747.233772] [] kswapd+0x6b7/0x930
[ 747.233774] [] kthread+0x107/0x10f
[ 747.233778] [] ret_from_fork+0x3f/0x70
[ 747.233783] irq event stamp: 138297
[ 747.233784] hardirqs last enabled at (138297): []
debug_check_no_locks_freed+0x113/0x12f
[ 747.233786] hardirqs last disabled at (138296): []
debug_check_no_locks_freed+0x33/0x12f
[ 747.233788] softirqs last enabled at (137818): []
__do_softirq+0x2d3/0x3e9
[ 747.233792] softirqs last disabled at (137813): []
irq_exit+0x41/0x95
[ 747.233794]
other info that might help us debug this:
[ 747.233796] Possible unsafe locking scenario:
[ 747.233797]CPU0
[ 747.233798]
[ 747.233799] lock(jbd2_handle);
[ 747.233801]
[ 747.233801] lock(jbd2_handle);
[ 747.233803]
*** DEADLOCK ***
[ 747.233805] 5 locks held by git/20158:
[ 747.233806] #0: (sb_writers#7){.+.+.+}, at: []
mnt_want_write+0x24/0x4b
[ 747.233811] #1: (>i_mutex_dir_key#2/1){+.+.+.}, at:
[] lock_rename+0xd9/0xe3
[ 747.233817] #2: (>s_type->i_mutex_key#11){+.+.+.}, at:
[] lock_two_nondirectories+0x3f/0x6b
[ 747.233822] #3: (>s_type->i_mutex_key#11/4){+.+.+.}, at:
[] lock_two_nondirectories+0x66/0x6b
[ 747.233827] #4: (jbd2_handle){+.+.?.}, at: []
start_this_handle+0x4ca/0x555
[ 747.233831]
stack backtrace:
[ 747.233834] CPU: 2 PID: 20158 Comm: git Not tainted
4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
[ 747.233837] 8800a56cea40 88010d0a75f8 814f446d
81077036
[ 747.233840] 823a84b0 88010d0a7638 814f3849
0001
[ 747.233843] 000a 8800a56cf6f8 8800a56cea40
810795dd
[ 747.233846] Call Trace:
[ 747.233849] [] dump_stack+0x4c/0x6e
[ 747.233852] [] ? up+0x39/0x3e
[ 747.233854] [] print_usage_bug.part.23+0x25b/0x26a
[ 747.233857] [] ?
print_shortest_lock_dependencies+0x182/0x182
[ 747.233859] [] mark_lock+0x384/0x56d
[ 747.233862] [] mark_held_locks+0x5f/0x76
[ 747.233865] [] ? zcomp_strm_alloc+0x25/0x73 [zram]
[ 747.233867] [] lockdep_trace_alloc+0xb2/0xb5
[ 747.233870] [] kmem_cache_alloc_trace+0x32/0x1e2
[ 747.233873] [] zcomp_strm_alloc+0x25/0x73 [zram]
[ 747.233876] [] zcomp_strm_multi_find+0xe7/0x173 [zram]
[ 747.233879] [] zcomp_strm_find+0xc/0xe [zram]
[ 747.233881] [] zram_bvec_rw+0x2ca/0x7e0 [zram]
[ 747.233885] [] zram_make_request+0x1fa/0x301 [zram]
[ 747.233889] [] generic_make_request+0x9c/0xdb
[ 747.233891] [] submit_bio+0xf7/0x120
[ 747.233895] [] ? __test_set_page_writeback+0x1a0/0x1b8
[ 747.233897] [] ext4_io_submit+0x2e/0x43
[ 747.233899] [] ext4_bio_write_page+0x1b7/0x300
[ 747.233902] [] mpage_submit_page+0x60/0x77
[ 747.233905] [] mpage_map_and_submit_buffers+0x10f/0x21d
[ 747.233907] [] ext4_writepages+0xc8c/0xe1b
[ 747.233910] [] do_writepages+0x23/0x2c
[ 747.233913] [] __filemap_fdatawrite_range+0x84/0x8b
[ 747.233915] [] filemap_flush+0x1c/0x1e
[ 747.233917] [] ext4_alloc_da_blocks+0xb8/0x117
[ 747.233919] [] ext4_rename+0x132/0x6dc
[ 747.233921] [] ? mark_held_locks+0x5f/0x76
[ 747.233924] [] ext4_rename2+0x29/0x2b
[ 747.233926] [] vfs_rename+0x540/0x636
[ 747.233928] [] SyS_renameat2+0x359/0x44d
[ 747.233931] [] SyS_rename+0x1e/0x20
[ 747.233933] [] entry_SYSCALL_64_fastpath+0x12/0x6f
The patch also does some very trivial cosmetic tweaks, not worth
of a separate patch.
[minchan: drop vmalloc part and cosmetic change]
Signed-off-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
I hope to send it -to stable if Sergey agree.
drivers/block/zram/zcomp.c | 4
[PATCH 2/3] zram: try vmalloc() after kmalloc()
From: Kyeongdon Kim
When we're using LZ4 multi compression streams for zram swap,
we found out page allocation failure message in system running test.
That was not only once, but a few(2 - 5 times per test).
Also, some failure cases were continually occurring to try allocation
order 3.
In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
2/3 size memory to allocate in that time, page allocation fails.
This patch makes to use vmalloc() as fallback of kmalloc(), this
prevents page alloc failure warning.
After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.
For reference a call trace :
Binder_1: page allocation failure: order:3, mode:0x10c0d0
CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
Call trace:
[] dump_backtrace+0x0/0x270
[] show_stack+0x10/0x1c
[] dump_stack+0x1c/0x28
[] warn_alloc_failed+0xfc/0x11c
[] __alloc_pages_nodemask+0x724/0x7f0
[] __get_free_pages+0x14/0x5c
[] kmalloc_order_trace+0x38/0xd8
[] zcomp_lz4_create+0x2c/0x38
[] zcomp_strm_alloc+0x34/0x78
[] zcomp_strm_multi_find+0x124/0x1ec
[] zcomp_strm_find+0xc/0x18
[] zram_bvec_rw+0x2fc/0x780
[] zram_make_request+0x25c/0x2d4
[] generic_make_request+0x80/0xbc
[] submit_bio+0xa4/0x15c
[] __swap_writepage+0x218/0x230
[] swap_writepage+0x3c/0x4c
[] shrink_page_list+0x51c/0x8d0
[] shrink_inactive_list+0x3f8/0x60c
[] shrink_lruvec+0x33c/0x4cc
[] shrink_zone+0x3c/0x100
[] try_to_free_pages+0x2b8/0x54c
[] __alloc_pages_nodemask+0x514/0x7f0
[] __get_free_pages+0x14/0x5c
[] proc_info_read+0x50/0xe4
[] vfs_read+0xa0/0x12c
[] SyS_read+0x44/0x74
DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
[minchan: change vmalloc gfp and adding comment about gfp]
Signed-off-by: Kyeongdon Kim
Signed-off-by: Minchan Kim
---
drivers/block/zram/zcomp_lz4.c | 23 +--
drivers/block/zram/zcomp_lzo.c | 23 +--
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index f2afb7e..928bd72 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -10,17 +10,36 @@
#include
#include
#include
+#include
+#include
#include "zcomp_lz4.h"
static void *zcomp_lz4_create(void)
{
- return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
+ void *ret;
+
+ /*
+* This function could be called in swapout/fs write path
+* so we couldn't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
+*/
+ ret = kzalloc(LZ4_MEM_COMPRESS,
+ __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
+ if (!ret)
+ ret = __vmalloc(LZ4_MEM_COMPRESS,
+ __GFP_NORETRY|__GFP_NOWARN|
+ __GFP_NOMEMALLOC|__GFP_ZERO,
+ PAGE_KERNEL);
+ return ret;
}
static void zcomp_lz4_destroy(void *private)
{
- kfree(private);
+ kvfree(private);
}
static int zcomp_lz4_compress(const unsigned char *src, unsigned char *dst,
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index da1bc47..044410a 100644
--- a/drivers/block/zram/zcomp_lzo.c
+++ b/drivers/block/zram/zcomp_lzo.c
@@ -10,17 +10,36 @@
#include
#include
#include
+#include
+#include
#include "zcomp_lzo.h"
static void *lzo_create(void)
{
- return kzalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL);
+ void *ret;
+ /*
+* This function could be called in swapout/fs write path
+* so we couldn't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
+*/
+ ret = kzalloc(LZO1X_MEM_COMPRESS,
+ __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC);
+ if (!ret)
+ ret = __vmalloc(LZO1X_MEM_COMPRESS,
+ __GFP_NORETRY|__GFP_NOWARN|
+ __GFP_NOMEMALLOC|__GFP_ZERO,
+ PAGE_KERNEL);
+ return ret;
+
}
static void lzo_destroy(void *private)
{
- kfree(private);
+ kvfree(private);
}
static int lzo_compress(const unsigned char *src, unsigned char *dst,
--
1.9.3
--
To unsubscribe from this list: send
[PATCH v4 2/6] mfd: axp20x: Split the driver into core and i2c bits
The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".
This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.
Included but unused header files are removed as well.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 14 +++--
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-i2c.c | 127 +
drivers/mfd/axp20x.c | 108 +-
include/linux/mfd/axp20x.h | 33 +++-
5 files changed, 183 insertions(+), 100 deletions(-)
create mode 100644 drivers/mfd/axp20x-i2c.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6ef9fe..804cd3dcce32 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
Support for the BCM590xx PMUs from Broadcom
config MFD_AXP20X
- bool "X-Powers AXP20X"
+ tristate
select MFD_CORE
- select REGMAP_I2C
select REGMAP_IRQ
- depends on I2C=y
+
+config MFD_AXP20X_I2C
+ tristate "X-Powers AXP series PMICs with I2C"
+ select MFD_AXP20X
+ select REGMAP_I2C
+ depends on I2C
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with I2C.
This driver include only the core APIs. You have to select individual
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b81b467..a6913007d667 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index ..75b247af2514
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,127 @@
+/*
+ * axp20x-i2c.c - I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Author: Carlo Caione
+ *
+ * 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
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+ { .compatible = "x-powers,axp152", .data = (void *) AXP152_ID },
+ { .compatible = "x-powers,axp202", .data = (void *) AXP202_ID },
+ { .compatible = "x-powers,axp209", .data = (void *) AXP209_ID },
+ { .compatible = "x-powers,axp221", .data = (void *) AXP221_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id axp20x_i2c_acpi_match[] = {
+ {
+ .id = "INT33F4",
+ .driver_data = AXP288_ID,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, axp20x_i2c_acpi_match);
+
+static int axp20x_i2c_match_device(struct axp20x_dev *axp20x,
+ struct device *dev)
+{
+ const struct acpi_device_id *acpi_id;
+ const struct of_device_id *of_id;
+
+ if (dev->of_node) {
+ of_id = of_match_device(axp20x_i2c_of_match, dev);
+ if (!of_id) {
+ dev_err(dev, "Unable to match OF ID\n");
+ return -ENODEV;
+ }
+ axp20x->variant = (long) of_id->data;
+ } else {
+ acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!acpi_id || !acpi_id->driver_data) {
+ dev_err(dev, "Unable to match ACPI ID and data\n");
+ return -ENODEV;
+ }
+ axp20x->variant = (long) acpi_id->driver_data;
+ }
+
+ return
[PATCH v4 5/6] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes
This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.
Also update the regulator supply phandles.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 79 +-
1 file changed, 76 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 13ce68f06dd6..91a0fde47fdd 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
};
{
- vref-supply = <_vcc3v0>;
+ vref-supply = <_dcdc1>;
status = "okay";
button@200 {
@@ -96,7 +96,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_sina33>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <8>;
non-removable;
status = "okay";
@@ -132,6 +132,79 @@
_rsb {
status = "okay";
+
+ axp22x: pmic@3e3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3e3>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-rtc";
};
{
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/6] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Acked-by: Rob Herring --- Documentation/devicetree/bindings/mfd/axp20x.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index a474359dd206..fd39fa54571b 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -5,11 +5,12 @@ axp152 (X-Powers) axp202 (X-Powers) axp209 (X-Powers) axp221 (X-Powers) +axp223 (X-Powers) Required properties: - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209", - "x-powers,axp221" -- reg: The I2C slave address for the AXP chip + "x-powers,axp221", "x-powers,axp223" +- reg: The I2C slave address or RSB hardware address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - interrupt-controller: The PMIC has its own internal IRQs @@ -51,7 +52,7 @@ LDO3 : LDO : ldo3in-supply LDO4 : LDO : ldo24in-supply: shared supply LDO5 : LDO : ldo5in-supply -AXP221 regulators, type, and corresponding input supply names: +AXP221/AXP223 regulators, type, and corresponding input supply names: RegulatorTypeSupply Name Notes ---- - -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/6] mfd: axp20x: Add support for RSB based AXP223
Hi everyone, This is v4 of the AXP223 PMIC series. Changes since v3: - Removed settings for axp223 reg_rtc_ldo from board dts files that are already in axp22x.dtsi. The name is kept. - Dropped simplefb label and defconfig patches, as they are merged. Changes since v2: - s/It's/Its/ for the commit messages of patches 5 and 7 - Add Rob's Acked-by for patch 1 Changes since v1: - Dropped NMI interrupt controller dts patch (Merged) - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE - Keep the axp20x core bits named axp20x.c - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi - Add patch 8 & 9 to update defconfigs - Make axp20x drivers tristate and buildable as modules - Drop "_sunxi" substring from identifiers in axp20x-rsb driver This series adds support for the Reduced Serial Bus based AXP223 PMIC. The AXP223 is functionally identical to the AXP221, which we already support. Only some default values for the regulators are different. The defaults fit their recommended application, paired with different SoCs. Patch 1 adds AXP223 to the list of supported chips in the DT binding. Patch 2 splits the axp20x mfd driver into 2 parts, a core library, and an I2C driver. Patch 3 adds an RSB based driver for the AXP223. Patch 4 adds support for the AXP223 regulators Patch 5 enables the AXP223 PMIC and its regulators for the Sinlinx SinA33. Patch 6 enables the AXP223 PMIC and its regulators for A23/A33 based Q8 devices. Regards ChenYu Chen-Yu Tsai (6): mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings mfd: axp20x: Split the driver into core and i2c bits mfd: axp20x: Add support for RSB based AXP223 PMIC regulator: axp20x: Support new AXP223 PMIC ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes Documentation/devicetree/bindings/mfd/axp20x.txt | 7 +- arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 79 +- arch/arm/boot/dts/sun8i-q8-common.dtsi | 86 ++- drivers/mfd/Kconfig | 25 - drivers/mfd/Makefile | 2 + drivers/mfd/axp20x-i2c.c | 127 +++ drivers/mfd/axp20x-rsb.c | 93 + drivers/mfd/axp20x.c | 110 +++- drivers/regulator/axp20x-regulator.c | 3 + include/linux/mfd/axp20x.h | 34 +- 10 files changed, 458 insertions(+), 108 deletions(-) create mode 100644 drivers/mfd/axp20x-i2c.c create mode 100644 drivers/mfd/axp20x-rsb.c -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] zram: try vmalloc() after kmalloc()
On Tue, Nov 24, 2015 at 10:06:22AM +0900, Sergey Senozhatsky wrote: > On (11/24/15 09:35), Minchan Kim wrote: > [..] > > > We can use __GFP_RECLAIM (used to be __GFP_WAIT). That permits the > > > allocation to wait for in-flight IO to complete and to reclaim clean > > > pagecache. > > > > Generally, you're right but in case of zram, it would be unfortunate. > > > > It would be void *most of time* because it is called in reclaim context > > and reclaim path bails out to avoid recursion of direct reclaim > > by PF_MEMALLOC without trying reclaim. > > However, the reason I said *most of time* is we has another context > > the funcion could be called. > > > > "disksize_store"->zcomp_create > > > > In the place, we should make sure the successful allocation to work > > zram at least so that path should use another gfp. > > I will work for that. > > Hm... is it really worth it? passing a bool to zcomp_strm_alloc() (so > it can decide what gfp flags to use) or gfp flags directly is just a > bit complicated. what's the problem with GFP_NOIO (__GFP_RECLAIM) in > the first place (sorry if I'm missing something terribly obvious)? No, you didn't miss anything and your question is really proper. Actually, I was on same page with you but when I think more, I guess it makes code looks clean and right way for structuring, IMO. So, I coded now and am preasure with it. I hope you are on same page when you look at new patchset. :) > > alternatively, we can just remove the 'dynamic' streams allocation part > and allocate all of the streams via sysfs store path only. Hmm, I don't think it's really trouble part we cannot fix easily so let's stay with it! > > -ss -- Kind regards, Minchan Kim -- 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 v4 6/6] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes
A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.
Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 86 +-
1 file changed, 84 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..01ab47b32d8d 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <8>;
enable-gpios = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
- /* backlight is powered by AXP223 DC1SW */
};
chosen {
@@ -67,7 +66,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_q8>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -92,6 +91,85 @@
_rsb {
status = "okay";
+
+ axp22x: pmic@3e3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3e3>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-lcd";
+};
+
+_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-rtc";
};
_uart {
@@ -99,3 +177,7 @@
pinctrl-0 = <_uart_pins_a>;
status = "okay";
};
+
+_lcd {
+ vcc-lcd-supply = <_dc1sw>;
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/6] regulator: axp20x: Support new AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Reviewed-by: Mark Brown --- drivers/regulator/axp20x-regulator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index 35de22fdb7a0..55cce8125716 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq) step = 75; break; case AXP221_ID: + case AXP223_ID: min = 1800; max = 4050; def = 3000; @@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work break; case AXP221_ID: + case AXP223_ID: if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5) return -EINVAL; @@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev) nregulators = AXP20X_REG_ID_MAX; break; case AXP221_ID: + case AXP223_ID: regulators = axp22x_regulators; nregulators = AXP22X_REG_ID_MAX; break; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-rsb.c | 93 ++
drivers/mfd/axp20x.c | 2 +
include/linux/mfd/axp20x.h | 1 +
5 files changed, 108 insertions(+)
create mode 100644 drivers/mfd/axp20x-rsb.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 804cd3dcce32..13c565103e96 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
+config MFD_AXP20X_RSB
+ tristate "X-Powers AXP series PMICs with RSB"
+ select MFD_AXP20X
+ depends on SUNXI_RSB
+ help
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with RSB.
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a6913007d667..caea6637d5e8 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..3ea0d5db37d0
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,93 @@
+/*
+ * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Author: Chen-Yu Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+ { .compatible = "x-powers,axp223", .data = (void *) AXP223_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static int axp20x_rsb_match_device(struct axp20x_dev *axp20x,
+struct device *dev)
+{
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(axp20x_rsb_of_match, dev);
+ if (!of_id) {
+ dev_err(dev, "Unable to match OF ID\n");
+ return -ENODEV;
+ }
+ axp20x->variant = (long) of_id->data;
+
+ return axp20x_match_device(axp20x, dev);
+}
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x;
+ int ret;
+
+ axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+ if (!axp20x)
+ return -ENOMEM;
+
+ ret = axp20x_rsb_match_device(axp20x, >dev);
+ if (ret)
+ return ret;
+
+ axp20x->dev = >dev;
+ axp20x->irq = rdev->irq;
+ sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+ axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+ if (IS_ERR(axp20x->regmap)) {
+ ret = PTR_ERR(axp20x->regmap);
+ dev_err(>dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+ return axp20x_device_remove(axp20x);
+}
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+ .driver = {
+ .name = "axp20x-rsb",
+ .of_match_table = of_match_ptr(axp20x_rsb_of_match),
+ },
+ .probe = axp20x_rsb_probe,
+ .remove = axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 01f139856bf1..8057000da9d6 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -32,6 +32,7 @@ static const char * const
Re: [PATCH 3.12 00/72] 3.12.51-stable review
On 11/23/2015 05:07 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.51 release. There are 72 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late. This time for real. Build results: total: 124 pass: 124 fail: 0 Qemu test results: total: 78 pass: 78 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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] ARM: dts: vf6xx: Cosmic+: M4(nommu) initial support
On Sun, Oct 25, 2015 at 11:20:56PM +0530, Afzal Mohammed wrote:
> Minimal Cortex-M4 device tree to boot Linux to shell. M4 is booted via
> Cortex-A5 running Linux using Stefan Agner's "m4boot"
> utility.
>
> Signed-off-by: Afzal Mohammed
Stefan,
Are you okay with this patch?
Shawn
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/vf610m4-cosmic.dts | 90
>
> 2 files changed, 91 insertions(+)
> create mode 100644 arch/arm/boot/dts/vf610m4-cosmic.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index bb8fa023d574..06a1a7a1d104 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_VF610) += \
> vf610-colibri-eval-v3.dtb \
> vf610m4-colibri.dtb \
> vf610-cosmic.dtb \
> + vf610m4-cosmic.dtb \
> vf610-twr.dtb
> dtb-$(CONFIG_ARCH_MXS) += \
> imx23-evk.dtb \
> diff --git a/arch/arm/boot/dts/vf610m4-cosmic.dts
> b/arch/arm/boot/dts/vf610m4-cosmic.dts
> new file mode 100644
> index ..8944a2d2054c
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610m4-cosmic.dts
> @@ -0,0 +1,90 @@
> +/*
> + * Device tree for Cosmic+ VF6xx Cortex-M4 support
> + *
> + * Copyright (C) 2015
> + *
> + * Based on vf610m4 Colibri
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "vf610m4.dtsi"
> +
> +/ {
> + model = "VF610 Cortex-M4";
> + compatible = "fsl,vf610m4";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart3>;
> + status = "okay";
> +};
> +
> + {
> + vf610-cosmic {
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + VF610_PAD_PTA20__UART3_TX 0x21a2
> + VF610_PAD_PTA21__UART3_RX 0x21a1
> + >;
> + };
> + };
> +};
> --
> 2.5.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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/
