On Thu, Nov 07, 2013 at 05:31:08AM +0100, Mike Galbraith wrote:
> On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote:
> > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote:
>
> > > I bet you are trying to work around some of the side effects of the
> > > occasional tick which is stil
On Fri, 2013-11-08 at 14:20 +1100, NeilBrown wrote:
> In particular fix the capitalisation of GPIO and LED and
> correct TCA6507_MAKE_CPIO, but also rewrite the comment about
> platform-data to include reference to devicetree.
trivia:
> diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds
Hi,
Reccently people reported kexec didn't work correctly. After check, it's
a regression. Since a code block which migrate current thread to cpu0
when executing "kexec -e", this can be reproduced by setting affinity to
CPUn(n!=0). You can find this patch in this link:
https://lkml.org/lkml/2013/1
HI Bjorn,
Thanks for your review and comments very much!
>> +list_for_each_entry(dmar_dev, head, list)
>> +if (dmar_dev->segment == pci_domain_nr(dev->bus)
>> +&& dmar_dev->bus == dev->bus->number
>> +&& dmar_dev->devfn
For all uapi headers, need use "_UAPI" prefix for its guard macro
(which will be stripped by "scripts/headers_installer.sh").
Additional completions:
- be sure that all "endif" need be appended related comment, also it
has and only has one empty line above and no any lines below either.
- b
2013/11/8 Rusty Russell :
> Axel Lin writes:
>> 2013/11/7 Ming Lei :
>>> Hi,
>>>
>>> On Thu, Nov 7, 2013 at 10:47 AM, Axel Lin wrote:
hi Ming,
Seems CONFIG_PAGE_OFFSET is not configurabe in "make menuconfig".
And I found CONFIG_PAGE_OFFSET=0xC000 for all below configs...
>
* Peter Zijlstra (pet...@infradead.org) wrote:
[...]
Hi Peter,
Looking at this simplified version of perf's ring buffer
synchronization, I get concerned about the following issue:
> /*
> * One important detail is that the kbuf part and the kbuf_writer() are
> * strictly per cpu and we can thu
According to the datasheet[1], the Interrupt IRQ Pending Registers are
read-only. The implementation of sun4i_irq_ack() is wrong because it writes
to these read-only registers.
This patch removes the wrong irq_ack callback implementation and all the code
writing to these read-only registers in sun
(2013/11/08 12:30), Baoquan He wrote:
Hi,
Reccently people reported kexec didn't work correctly. After check, it's
a regression. Since a code block which migrate current thread to cpu0
when executing "kexec -e", this can be reproduced by setting affinity to
CPUn(n!=0). You can find this patch in
>>> Hi Ming,
>>>
>>> I found in arch/arm/include/asm/memory.h:
>>> CONFIG_PAGE_OFFSET is not used if !CONFIG_MMU.
>>> So looks like setting CONFIG_PAGE_OFFSET to other value still won't work.
>>
>> This seems like the simplest solution, but it may mean you still have
>> crap in /proc/kallsyms.
>>
>
Current tracing_saved_cmdlines_read() implementation is naive;
simply allocate a big buffer, construct output data on the
buffer for each read operation, and then copy a portion of
the buffer to the user space buffer. This can cause a couple of
issues such as a slow memory allocation, high cpu usa
Hi,
This patch set introduces the new I/F "nr_saved_cmdlines" for increasing
the number of saved cmdlines. Current saved_cmdlines can store just 128 command
names and PIDs, but process names are often lost like <...> when we read trace
data. If the process exists, we can get the name by using ps
Version 4. I think I have addressed all of Ingo's comments plus a few
extra refactorings.
Ingo: updated responses to your comment:
1. out-pages and rounding up to power of 2
- leveraging the same code used for mmap-pages. A follow on patch
will do that for both mmap use cases.
2. what ha
Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
'no-existing processes' names are often lost in saved_cmdlines when we
read trace data. So, by introducing nr_saved_cmdlines I/F, the rule storing
128 c
When recording raw_syscalls for the entire system, e.g.,
perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
you end up with a negative feedback loop as perf itself calls write() fairly
often. This patch handles the problem by mmap'ing the file in chunks of 64M at
a time and copies
Code move only; no logic changes. In preparation for the mmap
based output option in the next patch.
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Mike Galbraith
Cc: Stephane Eranian
---
tools/perf/builtin-record.c
Hello All:
I guess COPYING is our GPL License file, it already contents related
Free Software Foundation address. Do we also need content related web
site link?
When make patch for "arch/arm64/include/uapi/", "scripts/checkpatch.pl"
will report the issue below:
ERROR: Do not include the paragr
Currently perf requires the -m / --mmap_pages option to be a power of 2.
To be more user friendly perf should automatically round this up to the
next power of 2.
Currently:
$ perf record -m 3 -a -- sleep 1
--mmap_pages/-m value must be a power of two.sleep: Terminated
With patch:
$ perf rec
On 8 November 2013 00:27, Rafael J. Wysocki wrote:
> On Thursday, November 07, 2013 10:39:38 AM Viresh Kumar wrote:
>> We need another patch for fixing the other part of code where we
>> increase freq..
>> We need to replace:
>>
>> if (dbs_info->requested_freq == policy->max)
>> return;
>>
>>
On 8 November 2013 00:36, Stratos Karafotis wrote:
> I think the existing code already checks if the requested_freq is greater
> than policy->max in __cpufreq_driver_target.
Yes it does. But the problem is:
- cs_check_cpu() sets requested_freq above policy->max
- We execute following code because
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/net/virtio_net.c between commit 9bb8ca86075f ("virtio-net: switch
to use XPS to choose txq") from the net-next tree and commit 827da44c6141
("net: Explicitly initialize u64_stats_sync structures for lockdep") from
the tip t
Hi, Viresh, Sorry for the late reply.
I'll prepare the patch.
BTW, do you think we should set requeste_freq to policy->max when such
condition happens?
Thanks
Xiaoguang
2013/11/8 Viresh Kumar :
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if th
On 8 November 2013 10:31, Xiaoguang Chen wrote:
> Hi, Viresh, Sorry for the late reply.
That's fine :)
> I'll prepare the patch.
Thanks.
> BTW, do you think we should set requeste_freq to policy->max when such
> condition happens?
I thought about that earlier, but then thought this would be a
Dan Carpenter writes:
> There is a stray unlock here which was not intended. I have removed it.
>
> Fixes: 3f9f3dfb5755 ('fat: add fat_fallocate operation')
> Signed-off-by: Dan Carpenter
>
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 03f716f..befedee 100644
> --- a/fs/fat/file.c
> +++
2013/11/8 Viresh Kumar :
> On 8 November 2013 10:31, Xiaoguang Chen wrote:
>> Hi, Viresh, Sorry for the late reply.
>
> That's fine :)
>
>> I'll prepare the patch.
>
> Thanks.
>
>> BTW, do you think we should set requeste_freq to policy->max when such
>> condition happens?
>
> I thought about that
Hi Pali,
Sorry for the late reply.
On 10/26/2013 03:21 AM, Pali Rohár wrote:
On Friday 25 October 2013 19:10:07 Bryan Wu wrote:
On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár
wrote:
On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote:
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim
wrote:
This pat
On Thu, Nov 07, 2013 at 06:26:47PM -0500, David Turner wrote:
> In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
> the {a,c,m}time fields, deferring the year 2038 problem to the year
> 2446. The representation (which this patch does not alter) is a bit
> hackish, in that the mo
Call try_to_freeze() in sleep_thread() only when it's safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these won't call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage
(2013/11/08 14:12), Atsushi Kumagai wrote:
> Hello Jingbai,
>
> (2013/11/07 17:58), Jingbai Ma wrote:
>> On 11/06/2013 10:23 PM, Vivek Goyal wrote:
>>> On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote:
> On Tue, Nov 05, 2013 at 09:45:32
On Thu, Nov 07, 2013 at 02:40:49PM +0100, Daniel Lezcano wrote:
> On 10/31/2013 06:24 AM, Simon Horman wrote:
> >On Tue, Oct 29, 2013 at 03:31:37PM +0100, Laurent Pinchart wrote:
> >>Prepare the clock at probe time, as there is no other appropriate place
> >>in the driver where we're allowed to sle
Hello Jingbai,
(2013/11/07 17:58), Jingbai Ma wrote:
> On 11/06/2013 10:23 PM, Vivek Goyal wrote:
>> On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
>>> (2013/11/06 5:27), Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
> This patch set inte
When decreasing frequency, requested_freq may be less than
freq_target, So requested_freq minus freq_target may be negative,
But reqested_freq's unit is unsigned int, then the negative result
will be one larger integer which may be even higher than
requested_freq.
This patch is to fix such issue.
When requested_freq is over policy->max, set it to policy->max.
This can help to speed up decreasing frequency.
Signed-off-by: Xiaoguang Chen
---
drivers/cpufreq/cpufreq_conservative.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufre
On 8 November 2013 10:53, Xiaoguang Chen wrote:
> When requested_freq is over policy->max, set it to policy->max.
> This can help to speed up decreasing frequency.
>
> Signed-off-by: Xiaoguang Chen
> ---
> drivers/cpufreq/cpufreq_conservative.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff
On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote:
> (2013/11/08 14:12), Atsushi Kumagai wrote:
>> Hello Jingbai,
>>
>> (2013/11/07 17:58), Jingbai Ma wrote:
>>> On 11/06/2013 10:23 PM, Vivek Goyal wrote:
On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
> (2013/11/06 5:27), Vi
On Thu, Nov 07, 2013 at 08:24:23PM +, Phillip Lougher wrote:
> Further generalise the decompressors by adding a page handler
> abstraction. This adds helpers to allow the decompressors
> to access and process the output buffers in an implementation
> independant manner.
>
> This allows differ
On Thu, Nov 07, 2013 at 08:24:24PM +, Phillip Lougher wrote:
> Restructure squashfs_readpage() splitting it into separate
> functions for datablocks, fragments and sparse blocks.
>
> Move the memcpying (from squashfs cache entry) implementation of
> squashfs_readpage_block into file_cache.c
>
On Thu, Nov 07, 2013 at 08:24:24PM +, Phillip Lougher wrote:
> Restructure squashfs_readpage() splitting it into separate
> functions for datablocks, fragments and sparse blocks.
>
> Move the memcpying (from squashfs cache entry) implementation of
> squashfs_readpage_block into file_cache.c
>
Hi Nicholas,
Today's linux-next merge of the target-updates tree got a conflict in
lib/percpu-refcount.c between commit 5e9dd373dea4 ("percpu_refcount:
export symbols") from Linus' tree and commit c9e8d128fe31
("percpu-refcount: Add EXPORT_SYMBOL to use percpu_ref from modules")
from the target-up
2013/11/8, OGAWA Hirofumi :
> Dan Carpenter writes:
>
>> There is a stray unlock here which was not intended. I have removed it.
>>
>> Fixes: 3f9f3dfb5755 ('fat: add fat_fallocate operation')
>> Signed-off-by: Dan Carpenter
>>
>> diff --git a/fs/fat/file.c b/fs/fat/file.c
>> index 03f716f..befed
From: "Lad, Prabhakar"
This patch series fixes gpio driver regestration
and offset check for unbanked gpio.
Lad, Prabhakar (2):
gpio: davinci: Fix a check for unbanked gpio
ARM: davinci: Fix number of resources passed to
davinci_gpio_register() call
arch/arm/mach-davinci/dm355.c |
From: "Lad, Prabhakar"
The davinci_gpio_register() function expects the number of
resources as the second parameter, but size of resources
was passed to it due to which it was causing unexpected
behaviour. This patch fixes the same by passing the
ARRAY_SIZE of resources.
Reported-by: Grygorii St
From: "Lad, Prabhakar"
This patch fixes a check for offset in gpio_to_irq_unbanked()
and also assigns gpio_irq, gpio_unbanked of chips[0] to
appropriate values which is used in gpio_to_irq_unbanked()
function.
Reported-by: Grygorii Strashko
Signed-off-by: Lad, Prabhakar
---
drivers/gpio/gpio-
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in
fs/namespace.c between commit aba809cf0944 ("namespace.c: get rid of
mnt_ghosts") from the vfs tree and commit 484df667efe9 ("vfs: Keep a list
of mounts on a mount point") from the userns tree.
I fixed it up (see below) and ca
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/namei.c
between commits 45b1139e249d ("namei: minor vfs_unlink cleanup"),
0e22d7c4652b ("locks: break delegations on unlink"), 5d375b9f8afb
("locks: helper functions for delegation breaking") and 909b30216356
("locks: break
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/dcache.c
between commit 84550b9356af ("RCU'd vfsmounts") from the vfs tree and
commit 40216baa0101 ("vfs: Lazily remove mounts on unlinked files and
directories. v2") from the userns tree.
I fixed it up (I think - see below
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/mount.h
between commits 84550b9356af ("RCU'd vfsmounts") and 474279dc0f77 ("split
__lookup_mnt() in two functions") from the vfs tree and commit
d7e58b8abc4f ("vfs: Add a function to lazily unmount all mounts from any
dentry
>> For further information, see "https://lkml.org/lkml/2013/8/6/550";
>
> Thanks for doing this. Could we please get some acked-by's or,
> preferably, tested-by's from the MTD people?
Acked-by: Ezequiel Garcia
Acked-by: Andrew Morton
--
To unsubscribe from this list: send the line "unsubscrib
Hi Eric,
After merging the userns tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/namei.c: In function 'covered':
fs/namei.c:3528:2: error: too many arguments to function '__lookup_mnt'
is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry, 1);
^
Caused
Dear Buyer,
I am Mr. Michael Doku, representative to my villagers in Ghana, we are
prepared to provide any quantities of 99.6% purity (23 karat+) alluvial
gold at any time of demand.
Below is the information of our Gold dust:
Quantity: Large Quantity available monthly
Quality: 23karat+ plus al
Joe Perches writes:
>> have a
>> second round of convincing ath guys to change printing code. How does
>> that sound?
>
> Luis? Kalle? Other Qualcomm/Atheros folk?
I didn't quite get what you are asking from me. But for me most
important is that the current debugging facilities from user's poi
Hi Eric,
After merging the userns tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/namespace.c: In function 'detach_mounts':
fs/namespace.c:1340:2: error: implicit declaration of function 'br_write_lock'
[-Werror=implicit-function-declaration]
br_write_lock(&vfsmou
Hi Sebastian,
On Nov 7, 2013, at 10:46 PM, Sebastian Andrzej Siewior wrote:
> On 07.11.13, Pantelis Antoniou wrote:
>> Hi Sebastian,
> Hi Pantelis,
>
>> FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and
>> possibly
>> others.
>
> Yes, I know. I am the one that did the
Hi Guenter,
On Nov 8, 2013, at 1:00 AM, Guenter Roeck wrote:
> On Thu, Nov 07, 2013 at 09:46:26PM +0100, Sebastian Andrzej Siewior wrote:
>> On 07.11.13, Pantelis Antoniou wrote:
>>> Hi Sebastian,
>> Hi Pantelis,
>>
>>> FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and
Hi Axel,
On Fri, Nov 8, 2013 at 12:20 PM, Axel Lin wrote:
>
>
> Hi Ming,
>
> I have patches on top of 3.12 to support gpl32700 SoC.
> So you cannot find this platform on mainline kernel.
OK, I see.
> I havn't tried perf, below is my config for your reference:
> (to make the config smaller, I gr
Hi Alan,
On Nov 8, 2013, at 1:38 AM, delicious quinoa wrote:
> On Tue, Nov 5, 2013 at 12:41 PM, Pantelis Antoniou
> wrote:
>> +
>> + pr_info("%s: Applied #%d overlay segments @%d\n", __func__,
>> + od->ovinfo_cnt, od->id);
>> +
>
> This could be pr_debug so that we g
> Nobody has had time to test this on MTD, it seems, and as such, I
> strongly recommend you do not force it through -mm. We are perfectly
> capable of merging it through the MTD tree if it ever gets proper
> vetting by people in MTD (not just on block devices), and I am well
> aware of this patch
Hi Al,
On Fri, 8 Nov 2013 17:50:55 +1100 Stephen Rothwell
wrote:
>
> Al, I do have to wonder why a commit whose whole commit message is:
>
> "RCU'd vfsmounts
>
> _very_ preliminary, barely tested."
>
> is in linux-next as is not being kept over for v3.14 at this point.
Oh, I see, it was
In this context, a "doomed" object is an object whose refcount has reached
zero, but that has not yet been freed.
To avoid mutual refcounting vmwgfx need to have a non-refcounted pointer to
a dma-buf in a lookup structure. The pointer is removed in the dma-buf
destructor. To allow lookup-structure
From: Weng Meiling
Signed-off-by: Weng Meiling
---
fs/nfsd/nfsctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 7f55517..31db42c 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -188,7 +188,7 @@ static const struct file_o
From: Weng Meiling
Signed-off-by: Weng Meiling
---
net/sunrpc/svc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index b974571..e7fbe36 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1104,8 +1104,6 @@ svc_process_common(struct svc_rqst *rqs
On Fri, Nov 08, 2013 at 05:58:48PM +1100, Stephen Rothwell wrote:
> Hi Eric,
>
> After merging the userns tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/namei.c: In function 'covered':
> fs/namei.c:3528:2: error: too many arguments to function '__lookup_mnt'
>
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
forbid open via /proc") from the akpm-current tree.
I just dropped the ak
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote:
> An untested patch that gets rid of the RCU_SOFTIRQs in this case is below.
Yup, toasted.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
Btw, I have to state that I very much disagree with dropping the
direct I/O kernel changes, and I also very much disagree with keeping
the immutable iovecs in.
For the latter I think the immutable iovecs are useful and do want to
see them eventually, but they were merged at the latest possible poi
By following works, my system very often fails set_variable() to set new
variable to efi variable storage and shows "efivars: set_variable() failed:
status=-28" message.
- commit 31ff2f20d9003e74991d135f56e503fe776c127c
efi: Distinguish between "remaining space" and actually used space
- commi
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/autofs4/inode.c between commit baa40671d3e3 ("autofs4: make freeing
sbi rcu-delayed") from the vfs tree and commit e4af471815fc ("autofs4:
allow autofs to work outside the initial PID namespace") from the
akpm-curren
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
include/linux/lglock.h between commit 4314ff760e8b ("no need to keep
brlock macros anymore...") from the vfs tree and commit f5639052d567
("lglock: map to spinlock when !CONFIG_SMP") from the akpm-current tree.
I fixed
On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote:
> On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote:
> > Hi all,
> >
> > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for
> > locking bits.
> >
> > To remedy this Ingo suggested gathering al
On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote:
> The changes for direct I/O from kernel space have been in for a long
> time, and they are blocking multiple consumers of the interface from
> getting submitted for about a year now. Even if the guts of the
> direct-io code will g
On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote:
> On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote:
> > The changes for direct I/O from kernel space have been in for a long
> > time, and they are blocking multiple consumers of the interface from
> > getting submitt
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
kernel/Makefile between commits 60fc28746a7b ("locking: Move the spinlock
code to kernel/locking/") and cd4d241d57c9 ("locking: Move the lglocks
code to kernel/locking/") from the tip tree and commit f5639052d567
("lglo
Date 7.11.2013 21:04, Joe Perches wrote:
> Jaroslav hasn't acked or signed a patch in quite awhile.
It does not mean that I'm not willing to continue the kernel code
maintenance when Takashi is offline. Keep me in. You may reorder M: lines.
> Mark ISAPnp and HP VG/AnyLAN driver as orphan.
I agre
On 05/11/13 19:31, Arnaldo Carvalho de Melo wrote:
> PeterZ,
>
> Can I have your Acked-by for this one? I guess now the goal is
> achieved, no?
Ping
>
> - Arnaldo
>
> Em Tue, Nov 05, 2013 at 11:25:45AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Nov 05, 2013 at 02:30:24PM +0100, Ji
On Thu, Nov 07, 2013 at 11:44:45PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote:
> > On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote:
> > > The changes for direct I/O from kernel space have been in for a long
> > > time, and the
601 - 675 of 675 matches
Mail list logo
