On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> In order to help unify the naming scheme for shared
> backports versioning information rely on the CPTCFG_
> prefix, when integration support gets added that will
> translate to the respective
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> +++ b/backport/Kconfig.package
> @@ -0,0 +1,32 @@
> +mainmenu "Backports from $BACKPORTED_KERNEL_NAME $BACKPORTED_KERNEL_VERSION
> (backports $BACKPORTS_VERSION)"
> +
> +config BACKPORT_DIR
> + string
> + option
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> During development of kernel integration support using CONFIG_BACKPORT
> was evaluated as a prefix over CPTCFG even for packaging backports,
> for some reason this change lifted some restrictions one some
Hi Steve,
On Tue, 04 Nov 2014 10:28:47 -0500, Steven Rostedt wrote:
> +count=`cat trace | grep '()' | grep -v schedule | wc -l`
> +
> +if [ $count -ne 0 ]; then
> +echo "Graph filtering not working after stack tracer disabled?"
> +exit -1
> +fi
> +
> +count=`cat trace | grep 'schedule()'
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> @@ -21,23 +22,53 @@ class ConfigTree(object):
> yield f
> for l in open(os.path.join(self.basedir, f), 'r'):
> m = src_line.match(l)
> -if m and os.path.exists(os.path.join(self.basedir,
>
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> @@ -71,6 +71,9 @@ def read_dependencies(depfilename):
> ret[sym].append(kconfig_exp)
> else:
> sym, dep = item.split()
> +if bp_prefix != 'CPTCFG_':
> +dep_prefix =
On 11/04/2014 11:19 AM, David Laight wrote:
That code (and all the ones below) are gibberish, neither the old or new
sequences make any sense.
Thank you for your feedback I did it again and objdiff doesn't show any
changes (if I'm not mistaken).
Almost as though you used the wrong
On Wed, Nov 05, 2014 at 04:16:46PM +0900, byungchul.p...@lge.com wrote:
> From: Byungchul Park
>
> Changes from v1 to v2
> * update Document/trace/ftrace.txt
> * seperate the implementation as a macro
> * apply the implementation to delay printing, too
>
> Hello.
>
> When I analysis the
On Tue, Nov 04, 2014 at 11:14:33AM -0700, Jason Gunthorpe wrote:
> On Tue, Nov 04, 2014 at 01:47:34PM +0200, Jarkko Sakkinen wrote:
>
> > > > I used the class 'tpm' only for TPM 2.x because I didn't want to
> > > > break the binary compatibility for TPM 1.x anyway. In ideal situtation
> > > >
Hi Joerg,
While debugging Bill's patches, I found this problem:
When copying iommu data from old kernel to the kdump kernel, the
original function context_set_address_root() may cause kdump kernel
using incorrect address root value.
So I created this patch to fix it.
Zhenhua
On 11/05/2014
The function context_set_address_root() and set_root_value are setting new
address in a wrong way, and this patch is trying to fix this problem.
According to Intel Vt-d specs(Feb 2011, Revision 1.3), Chapter 9.1 and 9.2,
field ctp in root entry is using bits 12:63, field asr in context entry is
On Wed, 2014-11-05 at 01:21 +0100, Luis R. Rodriguez wrote:
> > > I did at one point have BACKPORT_BPAUTO_* stuff on the compat/Kconfig for
> > > the auto stuff but figured that was superfluous. I'll respin with it.
> >
> > Not sure what you mean? It seems to me you should just drop the changes
On Tue, Nov 04, 2014 at 11:48:26PM +0200, Aya Mahfouz wrote:
> On Tue, Nov 04, 2014 at 03:06:53PM +0530, Sudip Mukherjee wrote:
> > On Tue, Nov 04, 2014 at 02:13:19AM +0200, Aya Mahfouz wrote:
> > > This patch replaces dev_err by pr_err since the value
> > > of ir is NULL when the message is
On 11/04/2014 03:43 PM, Chen Gang wrote:
> Microblaze is a fpga soft core, it can be customized easily, which may
> cause many various hardware version strings.
>
> So the original fix patch based on hard-coded compatible version strings
> is not a good idea (although it is correct for current
On Wed, Nov 5, 2014 at 12:18 PM, Gregory Fong wrote:
> On Tue, Nov 4, 2014 at 2:27 PM, Michal Nazarewicz wrote:
>> On Tue, Nov 04 2014, Gregory Fong wrote:
>>> The alignment in cma_alloc() is done w.r.t. the bitmap. This is a
>>> problem when, for example:
>>>
>>> - a device requires 16M (order
From: Byungchul Park
Currently, function graph tracer prints "!" or "+" just before
function execution time to signal a function overhead, depending
on the time. Even it is usually enough to do that, we sometimes
need to be signaled for bigger execution time than 100 micro seconds.
For example,
From: Byungchul Park
Usually, "msecs" notation means milli-seconds, and "usecs" notation
means micro-seconds. Since the unit used in the code is micro-seconds,
the notation should be replaced from msecs to usecs.
Signed-off-by: Byungchul Park
---
kernel/trace/trace_functions_graph.c | 12
From: Byungchul Park
Currently, some tracers tracing latency print "!" or "+" just after time
to signal overhead, depending on the interval between events. Even it is
usually enough to do that, we sometimes need to be signaled for bigger
interval than 100 micro seconds.
Signed-off-by: Byungchul
From: Byungchul Park
Changes from v1 to v2
* update Document/trace/ftrace.txt
* seperate the implementation as a macro
* apply the implementation to delay printing, too
Hello.
When I analysis the exit_mm() function to find out the reason why the
function spends much time occasionally, this
From: Byungchul Park
Changes from v1 to v2
* update Document/trace/ftrace.txt
* seperate the implementation as a macro
* apply the implementation to delay printing, too
Hello.
When I analysis the exit_mm() function to find out the reason why the
function spends much time occasionally, this
At Wed, 5 Nov 2014 12:31:50 +0530,
Sudip Mukherjee wrote:
>
> On Tue, Nov 04, 2014 at 10:28:01AM -0800, Joe Perches wrote:
> > On Tue, 2014-11-04 at 23:47 +0530, Sudip Mukherjee wrote:
> > > commit "b5b4a41b392960010fccf1f9ccf8334d612bd450" was dereferencing
> > > chip after it has been freed.
From: "sh.yoon"
With cache writeback turned on(kernel & library & user-fs),
writing to a file that is opened with O_WRONLY flag fails
to write and return EBADF error as below.
strace result :
open("/storage/emulated/legacy/tempfile.txt", O_WRONLY) = 3
write(3, "hello
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
One small improvement for the cputime accounting, two bug fixes and
an update for the default configuration files.
Heiko
It is possible that a GPE handler or a fixed event handler still accessed
after removing the handlers by invoking acpi_remove_gpe_handler() or
acpi_remove_fixed_event_handler(), this possibility can crash OPSM after a
module removal. In the Linux kernel, though all other GPE drivers are not
On Tue, 04 Nov 2014 21:56:53 +0900, Masami Hiramatsu wrote:
> Hi,
>
> (2014/11/04 17:06), Hemant Kumar wrote:
>> Hi Namhyung,
>>
>> On 11/04/2014 01:08 PM, Namhyung Kim wrote:
>>> Hi Hemant,
>>>
>>> As you know, you need to keep an eye on how (kprobes) event cache
>>> patchset from Masami settles
On 14-11-04 09:00 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 is missing and needed for this controller.
This seems fine, although any explanation of why this quirk is needed
would be useful.
I don't know who to talk to at Arasan
On Tue, Nov 04, 2014 at 10:28:01AM -0800, Joe Perches wrote:
> On Tue, 2014-11-04 at 23:47 +0530, Sudip Mukherjee wrote:
> > commit "b5b4a41b392960010fccf1f9ccf8334d612bd450" was dereferencing
> > chip after it has been freed. This patch fixes that and at the same
> > time removes some debugging
On 14-11-04 08:59 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
Add a verify option to driver to print out an error message if a
potential back to back write could cause a clock domain issue.
index f8c450a..11af27f 100644
+#ifdef
On 14-11-04 08:57 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
The bcm2835 has clock domain issues when back to back writes to certain
registers are written. The existing driver works around this issue with
udelay. A more efficient method is to store the 8 and 16 bit
Hi all,
Due to a move of office, there will not be a linux-next release on
Friday (and maybe Monday).
Changes since 20141104:
The f2fs tree gained a build failure so I used the version from
next-20141104.
The mfd tree lost its build failure.
The iommu tree gained a build failure so I used
Hi Peter and Pawel,
On Tue, 4 Nov 2014 19:40:31 +0100, Peter Zijlstra wrote:
> On Tue, Nov 04, 2014 at 04:42:11PM +, Pawel Moll wrote:
>>
>> 1. I'm wrong and the record doesn't have to be padded to make it 8 bytes
>> aligned. Then I can drop the additional size field.
>
> No, you're right,
Hi Masami,
Hi,
(2014/11/04 17:06), Hemant Kumar wrote:
Hi Namhyung,
On 11/04/2014 01:08 PM, Namhyung Kim wrote:
Hi Hemant,
As you know, you need to keep an eye on how (kprobes) event cache
patchset from Masami settles down. For those who aren't CC'ed, please
see the link below:
Hi Kan,
On Tue, 4 Nov 2014 17:07:43 +, Kan Liang wrote:
> Hi Namhyung,
>
>> > tchain_edit[.] f1
>> > 0.14%3.913444 tchain_edit[.] f2
>> > 99.82%1.005478 tchain_edit[.] f3
>>
>> Hmm.. I think it should be a default
Hi Juri,
On 14/11/4 下午11:50, Juri Lelli wrote:
Hi,
On 04/11/14 15:46, Peter Zijlstra wrote:
On Tue, Nov 04, 2014 at 09:30:46PM +0800, Wanpeng Li wrote:
+ if (!rq->online) {
+ struct rq *latest_rq = NULL;
+ int cpu;
+ u64 dmin = LONG_MAX;
+
+ for_each_cpu(cpu, >cpus_allowed)
+ if
This patch is to enable the quirk for AMD sdhci requiring transfer
mode register need to be cleared for commands without data
Signed-off-by: Vincent Wan
Signed-off-by: Wan Zongshun
---
drivers/mmc/host/sdhci-pci.c | 27 ++-
1 file changed, 26 insertions(+), 1
On Wed, 05 Nov 2014 01:22:46 +0900, Masami Hiramatsu wrote:
> (2014/11/04 23:38), Arnaldo Carvalho de Melo wrote:
>> Em Tue, Nov 04, 2014 at 01:36:31PM +0900, Masami Hiramatsu escreveu:
>>> OK, I agree using .debug/.buildid/ to store caches.
>>> Here is what I'm thinking,
>>
>>> # this makes
AMD SD controller supports the SDR104 mode, but caps2 can not
be promoted to support hs200 for eMMC.
Signed-off-by: Vincent Wan
Signed-off-by: Wan Zongshun
---
drivers/mmc/host/sdhci-pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pci.c
Hi Masami,
On Tue, 04 Nov 2014 14:44:28 +0900, Masami Hiramatsu wrote:
> (2014/11/04 12:14), Namhyung Kim wrote:
>> Hi Masami,
>>
>> On Fri, 31 Oct 2014 14:51:29 -0400, Masami Hiramatsu wrote:
>>> So by using all of them, we can make an "event cache" file on all
>>> functions (except for inlined
SDHC controller in AMD chipsets require SDHC transfer mode
register to be cleared for commands without data. The issue was
uncovered during testing eMMC cards on KB/ML based platforms
Signed-off-by: Vincent Wan
Signed-off-by: Wan Zongshun
Signed-off-by: Arindam Nath
Tested-by: Vikram B
Hi Sören,
Am 03.11.2014 um 20:05 schrieb Soren Brinkmann:
> Soren Brinkmann (7):
> pinctrl: pinconf-generic: Declare dt_params/conf_items const
> pinctrl: pinconf-generic: Infer map type from DT property
> pinctrl: pinconf-generic: Allow driver to specify DT params
> pinctrl: zynq:
On 14-11-04 08:44 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
Add a verify option to driver to print out an error message if a
potential back to back write could cause a clock domain issue.
diff --git a/drivers/mmc/host/sdhci-bcm2835.c
Hello Joe,
On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote:
> Hello Pratyush,
>
> A kernel bug report was opened against Ubuntu [0]. After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit a40178b2fa6ad87670fb1e5fa4024db00c149629
Hi,
David Miller wrote:
> From: Lothar Waßmann
> Date: Tue, 4 Nov 2014 11:29:12 +0100
>
> > Hi David,
> >
> > Lothar Waßmann wrote:
> >> David Miller wrote:
> >> > From: Lothar Waßmann
> >> > Date: Thu, 30 Oct 2014 07:51:04 +0100
> >> >
> >> > >> Also, I don't thnk your DIV_ROUND_UP()
On 14-11-04 08:48 PM, Stephen Warren wrote:
On 10/30/2014 12:36 AM, Scott Branden wrote:
Make the shift calculations consistent rather than having different
implementations to calculate the same thing.
diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Signed-off-by: Lu Baolu
Reported-by: Dmitry Nezhevenko
---
drivers/usb/host/xhci-hub.c | 5 +
1 file
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means "Device is non-removable".
Signed-off-by: Lu Baolu
Reported-by: Juro Bystricky
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h
xhci: clear root port wake on bits if controller isn't allowed to do wakeup
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
This has been discussed at http://www.spinics.net/lists/linux-usb/msg114986.html
It also includes a patch to fix a comment in drivers/usb/host/xhci.h.
Changes in v3:
* Need to consider run-time suspend as well.
* Change
On 2014/11/5 11:52, Greg KH wrote:
> On Tue, Nov 04, 2014 at 10:29:43PM -0500, Tejun Heo wrote:
>> Hello,
>>
>> On Wed, Nov 05, 2014 at 11:27:39AM +0800, Yijing Wang wrote:
>>> Keep the parent directory looks good to me, we could only add
>>> kobject_get()
>>> after the parent dir be created.
Am 03.11.2014 um 20:05 schrieb Soren Brinkmann:
> +enum zynq_pinmux_functions {
> + ZYNQ_PMUX_ethernet0,
> + ZYNQ_PMUX_ethernet1,
> + ZYNQ_PMUX_mdio0,
> + ZYNQ_PMUX_mdio1,
> + ZYNQ_PMUX_qspi0,
> + ZYNQ_PMUX_qspi1,
> + ZYNQ_PMUX_qspi_fbclk,
> + ZYNQ_PMUX_qspi_cs1,
On Tue, Nov 04, 2014 at 08:47:26AM -0600, Felipe Balbi wrote:
> On Tue, Nov 04, 2014 at 05:29:51PM +0800, Huang Rui wrote:
> > Some SoC's FPGA platform will need this quirk, but it will complain if
> > running at true SoC platform. This is a normal case, so remove this
> > warning.
>
> nope, why
On 10/30/2014 12:36 AM, Scott Branden wrote:
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 is missing and needed for this controller.
This seems fine, although any explanation of why this quirk is needed
would be useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Add a verify option to driver to print out an error message if a
> potential back to back write could cause a clock domain issue.
> index f8c450a..11af27f 100644
> +#ifdef CONFIG_MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
> + struct sdhci_pltfm_host
On 10/30/2014 12:36 AM, Scott Branden wrote:
> The bcm2835 has clock domain issues when back to back writes to certain
> registers are written. The existing driver works around this issue with
> udelay. A more efficient method is to store the 8 and 16 bit writes
> to the registers affected and
(2014/11/05 0:41), Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote admin) it
Until now, the mce_severity mechanism can only identify the severity
of UCNA error as MCE_KEEP_SEVERITY. Meanwhile, it is not able to filter
out DEFERRED error for ADM platform.
This patch aims to extend the mce_severity mechanism for handling
UCNA/DEFERRED error. In order to do this, the patch
Uncorrected no action required (UCNA) - is a UCR error that is not
signaled via a machine check exception and, instead, is reported to
system software as a corrected machine check error. UCNA errors indicate
that some data in the system is corrupted, but the data has not been
consumed and the
Hi Hannes,
On Tue, 04 Nov 2014 08:07:51 +0100 Hannes Reinecke wrote:
>
> On 11/04/2014 05:43 AM, Stephen Rothwell wrote:
> >
> > After merging the scsi tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > In file included from include/linux/sched.h:17:0, from
Hi all,
At the suggestion of Boris, the first patch extends the mce_severity
mechanism for handling UCNA/DEFERRED error.
Link: https://lkml.org/lkml/2014/10/23/190
The first patch have also eliminated a big hack to make mce_severity() work
when called from non-exception context on the advice
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Make the shift calculations consistent rather than having different
> implementations to calculate the same thing.
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c
> b/drivers/mmc/host/sdhci-bcm2835.c
> +#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 &
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Add a verify option to driver to print out an error message if a
> potential back to back write could cause a clock domain issue.
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c
> b/drivers/mmc/host/sdhci-bcm2835.c
> static inline void
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_sasem.c between commit f3a75505ab5f
("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
from the v4l-dvb tree and commit eca6a8872a04 ("staging: media: lirc:
Use pr_* instead of
On Wed, Nov 05, 2014 at 03:18:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/host/Kconfig between commit cd6e245a2d06 ("usb: Remove
> references to non-existent PLAT_S5P symbol") from the usb.current tree
> and commit
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_igorplugusb.c between commit
3e5907e695f2 ("[media] lirc_igorplugusb: remove") from the v4l-dvb tree
and commit d82e62deb51b ("staging: media: lirc: Remove useless cast on
void pointer") from
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_imon.c between commit f3a75505ab5f
("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
from the v4l-dvb tree and commit 732ba199ab07 ("staging: media: lirc:
lirc_imon.c: replace
On 11/04/14 at 10:41am, Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote
On Tue, Nov 4, 2014 at 2:27 PM, Michal Nazarewicz wrote:
> On Tue, Nov 04 2014, Gregory Fong wrote:
>> The alignment in cma_alloc() is done w.r.t. the bitmap. This is a
>> problem when, for example:
>>
>> - a device requires 16M (order 12) alignment
>> - the CMA region is not 16 M aligned
>>
>>
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/Kconfig between commit cd6e245a2d06 ("usb: Remove
references to non-existent PLAT_S5P symbol") from the usb.current tree
and commit dd3cf17488b1 ("usb: host: Remove optional dependencies on
PLAT_S5P") from the
On Wed, Nov 05, 2014 at 03:55:36AM +, Al Viro wrote:
> What do you think of the trick with user_msghdr, BTW?
PS: where do you prefer the branches to be based off?
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net#master, mainline,
something else? I can certainly do that as
dobar dan
Trebate li osobne ili poslovne kredite s povoljnim kamatnim stopama? Mi djeluje
domace, kao i medunarodna, naši izvori financiranja strucnjaci su kreativna
rješenja za svoje financijske probleme.
Ako ste zainteresirani, možete se vratiti sa sljedecim podacima:
Iznos je
On Tue, Nov 04, 2014 at 10:27:27PM -0500, David Miller wrote:
> Al, is this the helper you are talking about?
Mostly, except that I kept it 4-argument (and used skb_copy_datagram_msg()
for name). Matter of taste - the ones you've missed because of that are
net/appletalk/ddp.c:1761: err =
On Tue, Nov 04, 2014 at 10:29:43PM -0500, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 05, 2014 at 11:27:39AM +0800, Yijing Wang wrote:
> > Keep the parent directory looks good to me, we could only add
> > kobject_get()
> > after the parent dir be created.
> >
> >
> > /* or
YOSHIFUJI Hideaki wrote:
>>
>> - if (len < skb->len + vlan_hlen + vnet_hdr_sz) {
>> + if (iov_iter_count(iter) < total) {
>
> I guess this should be: sizeof(pi) + total
Good catch! Here is a third update:
tun: Use iovec iterators
This patch removes the use of
Am 03.11.2014 um 20:05 schrieb Soren Brinkmann:
> Add documentation for the devicetree binding for the Zynq pincontroller.
>
> Signed-off-by: Soren Brinkmann
> ---
> .../bindings/pinctrl/xlnx,zynq-pinctrl.txt | 90
> ++
> 1 file changed, 90 insertions(+)
> create
Hello,
On Wed, Nov 05, 2014 at 11:27:39AM +0800, Yijing Wang wrote:
> Keep the parent directory looks good to me, we could only add
> kobject_get()
> after the parent dir be created.
>
>
> /* or create a new class-directory at the parent device */
> k =
On 2014/11/5 11:13, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 05, 2014 at 10:01:39AM +0800, Yijing Wang wrote:
>>> So, yeah, this looks like a correct approach; however, do we even need
>>> to clear the glue directories?
>>
>> Yes. In our platform, the glue directories
>>
From: Herbert Xu
Date: Wed, 5 Nov 2014 10:22:51 +0800
> On Tue, Nov 04, 2014 at 03:13:55PM +, Al Viro wrote:
>>
>> Think of it that way: every sendmsg/recvmsg path leading to memcpy_fromiovec
>> and its friends (including the open-coded ones) would need to be changed
>> at some point.
Hi,
Am 03.11.2014 um 20:05 schrieb Soren Brinkmann:
> + PINCTRL_PIN(54, "EMIO_SD0_WP"),
> + PINCTRL_PIN(55, "EMIO_SD0_CD"),
> + PINCTRL_PIN(56, "EMIO_SD1_WP"),
> + PINCTRL_PIN(57, "EMIO_SD0_CD"),
Should this be "EMIO_SD1_CD"?
Regards,
Andreas
--
SUSE LINUX GmbH, Maxfeldstr. 5,
From: "Luis R. Rodriguez"
We only need this for modules.
Signed-off-by: Luis R. Rodriguez
---
backport/backport-include/linux/module.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/backport/backport-include/linux/module.h
b/backport/backport-include/linux/module.h
index
From: "Luis R. Rodriguez"
The CPTCFG_ prefix already implies backport, when integration
is used we'd end up with a double BACKPORT_ prefix, so just
remove the existing one as its not needed.
Signed-off-by: Luis R. Rodriguez
---
backport/Makefile | 2 +-
From: "Luis R. Rodriguez"
This will allow us to do less work for built-in integration support.
This requires a bit of self evaluation of the variable within our
kconfig library, ideally we'd have support for groking all variables
defined within the Kconfig setup but that requires quite a lot
From: "Luis R. Rodriguez"
The version file contains:
* BACKPORTS_VERSION
* BACKPORTED_KERNEL_VERSION
* BACKPORTED_KERNEL_NAME
This file is used by the Makefile to export variable
definitions used to identify the backport. For kernel
integration we'll be using a generated Kconfig file
From: "Luis R. Rodriguez"
This will also be used for built-in kernel integration, by
using this we can share more code with the built-in kernel
approach.
Reviewed-by: Johannes Berg
Signed-off-by: Luis R. Rodriguez
---
backport/Makefile | 6 +++---
backport/Makefile.build |
From: "Luis R. Rodriguez"
Things we backport are now prefixed with BACKPORT_, when we copy
over libraries with the c-files / h-files trick on the compat/Kconfig
trick we prefix these with BACKPORT_ already so in order to help
distinguish them use BACKPORT_BPAUTO_ for them and prevent a double
From: "Luis R. Rodriguez"
This splits up the Kconfig from things which are needed due to
our copy of code from the kernel and things which we need
specifically only for packaging backports. We will later then
share the Kconfig.souce for instance for kernel integration.
While at it, split up the
From: "Luis R. Rodriguez"
The way we'll define backports versioning information for
kernel integration is slightly different, we'll rely completely
on Kconfig for the job, but in the end share the same C code
defines.
Signed-off-by: Luis R. Rodriguez
---
gentree.py | 18 ++
1
From: "Luis R. Rodriguez"
During development of kernel integration support using CONFIG_BACKPORT
was evaluated as a prefix over CPTCFG even for packaging backports,
for some reason this change lifted some restrictions one some device
drivers which was present before and as such requires some
From: "Luis R. Rodriguez"
In order to help unify the naming scheme for shared
backports versioning information rely on the CPTCFG_
prefix, when integration support gets added that will
translate to the respective CONFIG_BACKPORT_ prefix.
Kconfig opt env entries don't get propagated out, so
we
From: "Luis R. Rodriguez"
This enables support for using the backports project
to integrate device drivers from a future version of Linux
into an older version of Linux. What you end up seeing is
a backports submenu when configuring your kernel and the
ability to select specific device drivers
From: "Luis R. Rodriguez"
The way we backport when packaging is to minimize the amount of
changes required by taking advantage of the fact that Kconfig
will treat can read CONFIG_ an environment variable with getenv()
when parsing menu entries. When doing integration we don't want
to do this so
From: "Luis R. Rodriguez"
This allows us to extend how backports uses patches for
different types of applications. This will later be used
for kernel integration support, for example.
This should have no functional change.
Signed-off-by: Luis R. Rodriguez
---
gentree.py | 279
From: "Luis R. Rodriguez"
Here's a v2 series on kernel integration support. This addresses
the expresed concerns over killing the versions file for packaging.
While at it it also addresses avoiding the double prefix issue
by prefixing the things we carry over with the copy trick with
BPAUTO, and
From: Yan, Zheng
Introduce a new flag PERF_ATTACH_TASK_DATA for perf event's attach
stata. The flag is set by PMU's event_init() callback, it indicates
that perf event needs PMU specific data.
The PMU specific data are initialized to zeros. Later patches will
use PMU specific data to save LBR
For many profiling tasks we need the callgraph. For example we often
need to see the caller of a lock or the caller of a memcpy or other
library function to actually tune the program. Frame pointer unwinding
is efficient and works well. But frame pointers are off by default on
64bit code (and on
From: Yan, Zheng
If two tasks were both forked from the same parent task, Events in
their perf task contexts can be the same. Perf core may leave out
switching the perf event contexts.
Previous patch inroduces pmu specific data. The data is for saving
the LBR stack, it is task specific. So we
Hello,
On Wed, Nov 05, 2014 at 10:01:39AM +0800, Yijing Wang wrote:
> > So, yeah, this looks like a correct approach; however, do we even need
> > to clear the glue directories?
>
> Yes. In our platform, the glue directories
> /sys/devices/virtual/block will be removed once the last child
>
From: Yan, Zheng
When the LBR call stack is enabled, it is necessary to save/restore
the LBR stack on context switch. We can use pmu specific data to
store LBR stack when task is scheduled out. This patch adds code
that allocates the pmu specific data.
Signed-off-by: Yan, Zheng
Signed-off-by:
From: Yan, Zheng
Previous commit introduces context switch callback, its function
overlaps with the flush branch stack callback. So we can use the
context switch callback to flush LBR stack.
This patch adds code that uses the flush branch callback to
flush the LBR stack when task is being
From: Yan, Zheng
When the LBR call stack is enabled, it is necessary to save/restore
the LBR stack on context switch. The solution is saving/restoring
the LBR stack to/from task's perf event context.
The LBR stack is saved/restored only when there are events that use
the LBR call stack. If no
From: Yan, Zheng
Haswell has a new feature that utilizes the existing LBR facility to
record call chains. To enable this feature, bits (JCC, NEAR_IND_JMP,
NEAR_REL_JMP, FAR_BRANCH, EN_CALLSTACK) in LBR_SELECT must be set to 1,
bits (NEAR_REL_CALL, NEAR-IND_CALL, NEAR_RET) must be cleared. Due to
1 - 100 of 2044 matches
Mail list logo
