Re: [PATCH v6 00/16] Revert h8300 archtecture support
On Mon, Mar 09, 2015 at 05:46:54PM +0900, Yoshinori Sato wrote: > Hello. > > I rewriting h8300 support. > It might possibly be better to use the term "re-introduce" instead of rewrite or revert (as in the headline). Also, s/archtecture/architecture/ in the headline. Given that the reason for dropping the architecture in the first place was the lack of an active maintainer, I am somewhat surprised that you don't add one to the MAINTAINERS file. 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 man-pages] bpf.2: new page documenting bpf(2)
Hi Alexei,
The page needs a license. See
https://www.kernel.org/doc/man-pages/licenses.html
for some possible choices.
Thanks,
Michael
On 03/09/2015 11:10 PM, Alexei Starovoitov wrote:
> Signed-off-by: Alexei Starovoitov
> ---
> man2/bpf.2 | 593
>
> 1 file changed, 593 insertions(+)
> create mode 100644 man2/bpf.2
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> new file mode 100644
> index 000..21b42b4
> --- /dev/null
> +++ b/man2/bpf.2
> @@ -0,0 +1,593 @@
> +.TH BPF 2 2015-03-09 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +bpf - perform a command on extended BPF map or program
> +.SH SYNOPSIS
> +.nf
> +.B #include
> +.sp
> +.BI "int bpf(int cmd, union bpf_attr *attr, unsigned int size);
> +
> +.SH DESCRIPTION
> +.BR bpf()
> +syscall is a multiplexor for a range of different operations on extended BPF
> +which can be characterized as "universal in-kernel virtual machine".
> +Extended BPF (or eBPF) is similar to original Berkeley Packet Filter
> +(or "classic BPF") used to filter network packets. Both statically analyze
> +the programs before loading them into the kernel to ensure that programs
> cannot
> +harm the running system.
> +.P
> +eBPF extends classic BPF in multiple ways including ability to call
> +in-kernel helper functions and access shared data structures like BPF maps.
> +The programs can be written in a restricted C that is compiled into
> +eBPF bytecode and executed on the in-kernel virtual machine or JITed into
> native
> +instruction set.
> +.SS Extended BPF Design/Architecture
> +.P
> +BPF maps is a generic storage of different types.
> +User process can create multiple maps (with key/value being
> +opaque bytes of data) and access them via file descriptor. In parallel BPF
> +programs can access maps from inside the kernel.
> +It's up to user process and BPF program to decide what they store inside
> maps.
> +.P
> +BPF programs are similar to kernel modules. They are loaded by the user
> +process and automatically unloaded when process exits. Each BPF program is
> +a safe run-to-completion set of instructions. BPF verifier statically
> +determines that the program terminates and is safe to execute. During
> +verification the program takes a hold of maps that it intends to use,
> +so selected maps cannot be removed until the program is unloaded. The program
> +can be attached to different events. These events can be packets, tracing
> +events and other types in the future. A new event triggers execution of
> +the program which may store information about the event in the maps.
> +Beyond storing data the programs may call into in-kernel helper functions.
> +The same program can be attached to multiple events. Different programs can
> +access the same map:
> +.nf
> + tracing tracing tracing packet packet
> + event A event B event C on eth0on eth1
> + | | | | |
> + | | | | |
> + --> tracing <-- tracing socket socket
> +prog_1 prog_2 prog_3 prog_4
> +| | ||
> + |--- -| |---| map_3
> + map_1 map_2
> +.fi
> +.SS Syscall Arguments
> +.B bpf()
> +syscall operation is determined by
> +.IR cmd
> +which can be one of the following:
> +.TP
> +.B BPF_MAP_CREATE
> +Create a map with given type and attributes and return map FD
> +.TP
> +.B BPF_MAP_LOOKUP_ELEM
> +Lookup element by key in a given map and return its value
> +.TP
> +.B BPF_MAP_UPDATE_ELEM
> +Create or update element (key/value pair) in a given map
> +.TP
> +.B BPF_MAP_DELETE_ELEM
> +Lookup and delete element by key in a given map
> +.TP
> +.B BPF_MAP_GET_NEXT_KEY
> +Lookup element by key in a given map and return key of next element
> +.TP
> +.B BPF_PROG_LOAD
> +Verify and load BPF program
> +.TP
> +.B attr
> +is a pointer to a union of type bpf_attr as defined below.
> +.TP
> +.B size
> +is the size of the union.
> +.P
> +.nf
> +union bpf_attr {
> +struct { /* anonymous struct used by BPF_MAP_CREATE command */
> +__u32 map_type;
> +__u32 key_size;/* size of key in bytes */
> +__u32 value_size; /* size of value in bytes */
> +__u32 max_entries; /* max number of entries in a map */
> +};
> +
> +struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
> +__u32 map_fd;
> +__aligned_u64 key;
> +union {
> +__aligned_u64 value;
> +__aligned_u64 next_key;
> +};
> + __u64 flags;
> +};
> +
> +struct { /* anonymous struct used by BPF_PROG_LOAD command */
> +__u32 prog_type;
> +__u32 insn_cnt;
> +__aligned_u64 insns; /* 'const struct bpf_insn *' */
> +__aligned_u64 license; /* 'const char *' */
linux-next: build warnings after merge of the crypto tree
Hi Herbert,
After merging the crypto tree, today's (and the past few days)
linux-next build (powerpc allyesconfig) produced these warnings:
crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer
type
.sendmsg = aead_sendmsg,
^
crypto/algif_aead.c:561:2: warning: (near initialization for
'algif_aead_ops.sendmsg')
crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer
type
.recvmsg = aead_recvmsg,
^
crypto/algif_aead.c:563:2: warning: (near initialization for
'algif_aead_ops.recvmsg')
Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxM1aSo7Dv2.pgp
Description: OpenPGP digital signature
Re: [PATCH] sched: fix RLIMIT_RTTIME when PI-boosting to RT
* Brian Silverman wrote:
> Here's my test code. Compile with `gcc -pthread -lrt test_pi.c`. It
> requires permission to set a realtime scheduling policy of 2 when
> running.
Mind sending a patch that sticks this testcase into
tools/testing/selftests/sched/ or so, with the new 'sched' directory
and new Makefile to be created by you as well?
I've reformatted the testcase below, to kernel coding style. Note that
I added a minimal license notification, you might want to add your
copyright.
Thanks,
Ingo
==>
/*
* RLIMIT_RTTIME test code. Compile with:
*
* gcc -pthread -lrt test_pi.c
*
* It requires permission to set a realtime scheduling policy of 2 when running.
*
* License: GPLv2
*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static const struct timespec kSleepTime = { 0, 1 };
static pthread_mutex_t mutex;
extern void nop()
{
}
void *nonrealtime(void *ignored_param)
{
while (1) {
assert(pthread_mutex_lock() == 0);
assert(pthread_mutex_unlock() == 0);
assert(clock_nanosleep(CLOCK_MONOTONIC, 0, , NULL)
== 0);
}
}
void *realtime(void *ignored_param)
{
struct sched_param param;
memset(, 0, sizeof(param));
param.sched_priority = 2;
assert(sched_setscheduler(0, SCHED_FIFO, ) == 0);
while (1) {
assert(pthread_mutex_lock() == 0);
assert(clock_nanosleep(CLOCK_MONOTONIC, 0, , NULL)
== 0);
assert(pthread_mutex_unlock() == 0);
}
}
void signal_handler(int number)
{
printf("got signal %d, SIGXCPU=%d\n", number, SIGXCPU);
exit(0);
}
int main()
{
struct sigaction action;
memset(, 0, sizeof(action));
action.sa_handler = signal_handler;
assert(sigaction(SIGXCPU, , NULL) == 0);
struct rlimit rlim;
rlim.rlim_cur = 500;
rlim.rlim_max = 5000;
assert(prlimit(0, RLIMIT_RTTIME, , NULL) == 0);
pthread_mutexattr_t mutexattr;
assert(pthread_mutexattr_init() == 0);
assert(pthread_mutexattr_setprotocol(, PTHREAD_PRIO_INHERIT)
== 0);
assert(pthread_mutex_init(, ) == 0);
assert(pthread_mutexattr_destroy() == 0);
pthread_t nrt, rt;
assert(pthread_create(, NULL, nonrealtime, NULL) == 0);
assert(pthread_create(, NULL, realtime, NULL) == 0);
assert(pthread_join(nrt, NULL) == 0);
assert(pthread_join(rt, NULL) == 0);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the trivial tree
Hi all, On Tue, 10 Mar 2015 16:34:17 +1100 Stephen Rothwell wrote: > > After merging the trivial tree, today's linux-next build () This was an x86_64 allmodconfig build. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJfESNjaf3L.pgp Description: OpenPGP digital signature
Re: + zram-support-compaction.patch added to -mm tree
On (03/09/15 23:56), Minchan Kim wrote: > > in zram_slot_free_notify() and zram_rw_page() we don't have request queue, > > request, > > etc. so it's a bit troubling. > > I skim the code so I might miss something. > > zram_slot_free_notify is just to free allocated space on zsmalloc so > it's not related to I/O operation so it would be okay if we handle > make_request and rw_page. Fortunately, they share core function > called by zram_bvec_rw. So could we use generic_[start|end]_io_acct > in there? It seems we don't need request queue. > that will do the trick, I think. thanks. I found these two late last night. > > > > Nameunits description > > - --- > > read I/Os requests number of read I/Os processed > > read merges requests number of read I/Os merged with in-queue I/O > > read sectorssectors number of sectors read > > read ticks milliseconds total wait time for read requests > > write I/Os requests number of write I/Os processed > > write mergesrequests number of write I/Os merged with in-queue I/O > > write sectors sectors number of sectors written > > write ticks milliseconds total wait time for write requests > > in_flight requests number of I/Os currently in flight > > io_ticksmilliseconds total time this block device has been active > > time_in_queue milliseconds total wait time for all requests > > > > > > the only overlaps are num_read and num_write. so we will not be able to > > move all > > When I read above, read/write ticks would be useful to us. yes. somehow I didn't manage to shape my thoughts, I was going to say that this stat file is surely interesting on his own; and was about to let num_reads and num_writes to sit in both zram/stat and zram/io_stat files. > > (or any significant amount) of our IO stats to that file. that will force > > users > > to gather IO stats accross several files. > > I'm not saying let's move all of I/O related stuff. > What I want is to remove duplicated stat if it is and enable zram/stats > so I hope we could use iostat/nmon to monitor zram I/O. ok. I did some overlapping (as I mentioned above) -- num_reads and num_writes present in both ./stat and ./io_stat files. will remove them. so we end up having: -- block layer stats in zram/stat -- zram internal IO stats in zram/io_stat (no num_reads, no num_writes) -- zram mm stats in zram/mm_stat (orig size, compressed size, num_migrated, etc.) > > > > I'll take a look later today/tomorrow if I can do anything about it, but it > > seems > > that our own zramX/io_stat file would be simpler solution here. it does > > sound ugly, > > but it doesn't look so bad after all. > > If it is really impossible or makes kernel complicated, I will agree with you. > Otherwise, I really want to see zram in iostat. :) yes, that's the goal. I found our previous discussion on the topic: https://lkml.org/lkml/2014/9/4/368 6 months later we are finally on it :) will send the patches later today. thanks, -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/
linux-next: build warnings after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/tty/serial/serial_mctrl_gpio.c: In function 'mctrl_gpio_init':
drivers/tty/serial/serial_mctrl_gpio.c:110:4: warning: return makes pointer
from integer without a cast
return PTR_ERR(gpios->gpio[i]);
^
drivers/tty/serial/serial_mctrl_gpio.c:90:6: warning: unused variable 'err'
[-Wunused-variable]
int err;
^
Introduced by commit 1d267ea6539f ("serial: mctrl-gpio: simplify init
routine").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpkis5Cv8Veb.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the trivial tree
Hi Jiri,
After merging the trivial tree, today's linux-next build ()
produced this warning:
drivers/tty/goldfish.c: In function 'goldfish_tty_probe':
drivers/tty/goldfish.c:232:6: warning: unused variable 'i' [-Wunused-variable]
int i;
^
Introduced by commit 2a2483685a9d ("goldfish: remove unreachable line
of code").
Also, the author email of that patch does not have a full name and does
not match any of the Signed-off-by lines :-( (Yes, I know they are the
same person).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpmPInUlUcae.pgp
Description: OpenPGP digital signature
Re: [PATCH RESEND] x86:pci: Change sta2x11_dma_ops stucture to use switolb_dma_supported as it's dma_supported function in sta2x11-fixup.c
* Nicholas Krause wrote: > > > On March 10, 2015 12:45:01 AM EDT, Ingo Molnar wrote: > > > >* Nicholas Krause wrote: > > > >> This changes the structure sta2x11_dma_ops stucture to use > >switolb_dma_supported as it's > >> function for dma_supported hardware verus setting this value to NULL > >as this should be set > >> correctly for when dma_supported function needs to be called for > >hardware needing this > >> function to be supported. Otherwise hardware needing this function to > >be supported will > >> either cause a kernel panic or oops due to a NULL pointer being > >dereferenced in the > >> structure, sta1x11_dma_ops for the dma_supported function. Further > >more in order to > >> prevent a kernel panic or oops here due to a NULL pointer being > >deferred here we add the > >> function, swiotlb_dma_supported as the dma_supported function for the > >structure, > >> sta2x11_dma_ops. > > > >Pleasedontresendtotallyunstructuredandunreadablechangelogs. > > > >You also (still) don't explain where and how this supposed crash might > >happen in practice. Please don't resend unless you've addressed those > >deficiencies. > > > >I.e. I'm not convinced you know what you are modifying there and what > >effects your modifications will have. > > > >Thanks, > > > > Ingo > Ingo, > I was just wondering why my patch wasn't merged yet. In addition this patch > is more of a preventive measure as if there is no function pointer here > either we kernel panic or oops at best if hardware needs to access a dma > function for this structure . At the moment I am unaware of any actual > hardware that causes this issues, however this doesn't mean it won't happen > at some point. I can rewrite my change log to this reasoning if required. > Nick 1) So as a reply to my feedback complaining about the quality of your submissions, you write an unstructured mail put into a single line with no newline at all? *whoosh* 2) So I restructured your reply, added newlines at logical boundaries of thought, added proper punctuation and capitalization, fixed typos, removed phantom spaces - to make it minimally readable: > I was just wondering why my patch wasn't merged yet. > > In addition, this patch is more of a preventive measure, as if there > is no function pointer here either we kernel panic or oops at best > if hardware needs to access a DMA function for this structure. > > At the moment I am unaware of any actual hardware that causes these > issues, however this doesn't mean it won't happen at some point. > > I can rewrite my change log to this reasoning if required. You should have done this before expecting others to spend time on your mails. 3) As to the technical substance of your patch: where exactly would the kernel panic or oops? Your changelog is missing actual analysis. 4) And if you are wondering why maintainers have learned to start ignoring your trivial patches: - Unstructured changelogs, typos, missing punctuation, missing newlines, missing capitalization, phantom spaces cause submissions to be ignored as trivially deficient. - No real analysis is found in your patch, beyond the line that was spewed out by 'git grep -i fixme'. - Mass mailing of borderline useless patches is a waste of time for everyone. There are thousands of trivial FIXME's in the kernel and you want to generate a commit for every single one? The thing is, you now know how to write patches and how to upstream them. So it's time to rise beyond trivial patches: how about reading and understanding kernel code and fixing some real bugs? 5) All in one, I'm not convinced you went beyond the 'git grep -i fixme' line in reading kernel code... But it's up to Bjorn whether to merge your patch. Thanks, Ingo -- 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: build warning after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/tty/serial/imx.c: In function 'imx_set_termios':
drivers/tty/serial/imx.c:1301:7: warning: suggest explicit braces to avoid
ambiguous 'else' [-Wparentheses]
if (port->rs485.flags & SER_RS485_ENABLED)
^
Introduced by commit 17b8f2a3fdca ("serial: imx: add support for half
duplex rs485").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpCF4dRvYISK.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Inki, On 03/10/2015 03:50 AM, Inki Dae wrote: > On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote: Another thing that may be useful to detect these issues early is to have exynos-drm-next be pulled by linux-next since otherwise the integration is not tested until the changes are picked by the DRM maintainer. >> >> I know that I may sound like a broken record but could you please make >> sure that your tree is included in linux-next? > > Got it. I got several requests before. I have created a new branch - > exynos-drm/for-next - based on top of drm-next, which would have same > patch set as existing exynos-drm-next. > > I will request Stephen Rothwell to merge remote-tracking branch, > 'exynos-drm/for-next'. > Great new, thanks a lot. > Thanks, > Inki Dae > Best regards, Javier -- 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 4/4] charger-manager: Enable psy based charge control
Hi,
> On Fri, Mar 06, 2015 at 04:03:27PM +0530, Jenny TC wrote:
> > At present charger manager support only regulator based charging
> > control. But most of the charger drivers are registered with power
> > supply subsystem. This patch adds support for power supply based
> > charging control along with the regulator based control. With the
> > patch, charging control can be done either using power supply
> > interface or with regulator interface. The charging is setup
> > based on battery parameters received through the battery info
> > handlers.
>
> [...]
>
> (so far I only skipped over the patch)
Appreciate if you could review entire patch. I will submit next patch set
addressing all your comments.
> [...]
>
> > @@ -1704,6 +1968,10 @@ static int charger_manager_probe(struct
> platform_device *pdev)
> > strncpy(cm->psy_name_buf, desc->psy_name, PSY_NAME_MAX);
> > cm->charger_psy.name = cm->psy_name_buf;
> >
> > + if (!power_supply_get_property(fuel_gauge,
> POWER_SUPPLY_PROP_MODEL_NAME,
> > + ))
> > + cm->battery_info = psy_get_battery_info(val.strval);
> > +
> > /* Allocate for psy properties because they may vary */
> > cm->charger_psy.properties = devm_kzalloc(>dev,
> > sizeof(enum power_supply_property)
>
> We are currently splitting battery data from fuel gauge data, so
> acquiring the battery using the fuel gauge's MODEL_NAME is not very
> nice.
Will enhance struct charger_desc{ ..} to support list of battery model name
supported. This can be used to query battery_info using psy_get_battery_info()
-Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] f2fs: fix to truncate inline data past EOF
Previously if inode is with inline data, we will try to invalid partial inline
data in page #0 when we truncate size of inode in truncate_partial_data_page().
And then we set page #0 to dirty, after this we can synchronize inode page with
page #0 at ->writepage().
But sometimes we will fail to operate page #0 in truncate_partial_data_page()
due to below reason:
a) if offset is zero, we will skip setting page #0 to dirty.
b) if page #0 is not uptodate, we will fail to update it as it has no mapping
data.
So with following operations, we will meet recent data which should be
truncated.
1.write inline data to file
2.sync first data page to inode page
3.truncate file size to 0
4.truncate file size to max_inline_size
5.echo 1 > /proc/sys/vm/drop_caches
6.read file --> meet original inline data which is remained in inode page.
This patch renames truncate_inline_data() to truncate_inline_inode() for code
readability, then use truncate_inline_inode() to truncate inline data in inode
page in truncate_blocks() and truncate page #0 in truncate_partial_data_page()
for fixing.
v2:
o truncate partially #0 page in truncate_partial_data_page to avoid keeping
old data in #0 page.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/file.c | 16 +++-
fs/f2fs/inline.c | 26 +-
3 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 511d6cd..c1ad404 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1754,6 +1754,7 @@ extern struct kmem_cache *inode_entry_slab;
*/
bool f2fs_may_inline(struct inode *);
void read_inline_data(struct page *, struct page *);
+bool truncate_inline_inode(struct page *, u64);
int f2fs_read_inline_data(struct inode *, struct page *);
int f2fs_convert_inline_page(struct dnode_of_data *, struct page *);
int f2fs_convert_inline_inode(struct inode *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f1341c7..d927f8e 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -456,15 +456,16 @@ void truncate_data_blocks(struct dnode_of_data *dn)
truncate_data_blocks_range(dn, ADDRS_PER_BLOCK);
}
-static int truncate_partial_data_page(struct inode *inode, u64 from)
+static int truncate_partial_data_page(struct inode *inode, u64 from,
+ bool force)
{
unsigned offset = from & (PAGE_CACHE_SIZE - 1);
struct page *page;
- if (!offset)
+ if (!offset && !force)
return 0;
- page = find_data_page(inode, from >> PAGE_CACHE_SHIFT, false);
+ page = find_data_page(inode, from >> PAGE_CACHE_SHIFT, force);
if (IS_ERR(page))
return 0;
@@ -475,7 +476,8 @@ static int truncate_partial_data_page(struct inode *inode,
u64 from)
f2fs_wait_on_page_writeback(page, DATA);
zero_user(page, offset, PAGE_CACHE_SIZE - offset);
- set_page_dirty(page);
+ if (!force)
+ set_page_dirty(page);
out:
f2fs_put_page(page, 1);
return 0;
@@ -489,6 +491,7 @@ int truncate_blocks(struct inode *inode, u64 from, bool
lock)
pgoff_t free_from;
int count = 0, err = 0;
struct page *ipage;
+ bool truncate_page = false;
trace_f2fs_truncate_blocks_enter(inode, from);
@@ -504,7 +507,10 @@ int truncate_blocks(struct inode *inode, u64 from, bool
lock)
}
if (f2fs_has_inline_data(inode)) {
+ if (truncate_inline_inode(ipage, from))
+ set_page_dirty(ipage);
f2fs_put_page(ipage, 1);
+ truncate_page = true;
goto out;
}
@@ -535,7 +541,7 @@ out:
/* lastly zero out the first data page */
if (!err)
- err = truncate_partial_data_page(inode, from);
+ err = truncate_partial_data_page(inode, from, truncate_page);
trace_f2fs_truncate_blocks_exit(inode, err);
return err;
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 4ba9732..153c5e7 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -50,10 +50,26 @@ void read_inline_data(struct page *page, struct page *ipage)
SetPageUptodate(page);
}
-static void truncate_inline_data(struct page *ipage)
+bool truncate_inline_inode(struct page *ipage, u64 from)
{
+ void *addr;
+
+ /*
+* we should never truncate inline data past max inline data size,
+* because we always convert inline inode to normal one before
+* truncating real data if new size is past max inline data size.
+*/
+ f2fs_bug_on(F2FS_P_SB(ipage), from > MAX_INLINE_DATA);
+
+ if (from >= MAX_INLINE_DATA)
+ return false;
+
+ addr = inline_data_addr(ipage);
+
f2fs_wait_on_page_writeback(ipage, NODE);
- memset(inline_data_addr(ipage), 0, MAX_INLINE_DATA);
+ memset(addr + from, 0, MAX_INLINE_DATA - from);
+
+ return true;
}
RE: [RFC 1/4] power_supply: Introduce charging object table
> > On Mon, Mar 09, 2015 at 12:26:21PM +, Tc, Jenny wrote: > > > > + char name[PSY_MAX_BAT_NAME_LEN]; > > > > > > char *name; > > > > > > No need for arbitrary length limitation. > > > > The length limitation is introduced to form a packed structure so that > > the data can be read directly from memory without parsing. > > This reason is ok for a device driver, but not for a kernel > subsystem. Agree, will fix this. Same for psy_temp_mon_table temp_mon_table -Jenny -- 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 3/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
Hi, On Mon, Mar 09, 2015 at 02:10:37PM +0200, Boaz Harrosh 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) > still have BIOS (On by default). The BIOS was yelled "Wolfe" for so long NOW > ;-) > Again these are working system in the field, who will switch them all to UEFI? > > How will the UEFI present them to the system? can you point me to the relevant > code? (Or did you mean BIOS but with a different communication path than > e820?) > Per my understand... With EFI Boot Stub, there have setup_e820() codes in arch/x86/boot/compressed/eboot.c that used to transfer EFI memmap to e820 entries. Currently doesn't have any EFI_MEMORY_TYPE reflects to NvDIMM that will map to e820_type. I wonder what kind of EFI_MEMORY_TYPE reported by UEFI BIOS on those "shipped NvDIMMs motherboards", like supermicro X9DRH-iF-NV. Then we may need add code to setup_e820() for mapping the efi memory type to e820 type 12 region. > > > > --Andy > > > > Thanks > Boaz > Thanks a lot! Joey Lee -- 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: build failure after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from include/linux/module.h:17:0,
from drivers/staging/sm750fb/sm750.c:2:
drivers/staging/sm750fb/sm750.c: In function '__check_g_option':
drivers/staging/sm750fb/sm750.c:1436:14: error: 'g_option' undeclared (first
use in this function)
module_param(g_option,charp,S_IRUGO);
^
Caused by commit 81dee67e215b ("staging: sm750fb: add sm750 to staging").
This driver also produced a large number of warnings ... a lot like this:
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_ops_mmap':
drivers/staging/sm750fb/sm750.c:533:2: warning: format '%x' expects argument of
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
^
Also note:
In file included from drivers/staging/sm750fb/ddk750_mode.h:4:0,
from drivers/staging/sm750fb/ddk750.h:15,
from drivers/staging/sm750fb/sm750_hw.c:24:
drivers/staging/sm750fb/ddk750_chip.h:4:0: warning: "SM750LE_REVISION_ID"
redefined
#define SM750LE_REVISION_ID (char)0xfe
^
In file included from drivers/staging/sm750fb/sm750_hw.c:23:0:
drivers/staging/sm750fb/sm750_hw.h:8:0: note: this is the location of the
previous definition
#define SM750LE_REVISION_ID (unsigned char)0xfe
^
I have disabled this driver for now, please let me know when it is OK
to enable it again.
From: Stephen Rothwell
Date: Tue, 10 Mar 2015 16:02:45 +1100
Subject: [PATCH] staging: disable the Silicon Motion SM750 framebuffer support
due to build problems
Signed-off-by: Stephen Rothwell
---
drivers/staging/sm750fb/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index c40d088a4d3b..24f3a7f787da 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,6 +1,7 @@
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
depends on FB && PCI
+ depends on BROKEN
help
Frame buffer driver for the Silicon Motion SM750 chip
with 2D accelearion and dual head support.
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpGPTKT6UrZU.pgp
Description: OpenPGP digital signature
Re: [PATCH 08/12] time: Add warnings when overflows or underflows are observed
* John Stultz wrote: > Thanks Ingo for the very close review, and apologies for my poor > keyboardmanship (I hope I didn't burn much of your good will here). No problem. I usually fix typos up when the patch is otherwise good, except for Git pulls, where I cannot, so I'm pushing back ... > I'll work to get these trivial changes integrated along with the > more substantial feedback as well. It's all nice changes otherwise. I'm fairly sure the new sanity checks are going to show us interesting things in the future. Thanks, Ingo -- 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] f2fs: fix to truncate inline data past EOF
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, March 10, 2015 11:00 AM
> To: Chao Yu
> Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] f2fs: fix to truncate inline data past EOF
>
> Hi Chao,
>
> On Tue, Mar 10, 2015 at 10:02:46AM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
>
> [snip]
>
> > > > > +static int truncate_partial_data_page(struct inode *inode, u64 from,
> > > > > bool force)
> > > > > {
> > > > > unsigned offset = from & (PAGE_CACHE_SIZE - 1);
> > > > > struct page *page;
> > > > >
> > > > > - if (!offset)
> > > > > + if (!offset && !force)
> > > >
> > > > We truncate on-disk inode page and #0 page separately, so IMO there is
> > > > a very
> > > > small chance the following issue will occur.
> > > >
> > > > (0 < truncated_size < MAX_INLINE_SIZE)
> > > > ->f2fs_setattr
> > > > ->truncate_setsize #0 page has been truncated partially
> > > > ->f2fs_truncate
> > > > ->truncate_blocks
> > > > invalidate #0 page by reclaimer
> > > > update #0 page with original
> > > > data in inode page by reader
> > >
> > > truncate_setsize called
> > > truncate_pagesize.
> > > so #0 page was truncated successfully.
> >
> > Yeah, but it's partially truncating as 0 < truncated_size < MAX_INLINE_SIZE,
> > After truncating, we still keep [0, truncated_size) valid data in #0 page,
> > and
> > our #0 page status is uptodate | !dirty.
> >
> > So what I mean is that mm can reclaim this #0 page, then if someone else
> > read
> > the #0 page again, we will update the #0 page with original data in inode
> > page
> > since inode page haven't truncated yet.
>
> The truncate_blocks dropped inline_data in inode page, which is modified by
> this patch.
> And, the cached #0 page was truncated by truncate_setsize.
> Even if this page was evicted and reloaded again, the data would be filled
> with
> the inode page having truncated inline_data.
> So, it seems there is no problem.
>
> BTW, do you mean like this scenario?
Yeah, actually it is. ;-)
>
> -> f2fs_setattr
> ->truncate_setsize: #0 page has been truncated partially
> ->f2fs_truncate
> invalidate #0 page by reclaimer
> update #0 page with original data in
> inode page by reader
>
> ->truncate_blocks
> (*)-> truncate_inline_inode
> (*)-> truncate_partial_data_page(,, force)
>find_data_page(,, force) <- we can use *force* here.
>
> Then, I agree that two functions as noted (*) above would be necessary.
>
> >
> > If this happened, if we don't truncate #0 page in following code of
> > truncate_blocks,
> > we will remain the original data for user, it's wrong.
> >
> > IMO, it's better to truncate inode page and #0 page together, or truncate
> > #0 page
> > in truncate_partial_data_page.
> >
> > How do you think?
> >
> > >
> > > > ->truncate_inline_inode
> > > > ->truncate_partial_data_page
> > > > we will fail to truncate #0 page because we can't find valid
> > > > blkaddr for
> > > > #0 page in find_data_page(,,false)
> > > >
> > > > How about using find_data_page(,,true) to check weather this page is
> > > > update or not
> > > > for this condition.
> > >
> > > Oh, I realized that we don't need to call truncate_partial_data_page,
> > > since the
> > > cached #0 page was truncated already. We don't care about that.
> >
> > IMO, we should care about this #0 page if above example can happen.
> >
> > > So, do we need to add just truncate_inline_inode() like below?
> > >
> > > >
> > > > > return 0;
> > > > >
> > > > > page = find_data_page(inode, from >> PAGE_CACHE_SHIFT, false);
> > > > > @@ -489,6 +489,7 @@ int truncate_blocks(struct inode *inode, u64
> > > > > from, bool lock)
> > > > > pgoff_t free_from;
> > > > > int count = 0, err = 0;
> > > > > struct page *ipage;
> > > > > + bool truncate_page = false;
> > > > >
> > > > > trace_f2fs_truncate_blocks_enter(inode, from);
> > > > >
> > > > > @@ -504,6 +505,9 @@ int truncate_blocks(struct inode *inode, u64
> > > > > from, bool lock)
> > > > > }
> > > > >
> > > > > if (f2fs_has_inline_data(inode)) {
> > > > > + truncate_inline_inode(ipage, from);
> > > > > + set_page_dirty(ipage);
> > > >
> > > > If @from is the same as MAX_INLINE_DATA, we will change nothing in
> > > > inode page,
> > > > How about skipping set_page_dirty for inode page in this condition?
> > >
> > > Agreed.
> > > How about adding this in truncate_inline_inode?
> > >
> > > if (from >= MAX_INLINE_DATA)
> > > return;
> > > ...
> > > set_page_dirty(ipage);
> >
> > Yeah, that's good.
> >
> > And What I suggest is:
> >
Re: [PATCH v2] x86, selftests: Add sigreturn_32 selftest
* Andy Lutomirski wrote: > On Mon, Mar 9, 2015 at 9:48 AM, Ingo Molnar wrote: > > > > now I get this build failure: > > > > make[1]: Entering directory > > '/home/mingo/tip/tools/testing/selftests/x86' > > gcc -m32 -o sigreturn_32 -O2 -g -std=gnu99 -pthread -Wall sigreturn.c -lrt > > -ldl > > In file included from /usr/include/time.h:27:0, > > from sigreturn.c:13: > > /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or > > directory > > # include > > ^ > > compilation terminated. > > Makefile:18: recipe for target 'sigreturn_32' failed > > make[1]: *** [sigreturn_32] Error 1 > > It builds for me on Ubuntu. > > It looks like your 32-bit build setup is broken. The line that's > failing to compile is: > > #include > > Are you missing 32-bit headers? This test *can't* be run as a 64-bit binary. Yeah, was a relatively fresh testbox, the magic incantation to get it to build there was: apt-get install gcc-multilib libc6-i386 libc6-dev-i386 On Fedora it's: yum install glibc-devel.*i686 Might make sense to include that in a README or so. Thanks, Ingo -- 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 1/2] fs proc: make pagemap a privileged interface
Dave Hansen writes: > On 03/09/2015 05:03 PM, Kees Cook wrote: >> On Mon, Mar 9, 2015 at 4:43 PM, Eric W. Biederman >> wrote: >>> A 1 to 1 blinding function like integer multiplication mudulo 2^32 by an >>> appropriate random number ought to keep from revealing page numbers or >>> page ajacencies while not requiring any changes in userspace. >>> >>> That way the revealed pfn and the physcial pfn would be different but >>> you could still use pagemap for it's intended purpose. >> >> If this could be done in a way where it was sufficiently hard to >> expose the random number, we should absolutely do this. > > We would need something which is both reversible (so that the given > offsets can still be used in /proc/kpagemap) and also hard to do a > known-plaintext-type attack on it. > > Transparent huge pages are a place where userspace knows the > relationship between 512 adjacent physical addresses. That represents a > good chunk of known data. Surely there are more of these kinds of things. > > Right now, for instance, the ways in which a series of sequential > allocations come out of the page allocator are fairly deterministic. We > would also need to do some kind of allocator randomization to ensure > that userspace couldn't make good guesses about the physical addresses > of things coming out of the allocator. > > Or, we just be sure and turn the darn thing off. :) Yes. If we are worried about something a big off switch is fine. As for a one-to-one transform that is resitant to plain text attacks I think that is the definition of a cypher. That is we should just use AES or something well know to encrypt the pafe frame numbers if we want to hide them. I don't know if the block mode of AES would be a problem or not. Eric -- 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] x86:pci: Change sta2x11_dma_ops stucture to use switolb_dma_supported as it's dma_supported function in sta2x11-fixup.c
* Nicholas Krause wrote: > This changes the structure sta2x11_dma_ops stucture to use > switolb_dma_supported as it's > function for dma_supported hardware verus setting this value to NULL as this > should be set > correctly for when dma_supported function needs to be called for hardware > needing this > function to be supported. Otherwise hardware needing this function to be > supported will > either cause a kernel panic or oops due to a NULL pointer being dereferenced > in the > structure, sta1x11_dma_ops for the dma_supported function. Further more in > order to > prevent a kernel panic or oops here due to a NULL pointer being deferred here > we add the > function, swiotlb_dma_supported as the dma_supported function for the > structure, > sta2x11_dma_ops. Pleasedontresendtotallyunstructuredandunreadablechangelogs. You also (still) don't explain where and how this supposed crash might happen in practice. Please don't resend unless you've addressed those deficiencies. I.e. I'm not convinced you know what you are modifying there and what effects your modifications will have. Thanks, Ingo -- 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 00/10] rcu: Cleanup RCU tree initialization
On Mon, Mar 09, 2015 at 04:49:43PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 09, 2015 at 04:39:47PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 09, 2015 at 02:40:21PM -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote:
> > > > Hi Paul,
> > > >
> > > > Here is cleanup of RCU tree initialization rebased on linux-rcu rcu/next
> > > > repo, as you requested. Please, note an extra patch #10 that was not
> > > > present in the first post.
> > > >
> > > > The series successfully passes kernel build test with CONFIG_RCU_FANOUT
> > > > and CONFIG_RCU_FANOUT_LEAF equal to 5.
> > >
> > > I queued up 1-9, as discussed and have started testing. I will let you
> > > know how it goes.
> >
> > Initial testing went well except for the following warning:
> >
> > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c: In function
> > ‘rcu_init_one.isra.63’:
> > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:3961:3: warning:
> > ‘levelcnt[0]’ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> >for (j = 0; j < levelcnt[i]; j++, rnp++) {
> >
> > This warning looks like a false positive to me, given that the loop
> > near the beginning of the function initializes levelcnt[0]. Am I
> > missing something here, and either way, what is the best way to shut
> > this warning up?
>
> My suggestion is the following:
>
> if (rcu_num_lvls <= 0)
> panic("rcu_init_one: rcu_num_lvls underflow");
>
> Just following the other panic() in rcu_init_one().
As in the following patch.
Thanx, Paul
rcu: Shut up spurious gcc uninitialized-variable warning
Because gcc doesn't realize that rcu_num_lvls must be strictly greater
than zero, some versions give a spurious warning about levelcnt[0] being
uninitialized in rcu_init_one(). This commit adds a panic() in that
case in order to educate gcc on this point.
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bd5a9a1db048..5b42d94335e3 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3942,6 +3942,8 @@ static void __init rcu_init_one(struct rcu_state *rsp,
/* Silence gcc 4.8 warning about array index out of range. */
if (rcu_num_lvls > RCU_NUM_LVLS)
panic("rcu_init_one: rcu_num_lvls overflow");
+ if (rcu_num_lvls <= 0)
+ panic("rcu_init_one: rcu_num_lvls underflow");
/* Initialize the level-tracking arrays. */
--
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] sched/deadline: add rq->clock update skip for dl task yield
This patch add rq->clock update skip for dl task yield to tell update_rq_clock() that we've just updated, so we don't do microscopic update in schedule() and double the fastpath cost. Signed-off-by: Wanpeng Li --- kernel/sched/deadline.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 1ed6928..c397e6b 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -968,6 +968,12 @@ static void yield_task_dl(struct rq *rq) } update_rq_clock(rq); update_curr_dl(rq); + /* +* Tell update_rq_clock() that we've just updated, +* so we don't do microscopic update in schedule() +* and double the fastpath cost. +*/ + rq_clock_skip_update(rq, true); } #ifdef CONFIG_SMP -- 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: sched: divide error in sg_capacity_factor
* Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside the latest -next kernel using trinity I've > stumbled on: > > [ 936.784266] divide error: [#1] PREEMPT SMP KASAN > [ 936.793957] RIP: find_busiest_group (kernel/sched/fair.c:6152 > kernel/sched/fair.c:6223 kernel/sched/fair.c:6341 kernel/sched/fair.c:6603) Hm, these line numbers don't seem to match up very well with my version of linux-next: 28855005be1d Add linux-next specific files for 20150306 and the Git version info included in the oops seems useless: 4.0.0-rc1-sasha-00044-ge21109a $ git log e21109a fatal: ambiguous argument 'e21109a': unknown revision or path not in the working tree. I think the kernel's SHA1 should be made at least 12 char wide, regardless of the user's gitconfig::core.abbrev settings. Also, latest linux-next is -rc2 based, while your version string says -rc1. > [ 936.829403] load_balance (kernel/sched/fair.c:6857) this does not match up either. > [ 936.829403] run_rebalance_domains (kernel/sched/fair.c:7494 > kernel/sched/fair.c:7659) The line numbers are not even close to anything related: run_rebalance_domains() starts at line 7666 and ends at 7680. Also, why are the offsets into the function missing from the output? Those would allow the rough determination of the crash site, even if debuginfo is crap. I also checked Linus's latest, and they do seem to match up better: affb8172de39 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm and the line number gives: capacity_factor = min_t(unsigned, capacity_factor, DIV_ROUND_CLOSEST(capacity, SCHED_CAPACITY_SCALE)); but that's a division with a constant? Should not trap. So I rebuild a kernel with debug info, pattern matched the disassembly you provided, and that gave me this division: (gdb) list *0x8107d958 0x8107d958 is in find_busiest_group (kernel/sched/fair.c:6162). 6157capacity = group->sgc->capacity; 6158capacity_orig = group->sgc->capacity_orig; 6159cpus = group->group_weight; 6160 6161/* smt := ceil(cpus / capacity), assumes: 1 < smt_capacity < 2 */ 6162smt = DIV_ROUND_UP(SCHED_CAPACITY_SCALE * cpus, capacity_orig); 6163capacity_factor = cpus / smt; /* cores */ 6164 6165capacity_factor = min_t(unsigned, 6166capacity_factor, DIV_ROUND_CLOSEST(capacity, SCHED_CAPACITY_SCALE)); So this too seems not very plausible: 'capacity_orig' comes straight from group->sgc->capacity_orig, which is: - boot time initialized - sometimes recalculated during CPU hot-plug: not sure how much of that your tests are doing? - but otherwise it's fairly constant and should have crashed your system early on if it was set up wrong unless I missed something that is. > [ 936.829403] __do_softirq (kernel/softirq.c:273 > include/linux/jump_label.h:114 include/trace/events/irq.h:126 > kernel/softirq.c:274) > [ 936.829403] irq_exit (kernel/softirq.c:350 kernel/softirq.c:391) > [ 936.829403] smp_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:918) > [ 936.829403] apic_timer_interrupt (arch/x86/kernel/entry_64.S:958) > [ 936.829403] > [ 936.829403] print_context_stack (arch/x86/kernel/dumpstack.c:105) > [ 936.829403] dump_trace (arch/x86/kernel/dumpstack_64.c:244) > [ 936.829403] save_stack_trace (arch/x86/kernel/stacktrace.c:64) > [ 936.829403] __set_page_owner (mm/page_owner.c:72) > [ 936.829403] get_page_from_freelist (include/linux/page_owner.h:26 > mm/page_alloc.c:2176) > [ 936.829403] __alloc_pages_nodemask (mm/page_alloc.c:2844) > [ 936.829403] alloc_pages_vma (mm/mempolicy.c:2007) > [ 936.829403] handle_mm_fault (mm/memory.c:2156 mm/memory.c:3164 > mm/memory.c:3269 mm/memory.c:3298) > [ 936.829403] __do_page_fault (arch/x86/mm/fault.c:1235) > [ 936.829403] trace_do_page_fault (arch/x86/mm/fault.c:1329) > [ 936.829403] do_async_page_fault (arch/x86/kernel/kvm.c:280) > [ 936.829403] async_page_fault (arch/x86/kernel/entry_64.S:1295) So debug info weirdnesses aside, other divisions in find_busiest_group(): sds.avg_load = (SCHED_CAPACITY_SCALE * sds.total_load) / sds.total_capacity; total_capacity ought to be zero only on a totally borked machine (unlikely to boot), or on memory corruption. if calculate_imbalance() got inlined, then: load_above_capacity /= busiest->group_capacity; that too ought to only get corrupted in the most serious cases, we don't recalculate it runtime. So I'm baffled. Some tentative handwaving, pointing away from the scheduler: - Your stack trace is 'weird' not just due to debug info: an async page fault doing allocations, doing a stack trace, interruted by a timer irq, doing scheduler rebalancing... - The (spectacularly misnamed [*] ) CONFIG_PAGE_OWNER=y page lifetime tracing facility got enabled explicitly via the page_owner=on boot
Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, Mar 10, 2015 at 12:41 PM, Yingjoe Chen wrote: > On Tue, 2015-03-10 at 02:00 +0900, Tomasz Figa wrote: >> On Mon, Mar 9, 2015 at 11:46 PM, Yingjoe Chen >> wrote: >> > On Mon, 2015-03-09 at 20:11 +0900, Tomasz Figa wrote: >> > <...> >> >> > +/* >> >> > + * pimudev is a global var for dma_alloc_coherent. >> >> > + * It is not accepatable, we will delete it if "domain_alloc" is >> >> > enabled >> >> > + */ >> >> > +static struct device *pimudev; >> >> >> >> This is indeed not acceptable. Could you replace dma_alloc_coherent() >> >> with something that doesn't require device pointer, e.g. >> >> alloc_pages()? (Although that would require you to handle cache >> >> maintenance in the driver, due to cached memory allocated.) I need to >> >> think about a better solution for this. >> > >> > Hi, >> > >> > For 2nd level page table, we use cached memory now. Currently we are >> > using __dma_flush_range to flush the cache, which is also unacceptable. >> > >> > For proper cache management, we'll need to use dma_map_single or >> > dma_sync_*, which still need a deivce*. >> >> Looking at how already mainlined drivers do this, they either use >> dmac_flush_range() >> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/msm_iommu.c?id=refs/tags/v4.0-rc3#n80) >> or directly __cpuc_flush_dcache_area() and outer_flush_range() >> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/rockchip-iommu.c?id=refs/tags/v4.0-rc3#n93). > > Hi, > > These only exist in arch/arm, not arm64. I think we should avoid using > API start with __ in drivers. This driver might be used in both > arm/arm64, I think the only option for us is DMA APIs. > > Actually, I'm thinking that we should change to use coherent memory for > 2nd level page table as well and totally skip the cache flush. It seems > dma_pool_create is suitable to replace kmem_cache we are using right > now. However it still need a device*, which we have to fix anyway. That sounds like a reasonable option, because this is what we have DMA mapping API for. Do you expect to have more than one M4U block inside a SoC? Maybe this static variable actually isn't that bad, with a comment added explaining that there is always only one such block and that a rework will be needed if future SoCs will have more. Best regards, Tomasz -- 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] can: use sock_efree instead of own destructor
It is identical to the can destructor.
Signed-off-by: Florian Westphal
---
include/linux/can/skb.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h
index cc00d15..b6a52a4 100644
--- a/include/linux/can/skb.h
+++ b/include/linux/can/skb.h
@@ -44,16 +44,11 @@ static inline void can_skb_reserve(struct sk_buff *skb)
skb_reserve(skb, sizeof(struct can_skb_priv));
}
-static inline void can_skb_destructor(struct sk_buff *skb)
-{
- sock_put(skb->sk);
-}
-
static inline void can_skb_set_owner(struct sk_buff *skb, struct sock *sk)
{
if (sk) {
sock_hold(sk);
- skb->destructor = can_skb_destructor;
+ skb->destructor = sock_efree;
skb->sk = sk;
}
}
--
2.0.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 1/2] tracing: remove ftrace:function TRACE_EVENT_FL_USE_CALL_FILTER flag
ping..
On 2015/3/3 15:21, He Kuang wrote:
TRACE_EVENT_FL_USE_CALL_FILTER flag in ftrace:functon event can be
removed. This flag was first introduced in commit
f306cc82a93d ("tracing: Update event filters for multibuffer").
Now, the only place uses this flag is ftrace:function, but the filter of
ftrace:function has a different code path with events/syscalls and
events/tracepoints. It uses ftrace_filter_write() and perf's
ftrace_profile_set_filter() to set the filter, the functionality of file
'tracing/events/ftrace/function/filter' is bypassed in function
init_pred(), in which case, neither call->filter nor file->filter is
used.
So we can safely remove TRACE_EVENT_FL_USE_CALL_FILTER flag from
ftrace:function events.
Signed-off-by: He Kuang
---
kernel/trace/trace_export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index 12e2b99..174a6a7 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -177,7 +177,7 @@ struct ftrace_event_call __used event_##call = {
\
}, \
.event.type = etype,\
.print_fmt = print,\
- .flags = TRACE_EVENT_FL_IGNORE_ENABLE |
TRACE_EVENT_FL_USE_CALL_FILTER, \
+ .flags = TRACE_EVENT_FL_IGNORE_ENABLE, \
};\
struct ftrace_event_call __used
\
__attribute__((section("_ftrace_events"))) *__event_##call = _##call;
--
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-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell
Date: Tue, 10 Mar 2015 12:08:42 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/cadence/macb.c between commit 0b2eb3e9bc73 ("net:
> macb: constify macb configuration data") from the net tree and commits
> a848748959d5 ("net: macb: remove #if defined(CONFIG_ARCH_AT91)
> sections") and 421d9df0628b ("net/macb: merge at91_ether driver into
> macb driver") from the net-next tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
Thanks Stephen, I'm merging net into net-next right now and will resolve
this similarly.
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 baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static
On Thu, Feb 05, 2015 at 05:11:59PM +, Mark Brown wrote: > On Fri, Feb 06, 2015 at 01:03:52AM +0800, kbuild test robot wrote: > > sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' > > was not declared. Should it be static? > > This file isn't in an upstream tree, should this patch have been sent > upstream (I suspect non-upstream trees may need a bit of filtering in > the scripts)? Good point! I just added some tests trying to avoid this, which should be much better, but nevertheless not complete enough to cover all cases. Please help point out inadequate cases when you come across them in future! Thanks, Fengguang -- 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/5] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, 2015-03-10 at 02:00 +0900, Tomasz Figa wrote: > On Mon, Mar 9, 2015 at 11:46 PM, Yingjoe Chen > wrote: > > On Mon, 2015-03-09 at 20:11 +0900, Tomasz Figa wrote: > > <...> > >> > +/* > >> > + * pimudev is a global var for dma_alloc_coherent. > >> > + * It is not accepatable, we will delete it if "domain_alloc" is enabled > >> > + */ > >> > +static struct device *pimudev; > >> > >> This is indeed not acceptable. Could you replace dma_alloc_coherent() > >> with something that doesn't require device pointer, e.g. > >> alloc_pages()? (Although that would require you to handle cache > >> maintenance in the driver, due to cached memory allocated.) I need to > >> think about a better solution for this. > > > > Hi, > > > > For 2nd level page table, we use cached memory now. Currently we are > > using __dma_flush_range to flush the cache, which is also unacceptable. > > > > For proper cache management, we'll need to use dma_map_single or > > dma_sync_*, which still need a deivce*. > > Looking at how already mainlined drivers do this, they either use > dmac_flush_range() > (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/msm_iommu.c?id=refs/tags/v4.0-rc3#n80) > or directly __cpuc_flush_dcache_area() and outer_flush_range() > (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/rockchip-iommu.c?id=refs/tags/v4.0-rc3#n93). Hi, These only exist in arch/arm, not arm64. I think we should avoid using API start with __ in drivers. This driver might be used in both arm/arm64, I think the only option for us is DMA APIs. Actually, I'm thinking that we should change to use coherent memory for 2nd level page table as well and totally skip the cache flush. It seems dma_pool_create is suitable to replace kmem_cache we are using right now. However it still need a device*, which we have to fix anyway. Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf hists browser: Fix segfault when all entries be filtered
ping..
On 2015/3/4 12:13, He Kuang wrote:
When all perf report entries be filtered, the result of
hists__filter_entries() can be NULL, check the result before processing.
Miss this checking will cause segmentation fault like this:
$ perf report
(filter all entries and left nothing, then zoom in/out)
perf: Segmentation fault
backtrace
../bin/perf[0x4d1858]
../lib64/libc.so.6(+0x3545f)[0x7fe72fc1145f]
../bin/perf[0x4cd9f5]
../bin/perf[0x4ce176]
../bin/perf[0x4d0506]
../bin/perf[0x41a94f]
../bin/perf[0x408cf2]
../bin/perf[0x408455]
../lib64/libc.so.6(__libc_start_main+0xf4)[0x7fe72fbfdbd4]
../bin/perf[0x408584]
Signed-off-by: He Kuang
---
tools/perf/ui/browsers/hists.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 788506e..1106bb8 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -992,6 +992,9 @@ static void ui_browser__hists_seek(struct ui_browser
*browser,
* and stop when we printed enough lines to fill the screen.
*/
do_offset:
+ if (!nd)
+ return;
+
if (offset > 0) {
do {
h = rb_entry(nd, struct hist_entry, rb_node);
--
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] perf tools: Fix possible double free on error
Hi,
It seems this patch not appeared in any repo, so ping..
On 2015/3/4 20:46, Masami Hiramatsu wrote:
(2015/03/04 19:01), He Kuang wrote:
A double free occurred when get source file path failed. If lr->path
failed to assign a new value, it will be freed as the old path and then
be freed again during line_range__clear(), and causes this:
$ perf probe -L do_execve -k vmlinux
*** Error in `/usr/bin/perf': double free or corruption (fasttop):
0x00a9ac50 ***
=== Backtrace: =
../lib64/libc.so.6(+0x6eeef)[0x75e44eef]
../lib64/libc.so.6(+0x78cae)[0x75e4ecae]
../lib64/libc.so.6(+0x79987)[0x75e4f987]
../bin/perf[0x4ab41f]
...
This patch fix this problem.
Good catch!
Acked-by: Masami Hiramatsu
Thank you,
Signed-off-by: He Kuang
---
tools/perf/util/probe-event.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 919937e..7df30bd 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -650,7 +650,11 @@ static int __show_line_range(struct line_range *lr, const
char *module)
/* Convert source file path */
tmp = lr->path;
ret = get_real_path(tmp, lr->comp_dir, >path);
- free(tmp); /* Free old path */
+
+ /* Free old path when new path is assigned */
+ if (tmp != lr->path)
+ free(tmp);
+
if (ret < 0) {
pr_warning("Failed to find source file path.\n");
return ret;
--
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 0/6] Drivers: hv: Miscellaneous fixes
> -Original Message- > From: KY Srinivasan > Sent: Friday, March 6, 2015 9:20 PM > To: KY Srinivasan; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; vkuzn...@redhat.com > Subject: RE: [PATCH 0/6] Drivers: hv: Miscellaneous fixes > > > > > -Original Message- > > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > > Sent: Friday, March 6, 2015 9:10 PM > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > vkuzn...@redhat.com > > Cc: KY Srinivasan > > Subject: [PATCH 0/6] Drivers: hv: Miscellaneous fixes > > > > This patch-set has miscellaneous fixes for both the VMBUS as well as > > the balloon driver. > > > > Dan Carpenter (1): > > hv: vmbus: missing curly braces in vmbus_process_offer() > > > > K. Y. Srinivasan (2): > > Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl() > > Drivers: hv: vmbus: Perform device register in the per-channel work > > element Greg, the upstream kernel is currently broken on Hyper-V under some configurations and this patch fixes the issue. Please apply. Regards, K. Y > > > > Nick Meier (1): > > Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY > > > > Vitaly Kuznetsov (2): > > Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure > > Drivers: hv: hv_balloon: don't lose memory when onlining order is not > > natural > > Greg, > > Please drop the patch-set; one of the patches I sent was incorrect. I will > resend. > > K. Y > > > > drivers/hv/channel.c |1 + > > drivers/hv/channel_mgmt.c | 146 > +++- > > - > > drivers/hv/connection.c |6 ++- > > drivers/hv/hv_balloon.c | 15 ++--- > > drivers/hv/hyperv_vmbus.h |4 +- > > 5 files changed, 115 insertions(+), 57 deletions(-) > > > > -- > > 1.7.4.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 v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING
Thomas Huth writes: > On Wed, 25 Feb 2015 16:11:27 +0100 > Cornelia Huck wrote: > >> On Wed, 25 Feb 2015 15:36:02 +0100 >> "Michael S. Tsirkin" wrote: >> >> > virtio balloon has this code: >> > wait_event_interruptible(vb->config_change, >> > (diff = towards_target(vb)) != 0 >> > || vb->need_stats_update >> > || kthread_should_stop() >> > || freezing(current)); >> > >> > Which is a problem because towards_target() call might block after >> > wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing >> > the task_struct::state collision typical of nesting of sleeping >> > primitives >> > >> > See also http://lwn.net/Articles/628628/ or Thomas's >> > bug report >> > http://article.gmane.org/gmane.linux.kernel.virtualization/24846 >> > for a fuller explanation. >> > >> > To fix, rewrite using wait_woken. >> > >> > Cc: sta...@vger.kernel.org >> > Reported-by: Thomas Huth >> > Signed-off-by: Michael S. Tsirkin >> > --- >> > >> > changes from v1: >> >remove wait_event_interruptible >> >noticed by Cornelia Huck >> > >> > drivers/virtio/virtio_balloon.c | 19 ++- >> > 1 file changed, 14 insertions(+), 5 deletions(-) >> > >> >> I was able to reproduce Thomas' original problem and can confirm that >> it is gone with this patch. >> >> Reviewed-by: Cornelia Huck > > Right, I just applied the patch on my system, too, and the problem is > indeed gone! Thanks for the quick fix! > > Tested-by: Thomas Huth Applied. Thanks, Rusty. -- 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] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up
On 2015/3/10 10:47, Tim Kryger wrote: > On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox wrote: > >> Ah no - I meant what is their official software workaround for existing >> parts with the bug ? Presumably they have an errata document that >> discusses this and the correct methods they recommend to avoid the >> hang ? > > As far as I know, the only advice they provided was rather naive. > > The documentation I saw suggested stashing a copy of the LCR and then > rewriting it when the special LCR write failed interrupt was raised. > > That approach was not workable as the LCR might be written while the > interrupt is masked causing the sequence of register writes to occur > in an order other than what was desired. > > Additionally, when the LCR needed to be re-written but the UART stayed > busy, the interrupt would keep firing and the driver would starve out > everything else on the CPU. > > The current workaround of clearing fifos and retrying a fixed number > of times isn't ideal but I'm not sure what else can be done given the > way this hardware works. > > Additional background is in c49436b657d0a56a6ad90d14a7c3041add7cf64d > Hi, If writes to the LCR failed and the dev_err in dw8250_serial_out lead to the system hung up. The root cause is that serial8250_console_write try to get port->lock which has been got by serial8250_do_set_termios. "Writes to the LCR are used to change the baud rate, parity, stop bit, or data length so the data that may be lost is likely not important." The dev_err in dw8250_serial_out must be needed? We can delete dev_err directly ? Best regards! > -Tim > > . > -- 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 2/2] livepatch/module: Correctly handle going modules
Petr Mladek writes: > On Sat 2015-03-07 11:34:36, Rusty Russell wrote: >> I don't think you should handle going modules at all. Rarely happens, >> and it should happen fast. > > I would like to handle it correctly. It would be pity to break a system > just because of a module removal. Also the extra overhead will be > very small and it will happen only very rarely. I don't understand why you don't just stop modules. I'm happy to write "int stop_module_changes() / void restart_module_changes()" for you. This is far far simpler. Stop module changes before you start patching. Restart after it's done. Is your intent to apply patches to modules which are applied (long) after the original patch? Or leave that problem to userspace (ie. assume you've updated the on-disk modules)? >> If you can hold the module_lock, the easiest thing to do is have us wake >> module_wq when a module is freed, then you can just: > > Unfortunately, we could not use a waitqueue easily. We would need to > release klp_mutex to do not block going modules. But we could not > do so in the middle of a patch adding. > > BTW: It seems that module_wq is used for coming modules. We could not > use it for coming modules from the same reason. In addition, waiters > are weaken after mod->init(). But we would need to apply the patch > before mod->init() to avoid any inconsistency. You grab the module mutex using stop_module_changes() before anything else. Or are you using the "failed module loading" hack to apply patches? That would imply that the current module would have to be excluded from the stop_module_changes() check, but should still be possible. Cheers, Rusty. -- 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: NMI watchdog triggering during load_balance
On 3/6/15 12:29 PM, Mike Galbraith wrote: On Fri, 2015-03-06 at 11:37 -0700, David Ahern wrote: But, I do not understand how the wrong topology is causing the NMI watchdog to trigger. In the end there are still N domains, M groups per domain and P cpus per group. Doesn't the balancing walk over all of them irrespective of physical topology? You have this size extra large CPU domain that you shouldn't have, massive collisions therein ensue. I was able to get the socket/cores/threads issue resolved, so the topology is correct. But still need to check out a few things. Thanks Mike and Peter for the suggestions. David -- 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: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
> On Mon, 2015-03-09 at 18:52 -0700, Jeff Kirsher wrote: > > On Tue, 2015-03-10 at 01:42 +, Hiroshi Shimamoto wrote: > > > > On 03/08/2015 02:15 PM, Or Gerlitz wrote: > > > > > On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher > > > > > wrote: > > > > > [...] > > > > >> We discussed this during NetConf last week, and Don is correct > > > that a > > > > >> custom sysfs interface is not the way we want to handle this. We > > > agreed > > > > >> upon a generic interface so that any NIC is able to turn on or > > > off VF > > > > >> multicast promiscuous mode. > > > > > > > > > > Jeff, please make sure to either respond to my comments on the V2 > > > > > thread (or better) address them for the V3 post. > > > > > > > > > > > > > > > http://marc.info/?l=linux-netdev=142441852518152=2 > > > > > http://marc.info/?l=linux-netdev=142441867218183=2 > > > > > > > > I agree with you that the patch descriptions should be cleaned up > > > and > > > > "beefed" up for that matter. > > > > > > > > If/when I look to push his series of patches, I will make sure that > > > your > > > > concerns are addressed so that we can get a accurate changelog. > > > > > > I see that the patchset should have better explanation in changelog. > > > I will rewrite it and submit again. > > > > > > Jeff, are you planning to drop the patchset from your tree? > > > I just concerned which tree I should create patches against for. > > > > Yes, I will drop the current patchset in my queue. I am in the process > > of updating my queue, go ahead and make your patches against the > > following tree: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git > > all-queue branch > > > > If you give me an hour or so, I should have my tree updated with all the > > patches in my queue currently. > > Ok, correction on the branch name. After doing some cleanup and future > planning, the following tree: > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git > is what you want to use and the branch name is: > unstable-queue > > The branch has all the patches currently in my queue. OK, now I have the above branch: From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue d7ed747..115403d master -> jeff-next/master * [new branch] unstable-queue -> jeff-next/unstable-queue I will work against that tree. thanks, Hiroshi
RE: [PATCH] drivers: usb: gadget: udc: Fix NULL dereference
> On Tue, Mar 10, 2015 at 02:02:44AM +, Peter Chen wrote:
> >
> > > > --- a/drivers/usb/gadget/udc/lpc32xx_udc.c
> > > > +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
> > > > @@ -1803,7 +1803,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > > > req = container_of(_req, struct lpc32xx_request, req);
> > > > ep = container_of(_ep, struct lpc32xx_ep, ep);
> > > >
> > > > - if (!_req || !_req->complete || !_req->buf ||
> > > > + if (!_ep || !_req || !_req->complete || !_req->buf ||
> > > > !list_empty(>queue))
> > > > return -EINVAL;
> > > >
> > > > @@ -1815,8 +1815,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > > > }
> > > >
> > > >
> > > > - if ((!udc) || (!udc->driver) ||
> > > > - (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > + if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN))
> > > {
> > > > dev_dbg(udc->dev, "invalid device\n");
> > > > return -EINVAL;
> > > > }
> > >
> > > what's going to happen here ?
> > >
> >
> > I just changed the current code, in fact, udc->driver is impossible to
> > NULL which is cleared at .udc_stop.
> >
> > The speed is possible for unknown if the reset has occurred at that time.
>
> oh, alright.
Do you need me or Tapasweni send patch for this?
Peter
--
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] f2fs: fix to truncate inline data past EOF
Hi Chao,
On Tue, Mar 10, 2015 at 10:02:46AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
[snip]
> > > > +static int truncate_partial_data_page(struct inode *inode, u64 from,
> > > > bool force)
> > > > {
> > > > unsigned offset = from & (PAGE_CACHE_SIZE - 1);
> > > > struct page *page;
> > > >
> > > > - if (!offset)
> > > > + if (!offset && !force)
> > >
> > > We truncate on-disk inode page and #0 page separately, so IMO there is a
> > > very
> > > small chance the following issue will occur.
> > >
> > > (0 < truncated_size < MAX_INLINE_SIZE)
> > > ->f2fs_setattr
> > > ->truncate_setsize #0 page has been truncated partially
> > > ->f2fs_truncate
> > > ->truncate_blocks
> > > invalidate #0 page by reclaimer
> > > update #0 page with original data in
> > > inode page by reader
> >
> > truncate_setsize called
> > truncate_pagesize.
> > so #0 page was truncated successfully.
>
> Yeah, but it's partially truncating as 0 < truncated_size < MAX_INLINE_SIZE,
> After truncating, we still keep [0, truncated_size) valid data in #0 page, and
> our #0 page status is uptodate | !dirty.
>
> So what I mean is that mm can reclaim this #0 page, then if someone else read
> the #0 page again, we will update the #0 page with original data in inode page
> since inode page haven't truncated yet.
The truncate_blocks dropped inline_data in inode page, which is modified by
this patch.
And, the cached #0 page was truncated by truncate_setsize.
Even if this page was evicted and reloaded again, the data would be filled with
the inode page having truncated inline_data.
So, it seems there is no problem.
BTW, do you mean like this scenario?
-> f2fs_setattr
->truncate_setsize: #0 page has been truncated partially
->f2fs_truncate
invalidate #0 page by reclaimer
update #0 page with original data in
inode page by reader
->truncate_blocks
(*)-> truncate_inline_inode
(*)-> truncate_partial_data_page(,, force)
find_data_page(,, force) <- we can use *force* here.
Then, I agree that two functions as noted (*) above would be necessary.
>
> If this happened, if we don't truncate #0 page in following code of
> truncate_blocks,
> we will remain the original data for user, it's wrong.
>
> IMO, it's better to truncate inode page and #0 page together, or truncate #0
> page
> in truncate_partial_data_page.
>
> How do you think?
>
> >
> > > ->truncate_inline_inode
> > > ->truncate_partial_data_page
> > > we will fail to truncate #0 page because we can't find valid
> > > blkaddr for
> > > #0 page in find_data_page(,,false)
> > >
> > > How about using find_data_page(,,true) to check weather this page is
> > > update or not
> > > for this condition.
> >
> > Oh, I realized that we don't need to call truncate_partial_data_page, since
> > the
> > cached #0 page was truncated already. We don't care about that.
>
> IMO, we should care about this #0 page if above example can happen.
>
> > So, do we need to add just truncate_inline_inode() like below?
> >
> > >
> > > > return 0;
> > > >
> > > > page = find_data_page(inode, from >> PAGE_CACHE_SHIFT, false);
> > > > @@ -489,6 +489,7 @@ int truncate_blocks(struct inode *inode, u64 from,
> > > > bool lock)
> > > > pgoff_t free_from;
> > > > int count = 0, err = 0;
> > > > struct page *ipage;
> > > > + bool truncate_page = false;
> > > >
> > > > trace_f2fs_truncate_blocks_enter(inode, from);
> > > >
> > > > @@ -504,6 +505,9 @@ int truncate_blocks(struct inode *inode, u64 from,
> > > > bool lock)
> > > > }
> > > >
> > > > if (f2fs_has_inline_data(inode)) {
> > > > + truncate_inline_inode(ipage, from);
> > > > + set_page_dirty(ipage);
> > >
> > > If @from is the same as MAX_INLINE_DATA, we will change nothing in inode
> > > page,
> > > How about skipping set_page_dirty for inode page in this condition?
> >
> > Agreed.
> > How about adding this in truncate_inline_inode?
> >
> > if (from >= MAX_INLINE_DATA)
> > return;
> > ...
> > set_page_dirty(ipage);
>
> Yeah, that's good.
>
> And What I suggest is:
>
> bool truncate_inline_inode(struct page *ipage, u64 from)
> {
> /*
>* we should never truncate inline data past max inline data size,
>* because we always convert inline inode to normal one before
>* truncating real data if new size is past max inline data size.
>*/
> f2fs_bug_on(F2FS_P_SB(ipage), from > MAX_INLINE_DATA);
>
> if (from == MAX_INLINE_DATA)
if (from >= MAX_INLINE_DATA) to handle when f2fs_bug_on is bypassed.
> return false;
> ...
> return true;
> }
>
> in
Re: [PATCH] kprobes/x86: Return correct length in __copy_instruction()
(2015/03/09 20:19), Eugene Shatokhin wrote:
> 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
> fail, register_kprobe() will return -EINVAL.
Oops, good catch!
Acked-by: Masami Hiramatsu
Thank you!
>
> This patch fixes the problem.
>
> Signed-off-by: Eugene Shatokhin
> ---
> arch/x86/kernel/kprobes/core.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 4e3d5a9..03189d8 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -354,6 +354,7 @@ int __copy_instruction(u8 *dest, u8 *src)
> {
> struct insn insn;
> kprobe_opcode_t buf[MAX_INSN_SIZE];
> + int length;
> unsigned long recovered_insn =
> recover_probed_instruction(buf, (unsigned long)src);
>
> @@ -361,16 +362,18 @@ int __copy_instruction(u8 *dest, u8 *src)
> return 0;
> kernel_insn_init(, (void *)recovered_insn, MAX_INSN_SIZE);
> insn_get_length();
> + length = insn.length;
> +
> /* Another subsystem puts a breakpoint, failed to recover */
> if (insn.opcode.bytes[0] == BREAKPOINT_INSTRUCTION)
> return 0;
> - memcpy(dest, insn.kaddr, insn.length);
> + memcpy(dest, insn.kaddr, length);
>
> #ifdef CONFIG_X86_64
> if (insn_rip_relative()) {
> s64 newdisp;
> u8 *disp;
> - kernel_insn_init(, dest, insn.length);
> + kernel_insn_init(, dest, length);
> insn_get_displacement();
> /*
>* The copied instruction uses the %rip-relative addressing
> @@ -394,7 +397,7 @@ int __copy_instruction(u8 *dest, u8 *src)
> *(s32 *) disp = (s32) newdisp;
> }
> #endif
> - return insn.length;
> + return length;
> }
>
> static int arch_copy_kprobe(struct kprobe *p)
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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: nios2: is the ptrace ABI correct?
On Tue, Mar 10, 2015 at 1:05 AM, Ezequiel Garcia
wrote:
>
>
> On 03/09/2015 02:02 PM, Chung-Lin Tang wrote:
>> On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
>>> It appears that some of the ways nios2 has organized the
>>> ucontext/pt_regs/etc. are remnants of the pre-generic code, some
>>> basically because the port was based off m68k.
>>>
>>> I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
>>> deleted, and re-definition of struct sigcontext now allows use of
>>> uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
>>> effectively renaming some fields, is still binary compatible. I'll
>>> probably update the corresponding glibc definitions later.
>>>
>>> struct pt_regs is now not exported, and all exported register sets are
>>> now supposed to follow the 49 register set defined as in GDB now.
>>>
>>> Tobias, Ley Foon, how do you think this looks?
>>
>> Sorry, accidentally attached unrelated GCC patch instead, this one's the
>> correct one.
>>
>
> Looks good. I'm wondering if...
>
> +/* User structures for general purpose registers. */
> +struct user_pt_regs {
> + __u32 regs[49];
> };
>
> Can we expose the registers explicitly here? Like this:
>
> struct user_pt_regs {
> __u32 r0;
> __u32 r1;
> ...
> __u32 sp;
> __u32 gp;
> __u32 estatus;
> };
>
> It looks self-documenting and thus easier to use.
Hi Chung-Lin,
Your patch look good to me.
Do you have any problem to change the struct user_pt_regs based on
Ezequiel's suggestion?
If not, can you please resend the new patch.
Thanks.
Regards
Ley Foon
--
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 1/2] fs proc: make pagemap a privileged interface
On 03/09/2015 05:03 PM, Kees Cook wrote: > On Mon, Mar 9, 2015 at 4:43 PM, Eric W. Biederman > wrote: >> A 1 to 1 blinding function like integer multiplication mudulo 2^32 by an >> appropriate random number ought to keep from revealing page numbers or >> page ajacencies while not requiring any changes in userspace. >> >> That way the revealed pfn and the physcial pfn would be different but >> you could still use pagemap for it's intended purpose. > > If this could be done in a way where it was sufficiently hard to > expose the random number, we should absolutely do this. We would need something which is both reversible (so that the given offsets can still be used in /proc/kpagemap) and also hard to do a known-plaintext-type attack on it. Transparent huge pages are a place where userspace knows the relationship between 512 adjacent physical addresses. That represents a good chunk of known data. Surely there are more of these kinds of things. Right now, for instance, the ways in which a series of sequential allocations come out of the page allocator are fairly deterministic. We would also need to do some kind of allocator randomization to ensure that userspace couldn't make good guesses about the physical addresses of things coming out of the allocator. Or, we just be sure and turn the darn thing off. :) -- 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 3/4] cpufreq: mediatek: add Mediatek cpufreq driver
On 6 March 2015 at 11:19, Pi-Cheng Chen wrote: > On 5 March 2015 at 17:55, Viresh Kumar wrote: > About putting > those stuff into regulator driver, I think you mean creating a > "virtual regulator > device" and put all the voltage controlling complex into the driver, right? > Maybe it's a good idea in this case, but I am sure if this kind of > virtual regulator is acceptable. @Mark: Is this allowed to create virtual regulator for a CPU ? > And the flexibility might be an issue, since we might > use different > PMIC for same SoC on different board. We can talk about that separately once Mark replies to my query. > Combining comments and suggestions from you and Sascha[1], I conclude some > architectural changes are going to be made in the next version: > > 1. Use set_rate hook instead of determine_rate in clk driver, and > switch to intermeidate > PLL parent and back to original CPU PLL parent explicitly in set_rate Lets wait for Russell's answer to the query I posted before making any progress here. -- 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/1] ARM: exynos_defconfig: Disable IOMMU support
On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote: > Hello Inki, > > On 03/06/2015 02:32 PM, Inki Dae wrote: >>> >>> Another interesting data point is that the error in next-20150303 for >>> these 2 boards was the NULL pointer dereference in exynos_plane_destroy >>> that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit. >> >> I think the NULL pointer dereference issue may be fixed with below patch >> I merged to exynos-drm-fixes just a while ago, >> https://lkml.org/lkml/2015/2/17/434 >> >> Could you test it with this patch again? >> > > Thanks, I tested v4.0-rc2 + the patch to disable IOMMU + the patch you > mentioned and the crash does not happen anymore in Peach Pit and Snow. > >>> >>> Another thing that may be useful to detect these issues early is to have >>> exynos-drm-next be pulled by linux-next since otherwise the integration >>> is not tested until the changes are picked by the DRM maintainer. >>> > > I know that I may sound like a broken record but could you please make > sure that your tree is included in linux-next? Got it. I got several requests before. I have created a new branch - exynos-drm/for-next - based on top of drm-next, which would have same patch set as existing exynos-drm-next. I will request Stephen Rothwell to merge remote-tracking branch, 'exynos-drm/for-next'. Thanks, Inki Dae > > That way the fix could be tested by all the machines that are testing > linux-next daily since right now Exynos will still be broken until you > send a pull request to the DRM maintainer. > > So it would be nice to get the changes as soon as possible into -next > to avoid a recurrent error to mask other possible new issues. > > Best regards, > Javier > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
On Mon, 2015-03-09 at 18:52 -0700, Jeff Kirsher wrote: > On Tue, 2015-03-10 at 01:42 +, Hiroshi Shimamoto wrote: > > > On 03/08/2015 02:15 PM, Or Gerlitz wrote: > > > > On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher > > > > wrote: > > > > [...] > > > >> We discussed this during NetConf last week, and Don is correct > > that a > > > >> custom sysfs interface is not the way we want to handle this. We > > agreed > > > >> upon a generic interface so that any NIC is able to turn on or > > off VF > > > >> multicast promiscuous mode. > > > > > > > > Jeff, please make sure to either respond to my comments on the V2 > > > > thread (or better) address them for the V3 post. > > > > > > > > > > > > http://marc.info/?l=linux-netdev=142441852518152=2 > > > > http://marc.info/?l=linux-netdev=142441867218183=2 > > > > > > I agree with you that the patch descriptions should be cleaned up > > and > > > "beefed" up for that matter. > > > > > > If/when I look to push his series of patches, I will make sure that > > your > > > concerns are addressed so that we can get a accurate changelog. > > > > I see that the patchset should have better explanation in changelog. > > I will rewrite it and submit again. > > > > Jeff, are you planning to drop the patchset from your tree? > > I just concerned which tree I should create patches against for. > > Yes, I will drop the current patchset in my queue. I am in the process > of updating my queue, go ahead and make your patches against the > following tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git > all-queue branch > > If you give me an hour or so, I should have my tree updated with all the > patches in my queue currently. Ok, correction on the branch name. After doing some cleanup and future planning, the following tree: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git is what you want to use and the branch name is: unstable-queue The branch has all the patches currently in my queue. signature.asc Description: This is a digitally signed message part
Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up
On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox wrote: > Ah no - I meant what is their official software workaround for existing > parts with the bug ? Presumably they have an errata document that > discusses this and the correct methods they recommend to avoid the > hang ? As far as I know, the only advice they provided was rather naive. The documentation I saw suggested stashing a copy of the LCR and then rewriting it when the special LCR write failed interrupt was raised. That approach was not workable as the LCR might be written while the interrupt is masked causing the sequence of register writes to occur in an order other than what was desired. Additionally, when the LCR needed to be re-written but the UART stayed busy, the interrupt would keep firing and the driver would starve out everything else on the CPU. The current workaround of clearing fifos and retrying a fixed number of times isn't ideal but I'm not sure what else can be done given the way this hardware works. Additional background is in c49436b657d0a56a6ad90d14a7c3041add7cf64d -Tim -- 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/
Vinder No. 009
Vinder No. 009, Det er indlysende, at denne meddelelse vil komme til dig som en overraskelse, men du finde tid til at læse det omhyggeligt, som vi lykønsker dig over din succes i følgende officielle offentliggørelse af resultaterne af e-mail elektroniske online-konkurrencer arrangeret af Microsoft Corporation, sammenholdt med grundlaget for fremme af software produkter, (FPS) afholdt i Amsterdam-Holland. En betaling på 815.810.00 euro (otte hundrede og femten tusinde, otte hundrede og kun ti euro) vil blive udbetalt i dit navn. Det er vigtigt at bemærke, at din tildeling blev frigivet med følgende oplysninger, der er knyttet til den. (1) Fil nummer: MS1267-2015 (2) Tilskud nummer: MIWT / 11846563459/266 (3) Ref. Kode: KB23 / 857 / MCL5 / CO Videresend Ovenstående oplysninger, jf til Microsoft Agency NL. Microsoft Group Agency NL: Instruktør: Dr.David Bengal Kontakt E-mail: msoftagenc...@gmail.com Snart som ovenstående oplysninger er modtaget via e-mail til: msoftagenc...@gmail.com, vil din betaling blive behandlet og udbetalt til dig. Med venlig hilsen Mrs. Angela Banks -- 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: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/edp/edp_ctrl.c: In function 'edp_regulator_enable':
drivers/gpu/drm/msm/edp/edp_ctrl.c:335:2: error: implicit declaration of
function 'regulator_set_optimum_mode' [-Werror=implicit-function-declaration]
ret = regulator_set_optimum_mode(ctrl->vdda_vreg, VDDA_UA_ON_LOAD);
^
Caused by commits e39ce48f5362 ("regulator: Rename
regulator_set_optimum_mode") and ae6e808f1574 ("regulator: Drop
temporary regulator_set_optimum_mode wrapper") interacting with commit
ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver
(v5)") from Linus' tree (in v4.0-rc1) tree.
There was another use of regulator_set_optimum_mode() in
drivers/phy/phy-qcom-ufs.c (introduced by commit adaafaa393ef ("phy:
qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers") also
from v4.0-rc1) which I also fixed in the patch below.
grep is your friend ...
This patch should be applied to your tree as it is based off v4.0-rc1
already.
From: Stephen Rothwell
Date: Tue, 10 Mar 2015 13:35:59 +1100
Subject: [PATCH] fixes for regulator_set_optimum_mode name change
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 6 +++---
drivers/phy/phy-qcom-ufs.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 3e246210c46f..0ec5abdba5c4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -332,7 +332,7 @@ static int edp_regulator_enable(struct edp_ctrl *ctrl)
goto vdda_set_fail;
}
- ret = regulator_set_optimum_mode(ctrl->vdda_vreg, VDDA_UA_ON_LOAD);
+ ret = regulator_set_load(ctrl->vdda_vreg, VDDA_UA_ON_LOAD);
if (ret < 0) {
pr_err("%s: vdda_vreg set regulator mode failed.\n", __func__);
goto vdda_set_fail;
@@ -356,7 +356,7 @@ static int edp_regulator_enable(struct edp_ctrl *ctrl)
lvl_enable_fail:
regulator_disable(ctrl->vdda_vreg);
vdda_enable_fail:
- regulator_set_optimum_mode(ctrl->vdda_vreg, VDDA_UA_OFF_LOAD);
+ regulator_set_load(ctrl->vdda_vreg, VDDA_UA_OFF_LOAD);
vdda_set_fail:
return ret;
}
@@ -365,7 +365,7 @@ static void edp_regulator_disable(struct edp_ctrl *ctrl)
{
regulator_disable(ctrl->lvl_vreg);
regulator_disable(ctrl->vdda_vreg);
- regulator_set_optimum_mode(ctrl->vdda_vreg, VDDA_UA_OFF_LOAD);
+ regulator_set_load(ctrl->vdda_vreg, VDDA_UA_OFF_LOAD);
}
static int edp_gpio_config(struct edp_ctrl *ctrl)
diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
index 44ee983d57fe..86665e9dc399 100644
--- a/drivers/phy/phy-qcom-ufs.c
+++ b/drivers/phy/phy-qcom-ufs.c
@@ -346,10 +346,10 @@ int ufs_qcom_phy_cfg_vreg(struct phy *phy,
goto out;
}
uA_load = on ? vreg->max_uA : 0;
- ret = regulator_set_optimum_mode(reg, uA_load);
+ ret = regulator_set_load(reg, uA_load);
if (ret >= 0) {
/*
-* regulator_set_optimum_mode() returns new regulator
+* regulator_set_load() returns new regulator
* mode upon success.
*/
ret = 0;
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp8YjRzbgxPF.pgp
Description: OpenPGP digital signature
Re: [PATCH] rds: avoid potential stack overflow
From: Arnd Bergmann Date: Mon, 09 Mar 2015 13:06:52 +0100 > The rds_iw_add_conn function stores a large 'struct rds_sock' object > on the stack in order to pass a pair of addresses. As Sowmini pointed out, this function is not the top-level guilty one, it's rds_iw_update_cm_id. Please respin this with a corrected commit message, 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] drivers: usb: gadget: udc: Fix NULL dereference
On Tue, Mar 10, 2015 at 02:02:44AM +, Peter Chen wrote:
>
> > > --- a/drivers/usb/gadget/udc/lpc32xx_udc.c
> > > +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
> > > @@ -1803,7 +1803,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > > req = container_of(_req, struct lpc32xx_request, req);
> > > ep = container_of(_ep, struct lpc32xx_ep, ep);
> > >
> > > - if (!_req || !_req->complete || !_req->buf ||
> > > + if (!_ep || !_req || !_req->complete || !_req->buf ||
> > > !list_empty(>queue))
> > > return -EINVAL;
> > >
> > > @@ -1815,8 +1815,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > > }
> > >
> > >
> > > - if ((!udc) || (!udc->driver) ||
> > > - (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > + if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN))
> > {
> > > dev_dbg(udc->dev, "invalid device\n");
> > > return -EINVAL;
> > > }
> >
> > what's going to happen here ?
> >
>
> I just changed the current code, in fact, udc->driver is impossible to NULL
> which
> is cleared at .udc_stop.
>
> The speed is possible for unknown if the reset has occurred at that time.
oh, alright.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
On 03/09/2015 05:19 PM, Andy Lutomirski wrote: > per-pidns like this is no good. You shouldn't be able to create a > non-paranoid pidns if your parent is paranoid. That sounds like a reasonable addition that shouldn't be hard to add. > Also, at some point we need actual per-ns controls. This mount option > stuff is hideous. So, per-pidns == bad per-ns == good If the pid namespace is the wrong place, which namespace is the right place? -- 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 v9 01/21] ACPI / table: Use pr_debug() instead of pr_info() for MADT table scanning
On 2015年03月07日 04:31, Joe Perches wrote:
On Fri, 2015-03-06 at 20:17 +, Grant Likely wrote:
On Wed, 25 Feb 2015 16:39:41 +0800 Hanjun Guo wrote:
This patch just use pr_debug() instead of pr_info() for ioapic/iosapic,
local apic/x2apic/sapic structures when scanning the MADT table to remove
those verbose information, but leave other structures unchanged.
[]
One nitpick below, but don't respin over this, and don't do a fixup.
[]
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
[]
@@ -61,9 +63,9 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header
*header)
{
struct acpi_madt_local_apic *p =
(struct acpi_madt_local_apic *)header;
- pr_info("LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] %s)\n",
- p->processor_id, p->id,
- (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" :
"disabled");
+ pr_debug("LAPIC (acpi_id[0x%02x] lapic_id[0x%02x]
%s)\n",
+p->processor_id, p->id,
+(p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" :
"disabled");
The whitespace changes makes each 1 line change into 3 line changes. In
these situations, I would chose to leave the whitespace alone to keep
the diffstat as small as possible. It makes it less likely to conflict
with other patches and easier to find context.
I think it's mostly better to use a consistent indentation style
regardless of the number in whitespace changes surrounding the change.
I think both would be fine. Since this patch only touches acpi core
code and ACPI maintainer Rafael already acked it, I will keep it as
it is.
Thanks
Hanjun
--
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/1] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()
When a channel has been rescinded, the close operation is a noop.
Restructure the code so we deal with the rescind condition after
we properly cleanup the channel. I would like to thank
Dexuan Cui for observing this problem.
The current code leaks memory when the channel is rescinded.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index e58cdb7..fddd3b5 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -501,15 +501,6 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
put_cpu();
}
- /*
-* If the channel has been rescinded; process device removal.
-*/
- if (channel->rescind) {
- hv_process_channel_removal(channel,
- channel->offermsg.child_relid);
- return 0;
- }
-
/* Send a closing message */
msg = >close_msg.msg;
@@ -549,6 +540,12 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
free_pages((unsigned long)channel->ringbuffer_pages,
get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
+ /*
+* If the channel has been rescinded; process device removal.
+*/
+ if (channel->rescind)
+ hv_process_channel_removal(channel,
+ channel->offermsg.child_relid);
return ret;
}
--
1.7.4.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 3/3] scsi: storvsc: Enable clustering
Signed-off-by: K. Y. Srinivasan
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index a36c232..d7ebf00 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1693,7 +1693,7 @@ static struct scsi_host_template scsi_driver = {
.slave_configure = storvsc_device_configure,
.cmd_per_lun = 255,
.this_id = -1,
- .use_clustering = DISABLE_CLUSTERING,
+ .use_clustering = ENABLE_CLUSTERING,
/* Make sure we dont get a sg segment crosses a page boundary */
.dma_boundary = PAGE_SIZE-1,
.no_write_same =1,
--
1.7.4.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 1/3] scsi: storvsc: Retrieve information about the capability of the target
The storage protocol informs the guest of the I/O capabilities of the storage
stack. Retrieve this information and use it in the guest.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
---
drivers/scsi/storvsc_drv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index be8f12e..5c13eec 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,10 @@ struct storvsc_device {
unsigned char path_id;
unsigned char target_id;
+ /*
+* Max I/O, the device can support.
+*/
+ u32 max_transfer_bytes;
/* Used for vsc/vsp channel reset process */
struct storvsc_cmd_request init_request;
struct storvsc_cmd_request reset_request;
@@ -974,6 +978,8 @@ static int storvsc_channel_init(struct hv_device *device)
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
process_sub_channels = true;
}
+ stor_device->max_transfer_bytes =
+ vstor_packet->storage_channel_properties.max_transfer_bytes;
memset(vstor_packet, 0, sizeof(struct vstor_packet));
vstor_packet->operation = VSTOR_OPERATION_END_INITIALIZATION;
--
1.7.4.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 2/3] scsi: storvsc: Set the tablesize based on the information given by the host
Set the tablesize based on what the host has informed us.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
---
drivers/scsi/storvsc_drv.c | 70 ++-
1 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 5c13eec..a36c232 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -351,7 +351,10 @@ struct storvsc_cmd_request {
/* Synchronize the request/response if needed */
struct completion wait_event;
- struct hv_multipage_buffer data_buffer;
+ struct vmbus_channel_packet_multipage_buffer mpb;
+ struct vmbus_packet_mpb_array *payload;
+ u32 payload_sz;
+
struct vstor_packet vstor_packet;
};
@@ -1119,10 +1122,14 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
sense_hdr.ascq);
scsi_set_resid(scmnd,
- cmd_request->data_buffer.len -
+ cmd_request->payload->range.len -
vm_srb->data_transfer_length);
scmnd->scsi_done(scmnd);
+
+ if (cmd_request->payload_sz >
+ sizeof(struct vmbus_channel_packet_multipage_buffer))
+ kfree(cmd_request->payload);
}
static void storvsc_on_io_completion(struct hv_device *device,
@@ -1324,7 +1331,7 @@ static int storvsc_dev_remove(struct hv_device *device)
}
static int storvsc_do_io(struct hv_device *device,
- struct storvsc_cmd_request *request)
+struct storvsc_cmd_request *request)
{
struct storvsc_device *stor_device;
struct vstor_packet *vstor_packet;
@@ -1356,13 +1363,14 @@ static int storvsc_do_io(struct hv_device *device,
vstor_packet->vm_srb.data_transfer_length =
- request->data_buffer.len;
+ request->payload->range.len;
vstor_packet->operation = VSTOR_OPERATION_EXECUTE_SRB;
- if (request->data_buffer.len) {
- ret = vmbus_sendpacket_multipagebuffer(outgoing_channel,
- >data_buffer,
+ if (request->payload->range.len) {
+
+ ret = vmbus_sendpacket_mpb_desc(outgoing_channel,
+ request->payload, request->payload_sz,
vstor_packet,
(sizeof(struct vstor_packet) -
vmscsi_size_delta),
@@ -1535,6 +1543,10 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
struct scatterlist *sgl;
unsigned int sg_count = 0;
struct vmscsi_request *vm_srb;
+ struct vmbus_packet_mpb_array *payload;
+ u32 payload_sz;
+ u32 pfn_cnt;
+ u32 length;
if (vmstor_current_major <= VMSTOR_WIN8_MAJOR) {
/*
@@ -1588,7 +1600,11 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
memcpy(vm_srb->cdb, scmnd->cmnd, vm_srb->cdb_length);
- cmd_request->data_buffer.len = scsi_bufflen(scmnd);
+ sgl = (struct scatterlist *)scsi_sglist(scmnd);
+ length = scsi_bufflen(scmnd);
+ payload = (struct vmbus_packet_mpb_array *)_request->mpb;
+ payload_sz = sizeof(cmd_request->mpb);
+
if (scsi_sg_count(scmnd)) {
sgl = (struct scatterlist *)scsi_sglist(scmnd);
sg_count = scsi_sg_count(scmnd);
@@ -1615,19 +1631,40 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
sg_count = cmd_request->bounce_sgl_count;
}
- cmd_request->data_buffer.offset = sgl[0].offset;
+ pfn_cnt = DIV_ROUND_UP(sgl[0].offset + length, PAGE_SIZE);
+
+ if (pfn_cnt > MAX_PAGE_BUFFER_COUNT) {
+
+ payload_sz = (pfn_cnt * sizeof(void *) +
+ sizeof(struct vmbus_packet_mpb_array));
+ payload = kzalloc(payload_sz, GFP_ATOMIC);
+ if (!payload) {
+ if (cmd_request->bounce_sgl_count)
+ destroy_bounce_buffer(
+ cmd_request->bounce_sgl,
+ cmd_request->bounce_sgl_count);
+
+ return SCSI_MLQUEUE_DEVICE_BUSY;
+ }
+ }
+
+ payload->range.len = length;
+ payload->range.offset = sgl[0].offset;
for (i = 0; i < sg_count; i++)
- cmd_request->data_buffer.pfn_array[i] =
+ payload->range.pfn_array[i] =
page_to_pfn(sg_page(([i])));
} else if (scsi_sglist(scmnd)) {
- cmd_request->data_buffer.offset =
+ payload->range.len = length;
+
Re: [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface
On 03/09/2015 04:08 PM, Eric W. Biederman wrote: > If the concern is to protect against root getting into the kernel the > "trusted_kernel" snake-oil just compile out the pagemap file. Nothing > else is remotely interesting from a mainenance point of view. The paper I linked to showed one example of how pagemap makes a user->kernel exploint _easier_. Note that the authors had another way of actually doing the exploit when pagemap was not available, but it required some more trouble than if pagemap was around. I mentioned the "trusted_kernel" stuff as an aside. It's really not the main concern. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] scsi: storvsc: Increase the tablesize based on host's capabilities
Presently, storvsc limits the I/O size arbitrarily. Make this configurable based on what the host advertises. K. Y. Srinivasan (3): scsi: storvsc: Retrieve information about the capability of the target scsi: storvsc: Set the tablesize based on the information given by the host scsi: storvsc: Enable clustering drivers/scsi/storvsc_drv.c | 78 +++- 1 files changed, 62 insertions(+), 16 deletions(-) -- 1.7.4.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 v2] thermal: exynos: Add the support for Exynos5433 TMU
This patch adds the support for Exynos5433's TMU (Thermal Management Unit).
Exynos5433 has a little different register bit fields as following description:
- Support the eight trip points for rising/falling interrupt by using two
registers
- Read the calibration type (1-point or 2-point) and sensor id from TRIMINFO
register
- Use a little different register address
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Lukasz Majewski
Signed-off-by: Chanwoo Choi
---
Changes from v1:
(https://lkml.org/lkml/2015/2/26/234)
- Add exynos5433_tmu_control() instead of using exynos7_tmu_control() on both
Exynos5433 and Exynos7.
- Separate the patches related to devicetree and then send send Exnos5433's tmu
patches[1] with other Exynos5433 devicetree patches.
[1] https://lkml.org/lkml/2015/3/9/1036
drivers/thermal/samsung/exynos_tmu.c | 187 ++-
drivers/thermal/samsung/exynos_tmu.h | 1 +
2 files changed, 186 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 1d30b09..531f4b17 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -97,6 +97,32 @@
#define EXYNOS4412_MUX_ADDR_VALUE 6
#define EXYNOS4412_MUX_ADDR_SHIFT 20
+/* Exynos5433 specific registers */
+#define EXYNOS5433_TMU_REG_CONTROL10x024
+#define EXYNOS5433_TMU_SAMPLING_INTERVAL 0x02c
+#define EXYNOS5433_TMU_COUNTER_VALUE0 0x030
+#define EXYNOS5433_TMU_COUNTER_VALUE1 0x034
+#define EXYNOS5433_TMU_REG_CURRENT_TEMP1 0x044
+#define EXYNOS5433_THD_TEMP_RISE3_00x050
+#define EXYNOS5433_THD_TEMP_RISE7_40x054
+#define EXYNOS5433_THD_TEMP_FALL3_00x060
+#define EXYNOS5433_THD_TEMP_FALL7_40x064
+#define EXYNOS5433_TMU_REG_INTEN 0x0c0
+#define EXYNOS5433_TMU_REG_INTPEND 0x0c8
+#define EXYNOS5433_TMU_EMUL_CON0x110
+#define EXYNOS5433_TMU_PD_DET_EN 0x130
+
+#define EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT16
+#define EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT23
+#define EXYNOS5433_TRIMINFO_SENSOR_ID_MASK \
+ (0xf << EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT)
+#define EXYNOS5433_TRIMINFO_CALIB_SEL_MASK BIT(23)
+
+#define EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING 0
+#define EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING 1
+
+#define EXYNOS5433_PD_DET_EN 1
+
/*exynos5440 specific registers*/
#define EXYNOS5440_TMU_S0_7_TRIM 0x000
#define EXYNOS5440_TMU_S0_7_CTRL 0x020
@@ -484,6 +510,101 @@ out:
return ret;
}
+static int exynos5433_tmu_initialize(struct platform_device *pdev)
+{
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ struct exynos_tmu_platform_data *pdata = data->pdata;
+ struct thermal_zone_device *tz = data->tzd;
+ unsigned int status, trim_info;
+ unsigned int rising_threshold = 0, falling_threshold = 0;
+ unsigned long temp, temp_hist;
+ int ret = 0, threshold_code, i, sensor_id, cal_type;
+
+ status = readb(data->base + EXYNOS_TMU_REG_STATUS);
+ if (!status) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
+ sanitize_temp_error(data, trim_info);
+
+ /* Read the temperature sensor id */
+ sensor_id = (trim_info & EXYNOS5433_TRIMINFO_SENSOR_ID_MASK)
+ >> EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT;
+ dev_info(>dev, "Temperature sensor ID: 0x%x\n", sensor_id);
+
+ /* Read the calibration mode */
+ writel(trim_info, data->base + EXYNOS_TMU_REG_TRIMINFO);
+ cal_type = (trim_info & EXYNOS5433_TRIMINFO_CALIB_SEL_MASK)
+ >> EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT;
+
+ switch (cal_type) {
+ case EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING:
+ pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
+ break;
+ case EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING:
+ pdata->cal_type = TYPE_TWO_POINT_TRIMMING;
+ break;
+ default:
+ pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
+ break;
+ };
+
+ dev_info(>dev, "Calibration type is %d-point calibration\n",
+ cal_type ? 2 : 1);
+
+ /* Write temperature code for rising and falling threshold */
+ for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+ int rising_reg_offset, falling_reg_offset;
+ int j = 0;
+
+ switch (i) {
+ case 0:
+ case 1:
+ case 2:
+ case 3:
+ rising_reg_offset = EXYNOS5433_THD_TEMP_RISE3_0;
+ falling_reg_offset = EXYNOS5433_THD_TEMP_FALL3_0;
+ j = i;
+ break;
+ case
RE: [PATCH] drivers: usb: gadget: udc: Fix NULL dereference
> > --- a/drivers/usb/gadget/udc/lpc32xx_udc.c
> > +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
> > @@ -1803,7 +1803,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > req = container_of(_req, struct lpc32xx_request, req);
> > ep = container_of(_ep, struct lpc32xx_ep, ep);
> >
> > - if (!_req || !_req->complete || !_req->buf ||
> > + if (!_ep || !_req || !_req->complete || !_req->buf ||
> > !list_empty(>queue))
> > return -EINVAL;
> >
> > @@ -1815,8 +1815,7 @@ static int lpc32xx_ep_queue(struct usb_ep *_ep,
> > }
> >
> >
> > - if ((!udc) || (!udc->driver) ||
> > - (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > + if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN))
> {
> > dev_dbg(udc->dev, "invalid device\n");
> > return -EINVAL;
> > }
>
> what's going to happen here ?
>
I just changed the current code, in fact, udc->driver is impossible to NULL
which
is cleared at .udc_stop.
The speed is possible for unknown if the reset has occurred at that time.
Peter
--
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] f2fs: fix to truncate inline data past EOF
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, March 10, 2015 12:16 AM
> To: Chao Yu
> Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] f2fs: fix to truncate inline data past EOF
>
> Hi Chao,
>
> On Mon, Mar 09, 2015 at 04:30:32PM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Monday, March 09, 2015 11:49 AM
> > > To: Chao Yu
> > > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH] f2fs: fix to truncate inline data past EOF
> > >
> > > Hi Chao,
> > >
> > >
> > > On Mon, Mar 09, 2015 at 10:24:35AM +0800, Chao Yu wrote:
> > > > Hi Jaegeuk,
> > > >
> > > > > -Original Message-
> > > > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > > > Sent: Friday, March 06, 2015 5:34 AM
> > > > > To: Chao Yu
> > > > > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> > > > > linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH] f2fs: fix to truncate inline data past EOF
> > > > >
> > > > > Hi Chao,
> > > > >
> > > > > On Thu, Mar 05, 2015 at 05:41:32PM +0800, Chao Yu wrote:
> > > > > > Previously if inode is with inline data, we will try to invalid
> > > > > > partial inline
> > > > > > data in page #0 when we truncate size of inode in
> > > > > > truncate_partial_data_page().
> > > > > > And then we set page #0 to dirty, after this we can synchronize
> > > > > > inode page with
> > > > > > page #0 at ->writepage().
> > > > > >
> > > > > > But sometimes we will fail to operate page #0 in
> > > > > > truncate_partial_data_page()
> > > > > > due to below reason:
> > > > > > a) if offset is zero, we will skip setting page #0 to dirty.
> > > > > > b) if page #0 is not uptodate, we will fail to update it as it has
> > > > > > no mapping
> > > > > > data.
> > > > > >
> > > > > > So with following operations, we will meet recent data which should
> > > > > > be
> > > > > > truncated.
> > > > > >
> > > > > > 1.write inline data to file
> > > > > > 2.sync first data page to inode page
> > > > > > 3.truncate file size to 0
> > > > > > 4.truncate file size to max_inline_size
> > > > > > 5.echo 1 > /proc/sys/vm/drop_caches
> > > > > > 6.read file --> meet original inline data which is remained in
> > > > > > inode page.
> > > > > >
> > > > > > This patch renames truncate_inline_data() to
> > > > > > truncate_inline_inode() for code
> > > > > > readability, then intruduces new truncate_inline_data() and use it
> > > > > > to truncate
> > > > > > inline data in page #0 and inode page in
> > > > > > truncate_partial_data_page() for
> > > > > > fixing.
> > > > > >
> > > > > > Signed-off-by: Chao Yu
> > > > > > ---
> > > > > > fs/f2fs/f2fs.h | 1 +
> > > > > > fs/f2fs/file.c | 13 -
> > > > > > fs/f2fs/inline.c | 57
> > > > > > +++-
> > > > > > 3 files changed, 61 insertions(+), 10 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > > > > index 511d6cd..55dbbe7 100644
> > > > > > --- a/fs/f2fs/f2fs.h
> > > > > > +++ b/fs/f2fs/f2fs.h
> > > > > > @@ -1754,6 +1754,7 @@ extern struct kmem_cache *inode_entry_slab;
> > > > > > */
> > > > > > bool f2fs_may_inline(struct inode *);
> > > > > > void read_inline_data(struct page *, struct page *);
> > > > > > +int truncate_inline_data(struct inode *, u64 from);
> > > > > > int f2fs_read_inline_data(struct inode *, struct page *);
> > > > > > int f2fs_convert_inline_page(struct dnode_of_data *, struct page
> > > > > > *);
> > > > > > int f2fs_convert_inline_inode(struct inode *);
> > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > > > index f1341c7..6c4443e 100644
> > > > > > --- a/fs/f2fs/file.c
> > > > > > +++ b/fs/f2fs/file.c
> > > > > > @@ -461,6 +461,9 @@ static int truncate_partial_data_page(struct
> > > > > > inode *inode, u64
> from)
> > > > > > unsigned offset = from & (PAGE_CACHE_SIZE - 1);
> > > > > > struct page *page;
> > > > > >
> > > > > > + if (f2fs_has_inline_data(inode))
> > > > > > + return 0;
> > > > > > +
> > > > > > if (!offset)
> > > > > > return 0;
> > > > > >
> > > > > > @@ -497,14 +500,14 @@ int truncate_blocks(struct inode *inode, u64
> > > > > > from, bool lock)
> > > > > > if (lock)
> > > > > > f2fs_lock_op(sbi);
> > > > > >
> > > > > > - ipage = get_node_page(sbi, inode->i_ino);
> > > > > > - if (IS_ERR(ipage)) {
> > > > > > - err = PTR_ERR(ipage);
> > > > > > + if (f2fs_has_inline_data(inode)) {
> > > > > > + err = truncate_inline_data(inode, from);
> > > > > > goto out;
> > > > > > }
> > > > > >
> > > > > > - if (f2fs_has_inline_data(inode)) {
> > > > > > - f2fs_put_page(ipage, 1);
> > > > > > + ipage =
Re: [PATCH 0/5] [GIT PULL] seq-buf/ftrace: Various fixes
On Mon, 9 Mar 2015 18:43:54 -0700 Linus Torvalds wrote: > Oh. Ok. I didn't pull that, simply because in the same thread you said > you were going to fix the other case that Joe pointed out and you said > "I'll make another patch". So I dismissed your previous pull request > as premature.. Yeah I figured as much. But right after I did that fix, the other bug was reported to me. I decided to fix that bug before posting again, and that took a bit longer than I expected. Sorry for the confusion, I didn't explain it very well. I should have stated this is the new update to my previous pull request with another bug fix included as well. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
sound/soc/codecs/rt5670.c: In function 'is_sys_clk_from_pll':
sound/soc/codecs/rt5670.c:519:38: error: 'struct snd_soc_dapm_widget' has no
member named 'codec'
struct snd_soc_codec *codec = source->codec;
^
Caused by commit 485372dc24ca ("ASoC: rt5670: Check sysclk source by
private data")?
sound/soc/codecs/rt5670.c: In function 'rt5670_set_dai_sysclk':
sound/soc/codecs/rt5670.c:2272:1: error: expected expression before '<<' token
<<< HEAD
^
sound/soc/codecs/rt5670.c:2284:1: error: expected expression before '>>' token
>>> v4.0-rc3
^
Oops :-(
I have used the cound-asoc tree from next-20150306 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpuwZTX5C3DP.pgp
Description: OpenPGP digital signature
[PATCH v6 3/9] arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
This patch adds SPI (Serial Peripheral Interface) dt node for Exynos5433 SoC.
SPI transfers serial data by using various peripherals. SPI includes
8-bit/16-bit/32-bit shift registers to transmit and receive data. PDMA is used
for SPI communication.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 114 +
1 file changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 5807f71..cc166c0 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -399,6 +399,35 @@
interrupts = <1 9 0xf04>;
};
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma0: pdma@1561 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1561 0x1000>;
+ interrupts = <0 228 0>;
+ clocks = <_fsys CLK_PDMA0>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+
+ pdma1: pdma@1560 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1560 0x1000>;
+ interrupts = <0 246 0>;
+ clocks = <_fsys CLK_PDMA1>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+ };
+
serial_0: serial@14c1 {
compatible = "samsung,exynos5433-uart";
reg = <0x14c1 0x100>;
@@ -499,6 +528,91 @@
interrupts = <0 442 0>;
};
+ spi_0: spi@14d2 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d2 0x100>;
+ interrupts = <0 432 0>;
+ dmas = < 9>, < 8>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI0>,
+<_top CLK_SCLK_SPI0_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_1: spi@14d3 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d3 0x100>;
+ interrupts = <0 433 0>;
+ dmas = < 11>, < 10>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI1>,
+<_top CLK_SCLK_SPI1_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_2: spi@14d4 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d4 0x100>;
+ interrupts = <0 434 0>;
+ dmas = < 13>, < 12>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI2>,
+<_top CLK_SCLK_SPI2_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_3: spi@14d5 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d5 0x100>;
+ interrupts = <0 447 0>;
+ dmas = < 23>, < 22>;
+ dma-names =
[PATCHv v6 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
2. clock controller node:
- CMU_TOP : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF : clocks for LLI (Low Latency Interface)
- CMU_MIF : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D : clocks for G2D/MDMA
- CMU_DISP : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D : clocks for 3D Graphics Engine
- CMU_GSCL : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
CoreSight and L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
3. pinctrl node for GPIO:
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad
4. HS (High-Speed) I2C device
5. Serial device
6. ARCH timer (arm,armv8-timer)
7. Interrupt controller (arm,gic-400)
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 669
2 files changed, 1367 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index 000..c56bbf8
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,698 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+_aud {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ i2s0_bus: i2s0-bus {
+ samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
+ "gpz0-4", "gpz0-5", "gpz0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm0_bus: pcm0-bus {
+ samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
+ samsung,pin-function = <3>;
+ samsung,pin-pud =
[PATCH v6 5/9] arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
This patch adds RTC (Real Time Clock) dt node for Exynos5433 SoC and adds
ADC dt node for Exynos5433 SoC. The c1b501564c98a94b4(iio: adc: exynos_adc:
Add support for exynos7) commit supports the ADC for Exynos7. Exynos5433's ADC
IP is the same with Exynos7's ADC IP. Exynos5433 has a little different from
ADCv2 on ADC_CON2 register. Exynos5433 don't contain OSEL/ESEL /HIGHF of
ADC_CON2.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index fa27bb8..99aa51e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -815,6 +815,24 @@
clock-names = "clkout16";
clocks = <>;
};
+
+ rtc: rtc@1059 {
+ compatible = "samsung,exynos3250-rtc";
+ reg = <0x1059 0x100>;
+ interrupts = <0 385 0>, <0 386 0>;
+ status = "disabled";
+ };
+
+ adc: adc@14d1 {
+ compatible = "samsung,exynos7-adc";
+ reg = <0x14d1 0x100>;
+ interrupts = <0 438 0>;
+ clock-names = "adc";
+ clocks = <_peric CLK_PCLK_ADCIF>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
};
timer {
--
1.8.5.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 v6 2/9] arm64: dts: exynos: Add MSHC dt node for Exynos5433
From: Jaehoon Chung
This patch adds MSHC (Mobile Storage Host Controller) dt node for Exynos5433
SoC. MSHC is an interface between the system the SD/MMC card.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Jaehoon Chung
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7c3488a..5807f71 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -655,6 +655,44 @@
status = "disabled";
};
+ mshc_0: mshc@1554 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 225 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1554 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC0>,
+<_fsys CLK_SCLK_MMC0>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_1: mshc@1555 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 226 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1555 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC1>,
+<_fsys CLK_SCLK_MMC1>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_2: mshc@1556 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 227 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1556 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC2>,
+<_fsys CLK_SCLK_MMC2>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
};
timer {
--
1.8.5.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 v6 6/9] arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
From: Inha Song
This patch adds ADMA (Advanced DMA) device tree node for Exynos5433 SoC.
In Exynos5433 SoC, ADMA is used for I2S audio interface.
Cc: Kukjin Kim
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 99aa51e..23d9018 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -426,6 +426,17 @@
#dma-channels = <8>;
#dma-requests = <32>;
};
+
+ adma: adma@1142 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1142 0x1000>;
+ interrupts = <0 73 0>;
+ clocks = <_aud CLK_ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
};
serial_0: serial@14c1 {
--
1.8.5.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 v6 8/9] arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
This patch adds the TMU (Thermal Management Unit) sensor devicetree node for
Exynos5433. The Exynos5433 includes the five temperature sensors as following:
- two temperature sensor for Cortex-A57 (ATLAS)
- one temperature sensor for Cortex-A53 (APOLLO)
- one temperature sensor for G3D IP
- one temperature sensor for ISP IP
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Lukasz Majewski
---
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 55 ++
2 files changed, 77 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
new file mode 100644
index 000..396e60f
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
@@ -0,0 +1,22 @@
+/*
+ * Device tree sources for Exynos5433 TMU sensor configuration
+ *
+ * Copyright (c) 2015 Chanwoo Choi
+ *
+ * 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
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <8>;
+samsung,tmu_reference_voltage = <16>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <75>;
+samsung,tmu_min_efuse_value = <40>;
+samsung,tmu_max_efuse_value = <150>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index fea4e32..22f36f5 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -836,6 +836,61 @@
status = "disabled";
};
+ tmu_atlas0: tmu@1006 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1006 0x200>;
+ interrupts = <0 95 0>;
+ clocks = <_peris CLK_PCLK_TMU0_APBIF>,
+<_peris CLK_SCLK_TMU0>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_atlas1: tmu@10068000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x10068000 0x200>;
+ interrupts = <0 96 0>;
+ clocks = <_peris CLK_PCLK_TMU0_APBIF>,
+<_peris CLK_SCLK_TMU0>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_g3d: tmu@1007 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1007 0x200>;
+ interrupts = <0 99 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_apollo: tmu@10078000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x10078000 0x200>;
+ interrupts = <0 115 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_isp: tmu@1007c000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1007c000 0x200>;
+ interrupts = <0 94 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
pmu_system_controller: system-controller@105c {
compatible = "samsung,exynos5433-pmu", "syscon";
reg = <0x105c 0x5008>;
--
1.8.5.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 v6 4/9] arm64: dts: exynos: Add PMU dt node for Exynos5433
This patch adds PMU (Power Management Unit) dt node for Exynos5433 SoC and
set the source clock for CLKOUT register as xxti .
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
[ideal.song: Add the setting of CLKOUT register]
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi| 8
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 67b2113..a87fc43 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+ - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index cc166c0..fa27bb8 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -807,6 +807,14 @@
fifo-depth = <0x40>;
status = "disabled";
};
+
+ pmu_system_controller: system-controller@105c {
+ compatible = "samsung,exynos5433-pmu", "syscon";
+ reg = <0x105c 0x5008>;
+ #clock-cells = <1>;
+ clock-names = "clkout16";
+ clocks = <>;
+ };
};
timer {
--
1.8.5.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 v6 9/9] arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
This patch adds the thermal-zones devicetree node for Exynos5433 SoC.
The thermal-zones has five thermal-zones and then each thermal-zone contains
each thermal-sensor to monitor the temperature of own IP. The {atlas0|apollo}_
thermal zone have the eight trip-points for interrupt method to detect the
over-temperature.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Lukasz Majewski
---
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 231 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
2 files changed, 232 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
new file mode 100644
index 000..7ff7b0e
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
@@ -0,0 +1,231 @@
+/*
+ * Device tree sources for Exynos5433 thermal zone
+ *
+ * Copyright (c) 2015 Chanwoo Choi
+ *
+ * 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
+
+/ {
+thermal-zones {
+ atlas0_thermal: atlas0-thermal {
+ thermal-sensors = <_atlas0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ atlas0_alert_0: atlas0-alert-0 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_1: atlas0-alert-1 {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_2: atlas0-alert-2 {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_3: atlas0-alert-3 {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_4: atlas0-alert-4 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_5: atlas0-alert-5 {
+ temperature = <105000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_6: atlas0-alert-6 {
+ temperature = <11>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ };
+ };
+
+ atlas1_thermal: atlas1-thermal {
+ thermal-sensors = <_atlas1>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ atlas1_alert_0: atlas1-alert-0 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_1: atlas1-alert-1 {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_2: atlas1-alert-2 {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_3: atlas1-alert-3 {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_4: atlas1-alert-4 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+
[PATCH v6 0/9] arm64: Add the support for new Exynos5433 SoC
This patchset adds new 64-bit Exynos5433 Samsung SoC which contains quad
Cortex-A57 and quad Cortex-A53. It is desigend with the 20nm low power process.
Depends on:
- This patch-set has the dependency on following four patch-set.
The Exynos5433 clock controller patch-set[1][2] was merged by Michael Turquette.
and Exynos5433's pinctrl patch[3] was merged by Linus Walleij. Exynos5433's TMU
patch[4] will be refactoring without feature update.
[1] [PATCH v5 00/13] clk: samsung: Add the support for exynos5433 clocks
- https://lkml.org/lkml/2015/2/2/368
[2] [PATCH v3 0/9] clk: samsung: Add clocks for remaining domains of Exynos5433
- https://lkml.org/lkml/2015/2/2/784
[3] [PATCH v4] pinctrl: exynos: Add support for Exynos5433
- https://lkml.org/lkml/2015/2/23/728
[4] [PATCH 0/3] thermal: exynos: Add support for Exynos5433 TMU
- https://lkml.org/lkml/2015/2/26/234
Changelog:
Changes from v5:
(https://lkml.org/lkml/2015/3/5/27)
- Move 'timer' dt node under root node by Mark Rutland's comment
Changes from v4:
(https://lkml.org/lkml/2015/2/24/2)
- Rebased it on Linux 4.0-rc2
- Remove CONFIG_ARCH_EXYNOS5433 configuration by Arnd Bergmann's comment
- Move 'aliases' dt node from SoC dtsi to board dts file by Arnd Bergmann's
comment
- Add Exynos5433 TMU patches which got the Lukasz Majewski's reviewed message
Changes from v3:
(https://lkml.org/lkml/2015/2/12/65)
- Rebased it on Linux 4.0-rc1.
- Remove ARM_GIC and ARM_AMBA dependency because CONFIG_ARM64 already included
them.
Changes from v2:
(https://lkml.org/lkml/2014/12/2/134)
: Fix the range of GICC memory map (0x1000 -> 0x2000)
: Fix address space of 'range' property under 'soc' node
: Add ADMA / I2S dt node for sound playback/capture
- Select ARM_AMBA/ARM_GIC/HAVE_S3C_RTC for Exynos5433 in arch/arm64/Kconfig
- Send separate patch-set for Exynos5433 clock controller[1][2] and pinctrl[3]
Changes from v1:
(https://lkml.org/lkml/2014/11/27/92)
- Merge two patches (patch2, patch3) to solve incomplete description
- Exynos5433 Clock driver
: Fix wrong register and code clean by using space instead of tab
: Add CLK_IGNORE_UNUSED flag to pclk_sysreg_* clock for accessing system
control register
: Remove duplicate definition on the patch for CMU_BUS{0|1|2} domain
- Exynos5433 SoC DTS
: Remove un-supported properties of arch_timer
: Remove 'clock-frequency' property from 'cpus' dt node
: Fix interrupt type from edge rising triggering to level high triggering
because Cortex-A53/A57 use level triggering.
: Fix defult address-size/size-celss from 1 to 2 because Exynos5433 is 64-bit
SoC
: Modify 'fin_pll' dt node to remove un-needed and ugly code
: Move 'chipid' dt node under 'soc'
: Use lowercase on all case in exynos5433.dtsi
: Add PSCI dt node for secondary cpu boot
: Add 'samsung,exynos5433' compatible to MCT dt node
- Divide pinctrl patch from this patchset
- Add new following patches:
: clocksource: exynos_mct: Add the support for Exynos 64bit SoC
: arm64: Enable Exynos5433 SoC in the defconfig
Chanwoo Choi (6):
arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
arm64: dts: exynos: Add PMU dt node for Exynos5433
arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
Inha Song (2):
arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
Jaehoon Chung (1):
arm64: dts: exynos: Add MSHC dt node for Exynos5433
.../devicetree/bindings/arm/samsung/pmu.txt| 1 +
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +++
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 231 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 931 +
5 files changed, 1883 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
--
1.8.5.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 v6 7/9] arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
From: Inha Song
This patch adds I2S device tree node for Exynos5433 SoC.
In Exynos5433 SoC, I2S0 is used for audio interface.
Signed-off-by: Inha Song
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 23d9018..fea4e32 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -475,6 +475,23 @@
status = "disabled";
};
+ i2s0: i2s0@1144 {
+ compatible = "samsung,exynos7-i2s";
+ reg = <0x1144 0x100>;
+ dmas = < 0 2>;
+ dma-names = "tx", "rx";
+ interrupts = <0 70 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_aud CLK_PCLK_AUD_I2S>,
+<_aud CLK_SCLK_AUD_I2S>,
+<_aud CLK_SCLK_I2S_BCLK>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1000>;
--
1.8.5.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 v2 3/4] cpufreq: mediatek: add Mediatek cpufreq driver
On 10 March 2015 at 00:28, Russell King - ARM Linux
wrote:
> On Wed, Mar 04, 2015 at 04:49:15PM +0800, pi-cheng.chen wrote:
>> +static int cpu_opp_table_get_freq_index(unsigned int freq)
>> +{
>> + struct cpu_opp_table *opp_tbl = dvfs_info->opp_tbl;
>> + int i;
>> +
>> + for (i = 0; opp_tbl[i].freq != 0; i++) {
>> + if (opp_tbl[i].freq >= freq)
>> + return i;
>> + }
>> +
>> + return -1;
>
> My "return -1" detector fired on this...
>
>> +static int cpu_opp_table_get_volt_index(unsigned int volt)
>> +{
>> + struct cpu_opp_table *opp_tbl = dvfs_info->opp_tbl;
>> + int i;
>> +
>> + for (i = 0; opp_tbl[i].vproc != -1; i++)
>> + if (opp_tbl[i].vproc >= volt)
>> + return i;
>> +
>> + return -1;
>
> And this.
>
>> +static int mtk_cpufreq_notify(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> + struct cpufreq_freqs *freqs = data;
>> + struct cpu_opp_table *opp_tbl = dvfs_info->opp_tbl;
>> + int old_vproc, new_vproc, old_index, new_index;
>> +
>> + if (!cpumask_test_cpu(freqs->cpu, _info->cpus))
>> + return NOTIFY_DONE;
>> +
>> + old_vproc = regulator_get_voltage(dvfs_info->proc_reg);
>> + old_index = cpu_opp_table_get_volt_index(old_vproc);
>> + new_index = cpu_opp_table_get_freq_index(freqs->new * 1000);
>> + new_vproc = opp_tbl[new_index].vproc;
>
> Let's say that cpu_opp_table_get_freq_index() returns -1. We then
> do no error checking on this, and access the memory immediately
> preceding opp_tbl[0].
>
> Since we'll be loading garbage from opp_tbl[-1], this probably means
> that mtk_cpufreq_voltage_trace() will go wrong. Your method of using
> the vproc values to work out which direction we should walk between
> old_index...new_index means that we could end up walking through
> almost the whole UINT_MAX range to wrap around to the new index.
>
> Yet again, "return -1" proves to be a sure sign of a bug.
Hi Russell,
Thanks for your reviewing. I'll fix it in next version.
Best Regards,
Pi-Cheng
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
--
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] m68k: Fix trivial typos in comments
Hi Yannick,
On 10/03/15 07:29, Yannick Guerrini wrote:
> Change 'Reaceive' to 'Receive'
> Change 'alighnment' to 'alignment'
>
> Signed-off-by: Yannick Guerrini
Thanks. I have put this in the m68knommu git tree, for-next branch.
Regards
Greg
> ---
> arch/m68k/include/asm/m68360_pram.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/include/asm/m68360_pram.h
> b/arch/m68k/include/asm/m68360_pram.h
> index e6088bb..c0cbd96 100644
> --- a/arch/m68k/include/asm/m68360_pram.h
> +++ b/arch/m68k/include/asm/m68360_pram.h
> @@ -170,7 +170,7 @@ struct uart_pram {
> unsigned short frmer; /* Rx framing error counter */
> unsigned short nosec; /* Rx noise counter */
> unsigned short brkec; /* Rx break character counter */
> -unsigned short brkln; /* Reaceive break length */
> +unsigned short brkln; /* Receive break length */
>
> unsigned short uaddr1; /* address character 1 */
> unsigned short uaddr2; /* address character 2 */
> @@ -338,7 +338,7 @@ struct ethernet_pram {
> unsigned long c_pres; /* preset CRC */
> unsigned long c_mask; /* constant mask for CRC */
> unsigned long crcec; /* CRC error counter */
> -unsigned long alec; /* alighnment error counter */
> +unsigned long alec; /* alignment error counter */
> unsigned long disfc; /* discard frame counter */
> unsigned short pads; /* short frame PAD characters */
> unsigned short ret_lim;/* retry limit threshold */
>
--
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 5/9] x86: Hook up epoll_ctl_batch syscall
Signed-off-by: Fam Zheng --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index b3560ec..fe809f6 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -365,3 +365,4 @@ 356i386memfd_createsys_memfd_create 357i386bpf sys_bpf 358i386execveatsys_execveat stub32_execveat +359i386epoll_ctl_batch sys_epoll_ctl_batch diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 8d656fb..67b2ea4 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -329,6 +329,7 @@ 320common kexec_file_load sys_kexec_file_load 321common bpf sys_bpf 32264 execveatstub_execveat +32364 epoll_ctl_batch sys_epoll_ctl_batch # # x32-specific system call numbers start at 512 to avoid cache impact -- 1.9.3 -- 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: mediatek: Export CPU mux clocks for CPU frequency control
On 5 March 2015 at 15:42, Sascha Hauer wrote:
>
> +Cc Viresh Kumar
>
> Viresh, this is the patch for the underlying clocks for the Mediatek
> cpufreq driver.
>
> On Thu, Mar 05, 2015 at 10:43:21AM +0800, Pi-Cheng Chen wrote:
>> Hi Sascha,
>>
>> On 4 March 2015 at 19:21, Sascha Hauer wrote:
>> > On Wed, Mar 04, 2015 at 06:49:11PM +0800, pi-cheng.chen wrote:
>> >> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
>> >> for intermediate clock source switching. This patch is based on Mediatek
>> >> clock driver patches[1].
>> >>
>> >> [1] http://thread.gmane.org/gmane.linux.kernel/1892436
>> >>
>> >> Signed-off-by: pi-cheng.chen
>> >> ---
>> >> +static long clk_cpumux_determine_rate(struct clk_hw *hw, unsigned long
>> >> rate,
>> >> + unsigned long min_rate,
>> >> + unsigned long max_rate,
>> >> + unsigned long *best_parent_rate,
>> >> + struct clk_hw **best_parent_p)
>> >> +{
>> >> + struct clk *clk = hw->clk, *parent;
>> >> + unsigned long parent_rate;
>> >> + int i;
>> >> +
>> >> + for (i = MAINPLL_INDEX; i >= ARMPLL_INDEX; i--) {
>> >> + parent = clk_get_parent_by_index(clk, i);
>> >> + if (!parent)
>> >> + return 0;
>> >> +
>> >> + if (i == MAINPLL_INDEX) {
>> >> + parent_rate = __clk_get_rate(parent);
>> >> + if (parent_rate == rate)
>> >> + break;
>> >> + }
>> >> +
>> >> + parent_rate = __clk_round_rate(parent, rate);
>> >> + }
>> >> +
>> >> + *best_parent_rate = parent_rate;
>> >> + *best_parent_p = __clk_get_hw(parent);
>> >> + return parent_rate;
>> >> +}
>> >
>> > Why this determine_rate hook? If you want to switch the clock to some
>> > intermediate parent I would assume you do this explicitly by setting the
>> > parent and not implicitly by setting a rate.
>> >
>>
>> I use determine_rate hook here because I am using generic cpufreq-dt
>> driver and I want to make clock switching transparent to cpufreq-dt.
>> I.e. when I am trying to switch the clock from ARMPLL to MAINPLL, I
>> call clk_set_rate() with the rate of MAINPLL, and determine_rate will
>> select MAINPLL as the new parent.
>
> We have clk_set_parent for changing the parent and clk_set_rate to
> change the rate. Use the former for changing the parent and the latter
> for changing the rate. What you are interested in is changing the
> parent, so use clk_set_parent for this and not abuse a side effect
> of clk_set_rate.
>
> My suggestion is to take another approach. Implement clk_set_rate for
> these muxes and in the set_rate hook:
>
> - switch mux to intermediate PLL parent
> - call clk_set_rate() for the real parent PLL
> - switch mux back to real parent PLL
Hi Sascha,
Thanks for your suggestion. I've tried to take this approach, but there's some
issues here.
Calling clk_set_rate() inside the set_rate callback of cpumux will cause
an infinite recursive calling in the clock framework:
mux.set_rate() -> pll.set_rate() -> mux.set_rate -> ...
I've also tries to update pll register settings in the set_rate()
callback of cpumux,
but the PLL clock information will not be correctly updated in this case.
How do you think to create a new "CPU PLL" type of clock and do underlying
mux switching in the set_rate callback of "CPU PLL"?
Best Regards,
Pi-Cheng
>
> This way the things happening behind the scenes are completely transparent
> to the cpufreq driver and you can use cpufreq-dt as is without changes.
>
> 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/
Re: fwupdate
On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov wrote: > + pjones. > > So reportedly, there is already a capsule-loading thing which doesn't > need the kernel at all: > > https://github.com/rhinstaller/fwupdate > > So why are we even wasting energy with this discussion here? > > -- > Regards/Gruss, > Boris. The network boot case can be taken care of as Peter described (ie taking network device paths, instead of just file paths), so this should work for those cases as well. There would be some extra setup, as for this to work the EFI firmware update program would need to be run at boot (via the BootNext variable), but I don't think this is unreasonable. It looks like GnuEFI now supports Aarch64, so building the firmware update utility shouldn't be a problem. Peter - have you you tried building this on Aarch64 yet? If not I'll give it a try. I think there is some value in using runtime update capsule calls, as that will help make sure the feature works in the firmware. I think with arm64 servers in an early stage of development, we can influence the firmware support of various features by using them. I don't know that this is a sufficient reason, but if runtime capsules are never used then there is a good chance that there will be many broken implementations. Roy -- 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: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
On Tue, 2015-03-10 at 01:42 +, Hiroshi Shimamoto wrote: > > On 03/08/2015 02:15 PM, Or Gerlitz wrote: > > > On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher > > > wrote: > > > [...] > > >> We discussed this during NetConf last week, and Don is correct > that a > > >> custom sysfs interface is not the way we want to handle this. We > agreed > > >> upon a generic interface so that any NIC is able to turn on or > off VF > > >> multicast promiscuous mode. > > > > > > Jeff, please make sure to either respond to my comments on the V2 > > > thread (or better) address them for the V3 post. > > > > > > > > > http://marc.info/?l=linux-netdev=142441852518152=2 > > > http://marc.info/?l=linux-netdev=142441867218183=2 > > > > I agree with you that the patch descriptions should be cleaned up > and > > "beefed" up for that matter. > > > > If/when I look to push his series of patches, I will make sure that > your > > concerns are addressed so that we can get a accurate changelog. > > I see that the patchset should have better explanation in changelog. > I will rewrite it and submit again. > > Jeff, are you planning to drop the patchset from your tree? > I just concerned which tree I should create patches against for. Yes, I will drop the current patchset in my queue. I am in the process of updating my queue, go ahead and make your patches against the following tree: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git all-queue branch If you give me an hour or so, I should have my tree updated with all the patches in my queue currently. signature.asc Description: This is a digitally signed message part
[PATCH v4 8/9] epoll: Add compat version implementation of epoll_pwait1
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 50 ++
include/linux/compat.h | 6 ++
2 files changed, 56 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 06a59fc..b837ea4 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2178,6 +2178,56 @@ COMPAT_SYSCALL_DEFINE6(epoll_pwait, int, epfd,
return epoll_pwait_do(epfd, events, maxevents, CLOCK_MONOTONIC, kt,
sigmask ? : NULL);
}
+
+struct compat_epoll_wait_params {
+ int size;
+ int clockid;
+ compat_uptr_t timeout;
+ compat_uptr_t sigmask;
+ compat_size_t sigsetsize;
+} EPOLL_PACKED;
+
+COMPAT_SYSCALL_DEFINE5(epoll_pwait1, int, epfd, int, flags,
+ struct epoll_event __user *, events,
+ int, maxevents,
+ struct compat_epoll_wait_params __user *, params)
+{
+ struct compat_epoll_wait_params p;
+
+ ktime_t kt = { 0 };
+ sigset_t sigmask;
+ compat_sigset_t compat_sigmask;
+ struct timespec timeout;
+
+ if (flags)
+ return -EINVAL;
+ if (!params)
+ return -EINVAL;
+ if (copy_from_user(, params, sizeof(p)))
+ return -EFAULT;
+ if (p.size != sizeof(p))
+ return -EINVAL;
+ if (p.sigmask) {
+ if (copy_from_user(_sigmask, compat_ptr(p.sigmask),
+ sizeof(sigmask)))
+ return -EFAULT;
+ if (p.sigsetsize != sizeof(p.sigmask))
+ return -EINVAL;
+ sigset_from_compat(, _sigmask);
+ }
+ if (p.timeout) {
+ if (compat_get_timespec(, compat_ptr(p.timeout)))
+ return -EFAULT;
+ if (!timespec_valid())
+ return -EINVAL;
+ kt = timespec_to_ktime(timeout);
+ } else {
+ kt = ns_to_ktime(-1);
+ }
+
+ return epoll_pwait_do(epfd, events, maxevents, p.clockid,
+ kt, p.sigmask ? : NULL);
+}
#endif
static int __init eventpoll_init(void)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index ab25814..649c5b2 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -452,6 +452,12 @@ asmlinkage long compat_sys_epoll_pwait(int epfd,
const compat_sigset_t __user *sigmask,
compat_size_t sigsetsize);
+struct compat_epoll_wait_params;
+asmlinkage long compat_sys_epoll_pwait1(int epfd, int flags,
+ struct epoll_event __user *events,
+ int maxevents,
+ struct compat_epoll_wait_params __user *params);
+
asmlinkage long compat_sys_utime(const char __user *filename,
struct compat_utimbuf __user *t);
asmlinkage long compat_sys_utimensat(unsigned int dfd,
--
1.9.3
--
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 9/9] x86: Hook up 32 bit compat epoll_pwait1 syscall
Signed-off-by: Fam Zheng --- arch/x86/syscalls/syscall_32.tbl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index bf912d8..5728c2e 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -366,4 +366,4 @@ 357i386bpf sys_bpf 358i386execveatsys_execveat stub32_execveat 359i386epoll_ctl_batch sys_epoll_ctl_batch -360i386epoll_pwait1sys_epoll_pwait1 +360i386epoll_pwait1sys_epoll_pwait1 compat_sys_epoll_pwait1 -- 1.9.3 -- 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/9] epoll: Add implementation for epoll_pwait1
This is the new implementation for poll which has a flags parameter and
packs a number of parameters into a structure.
The main advantage of it over existing epoll_pwait is about timeout:
epoll_pwait expects a relative millisecond value, while epoll_pwait1
accepts 1) a timespec which is in nanosecond granularity; 2) a clockid
to allow using a clock other than CLOCK_MONOTONIC.
The 'flags' field in params is reserved for now and must be zero. The
next step would be allowing absolute timeout value.
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 39 ++-
include/linux/syscalls.h | 5 +
include/uapi/linux/eventpoll.h | 8
3 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 54dc63f..06a59fc 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2085,7 +2085,6 @@ SYSCALL_DEFINE4(epoll_ctl_batch, int, epfd, int, flags,
cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
/* TODO: optimize for small arguments like select/poll with a stack
* allocated buffer */
-
kcmds = kmalloc(cmd_size, GFP_KERNEL);
if (!kcmds)
return -ENOMEM;
@@ -2119,6 +2118,44 @@ out:
return ret;
}
+SYSCALL_DEFINE5(epoll_pwait1, int, epfd, int, flags,
+ struct epoll_event __user *, events,
+ int, maxevents,
+ struct epoll_wait_params __user *, params)
+{
+ struct epoll_wait_params p;
+ ktime_t kt = { 0 };
+ sigset_t sigmask;
+ struct timespec timeout;
+
+ if (flags)
+ return -EINVAL;
+ if (!params)
+ return -EINVAL;
+ if (copy_from_user(, params, sizeof(p)))
+ return -EFAULT;
+ if (p.size != sizeof(p))
+ return -EINVAL;
+ if (p.sigmask) {
+ if (copy_from_user(, p.sigmask, sizeof(sigmask)))
+ return -EFAULT;
+ if (p.sigsetsize != sizeof(p.sigmask))
+ return -EINVAL;
+ }
+ if (p.timeout) {
+ if (copy_from_user(, p.timeout, sizeof(timeout)))
+ return -EFAULT;
+ if (!timespec_valid())
+ return -EINVAL;
+ kt = timespec_to_ktime(timeout);
+ } else {
+ kt = ns_to_ktime(-1);
+ }
+
+ return epoll_pwait_do(epfd, events, maxevents, p.clockid,
+ kt, p.sigmask ? : NULL);
+}
+
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE6(epoll_pwait, int, epfd,
struct epoll_event __user *, events,
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 7d784e3..a4823d9 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -13,6 +13,7 @@
struct epoll_event;
struct epoll_ctl_cmd;
+struct epoll_wait_params;
struct iattr;
struct inode;
struct iocb;
@@ -635,6 +636,10 @@ asmlinkage long sys_epoll_pwait(int epfd, struct
epoll_event __user *events,
int maxevents, int timeout,
const sigset_t __user *sigmask,
size_t sigsetsize);
+asmlinkage long sys_epoll_pwait1(int epfd, int flags,
+struct epoll_event __user *events,
+int maxevents,
+struct epoll_wait_params __user *params);
asmlinkage long sys_epoll_ctl_batch(int epfd, int flags,
int ncmds,
struct epoll_ctl_cmd __user *cmds);
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index 4e18b17..05ae035 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -72,6 +72,14 @@ struct epoll_ctl_cmd {
int result;
} EPOLL_PACKED;
+struct epoll_wait_params {
+ int size;
+ int clockid;
+ struct timespec *timeout;
+ sigset_t *sigmask;
+ size_t sigsetsize;
+} EPOLL_PACKED;
+
#ifdef CONFIG_PM_SLEEP
static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
{
--
1.9.3
--
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 7/9] x86: Hook up epoll_pwait1 syscall
Signed-off-by: Fam Zheng --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index fe809f6..bf912d8 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -366,3 +366,4 @@ 357i386bpf sys_bpf 358i386execveatsys_execveat stub32_execveat 359i386epoll_ctl_batch sys_epoll_ctl_batch +360i386epoll_pwait1sys_epoll_pwait1 diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 67b2ea4..9246ad5 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -330,6 +330,7 @@ 321common bpf sys_bpf 32264 execveatstub_execveat 32364 epoll_ctl_batch sys_epoll_ctl_batch +32464 epoll_pwait1sys_epoll_pwait1 # # x32-specific system call numbers start at 512 to avoid cache impact -- 1.9.3 -- 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/9] epoll: Add implementation for epoll_ctl_batch
This new syscall is a batched version of epoll_ctl. It will execute each
command as specified in cmds in given order, and stop at first failure
or upon completion of all commands.
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 50 ++
include/linux/syscalls.h | 4
include/uapi/linux/eventpoll.h | 11 ++
3 files changed, 65 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 7909c88..54dc63f 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -99,6 +99,8 @@
#define EP_MAX_EVENTS (INT_MAX / sizeof(struct epoll_event))
+#define EP_MAX_BATCH (INT_MAX / sizeof(struct epoll_ctl_cmd))
+
#define EP_UNACTIVE_PTR ((void *) -1L)
#define EP_ITEM_COST (sizeof(struct epitem) + sizeof(struct eppoll_entry))
@@ -2069,6 +2071,54 @@ SYSCALL_DEFINE6(epoll_pwait, int, epfd, struct
epoll_event __user *, events,
sigmask ? : NULL);
}
+SYSCALL_DEFINE4(epoll_ctl_batch, int, epfd, int, flags,
+ int, ncmds, struct epoll_ctl_cmd __user *, cmds)
+{
+ struct epoll_ctl_cmd *kcmds = NULL;
+ int i, ret = 0;
+ size_t cmd_size;
+
+ if (flags)
+ return -EINVAL;
+ if (!cmds || ncmds <= 0 || ncmds > EP_MAX_BATCH)
+ return -EINVAL;
+ cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
+ /* TODO: optimize for small arguments like select/poll with a stack
+* allocated buffer */
+
+ kcmds = kmalloc(cmd_size, GFP_KERNEL);
+ if (!kcmds)
+ return -ENOMEM;
+ if (copy_from_user(kcmds, cmds, cmd_size)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ for (i = 0; i < ncmds; i++) {
+ struct epoll_event ev = (struct epoll_event) {
+ .events = kcmds[i].events,
+ .data = kcmds[i].data,
+ };
+ if (kcmds[i].flags) {
+ kcmds[i].result = -EINVAL;
+ goto copy;
+ }
+ kcmds[i].result = ep_ctl_do(epfd, kcmds[i].op,
+ kcmds[i].fd, ev);
+ if (kcmds[i].result)
+ goto copy;
+ ret++;
+ }
+copy:
+ /* We lose the number of succeeded commands in favor of returning
+* -EFAULT, but in this case the application will want to fix the
+* memory bug first. */
+ if (copy_to_user(cmds, kcmds, cmd_size))
+ ret = -EFAULT;
+out:
+ kfree(kcmds);
+ return ret;
+}
+
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE6(epoll_pwait, int, epfd,
struct epoll_event __user *, events,
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 76d1e38..7d784e3 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -12,6 +12,7 @@
#define _LINUX_SYSCALLS_H
struct epoll_event;
+struct epoll_ctl_cmd;
struct iattr;
struct inode;
struct iocb;
@@ -634,6 +635,9 @@ asmlinkage long sys_epoll_pwait(int epfd, struct
epoll_event __user *events,
int maxevents, int timeout,
const sigset_t __user *sigmask,
size_t sigsetsize);
+asmlinkage long sys_epoll_ctl_batch(int epfd, int flags,
+ int ncmds,
+ struct epoll_ctl_cmd __user *cmds);
asmlinkage long sys_gethostname(char __user *name, int len);
asmlinkage long sys_sethostname(char __user *name, int len);
asmlinkage long sys_setdomainname(char __user *name, int len);
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index bc81fb2..4e18b17 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -18,6 +18,8 @@
#include
#include
+#include
+
/* Flags for epoll_create1. */
#define EPOLL_CLOEXEC O_CLOEXEC
@@ -61,6 +63,15 @@ struct epoll_event {
__u64 data;
} EPOLL_PACKED;
+struct epoll_ctl_cmd {
+ int flags;
+ int op;
+ int fd;
+ __u32 events;
+ __u64 data;
+ int result;
+} EPOLL_PACKED;
+
#ifdef CONFIG_PM_SLEEP
static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
{
--
1.9.3
--
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] shmem: Add eventfd notification on utlilization level
Any updates?
Thank you,
Kyungmin Park
On Wed, Feb 11, 2015 at 11:50 PM, Krzysztof Kozlowski
wrote:
> Allow notifying user space when used space of tmpfs exceeds specified
> level.
>
> The utilization level is passed as mount option 'warn_used'. The kernel
> will notify user-space through eventfd after exceeding this number of
> used blocks.
>
> The eventfd descriptor has to be passed through sysfs file:
> /sys/fs/tmpfs/tmpfs-[0-9]+/warn_used_blocks_efd
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> include/linux/shmem_fs.h | 4 ++
> mm/shmem.c | 138
> ++-
> 2 files changed, 140 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 50777b5b1e4c..c2ec9909da95 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -35,6 +35,10 @@ struct shmem_sb_info {
> kgid_t gid; /* Mount gid for root directory */
> umode_t mode; /* Mount mode for root directory */
> struct mempolicy *mpol; /* default memory policy for mappings */
> + unsigned long warn_used;/* Warn on reaching used blocks */
> + struct kobject s_kobj; /* kobj for sysfs attributes */
> + struct completion s_kobj_unregister; /* synchronization for put_super
> */
> + struct eventfd_ctx *warn_used_efd; /* user-space passed eventfd */
> };
>
> static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
> diff --git a/mm/shmem.c b/mm/shmem.c
> index f69d296bd0a3..b559adcef3b3 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -34,6 +34,7 @@
> #include
>
> static struct vfsmount *shm_mnt;
> +static struct kset *shmem_kset;
>
> #ifdef CONFIG_SHMEM
> /*
> @@ -69,6 +70,7 @@ static struct vfsmount *shm_mnt;
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -199,6 +201,106 @@ static struct backing_dev_info shmem_backing_dev_info
> __read_mostly = {
> static LIST_HEAD(shmem_swaplist);
> static DEFINE_MUTEX(shmem_swaplist_mutex);
>
> +
> +struct shmem_attr {
> + struct attribute attr;
> + ssize_t (*show)(struct shmem_attr *, struct shmem_sb_info *, char *);
> + ssize_t (*store)(struct shmem_attr *, struct shmem_sb_info *,
> +const char *, size_t);
> +};
> +
> +static int shmem_setup_warn_used_blocks_eventfd(struct shmem_sb_info *sbinfo,
> + unsigned int efd)
> +{
> + int ret = 0;
> +
> + if (sbinfo->warn_used_efd) {
> + eventfd_ctx_put(sbinfo->warn_used_efd);
> + sbinfo->warn_used_efd = NULL;
> + }
> +
> + sbinfo->warn_used_efd = eventfd_ctx_fdget(efd);
> + if (IS_ERR(sbinfo->warn_used_efd)) {
> + ret = PTR_ERR(sbinfo->warn_used_efd);
> + sbinfo->warn_used_efd = NULL;
> + }
> +
> + return ret;
> +}
> +
> +static int parse_strtouint(const char *buf,
> + unsigned long long max, unsigned int *value)
> +{
> + int ret;
> +
> + ret = kstrtouint(skip_spaces(buf), 0, value);
> + if (!ret && *value > max)
> + ret = -EINVAL;
> + return ret;
> +}
> +
> +static ssize_t warn_used_blocks_efd_store(struct shmem_attr *a,
> + struct shmem_sb_info *sbinfo,
> + const char *buf, size_t count)
> +{
> + unsigned int val;
> + int ret;
> +
> + if (parse_strtouint(buf, -1ULL, ))
> + return -EINVAL;
> +
> + ret = shmem_setup_warn_used_blocks_eventfd(sbinfo, val);
> +
> + return ret ? ret : count;
> +}
> +
> +static struct shmem_attr
> +shmem_attr_warn_used_blocks_efd = __ATTR_WO(warn_used_blocks_efd);
> +
> +static struct attribute *shmem_attrs[] = {
> + _attr_warn_used_blocks_efd.attr,
> + NULL,
> +};
> +
> +static ssize_t shmem_attr_show(struct kobject *kobj,
> + struct attribute *attr, char *buf)
> +{
> + struct shmem_sb_info *sbinfo = container_of(kobj, struct
> shmem_sb_info,
> + s_kobj);
> + struct shmem_attr *a = container_of(attr, struct shmem_attr, attr);
> +
> + return a->show ? a->show(a, sbinfo, buf) : 0;
> +}
> +
> +static ssize_t shmem_attr_store(struct kobject *kobj,
> + struct attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct shmem_sb_info *sbinfo = container_of(kobj, struct
> shmem_sb_info,
> + s_kobj);
> + struct shmem_attr *a = container_of(attr, struct shmem_attr, attr);
> +
> + return a->store ? a->store(a, sbinfo, buf, len) : 0;
> +}
> +
> +static void shmem_sb_release(struct kobject *kobj)
> +{
> + struct shmem_sb_info *sbinfo = container_of(kobj, struct
> shmem_sb_info,
> +
[PATCH v4 3/9] epoll: Extract ep_ctl_do
This is the common part from epoll_ctl implementation which will be
shared with the new syscall.
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 957d1d0..7909c88 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1810,22 +1810,15 @@ SYSCALL_DEFINE1(epoll_create, int, size)
* the eventpoll file that enables the insertion/removal/change of
* file descriptors inside the interest set.
*/
-SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
- struct epoll_event __user *, event)
+int ep_ctl_do(int epfd, int op, int fd, struct epoll_event epds)
{
int error;
int full_check = 0;
struct fd f, tf;
struct eventpoll *ep;
struct epitem *epi;
- struct epoll_event epds;
struct eventpoll *tep = NULL;
- error = -EFAULT;
- if (ep_op_has_event(op) &&
- copy_from_user(, event, sizeof(struct epoll_event)))
- goto error_return;
-
error = -EBADF;
f = fdget(epfd);
if (!f.file)
@@ -1947,6 +1940,23 @@ error_return:
return error;
}
+/*
+ * The following function implements the controller interface for
+ * the eventpoll file that enables the insertion/removal/change of
+ * file descriptors inside the interest set.
+ */
+SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
+ struct epoll_event __user *, event)
+{
+ struct epoll_event epds;
+
+ if (ep_op_has_event(op) &&
+ copy_from_user(, event, sizeof(struct epoll_event)))
+ return -EFAULT;
+
+ return ep_ctl_do(epfd, op, fd, epds);
+}
+
static inline int epoll_wait_do(int epfd, struct epoll_event __user *events,
int maxevents, int clockid,
const ktime_t timeout)
--
1.9.3
--
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/9] epoll: Extract epoll_wait_do and epoll_pwait_do
In preparation of new epoll syscalls, this patch allows reusing the code from
epoll_pwait implementation. The new functions uses ktime_t for more accuracy.
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 154 ++---
1 file changed, 71 insertions(+), 83 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 1e009ca..7dfabeb 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1554,17 +1554,6 @@ static int ep_send_events(struct eventpoll *ep,
return ep_scan_ready_list(ep, ep_send_events_proc, , 0, false);
}
-static inline struct timespec ep_set_mstimeout(long ms)
-{
- struct timespec now, ts = {
- .tv_sec = ms / MSEC_PER_SEC,
- .tv_nsec = NSEC_PER_MSEC * (ms % MSEC_PER_SEC),
- };
-
- ktime_get_ts();
- return timespec_add_safe(now, ts);
-}
-
/**
* ep_poll - Retrieves ready events, and delivers them to the caller supplied
* event buffer.
@@ -1573,17 +1562,15 @@ static inline struct timespec ep_set_mstimeout(long ms)
* @events: Pointer to the userspace buffer where the ready events should be
* stored.
* @maxevents: Size (in terms of number of events) of the caller event buffer.
- * @timeout: Maximum timeout for the ready events fetch operation, in
- * milliseconds. If the @timeout is zero, the function will not
block,
- * while if the @timeout is less than zero, the function will block
- * until at least one event has been retrieved (or an error
- * occurred).
+ * @timeout: Maximum timeout for the ready events fetch operation. If 0, the
+ * function will not block. If negative, the function will block
until
+ * at least one event has been retrieved (or an error occurred).
*
* Returns: Returns the number of ready events which have been fetched, or an
* error code, in case of error.
*/
static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
- int maxevents, long timeout)
+ int maxevents, const ktime_t timeout)
{
int res = 0, eavail, timed_out = 0;
unsigned long flags;
@@ -1591,13 +1578,7 @@ static int ep_poll(struct eventpoll *ep, struct
epoll_event __user *events,
wait_queue_t wait;
ktime_t expires, *to = NULL;
- if (timeout > 0) {
- struct timespec end_time = ep_set_mstimeout(timeout);
-
- slack = select_estimate_accuracy(_time);
- to =
- *to = timespec_to_ktime(end_time);
- } else if (timeout == 0) {
+ if (!ktime_to_ns(timeout)) {
/*
* Avoid the unnecessary trip to the wait queue loop, if the
* caller specified a non blocking operation.
@@ -1605,6 +1586,15 @@ static int ep_poll(struct eventpoll *ep, struct
epoll_event __user *events,
timed_out = 1;
spin_lock_irqsave(>lock, flags);
goto check_events;
+ } else if (ktime_to_ns(timeout) > 0) {
+ struct timespec now, end_time;
+
+ ktime_get_ts();
+ end_time = timespec_add_safe(now, ktime_to_timespec(timeout));
+
+ slack = select_estimate_accuracy(_time);
+ to =
+ *to = timespec_to_ktime(end_time);
}
fetch_events:
@@ -1954,12 +1944,8 @@ error_return:
return error;
}
-/*
- * Implement the event wait interface for the eventpoll file. It is the kernel
- * part of the user space epoll_wait(2).
- */
-SYSCALL_DEFINE4(epoll_wait, int, epfd, struct epoll_event __user *, events,
- int, maxevents, int, timeout)
+static inline int epoll_wait_do(int epfd, struct epoll_event __user *events,
+ int maxevents, const ktime_t timeout)
{
int error;
struct fd f;
@@ -2002,46 +1988,70 @@ error_fput:
/*
* Implement the event wait interface for the eventpoll file. It is the kernel
+ * part of the user space epoll_wait(2).
+ */
+SYSCALL_DEFINE4(epoll_wait, int, epfd, struct epoll_event __user *, events,
+ int, maxevents, int, timeout)
+{
+ ktime_t kt = ms_to_ktime(timeout);
+ return epoll_wait_do(epfd, events, maxevents, kt);
+}
+
+static inline int epoll_pwait_do(int epfd, struct epoll_event __user *events,
+int maxevents, ktime_t timeout,
+sigset_t *sigmask, size_t sigsetsize)
+{
+ int error;
+ sigset_t sigsaved;
+
+ /*
+* If the caller wants a certain signal mask to be set during the wait,
+* we apply it here.
+*/
+ if (sigmask) {
+ sigsaved = current->blocked;
+ set_current_blocked(sigmask);
+ }
+
+ error = epoll_wait_do(epfd, events, maxevents, timeout);
+
+ /*
+* If we changed the signal mask, we need to restore the original one.
[PATCH v4 2/9] epoll: Specify clockid explicitly
Later we will add clockid in the interface, so let's start using explicit
clockid internally. Now we specify CLOCK_MONOTONIC, which is the same as before.
Signed-off-by: Fam Zheng
---
fs/eventpoll.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 7dfabeb..957d1d0 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1570,7 +1570,7 @@ static int ep_send_events(struct eventpoll *ep,
* error code, in case of error.
*/
static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
- int maxevents, const ktime_t timeout)
+ int maxevents, int clockid, const ktime_t timeout)
{
int res = 0, eavail, timed_out = 0;
unsigned long flags;
@@ -1578,6 +1578,8 @@ static int ep_poll(struct eventpoll *ep, struct
epoll_event __user *events,
wait_queue_t wait;
ktime_t expires, *to = NULL;
+ if (clockid != CLOCK_MONOTONIC && clockid != CLOCK_REALTIME)
+ return -EINVAL;
if (!ktime_to_ns(timeout)) {
/*
* Avoid the unnecessary trip to the wait queue loop, if the
@@ -1624,7 +1626,8 @@ fetch_events:
}
spin_unlock_irqrestore(>lock, flags);
- if (!schedule_hrtimeout_range(to, slack,
HRTIMER_MODE_ABS))
+ if (!schedule_hrtimeout_range_clock(to, slack,
+ HRTIMER_MODE_ABS, clockid))
timed_out = 1;
spin_lock_irqsave(>lock, flags);
@@ -1945,7 +1948,8 @@ error_return:
}
static inline int epoll_wait_do(int epfd, struct epoll_event __user *events,
- int maxevents, const ktime_t timeout)
+ int maxevents, int clockid,
+ const ktime_t timeout)
{
int error;
struct fd f;
@@ -1979,7 +1983,7 @@ static inline int epoll_wait_do(int epfd, struct
epoll_event __user *events,
ep = f.file->private_data;
/* Time to fish for events ... */
- error = ep_poll(ep, events, maxevents, timeout);
+ error = ep_poll(ep, events, maxevents, clockid, timeout);
error_fput:
fdput(f);
@@ -1994,12 +1998,13 @@ SYSCALL_DEFINE4(epoll_wait, int, epfd, struct
epoll_event __user *, events,
int, maxevents, int, timeout)
{
ktime_t kt = ms_to_ktime(timeout);
- return epoll_wait_do(epfd, events, maxevents, kt);
+ return epoll_wait_do(epfd, events, maxevents, CLOCK_MONOTONIC, kt);
}
static inline int epoll_pwait_do(int epfd, struct epoll_event __user *events,
-int maxevents, ktime_t timeout,
-sigset_t *sigmask, size_t sigsetsize)
+int maxevents,
+int clockid, ktime_t timeout,
+sigset_t *sigmask)
{
int error;
sigset_t sigsaved;
@@ -2013,7 +2018,7 @@ static inline int epoll_pwait_do(int epfd, struct
epoll_event __user *events,
set_current_blocked(sigmask);
}
- error = epoll_wait_do(epfd, events, maxevents, timeout);
+ error = epoll_wait_do(epfd, events, maxevents, clockid, timeout);
/*
* If we changed the signal mask, we need to restore the original one.
@@ -2050,8 +2055,8 @@ SYSCALL_DEFINE6(epoll_pwait, int, epfd, struct
epoll_event __user *, events,
if (copy_from_user(, sigmask, sizeof(ksigmask)))
return -EFAULT;
}
- return epoll_pwait_do(epfd, events, maxevents, kt,
- sigmask ? : NULL, sigsetsize);
+ return epoll_pwait_do(epfd, events, maxevents, CLOCK_MONOTONIC, kt,
+ sigmask ? : NULL);
}
#ifdef CONFIG_COMPAT
@@ -2073,8 +2078,8 @@ COMPAT_SYSCALL_DEFINE6(epoll_pwait, int, epfd,
sigset_from_compat(, );
}
- return epoll_pwait_do(epfd, events, maxevents, kt,
- sigmask ? : NULL, sigsetsize);
+ return epoll_pwait_do(epfd, events, maxevents, CLOCK_MONOTONIC, kt,
+ sigmask ? : NULL);
}
#endif
--
1.9.3
--
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/9] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
Changes from v3:
- Add "size" field in epoll_wait_params. [Jon, Ingo, Seymour]
- Input validation for ncmds in epoll_ctl_batch. [Dan]
- Return -EFAULT if copy_to_user failed in epoll_ctl_batch. [Omar, Michael]
- Change "timeout" in epoll_wait_params to pointer, to get the same
convention of 'no wait', 'wait indefinitely' and 'wait for specified time'
with epoll_pwait. [Seymour]
- Add compat implementation of epoll_pwait1.
Justification
=
QEMU, among many select/poll based applications, considers epoll as an
alternative when its event loop needs to handle a big number of FDs. However,
there are currently two concerns with epoll which prevents the switching:
The major one is the timeout precision. For example in QEMU, the main loop
takes care of calling callbacks at a specific timeout - the QEMU timer API. The
timeout value in ppoll depends on the next firing timer. epoll_pwait's
millisecond timeout is so coarse that rounding up the timeout will hurt
performance badly.
The minor one is the number of system call to update fd set. While epoll can
handle a large number of fds quickly, it still requires one epoll_ctl per fd
update, compared to the one-shot call to select/poll with an fd array. This may
as well make epoll inferior to ppoll in the cases where a small, but frequently
changing set of fds are polled by the event loop.
This series introduces two new epoll sys calls to address them respectively.
The idea of epoll_ctl_batch is suggested by Andy Lutomirski in [1], who also
suggested clockid as a parameter in epoll_pwait1.
[1]: http://lists.openwall.net/linux-kernel/2015/01/08/542
Benchmark for epoll_pwait1
==
By running fio tests inside VM with both original and modified QEMU, we can
compare their difference in performance.
With a small VM setup [t1], the original QEMU (ppoll based) has an 4k read
latency overhead around 37 us. In this setup, the main loop polls 10~20 fds.
With a slightly larger VM instance [t2] - attached a virtio-serial device so
that there are 80~90 fds in the main loop - the original QEMU has a latency
overhead around 49 us. By adding more such devices [t3], we can see the latency
go even higher - 83 us with ~200 FDs.
Now modify QEMU to use epoll_pwait1 and test again, the latency numbers are
repectively 36us, 37us, 47us for t1, t2 and t3.
Previous Changelogs
===
Changes from v2 (https://lkml.org/lkml/2015/2/4/105)
- Rename epoll_ctl_cmd.error_hint to "result". [Michael]
- Add background introduction in cover letter. [Michael]
- Expand the last struct of epoll_pwait1, add clockid and timespec.
- Update man page in cover letter accordingly:
* "error_hint" -> "result".
* The result field's caveat in "RETURN VALUE" secion of epoll_ctl_batch.
Please review!
Changes from v1 (https://lkml.org/lkml/2015/1/20/189)
-
- As discussed in previous thread [1], split the call to epoll_ctl_batch and
epoll_pwait. [Michael]
- Fix memory leaks. [Omar]
- Add a short comment about the ignored copy_to_user failure. [Omar]
- Cover letter rewritten.
Documentation of the new system calls
=
1) epoll_ctl_batch
--
NAME
epoll_ctl_batch - batch control interface for an epoll descriptor
SYNOPSIS
#include
int epoll_ctl_batch(int epfd, int flags,
int ncmds, struct epoll_ctl_cmd *cmds);
DESCRIPTION
This system call is an extension of epoll_ctl(). The primary difference
is that this system call allows you to batch multiple operations with
the one system call. This provides a more efficient interface for
updating events on this epoll file descriptor epfd.
The flags argument is reserved and must be 0.
The argument ncmds is the number of cmds entries being passed in.
This number must be greater than 0.
Each operation is specified as an element in the cmds array, defined as:
struct epoll_ctl_cmd {
/* Reserved flags for future extension, must be 0. */
int flags;
/* The same as epoll_ctl() op parameter. */
int op;
/* The same as epoll_ctl() fd parameter. */
int fd;
/* The same as the "events" field in struct epoll_event. */
uint32_t events;
/* The same as the "data" field in struct epoll_event. */
uint64_t data;
/* Output field, will be set to the return code after this
* command is executed by kernel */
int result;
};
This system call is not atomic when updating the epoll descriptor. All
entries in cmds are executed in the provided order. If any cmds
Re: [PATCH 0/5] [GIT PULL] seq-buf/ftrace: Various fixes
On Mon, Mar 9, 2015 at 6:36 PM, Steven Rostedt wrote: > > The confusing part is that I included the patch in this series that I > had in my previous pull request that you did not pull... Oh. Ok. I didn't pull that, simply because in the same thread you said you were going to fix the other case that Joe pointed out and you said "I'll make another patch". So I dismissed your previous pull request as premature.. Linus -- 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: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
> On 03/08/2015 02:15 PM, Or Gerlitz wrote:
> > On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher
> > wrote:
> > [...]
> >> We discussed this during NetConf last week, and Don is correct that a
> >> custom sysfs interface is not the way we want to handle this. We agreed
> >> upon a generic interface so that any NIC is able to turn on or off VF
> >> multicast promiscuous mode.
> >
> > Jeff, please make sure to either respond to my comments on the V2
> > thread (or better) address them for the V3 post.
> >
> >
> > http://marc.info/?l=linux-netdev=142441852518152=2
> > http://marc.info/?l=linux-netdev=142441867218183=2
>
> I agree with you that the patch descriptions should be cleaned up and
> "beefed" up for that matter.
>
> If/when I look to push his series of patches, I will make sure that your
> concerns are addressed so that we can get a accurate changelog.
I see that the patchset should have better explanation in changelog.
I will rewrite it and submit again.
Jeff, are you planning to drop the patchset from your tree?
I just concerned which tree I should create patches against for.
thanks,
Hiroshi
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v4] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar, On Sun, Mar 08, 2015 at 11:33:27AM +, Lad Prabhakar wrote: > From: Benoit Parrot > > this patch adds support for omnivision's ov2659 > sensor, the driver supports following features: > 1: Asynchronous probing > 2: DT support > 3: Media controller support > > Signed-off-by: Benoit Parrot > Signed-off-by: Lad, Prabhakar Now that DT support is included, could you document it as well? There's a single proprerty to document. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
On Sun, Mar 08, 2015 at 11:33:27AM +, Lad Prabhakar wrote:
...
> +static struct ov2659_platform_data *
> +ov2659_get_pdata(struct i2c_client *client)
> +{
> + struct ov2659_platform_data *pdata;
> + struct device_node *endpoint;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node) {
> + dev_err(>dev, "ov2659_get_pdata: DT Node found\n");
> + return client->dev.platform_data;
> + }
> +
> + endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
> + if (!endpoint)
> + return NULL;
> +
> + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto done;
> +
> + ret = of_property_read_u32(endpoint, "link-frequencies",
> +>link_frequency);
This is actually documented as being a 64-bit array.
The smiapp wasn't even reading it from the endpoint node. Oh well...
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 0/5] [GIT PULL] seq-buf/ftrace: Various fixes
On Mon, 9 Mar 2015 18:14:26 -0700 Linus Torvalds wrote: > On Mon, Mar 9, 2015 at 9:03 AM, Steven Rostedt wrote: > > > > This is on top of the last pull request I sent out. But doesn't seem to > > have been pulled. > > You make no sense. The commits you list were all on top of plain 4.0-rc2. > > So exactly what do you expect me to pull, or haven't I pulled? The confusing part is that I included the patch in this series that I had in my previous pull request that you did not pull... http://marc.info/?l=linux-kernel=142549997928187 -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark, On 03/06/2015 09:18 PM, Chanwoo Choi wrote: > Hi, > > On 03/06/2015 08:40 PM, Mark Rutland wrote: [snip] >> I take it CPUs boot at EL2? >> >> Do the CPUs boot at EL1 or EL2? > > Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. > I think that a few SoC provider probably would know it. I guess I asked the wrong question. Do CPUs enter the kernel at EL2 or at EL1? >>> >>> Could you give me a tip how to check the kernel at EL2 or EL1? >> >> Hmm... I thought we logged this but it looks like we don't. >> >> You could hack in a check of is_hyp_mode_available() and >> is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, >> and whether all CPUs enter at the same mode (mandatory per the boot >> protocol). > > OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Best Regards, Chanwoo Choi -- 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 5/7] x86, kaslr: Consolidate mem_avoid array filling
On Mon, Mar 9, 2015 at 6:10 PM, Yinghai Lu wrote: > On Mon, Mar 9, 2015 at 6:00 PM, Kees Cook wrote: >> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote: >> >> This may be a stupid question, but are boot_params being used outside >> of the compressed loader? If so, it might make sense to split that >> change into a separate patch to go to stable, if it's causing >> problems. (And document what problem is getting solved.) > > boot_params will keep the same and until it is passed > x86_64_start_kernel in vmlinux. > and there it will be copied, same as cmdline. > > but current kaslr only support random the base high, and it does not > support kexec > and current boot loader (grub2) put it really low. (under 1M). the > real real_mode. :). Oh right! Of course, thanks for the details. Yes, it was implicitly ignored before, but now it needs to be explicitly ignored. Great, thanks! -Kees > > Thanks > > Yinghai -- Kees Cook Chrome OS Security -- 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] phy: twl4030-usb: Remove redundant assignment for twl->linkstat
It's pointless to set twl->linkstat twice. Signed-off-by: Axel Lin --- Resend with linux-usb in Cc. drivers/phy/phy-twl4030-usb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 8e87f54..bc42d6a 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -666,7 +666,6 @@ static int twl4030_usb_probe(struct platform_device *pdev) twl->dev= >dev; twl->irq= platform_get_irq(pdev, 0); twl->vbus_supplied = false; - twl->linkstat = -EINVAL; twl->linkstat = OMAP_MUSB_UNKNOWN; twl->phy.dev= twl->dev; -- 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 6/7 v21] LSM: Switch to lists of hooks
Subject: [PATCH 6/7 v21] LSM: Switch to lists of hooks
Instead of using a vector of security operations
with explicit, special case stacking of the capability
and yama hooks use lists of hooks with capability and
yama hooks included as appropriate.
The security_operations structure is no longer required.
Instead, there is a union of the function pointers that
allows all the hooks lists to use a common mechanism for
list management while retaining typing. Each module
supplies an array describing the hooks it provides instead
of a sparsely populated security_operations structure.
The description includes the element that gets put on
the hook list, avoiding the issues surrounding individual
element allocation.
The method for registering security modules is changed to
reflect the information available. The method for removing
a module, currently only used by SELinux, has also changed.
It should be generic now, however if there are potential
race conditions based on ordering of hook removal that needs
to be addressed by the calling module.
The security hooks are called from the lists and the first
failure is returned.
Signed-off-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 31 ++-
include/linux/security.h | 37 +--
security/Makefile | 2 +-
security/apparmor/domain.c | 4 +-
security/apparmor/lsm.c| 51 ++--
security/commoncap.c | 36 ++-
security/security.c| 592 +
security/selinux/hooks.c | 79 ++
security/smack/smack.h | 2 -
security/smack/smack_lsm.c | 53 +---
security/smack/smackfs.c | 2 +-
security/tomoyo/tomoyo.c | 14 +-
security/yama/yama_lsm.c | 50 ++--
13 files changed, 614 insertions(+), 339 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 09b1714..c86aaf0 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -32,8 +32,6 @@
#ifdef CONFIG_SECURITY
/**
- * struct security_operations - main security structure
- *
* Security module identifier.
*
* @name:
@@ -1314,9 +1312,7 @@
* This is the main security structure.
*/
-struct security_operations {
- char name[SECURITY_NAME_MAX + 1];
-
+union security_list_options {
int (*binder_set_context_mgr)(struct task_struct *mgr);
int (*binder_transaction)(struct task_struct *from,
struct task_struct *to);
@@ -1843,19 +1839,32 @@ struct security_hook_heads {
};
/*
+ * Security module hook list structure.
+ * For use with generic list macros for common operations.
+ */
+struct security_hook_list {
+ struct list_headlist;
+ struct list_head*head;
+ union security_list_options hook;
+};
+
+/*
* Initializing a security_hook_list structure takes
* up a lot of space in a source file. This macro takes
* care of the common case and reduces the amount of
* text involved.
- * Casey says: Comment is true in the next patch.
*/
-#define LSM_HOOK_INIT(HEAD, HOOK) .HEAD = HOOK
+#define LSM_HOOK_INIT(HEAD, HOOK) \
+ { .head = _hook_heads.HEAD, .hook = { .HEAD = HOOK } }
+
+extern struct security_hook_heads security_hook_heads;
/* prototypes */
-extern int security_module_enable(struct security_operations *ops);
-extern int register_security(struct security_operations *ops);
-extern void __init security_fixup_ops(struct security_operations *ops);
-extern void reset_security_ops(void);
+extern int security_module_enable(const char *module);
+extern void security_add_hooks(struct security_hook_list *hooks, int count);
+#ifdef CONFIG_SECURITY_SELINUX_DISABLE
+extern void security_delete_hooks(struct security_hook_list *hooks, int count);
+#endif
#endif /* CONFIG_SECURITY */
diff --git a/include/linux/security.h b/include/linux/security.h
index 884fe9f..04e2a3e 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
struct linux_binprm;
struct cred;
@@ -100,6 +101,7 @@ extern int cap_task_setscheduler(struct task_struct *p);
extern int cap_task_setioprio(struct task_struct *p, int ioprio);
extern int cap_task_setnice(struct task_struct *p, int nice);
extern int cap_vm_enough_memory(struct mm_struct *mm, long pages);
+extern void capability_add_hooks(void);
struct msghdr;
struct sk_buff;
@@ -472,7 +474,7 @@ static inline int security_settime(const struct timespec
*ts,
static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long
pages)
{
- return cap_vm_enough_memory(mm, pages);
+ return __vm_enough_memory(mm, pages, cap_vm_enough_memory(mm, pages));
}
static inline int security_bprm_set_creds(struct linux_binprm *bprm)
@@ -1651,36 +1653,9 @@ static inline void free_secdata(void *secdata)
{ }
#endif /* CONFIG_SECURITY */
-#ifdef CONFIG_SECURITY_YAMA
-extern int yama_ptrace_access_check(struct task_struct *child,
-
[PATCH 7/7 v21] LSM: Remove unused capability.c
Subject: [PATCH 7/7 v21] LSM: Remove unused capability.c
The stub functions in capability.c are no longer required
with the list based stacking mechanism. Remove the file.
Signed-off-by: Casey Schaufler
---
security/capability.c | 1164 -
1 file changed, 1164 deletions(-)
diff --git a/security/capability.c b/security/capability.c
deleted file mode 100644
index 20249d1..000
--- a/security/capability.c
+++ /dev/null
@@ -1,1164 +0,0 @@
-/*
- * Capabilities Linux Security Module
- *
- * This is the default security module in case no other module is loaded.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include
-
-static int cap_binder_set_context_mgr(struct task_struct *mgr)
-{
- return 0;
-}
-
-static int cap_binder_transaction(struct task_struct *from,
- struct task_struct *to)
-{
- return 0;
-}
-
-static int cap_binder_transfer_binder(struct task_struct *from,
- struct task_struct *to)
-{
- return 0;
-}
-
-static int cap_binder_transfer_file(struct task_struct *from,
- struct task_struct *to, struct file *file)
-{
- return 0;
-}
-
-static int cap_syslog(int type)
-{
- return 0;
-}
-
-static int cap_quotactl(int cmds, int type, int id, struct super_block *sb)
-{
- return 0;
-}
-
-static int cap_quota_on(struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_bprm_check_security(struct linux_binprm *bprm)
-{
- return 0;
-}
-
-static void cap_bprm_committing_creds(struct linux_binprm *bprm)
-{
-}
-
-static void cap_bprm_committed_creds(struct linux_binprm *bprm)
-{
-}
-
-static int cap_sb_alloc_security(struct super_block *sb)
-{
- return 0;
-}
-
-static void cap_sb_free_security(struct super_block *sb)
-{
-}
-
-static int cap_sb_copy_data(char *orig, char *copy)
-{
- return 0;
-}
-
-static int cap_sb_remount(struct super_block *sb, void *data)
-{
- return 0;
-}
-
-static int cap_sb_kern_mount(struct super_block *sb, int flags, void *data)
-{
- return 0;
-}
-
-static int cap_sb_show_options(struct seq_file *m, struct super_block *sb)
-{
- return 0;
-}
-
-static int cap_sb_statfs(struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_sb_mount(const char *dev_name, struct path *path,
- const char *type, unsigned long flags, void *data)
-{
- return 0;
-}
-
-static int cap_sb_umount(struct vfsmount *mnt, int flags)
-{
- return 0;
-}
-
-static int cap_sb_pivotroot(struct path *old_path, struct path *new_path)
-{
- return 0;
-}
-
-static int cap_sb_set_mnt_opts(struct super_block *sb,
- struct security_mnt_opts *opts,
- unsigned long kern_flags,
- unsigned long *set_kern_flags)
-
-{
- if (unlikely(opts->num_mnt_opts))
- return -EOPNOTSUPP;
- return 0;
-}
-
-static int cap_sb_clone_mnt_opts(const struct super_block *oldsb,
- struct super_block *newsb)
-{
- return 0;
-}
-
-static int cap_sb_parse_opts_str(char *options, struct security_mnt_opts *opts)
-{
- return 0;
-}
-
-static int cap_dentry_init_security(struct dentry *dentry, int mode,
- struct qstr *name, void **ctx,
- u32 *ctxlen)
-{
- return -EOPNOTSUPP;
-}
-
-static int cap_inode_alloc_security(struct inode *inode)
-{
- return 0;
-}
-
-static void cap_inode_free_security(struct inode *inode)
-{
-}
-
-static int cap_inode_init_security(struct inode *inode, struct inode *dir,
- const struct qstr *qstr, const char **name,
- void **value, size_t *len)
-{
- return -EOPNOTSUPP;
-}
-
-static int cap_inode_create(struct inode *inode, struct dentry *dentry,
- umode_t mask)
-{
- return 0;
-}
-
-static int cap_inode_link(struct dentry *old_dentry, struct inode *inode,
- struct dentry *new_dentry)
-{
- return 0;
-}
-
-static int cap_inode_unlink(struct inode *inode, struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_inode_symlink(struct inode *inode, struct dentry *dentry,
-const char *name)
-{
- return 0;
-}
-
-static int cap_inode_mkdir(struct inode *inode, struct dentry *dentry,
- umode_t mask)
-{
- return 0;
-}
-
-static int cap_inode_rmdir(struct inode *inode, struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_inode_mknod(struct inode *inode, struct dentry *dentry,
-
