Hi,
Here we have 5 patches that add a DRM driver for the LCD
controller in the Ingenic JZ4780 SoC.
The HDMI Controller in the JZ4780 is by Synopsys
and the dw_hdmi driver is used.
These patches are based on 4.0-rc3
V1 -> V2
Fixed module licenses
Fix in makefile and #include drm_flip_work
Rebase
From: "Suzuki K. Poulose"
Invalidate an event if the group has a hardware event from
a different PMU as we cannot schedule all of them in the same
context. The perf core code won't check the group consistency
until after pmu_event_init().
Signed-off-by: Suzuki K. Poulose
---
drivers/bus/arm-cc
Hi,
> > +struct power_supply_charger {
> > + int (*get_property)(struct power_supply_charger *psyc,
> > + enum psy_charger_control_property pspc,
> > + union power_supply_propval *val);
>
> The charging framework can simply call the same get_property
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
This patch adds a display susbsytem for the Ingenic JZ4780 SoC
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../devicetree/bindings/video/ingenic-jz4780-drm.txt| 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicet
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../bindings/video/ingenic-jz4780-hdmi.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devic
Add drm driver for the Ingenic JZ4780 SoC.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Fixed Module_License macro
Fix in makefile and a #include drm_flip_work
Rebased to 4.0-rc3
Removed you should have received a copy of license etc.
---
drivers/gpu/drm/Kconfig | 2 +
On 2015-03-09 10:58, Sascha Hauer wrote:
> On Fri, Mar 06, 2015 at 02:31:51PM +0100, Stefan Agner wrote:
>> On 2015-03-06 07:15, Sascha Hauer wrote:
>> > Hi Stefan,
>> >
>> > On Thu, Mar 05, 2015 at 12:10:20AM +0100, Stefan Agner wrote:
>> >> +
>> >> +static int vf610_nfc_probe_dt(struct device *de
Ingenic JZ4780 hdmi is compatible with dw_hdmi.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Fixed license macro
Rebased to 4.0-rc3
---
drivers/gpu/drm/jz4780/Kconfig | 10 ++
drivers/gpu/drm/jz4780/Makefile | 1 +
drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c | 235
Add DT bindings for the LCD controller on the jz4780 SoC
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../bindings/video/ingenic-jz4780-lcd.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bi
On 09/03/15 12:43, a wrote:
From: "Suzuki K. Poulose"
This is a collection of fixes which denies grouping hardware events
from different PMUs. They also fix crashes triggered by perf_fuzzer
on Linux-4.0-rc2.
Pawel,
Similar fix is required in ARM CCN PMU driver. I didn't find it
straight forwa
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
From: "Suzuki K. Poulose"
This is a collection of fixes which denies grouping hardware events
from different PMUs. They also fix crashes triggered by perf_fuzzer
on Linux-4.0-rc2.
Pawel,
Similar fix is required in ARM CCN PMU driver. I didn't find it
straight forward to fix it there. Could you
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
From: "Suzuki K. Poulose"
Invalidate an event if the group has a hardware event from
a different PMU as we cannot schedule all of them in the same
context. The perf core code won't check the group consistency
until after pmu_event_init().
Signed-off-by: Suzuki K. Poulose
---
drivers/bus/arm-cc
On Mon, Mar 09, 2015 at 01:05:06PM +0530, Sudip Mukherjee wrote:
> kbuild test robot reported that for microblaze-allyesconfig
> chan_to_field() and lynxfb_ops_set_par() were not defined. These two
> functions were defined under CONFIG_PM, so for any archtecture if
> CONFIG_PM is not defined we wil
On 03/06/2015 08:37 PM, Ross Zwisler wrote:
<>
>> I maintain these patches on latest Kernels here:
>> git://git.open-osd.org/pmem.git branch pmem
>>
>> Thanks for reviewing
>> Boaz
>
> Hey Boaz,
>
> Regarding the PMEM series, my group has been working on an updated
> version of this driver f
On 03/08/15 at 07:58pm, Alexander Kuleshov wrote:
> Hello,
>
> May be necessary to add comments that they will be used later, to
> prevent patches like 'removed unused..'
Hi,
Thanks for your comment. Do you mean adding comment above function
definition, later remove the comment when call it
Hi Marc,
(Sorry for the late reply as I was out of town!)
On Wed, Mar 04, 2015 at 10:15:45AM +0100, Marc Kleine-Budde wrote:
> On 02/26/2015 04:20 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish
> >
> > Upon a URB submission failure, the driver calls usb_free_urb()
> > but then manually
Hi Jacek,
On Mon, Mar 09, 2015 at 01:19:32PM +0100, Jacek Anaszewski wrote:
> Hi Sakari,
>
> Thanks for the review.
>
> On 03/09/2015 11:54 AM, Sakari Ailus wrote:
> >Hi Jacek,
> >
> >On Wed, Mar 04, 2015 at 05:14:31PM +0100, Jacek Anaszewski wrote:
> >>This patch adds device tree binding docume
On Friday 06 March 2015 10:00:34 Ray Jui wrote:
> >
>
> Although I have not tested it, but to my best knowledge there shouldn't
> be any technical issue by making the PCIe iProc driver a loadable module
> and installing the module later after the kernel finishes booting.
>
> But I wonder why I h
On Mon, Mar 09, 2015 at 12:20:12PM +, Russell King - ARM Linux wrote:
> On Fri, Feb 20, 2015 at 04:47:06PM +0100, Arnd Bergmann wrote:
> > On Thursday 19 February 2015 00:35:49 Russell King - ARM Linux wrote:
> > > On Wed, Feb 18, 2015 at 08:47:30PM +0100, Arnd Bergmann wrote:
> > > > The smc91
Dear Sergei,
Thanks very much for suggestion.
I will fix them in the next version.
On Fri, 2015-03-06 at 17:48 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 3/6/2015 1:48 PM, yong...@mediatek.com wrote:
>
> > From: Yong Wu
>
> > This patch add smi binding document.
>
> > Signe
At Sat, 7 Mar 2015 18:58:44 +0800,
Fengguang Wu wrote:
>
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git topic/hda-regmap
>
> commit 3103d80b8a89f1797e87d7265f9b389a0db4ccd8
> Author:
Hi,
> > +#define PSY_MAX_BAT_NAME_LEN 8
> > +#define PSY_MAX_TEMP_ZONE 6
> > +
> > +struct psy_charging_obj {
>
> This is not just about charging data, but also about the batteries
> thermal limits, technology and full capacity, so how about
>
> struct psy_battery_information {
Ok, Agree.
>
>
On 03/09/2015 01:11 PM, Zubair Lutfullah Kakakhel wrote:
The jz4780 and jz4740 have very similar i2s blocks.
The slight difference is in Rx/Tx fifos.
And the bitclocks for input/output are different.
This patch adds jz4780 support to the driver
Signed-off-by: Zubair Lutfullah Kakakhel
Acked
On 03/06/2015 01:03 AM, Andy Lutomirski wrote:
<>
>
> I think it would be nice to have control over the caching mode.
> Depending on the application, WT or UC could make more sense.
>
Patches are welcome. say
map=sss@aaa:WT,sss@aaa:CA, ...
But for us, with direct_access(), all benchmark
Dear Mitchel,
Thanks very much for your review.
On Fri, 2015-03-06 at 09:15 -0800, Mitchel Humpherys wrote:
> On Fri, Mar 06 2015 at 02:48:17 AM, wrote:
> > From: Yong Wu
> >
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> > Currently this only suppo
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.
This patch reworks i2c-mux-pinctrl driver to count the number of
avail
On Fri, Feb 20, 2015 at 04:47:06PM +0100, Arnd Bergmann wrote:
> On Thursday 19 February 2015 00:35:49 Russell King - ARM Linux wrote:
> > On Wed, Feb 18, 2015 at 08:47:30PM +0100, Arnd Bergmann wrote:
> > > The smc91x driver tries to support multiple platforms at compile
> > > time, but they are m
Hi Sakari,
Thanks for the review.
On 03/09/2015 11:54 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Mar 04, 2015 at 05:14:31PM +0100, Jacek Anaszewski wrote:
This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.
Signed-off-by: Jacek An
Dear Daniel,
Thanks very much. I will fix this in next version.
On Sat, 2015-03-07 at 23:20 +0800, Daniel Kurtz wrote:
> Hi Yong,
>
> On Fri, Mar 6, 2015 at 6:48 PM, wrote:
> > From: Yong Wu
> >
> > This patch add the iommu/larbs nodes for mt8173
> >
> > Signed-off-by: Yong Wu
> > ---
>
On Mon, Mar 9, 2015 at 4:54 AM, Archit Taneja wrote:
>
>
> On 03/09/2015 01:14 PM, Daniel Vetter wrote:
>>
>> On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
>>>
>>> On 03/05/2015 09:14 PM, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
>>>
Hello, Linus.
The cgroup iteration update two years ago and the recent cpuset
restructuring introduced regressions in subset of cpuset
configurations. Three patches to fix them. All are marked for
-stable.
Thanks.
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
On Mon, Mar 02, 2015 at 12:32:20PM -0300, Arnaldo Carvalho de Melo wrote:
SNIP
> > >
> > > Can you try to reproduce this? The ctf-data/metadata file is below:
> >
> > hum, i just tried and can't reproduce this one.. anychance of mixed
> > babeltrace installations? How did you install babeltrace
On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote:
> On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote:
> > 2015-03-09 1:35 GMT+01:00 Beomho Seo :
> >> On 03/08/2015 05:13 AM, Sebastian Reichel wrote:
> >>> On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote:
> From: Beomho Seo
> >>>
The jz4780 and jz4740 have very similar i2s blocks.
The slight difference is in Rx/Tx fifos.
And the bitclocks for input/output are different.
This patch adds jz4780 support to the driver
Signed-off-by: Zubair Lutfullah Kakakhel
---
Patch based on 4.0-rc3
Tested on the MIPS Creator CI20.
V2 -
On Mon, Mar 9, 2015 at 9:11 AM, Ivan T. Ivanov wrote:
>
> On Sun, 2015-03-08 at 20:01 +, Mark Brown wrote:
>> On Fri, Mar 06, 2015 at 05:45:15PM +0200, Ivan T. Ivanov wrote:
>>
>> > if (spi->master->setup)
>> > status = spi->master->setup(spi);
>> > + else
>> > +
On Mon, Mar 09, 2015 at 02:53:37PM +0300, Dan Carpenter wrote:
> On Mon, Mar 09, 2015 at 01:05:03PM +0530, Sudip Mukherjee wrote:
> >
> > V2: Giedrius commented resource_size_t can be either u64 or u32
> > depending on if CONFIG_PHYS_ADDR_T_64BIT. based on his comments i
> > should have kept the d
Dear Will,
On Fri, 2015-03-06 at 10:58 +, Will Deacon wrote:
> On Fri, Mar 06, 2015 at 10:48:17AM +, yong...@mediatek.com wrote:
> > From: Yong Wu
> >
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> > Currently this only supports m4u gen 2 with 2
On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
> On Mar 6, 2015, at 1:15 PM, Olof Johansson wrote:
>
> > On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala wrote:
> >>
> >> On Mar 5, 2015, at 7:59 PM, Olof Johansson wrote:
> >>
> >>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala wrote:
>
> >
On 03/06/2015 01:09 AM, Andy Lutomirski wrote:
<>
>
> I will be shocked if a standard of this form ever appears. Modern
> systems *don't have e820*. The BIOSes that are using this type 12
> hack are awful throwbacks.
So far the systems we have, with DDR4 NvDIMM(s) (Actual chips arriving soon)
s
The rds_iw_add_conn function stores a large 'struct rds_sock'
object on the stack in order to pass a pair of addresses. This
happens to just fit withint the 1024 byte stack size warning
limit on x86, but just exceed that limit on ARM, which gives
us this warning:
net/rds/iw_rdma.c:200:1: warning:
On Sat, 7 Mar 2015, Serge E. Hallyn wrote:
> > The ancestor here is ambient_test and when it is run pI will not be set
> > despite the cap setting.
>
> ambient_test is supposed to set it.
I thought the setcap +i would do it.
So the setcap and setting of the file inheritance bits has no effect on
In case of failure, unrelated to PERF_FLAG_FD_CLOEXEC,
perf_flag_probe() reports the error twice. For example:
$ perf record ls
Error:
perf_event_open(..., PERF_FLAG_FD_CLOEXEC) failed with unexpected error 16
(Device or resource busy)
perf_event_open(..., 0) failed unexpectedly with erro
On Mon, Mar 09 2015, David Rientjes wrote:
> If __get_user_pages() is faulting a significant number of hugetlb pages,
> usually as the result of mmap(MAP_LOCKED), it can potentially allocate a
> very large amount of memory.
>
> If the process has been oom killed, this will cause a lot of memory t
On Mon, Mar 9, 2015 at 12:46 PM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> >> */
>> >> unsigned longstack[64];
>> >>
>> >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
>> >
>> >
>> > Seems to be unused: I commented it out on "defconfig" build
This patch is a simplification of the logic introduced as part of
commit 63914aca8f7e ("perf tools: Show better error message in case
we fail to open counters due to EBUSY error"): if -EBUSY is reported
by perf_event_open(), it will not be possible to probe
PERF_FLAG_FD_CLOEXEC, so it's safe to lea
Hi,
Following the EBUSY errors reported by Jiri Olsa [1], I've tryed to
improve a bit the way perf_flag_probe() handle errors.
In case EBUSY is returned by perf_event_open(), testing the function
again without PERF_FLAG_FD_CLOEXEC is meaningless: EBUSY is not
related to close-on-exec flag, so the
Hello, Linus.
Speed limiting fix for sata_fsl.
Thanks.
The following changes since commit a38ecbbd0be025a6ecbbfd22d2575a5b46317117:
Merge branch 'x86-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2015-03-01 12:22:44
-0800)
are available in the git repository a
Dear Paul,
Thanks very much for your suggestion.
On Fri, 2015-03-06 at 12:30 +0100, Paul Bolle wrote:
> On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -20,3 +20,10 @@ config MT8173_PMIC_WRAP
Hi,
Two patches based on 4.0-rc3 that add NAND and BCH controller
drivers for the Ingenic JZ4780 SoC.
Core JZ4780 support is still in-flight.
Review and feedback welcome.
V1 - > V2
Fixed module license macros
Rebase to 4.0-rc3
Thanks,
ZubairLK
Alex Smith (2):
dt-bindings: binding for jz478
Hello, Linus.
One fix patch for a subtle livelock condition which can happen on
PREEMPT_NONE kernels involving two racing cancel_work calls. Whoever
comes in the second has to wait for the previous one to finish. This
was implemented by making the later one block for the same condition
that the
From: Alex Smith
Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
as well as the hardware BCH controller, used by the jz4780_{nand,bch}
drivers.
Signed-off-by: Alex Smith
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 - > V2
Rebase to 4.0-rc3
---
.../bindings/mtd/ingen
From: Alex Smith
Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
well as the hardware BCH controller. DMA is not currently implemented.
While older 47xx SoCs also have a BCH controller, they are incompatible
with the one in the 4780 due to differing register/bit positions,
On 03/09/2015 12:23 PM, Zubair Lutfullah Kakakhel wrote:
[...]
@@ -460,6 +499,9 @@ static int jz4740_i2s_dev_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, i2s);
+ if (i2s->version >= JZ_I2S_JZ4780)
+ jz4740_i2s_dai.symmetric_rates = 0;
We shouldn'
On Mon, Mar 09, 2015 at 01:05:03PM +0530, Sudip Mukherjee wrote:
> mention correct format specifier while printing.
> fixes all the build warnings about incorrect argument type while
> printing.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> V2: Giedrius commented resource_size_t can be either u64
Geert Uytterhoeven writes:
> Hi Pavel,
>
> On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek wrote:
>> Ok, so I played with RGB LED a bit, and we have quite a gap in
>> documentation: what 50% brightness means is non-trivial and very
>> important in case we want to do smooth blinking and color transi
On Mon, Mar 09, 2015 at 12:39:36PM +0100, Arnd Bergmann wrote:
> This warning has been rather annoying because it shows up in every
> 'allmodconfig' build. I assume others have reported it before, but
> please apply some fix for it, ideally before 4.0.
Sorry about that, we're aware of the warning
On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote:
> 2015-03-09 1:35 GMT+01:00 Beomho Seo :
>> On 03/08/2015 05:13 AM, Sebastian Reichel wrote:
>>> On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote:
From: Beomho Seo
This patch adds device driver of max77843 charger. This dr
* Andy Lutomirski wrote:
> >> */
> >> unsigned longstack[64];
> >>
> >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
> >
> >
> > Seems to be unused: I commented it out on "defconfig" build
> > and got no build errors.
>
> It's used. On 32-bit, NMIs d
Hi,
On Thursday 05 March 2015 07:27 AM, Axel Lin wrote:
The defines in phy-miphy365x.h are all covered in phy.h:
MIPHY_TYPE_SATA == PHY_TYPE_STA
MIPHY_TYPE_PCIE == PHY_TYPE_PCIE
MIPPHY_TYPE_USB == PHY_TYPE_USB2
So covert to use phy.h and then delete phy-miphy365x.h.
Signed-off-by: Axel Lin
-
hi, Tom
On 2015/3/3 3:55, Tom Zanussi wrote:
BTW, I've actually tried to play around with the BPF samples/, but it
seems they're not actually hooked into the system i.e. the samples
Makefile doesn't build them, and it even looks for tools/llvm that's
not there. I got as far as getting the late
On 03/08/2015 07:19 PM, Robert Jarzmik wrote:
> Ezequiel Garcia writes:
>
>>> I think you'll kill the zylonite board, and I'll nack it if that's the
>>> case. At
>>> least that's what happened when I tried to use onfi default values last
>>> time in
>>> barebox development.
>>>
>>> I can test y
This resolves a harmless gcc warning in btrfs_check_super_valid that
results from a size_t value being printed as %lu:
fs/btrfs/disk-io.c:3927:21: warning: format '%lu' expects argument of type
'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
On all Linux systems, size_t i
Dear Mark,
Thanks very much for your review.
I will fix them in the next verion.
On Fri, 2015-03-06 at 11:21 +, Mark Rutland wrote:
> On Fri, Mar 06, 2015 at 10:48:19AM +, yong...@mediatek.com wrote:
> > From: Yong Wu
> >
> > This patch add mediatek iommu dts binding document.
On Sun, Mar 08, 2015 at 11:35:59AM -0700, Linus Torvalds wrote:
> On Sun, Mar 8, 2015 at 3:02 AM, Ingo Molnar wrote:
> But:
>
> > As a second hack (not to be applied), could we change:
> >
> > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> >
> > to:
> >
> > #define _PAGE_BIT_PROTNONE (
On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
> On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> > Why do both mutex and rtmutex then exist one might ask? ;-) No big deal
> > either way though, it's not like it becomes immutable once applied.
>
> You don't choose rtmutex afai
On Mon, Mar 09, 2015 at 07:22:26AM +0100, Nicholas Mc Guire wrote:
> On Sun, 08 Mar 2015, Mark Brown wrote:
> > You are sending these to a very large CC list many of whom have no
> > obvious connection to the driver - please take care to ensure that the
> > people you are sending patches to are li
Hi,
2015년 03월 06일 20:16에 Oliver Neukum 이(가) 쓴 글:
>> +
>> +/* Check if same data is existed */
>> +list_for_each_entry(battery, &psy_battery_info_list, entry)
>> +if (!strcmp(battery->info->name, info->name))
>> +return -EEXIST;
>> +
>> +battery = kzalloc(
On Mon, Mar 09, 2015 at 12:42:15AM -0700, David Rientjes wrote:
> If __get_user_pages() is faulting a significant number of hugetlb pages,
> usually as the result of mmap(MAP_LOCKED), it can potentially allocate a
> very large amount of memory.
>
> If the process has been oom killed, this will cau
The jz4780 and jz4740 have very similar i2s blocks.
The slight difference is in Rx/Tx fifos.
And the bitclocks for input/output are different.
This patch adds jz4780 support to the driver
Signed-off-by: Zubair Lutfullah Kakakhel
---
Patch based on 4.0-rc3
Tested on the MIPS Creator CI20.
V1 -
On Sun, Mar 08, 2015 at 05:54:07PM +0100, Matteo Semenzato wrote:
> From: Matteo Semenzato
>
> Return -ENOMEM if allocating brd->flipbuf fails.
>
> Signed-off-by: Matteo Semenzato
> ---
> drivers/staging/dgnc/dgnc_driver.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/s
On Mon, Mar 09, 2015 at 12:03:12PM +0300, Alexey Brodkin wrote:
> As discussed here https://lkml.org/lkml/2015/3/3/568 and here
> https://lkml.org/lkml/2015/3/3/453 we're looking forward for
> implementing warnings and errors outputs right in platform_get_irq()
> instead of having all kind of diffe
This patch fixes a NULL pointer dereference when enabling regmap event
tracing in the presence of a syscon regmap, introduced by commit bdb0066df96e
("mfd: syscon: Decouple syscon interface from platform devices").
That patch introduced syscon regmaps that have their dev field set to NULL.
The regm
On x86-64, __copy_instruction() always returns 0 (error) if the
instruction uses %rip-relative addressing. This is because
kernel_insn_init() is called the second time for 'insn' instance
in such cases and sets all its fields to 0.
Because of this, trying to place a Kprobe on such instruction will
On 03/05/2015 10:56 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:24 AM, Boaz Harrosh wrote:
>>
<>
>> Now the ACPI comity, as far as I know, did not yet define a
>> standard type for NvDIMM. Also, as far as I know any NvDIMM
>> standard will only be defined for DDR4. So DDR3 NvDIMM is
>> prob
On 2015/3/9 15:39, Wang Long wrote:
cc: marco.storne...@gmail.com
cc: anton.voront...@linaro.org
cc: saly...@android.com
cc: ser...@chromium.org
> In the function ramoops_probe, the console_size, pmsg_size,
> ftrace_size may be update because the value is not the power
> of two. We should update t
Hi,
On Mon, Mar 09, 2015 at 11:06:53AM +1100, NeilBrown wrote:
> On Sat, 7 Mar 2015 22:01:02 +0100 Sebastian Reichel wrote:
> > platform_driver_probe() does not support deferred probing.
> >
> > Neil, can you take this patch into your series for the next round?
>
> I could, but I do wonder if i
On 03/06/2015 09:47 AM, Alexandre Belloni wrote:
On 06/03/2015 at 09:43:02 +0100, Daniel Lezcano wrote :
On 03/05/2015 04:49 PM, Alexandre Belloni wrote:
The register range from the system timer is also used by the watchdog driver.
Use a regmap to handle concurrent accesses.
Signed-off-by: Ale
Hi,
You can find part 2 of my comments inline.
On Fri, Mar 6, 2015 at 7:48 PM, wrote:
[snip]
> +static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> +{
> + struct iommu_domain *domain = dev_id;
> + struct mtk_iommu_domain *mtkdomain = domain->priv;
> + struct mtk_iommu_
* Arnaldo Carvalho de Melo wrote:
> [...]
>
> Further investigation is needed to figure out the nature of the
> objdump output change so as to make the parser grok it.
Btw., maybe someone finds this interesting: we could also (re-)use the
in-kernel disassembler (on x86 and any other architec
On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> Why do both mutex and rtmutex then exist one might ask? ;-) No big deal
> either way though, it's not like it becomes immutable once applied.
You don't choose rtmutex afaik. rtmutex is used by futex (only?) and
one of the things it does is PI.
On -R
From: Clément Perrochaud
Add a module to the NXP-NCI driver to support NFC controllers with an
I2C control interface, such as the NPC100.
Signed-off-by: Clément Perrochaud
---
.../devicetree/bindings/net/nfc/nxp-nci.txt| 35 ++
drivers/nfc/nxp-nci/Kconfig| 12
Hi,
I am now working on an example to see if what I suggested earlier is
possible.
During this, I encountered a problem in Kprobes on x86 that prevents
placing them on the insns with %rip-relative addressing.
register_kprobe() returns -EINVAL in such cases because
__copy_instruction() returns 0
On Fri, Mar 06, 2015 at 06:48:16PM +0800, yong...@mediatek.com wrote:
> From: Yong Wu
>
> This patch add SMI(Smart Multimedia Interface) driver. This driver is
> responsible to enable/disable iommu and control the clocks of each
> local arbiter.
>
> Signed-off-by: Yong Wu
> ---
> drivers/s
2015-03-09 1:35 GMT+01:00 Beomho Seo :
> On 03/08/2015 05:13 AM, Sebastian Reichel wrote:
>> On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote:
>>> From: Beomho Seo
>>>
>>> This patch adds device driver of max77843 charger. This driver provide
>>> initialize each charging mode(e.g. fast c
From: Clément Perrochaud
Add support for NXP NCI NFC controllers such as the NPC100 or PN7150
families.
Signed-off-by: Clément Perrochaud
---
MAINTAINERS | 7 +
drivers/nfc/Kconfig | 1 +
drivers/nfc/Makefile | 1 +
drivers/nfc
On Mon, Mar 9, 2015 at 11:50 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.0-rc3[1] to v4.0-rc2[3], the summaries are:
> - build errors: +18/-7
+ /home/kisskb/slave/src/arch/arm/mach-pxa/idp.c: error:
'SMC91X_NOWAIT' undeclared here (not in a function): => 85:47
+ /home/kisskb/sl
On 03/05/2015 10:41 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:20 AM, Boaz Harrosh wrote:
>>
>> There is something not very nice (Gentlemen nice) In current
>> e820.c code.
>>
>> At Multiple places for example @memblock_x86_fill() it will
>> add the different memory resources *except the E
Hi Jacek,
On Wed, Mar 04, 2015 at 05:14:31PM +0100, Jacek Anaszewski wrote:
> This patch adds device tree binding documentation for
> the flash cell of the Maxim max77693 multifunctional device.
>
> Signed-off-by: Jacek Anaszewski
> Signed-off-by: Andrzej Hajda
> Acked-by: Kyungmin Park
> Cc:
On Mon, 2015-03-09 at 11:00 +0100, Sebastian Andrzej Siewior wrote:
> On 03/06/2015 06:50 PM, Mike Galbraith wrote:
> > On Fri, 2015-03-06 at 13:36 +0100, Sebastian Andrzej Siewior wrote:
> >> On 03/06/2015 01:16 PM, Maarten Lankhorst wrote:
> >>
> Okay so what I the point made here? It is onl
Below is the list of build error/warning regressions/improvements in
v4.0-rc3[1] compared to v3.19[2].
Summarized:
- build errors: +20/-10
- build warnings: +120/-186
JFYI, when comparing v4.0-rc3[1] to v4.0-rc2[3], the summaries are:
- build errors: +18/-7
- build warnings: +72/-66
Note
Greg,
Somebody asking to backport following patch into 3.10.x stable tree.
https://lkml.org/lkml/2015/3/7/316
The patch is identified as following commit ID in Linus's tree.
commit e7ca2552369c1dfe0216c626baf82c3d83ec36bb
Author: Mateusz Guzik
Date: Mon Jan 27 17:07:11 2014 -0800
ipc: fix
On Mon, Mar 09, 2015 at 10:48:22AM +0100, Philipp Zabel wrote:
> Good point. As I see it I have three possiblities now:
> a) Just #include "../../../drivers/base/regmap/internal.h" in
>include/trace/events/regmap.h
I think this is my preference - it looks ugly which means that it's not
likel
On Mon, Mar 09, 2015 at 09:53:31AM +0100, Matthias Brugger wrote:
> 2015-02-22 13:02 GMT+01:00 Sascha Hauer :
> > From: Flora Fu
> >
> > new file mode 100644
> > index 000..b91665a
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -0,0 +1,11 @@
> > +#
> > +# MediaTek SoC drivers
From: Clément Perrochaud
This patch brings support for the NXP-NCI NFC controllers family.
It has been successfully tested on the following SoC boards:
- BeagleBone
- BeagleBone Black
- Raspberry Pi B
- Raspberry Pi B+
The submission is broken into three patches:
- The first one adds firmw
From: Clément Perrochaud
A simple forward for firmware download (i.e. sending a new firmware
to the NFC adapter) from the NFC subsystem to the drivers.
This feature is required to update the firmware of NXP-NCI NFC
controllers but can be used by any NCI driver.
This feature has been present in
On 01/30/2015 12:28 AM, Samuel Ortiz wrote:
> - It really is not obvious that FWDL actually means firmware download
> - A small commit message explaining why you need this (Mostly for the
> NXP chipset for now) would be nice.
Hi Samuel,
Thank you for all your comments, I just sent an improved v
801 - 900 of 1074 matches
Mail list logo