- 20 May, 2012 17 commits
-
-
Matt Carlson authored
[ Upstream commit f891ea16 ] When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Gerard Lledo authored
[ Upstream commit 5a8887d3 ] WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by:
Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit e072b3fa ] Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by:
Mirko Lindner <mlindner@marvell.com> Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 3f42941b ] When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by:
-
Sasha Levin authored
[ Upstream commit 84768edb ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270f ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 7d3d43da ] We already synthesize events in register_netdevice_notifier and synthesizing events in unregister_netdevice_notifier allows to us remove the need for special case cleanup code. This change should be safe as it adds no new cases for existing callers of unregiser_netdevice_notifier to handle. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 116a0fc3 ] skb_checksum_help(skb) can return an error, we must free skb in this case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if skb_unshare() failed), so lets use this generic helper. Signed-off-by:
-
Ingo van Lil authored
[ Upstream commit 2a580949 ] The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by:
Ingo van Lil <inguin@gmx.de> Signed-off-by:
-
Russ Anderson authored
commit 6bc2e853 upstream. Systems with 8 TBytes of memory or greater can hit a problem where only the the first 8 TB of memory shows up. This is due to "int i" being smaller than "unsigned long start_aligned", causing the high bits to be dropped. The fix is to change `i' to unsigned long to match start_aligned and end_aligned. Thanks to Jack Steiner for assistance tracking this down. Signed-off-by:
Russ Anderson <rja@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mike Galbraith authored
commit 5e2bf014 upstream. Fork() failure post namespace creation for a child cloned with CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted during creation, but not unmounted during cleanup. Call pid_ns_release_proc() during cleanup. Signed-off-by:
Mike Galbraith <efault@gmx.de> Acked-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
-
Chris Metcalf authored
commit 4998a6c0 upstream. Commit 66aebce7 ("hugetlb: fix race condition in hugetlb_fault()") added code to avoid a race condition by elevating the page refcount in hugetlb_fault() while calling hugetlb_cow(). However, one code path in hugetlb_cow() includes an assertion that the page count is 1, whereas it may now also have the value 2 in this path. The consensus is that this BUG_ON has served its purpose, so rather than extending it to cover both cases, we just remove it. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Acked-by:
Mel Gorman <mel@csn.ul.ie> Acked-by:
Hillf Danton <dhillf@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Tejun Heo authored
commit 42b64281 upstream. pcpu_embed_first_chunk() allocates memory for each node, copies percpu data and frees unused portions of it before proceeding to the next group. This assumes that allocations for different nodes doesn't overlap; however, depending on memory topology, the bootmem allocator may end up allocating memory from a different node than the requested one which may overlap with the portion freed from one of the previous percpu areas. This leads to percpu groups for different nodes overlapping which is a serious bug. This patch separates out copy & partial free from the allocation loop such that all allocations are complete before partial frees happen. This also fixes overlapping frees which could happen on allocation failure path - out_free_areas path frees whole groups but the groups could have portions freed at that point. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
"Pavel V. Panteleev" <pp_84@mail.ru> Tested-by:
-
David Henningsson authored
commit 32cf4023 upstream. When an IRQ for some reason gets lost, we wait up to a second using udelay, which is CPU intensive. This patch improves the situation by waiting about 30 ms in the CPU intensive mode, then stepping down to using msleep(2) instead. In essence, we trade some granularity in exchange for less CPU consumption when the waiting time is a bit longer. As a result, PulseAudio should no longer be killed by the kernel for taking up to much RT-prio CPU time. At least not for *this* reason. Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Tested-by:
Arun Raghavan <arun.raghavan@collabora.co.uk> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ben Hutchings authored
commit 48d99f47 upstream. Commit 554cdaef ('ARM: orion5x: Refactor mpp code to use common orion platform mpp.') seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error: [ 12.711476] leds-gpio: probe of leds-gpio failed with error -22 Reported-by:
Henry von Tresckow <hvontres@gmail.com> References: http://bugs.debian.org/667446Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
Mark Hills authored
commit c914f55f upstream. This assertion seems to imply that chip->dsp_code_to_load is a pointer. It's actually an integer handle on the actual firmware, and 0 has no special meaning. The assertion prevents initialisation of a Darla20 card, but would also affect other models. It seems it was introduced in commit dd7b254d. ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000 ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware... ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20 ------------[ cut here ]------------ WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]() Hardware name: Dell DM051 BUG? (!chip->dsp_code_to_load || !chip->comm_page) Signed-off-by:
Mark Hills <mark@pogo.org.uk> Signed-off-by:
-
Archit Taneja authored
commit 08ca7444 upstream. This reverts commit 46f8c3c7. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Archit Taneja <archit@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Axel Lin authored
commit f55205f4 upstream. I think this is a typo. To ensure new voltage setting won't greater than desc->max, the equation should be desc->min + desc->step * new_val <= desc->max. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
- 11 May, 2012 23 commits
-
-
Ben Hutchings authored
-
Paolo Pisati authored
commit 07d69d42 upstream. Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Tested on my Beagle XM. v2: added mantainer to the list of recipient Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by:
-
Larry Finger authored
commit 2080913e upstream. In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine. In combination with the bug introduced in commit a5ee6529 "staging: r8712u: Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833. Tested-by:
Alberto Lago Ballesteros <saniukeokusainaya@gmail.com> Tested-by:
Adrian <agib@gmx.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Oleg Nesterov authored
commit b6e238dc upstream. exit_notify() changes ->exit_signal if the parent already did exec. This doesn't really work, we are not going to send the signal now if there is another live thread or the exiting task is traced. The parent can exec before the last dies or the tracer detaches. Move this check into do_notify_parent() which actually sends the signal. The user-visible change is that we do not change ->exit_signal, and thus the exiting task is still "clone children" for do_wait()->eligible_child(__WCLONE). Hopefully this is fine, the current logic is racy anyway. Signed-off-by:
-
Oleg Nesterov authored
commit e6368253 upstream. exit_notify() checks "tsk->self_exec_id != tsk->parent_exec_id" to handle the "we have changed execution domain" case. We can change do_thread() to always set ->exit_signal = SIGCHLD and remove this check to simplify the code. We could change setup_new_exec() instead, this looks more logical because it increments ->self_exec_id. But note that de_thread() already resets ->exit_signal if it changes the leader, let's keep both changes close to each other. Note that we change ->exit_signal lockless, this changes the rules. Thereafter ->exit_signal is not stable under tasklist but this is fine, the only possible change is OLDSIG -> SIGCHLD. This can race with eligible_child() but the race is harmless. We can race with reparent_leader() which changes our ->exit_signal in parallel, but it does the same change to SIGCHLD. The noticeable user-visible change is that the execing task is not "visible" to do_wait()->eligible_child(__WCLONE) right after exec. To me this looks more logical, and this is consistent with mt case. Signed-off-by:
-
Wey-Yi Guy authored
commit 1ed2ec37 upstream. "iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Meenakshi Venkataraman authored
commit 78cbcf2b upstream. Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by:
-
Johannes Berg authored
commit b9148115 upstream. Since the uCode hasn't been released (yet?), warn only if using older than API 4, but load anything up to API 6. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Tejun Heo authored
commit d5e28005 upstream. With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE or PMD_SIZE for atom_size. PMD_SIZE is used when CPU supports PSE so that percpu areas are aligned to PMD mappings and possibly allow using PMD mappings in vmalloc areas in the future. Using larger atom_size doesn't waste actual memory; however, it does require larger vmalloc space allocation later on for !first chunks. With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem but x86_32 at this point is anything but reasonable in terms of address space and using larger atom_size reportedly leads to frequent percpu allocation failures on certain setups. As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space is aplenty and most x86_64 configurations support PSE, fix the issue by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32. v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and x86_32 PAGE_SIZE as suggested by hpa. Signed-off-by:
Yanmin Zhang <yanmin.zhang@intel.com> Reported-by:
ShuoX Liu <shuox.liu@intel.com> Acked-by:
H. Peter Anvin <hpa@zytor.com> LKML-Reference: <4F97BA98.6010001@intel.com> Signed-off-by:
-
David Vrabel authored
commit 76a8df7b upstream. The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Acked-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> [v1: Fixed compile error when CONFIG_PCI is not set] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit b7e5ffe5 upstream. If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [<ffffffff8106aa51>] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. 'ptdump_show' bitshifts it and gets and invalid value that it tries to dereference. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. This bug has been in existence .. at least until 2.6.37 (yikes!) Signed-off-by:
-
Daniel Vetter authored
commit 2e7a4481 upstream. I've flagged this while reviewing the first version and Ken Graunke fixed it up in v2, but unfortunately Dave Airlie picked up the wrong version. Cc: Dave Airlie <airlied@redhat.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
commit 768b107e upstream. Chris Wilson dug out a hw erratum saying that there's noise on the interrupt line on i945G chips. We also have a bug report from a i945GM chip with an sdvo hotplug interrupt storm (and no apparent cause). Play it safe and disable sdvo hotplug on all i945 variants. Note that this is a regression that has been introduced in 3.1, when we've enabled sdvo hotplug support with commit cc68c81a Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Date: Wed Sep 21 17:13:30 2011 +0100 drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442Reported-and-tested-by:
Dominik Köppl <dominik@devwork.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
-
Colin Cross authored
commit fde165b2 upstream. Commit 4e8ee7de (ARM: SMP: use idmap_pgd for mapping MMU enable during secondary booting) switched secondary boot to use idmap_pgd, which is initialized during early_initcall, instead of a page table initialized during __cpu_up. This causes idmap_pgd to contain the static mappings but be missing all dynamic mappings. If a console is registered that creates a dynamic mapping, the printk in secondary_start_kernel will trigger a data abort on the missing mapping before the exception handlers have been initialized, leading to a hang. Initial boot is not affected because no consoles have been registered, and resume is usually not affected because the offending console is suspended. Onlining a cpu with hotplug triggers the problem. A workaround is to the printk in secondary_start_kernel until after the page tables have been switched back to init_mm. Signed-off-by:
Colin Cross <ccross@android.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Tim Bird authored
commit e787ec13 upstream. The inline assembly in kernel_execve() uses r8 and r9. Since this code sequence does not return, it usually doesn't matter if the register clobber list is accurate. However, I saw a case where a particular version of gcc used r8 as an intermediate for the value eventually passed to r9. Because r8 is used in the inline assembly, and not mentioned in the clobber list, r9 was set to an incorrect value. This resulted in a kernel panic on execution of the first user-space program in the system. r9 is used in ret_to_user as the thread_info pointer, and if it's wrong, bad things happen. Signed-off-by:
Tim Bird <tim.bird@am.sony.com> Signed-off-by:
-
Kusanagi Kouichi authored
commit 7c77cda0 upstream. sh_symtab is set but not used. [ hpa: putting this in urgent because of the sheer harmlessness of the patch: it quiets a build warning but does not change any generated code. ] Signed-off-by:
Kusanagi Kouichi <slash@ac.auone-net.jp> Link: http://lkml.kernel.org/r/20120401082932.D5E066FC03D@msa105.auone-net.jpSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
H. Peter Anvin authored
commit f5c2347e upstream. <asm-generic/statfs.h> is exported to userspace, so using BITS_PER_LONG is invalid. We need to use __BITS_PER_LONG instead. This is kernel bugzilla 43165. Reported-by:
H.J. Lu <hjl.tools@gmail.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Eric Bénard authored
commit e875c1e3 upstream. * commit f9dfbf91 "ASoC: tlv320aic23: convert to soc-cache" leads to a bug preventing resumeof the codec as regmap expects a 9 bits data register but 0xFFFF is passed in tlv320aic23_set_bias_level and this values gets cached preventing any write to the TLV320AIC23_PWR register as the final value produced by regmap is (register << 9) | value * this patch solves the problem by only working on the 9 bits the register contains. Signed-off-by:
Eric Bénard <eric@eukrea.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 6f24f892 upstream. Commit ec81aecb ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by:
Timo Warns <warns@pre-sense.de> Acked-by:
WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Johannes Berg authored
commit 5ef4acd5 upstream. Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Signed-off-by:
-
Stanislaw Gruszka authored
commit 8db4c7e2 upstream. ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 4c1bcdb5 upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 328c32f0 upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by:
-
