* [U-Boot] [PATCH 02/39] GCC4.6: Squash warnings in common/usb.c
From: Stefano Babic @ 2011-10-24 12:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-3-git-send-email-marek.vasut@gmail.com>
On 10/22/2011 02:16 AM, Marek Vasut wrote:
> usb.c: In function ?usb_parse_config?:
> usb.c:331:17: warning: variable ?ch? set but not used
> [-Wunused-but-set-variable]
> usb.c: In function ?usb_hub_port_connect_change?:
> usb.c:1123:29: warning: variable ?portchange? set but not used
> [-Wunused-but-set-variable]
> usb.c: In function ?usb_hub_configure?:
> usb.c:1183:25: warning: variable ?hubsts? set but not used
> [-Wunused-but-set-variable]
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Mike Frysinger <vapier@gentoo.org>
> ---
> common/usb.c | 21 +++++++--------------
> 1 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/common/usb.c b/common/usb.c
> index 2cd50db..bed5116 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -56,16 +56,16 @@
> #endif
>
> #ifdef DEBUG
> -#define USB_DEBUG
> -#define USB_HUB_DEBUG
> -#endif
> -
> -#ifdef USB_DEBUG
> -#define USB_PRINTF(fmt, args...) printf(fmt , ##args)
> +#define USB_DEBUG 1
> +#define USB_HUB_DEBUG 1
Why do you nedd to set a value when then later to check only with #ifdef
if it is defined or not ?
> #else
> -#define USB_PRINTF(fmt, args...)
> +#define USB_DEBUG 0
> +#define USB_HUB_DEBUG 0
Maybe #undef ?
Best regards,
Stefano babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [RFC] mac80211: Fix STA supported rate configuration with dummy entry
From: Jouni Malinen @ 2011-10-24 12:15 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Johannes Berg, Felix Fietkau, linux-wireless
In-Reply-To: <CA+XVXfdP5VjMLaYxh6Saa+SM+cDUG+h18L0ixheQmaAo+yQX+Q@mail.gmail.com>
On Mon, Oct 24, 2011 at 01:59:45PM +0200, Arik Nemtsov wrote:
> Note that the sta-rates are not really required before second addition
> (which also sets them). Initially the STA is not authorized for direct
> Tx (as determined by the WLAN_STA_TDLS_PEER_AUTH bit).
> We don't expect direct frames during link setup.
OK.. Though, there can still be some direct frames like TDLS Discovery
Response.
> The STA is added to let us know we should drop all non-setup packets
> between TDLS peers currently in link setup. We could have used a
> different indication, but the STA entry is make the most sense here
> since it is automatically cleaned up when we are disconnected from the
> AP (as all TDLS state should be).
When you say "drop", I hope you mean "buffer for later delivery" and
when you say "non-setup packets", I hope you mean "non-setup Data
frames" ;-).
> How about this one instead (tested hwsim with it):
> Subject: [RFC] mac80211: init rate-control for TDLS sta when supp-rates are
> known
>
> Initialize rate control algorithms only when supported rates are known
> for a TDLS peer sta. Direct Tx between peers is not allowed before the
> link is enabled. In turn, this only occurs after a change_station()
> call that sets supported rates.
I guess this could be fine, too, assuming TDLS is the only use case for
this type of changing of STA supported rates.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [linux-lvm] Changing dev_t-devname mapping in lvmlib seems to be problematic
From: Alexander Lyakas @ 2011-10-24 12:16 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
In-Reply-To: <CAJJYPdkzu_SXGjuoUmfMVOA_UJhAFsnZWf8z41pfGUxJFMT6xA@mail.gmail.com>
Hi Zdenek,
It appears that I don't understand part of your comments, or perhaps
we have a disconnect.
> Not really sure about lvmlib API capabilities - IMHO I'd not use it
> for anything else then lvs-like operations ATM. �(since there are
> quite a few rules to avoid deadlocks) If it's not a problem for you
> app I'd suggest to use lvm2cmd library preferable in a separate forked
> small process so there could be full control over memory and file
> descriptors....
Do you suggest not to use lvmlib at all? And always use command-line
LVM tools from within a forked process? Currently I use
command-line/fork only for pvcreate/pvremove, since these APIs are not
available in lvmlib.
> dm-xxx devices are created dynamicaly - there is currently no way to
> have a fixed dm device node and it would be quite ugly to provide such
> feature.
I did not understand this comment. Do you mean the dm-xxx devices that
LVM creates for its LVs? I was talking about dm-linear devices that I
use for PVs.
>
> So at dm level - you could use � /dev/mapper/devicename however at lvm
> level the only supported way �is /dev/vg/lv
> (even though they are visible through /dev/mapper �- only /dev/vg �are
> meant to be 'public')
Again, do you mean the LV dm-xxx devices? I was talking about PV
devices, which are dm-linear in my case.
> Yes, there is locking, so as long as you are using only lvm tools,
> there should be no collisions.
What I meant here, is that each time a command-line tool is invoked,
it has a fresh instance of caches of its own. While in my application,
if I keep the lvm_t handle open, then the caches within lvm are not
cleaned up. This (plus the change in dev_t) causes the problem I am
seeing.
> Recent versions of lvm should be getting list of block devices for
> scanning from udev, and then more filters are applied.
Is there an option to restrict this list only to certain devices? In
my system there is no point of scanning all the devices.
All in all, I fixed my code to issue lvm_config_reload() before each
LVM operation. This cleans all the caches, so I am not seeing the
problem anymore.
Basically, I looked at the various caches code in the LVM, and they
seem quite dangerous to me, if not refreshed before each LVM
operation. Since most LVM usage (I presume) is done via command-line
tools, which create a new process (i.e., new caches) each time
invoked, not sure how big is the gain of caching. But I am probably
not seeing the whole picture.
Thanks,
Alex.
^ permalink raw reply
* Re: Information Request
From: Dušan Čolić @ 2011-10-24 12:17 UTC (permalink / raw)
To: Matias Seco; +Cc: reiserfs-devel
In-Reply-To: <CAMjNLwoY2nx=1FczwigL0WSubKattSq69sZQT2veRUERbnqT3A@mail.gmail.com>
Hello,
You can find enough informations in a FAQ I made for Gentoo
http://forums.gentoo.org/viewtopic-p-5200706.html#5200706
Have fun
Dushan
On Mon, Oct 24, 2011 at 2:10 PM, Matias Seco <matias.jose.seco@gmail.com> wrote:
> Greetings,
> i found very interesting about testing this filesystem. Unfortunately
> i got late with my project, because i couldn't find useful resources
> from google for reiser4,
> mainly because the reiser4's kernel Wiki was down due to maintenaince.
> After time, i saw that the page still didn't return: this is why i
> would like to ask you, if you can point me resources, to understand
> how to configure the reiser4 on my HDD.
>
> Salut, Matias
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [DVB] Digital Devices Cine CT V6 support
From: Sébastien RAILLARD (COEXSI) @ 2011-10-24 12:18 UTC (permalink / raw)
To: 'Linux Media Mailing List'
In-Reply-To: <201110240906.24543@orion.escape-edv.de>
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Oliver Endriss
> Sent: lundi 24 octobre 2011 09:06
> To: Sébastien RAILLARD (COEXSI)
> Cc: Linux Media Mailing List
> Subject: Re: [DVB] Digital Devices Cine CT V6 support
>
> Hi,
>
> > Using your latest development tree (hg clone
> > http://linuxtv.org/hg/~endriss/media_build_experimental), I have made
> > a small modification in ddbridge-core.c (see below) to make the new
> > "Cine CT V6" card detected by the ddbridge module.
> >
> > With this small patch, the card is now detected, but not the double
> > C/T tuner onboard.
>
> This cannot work, as the cards requires different frontend drivers.
>
> Please try a fresh check-out from
> http://linuxtv.org/hg/~endriss/media_build_experimental
>
> The Cine CT v6 is supported now.
>
Thank you for the update, we'll test it soon, we're waiting for the new
double-CI reader support.
I've seen a new parameter "ts_loop", can you explain how it's working?
Is-it for sending the stream from the demodulator directly to the CAM
reader?
> > Also, I was wondering why they put a male and a female RF connectors
> > on the "Cine CT V6" (maybe a loop-through?) where there are two female
> > RF connectors on the "DuoFlex CT" card.
>
> The second connector of the Cine CT is the loop-through output.
>
Ok
> CU
> Oliver
>
> --
> ----------------------------------------------------------------
> VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
> 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
> Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
> ----------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA55076.2010701@stericsson.com>
On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> [Russell]
>> The MCIPWR signal controls the external power switch. ?This is the only
>> signal for it. ?This is the only connection for it. ?There is no other
>> control form for this power switch.
>>
>
> Then we are only left to use the variant struct I believe. In principle, a
> flag in the variant struct, could indicate whether it is OK to disable the
> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
Yep I think the best could be to add some variant named
bool external_card_power; and then document in the kerneldoc that this
means the driver can clear MMCIPWR without risk of cutting the power
to the card.
This should be true for Ux500, U300 and Nomadik (just checked the designs -
they all have external regulators).
So the state save/restore and amba_vcore_disable(adev); should be done
only for those variants.
However this:
clk_disable(host->clk);
We ought to be able to do for *all* variants, provided we can create
pm_runtime_get/put and delay properly to cover all bus traffic
(looks like the patch already does that), plus all the time the card is
signalling busy. The best I can think of is to just return -EBUSY to runtime
PM like this:
if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
return -EBUSY;
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 12:18 UTC (permalink / raw)
To: Ulf Hansson
Cc: Russell King - ARM Linux, Sebastian Rasmussen,
linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4EA55076.2010701@stericsson.com>
On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> [Russell]
>> The MCIPWR signal controls the external power switch. This is the only
>> signal for it. This is the only connection for it. There is no other
>> control form for this power switch.
>>
>
> Then we are only left to use the variant struct I believe. In principle, a
> flag in the variant struct, could indicate whether it is OK to disable the
> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
Yep I think the best could be to add some variant named
bool external_card_power; and then document in the kerneldoc that this
means the driver can clear MMCIPWR without risk of cutting the power
to the card.
This should be true for Ux500, U300 and Nomadik (just checked the designs -
they all have external regulators).
So the state save/restore and amba_vcore_disable(adev); should be done
only for those variants.
However this:
clk_disable(host->clk);
We ought to be able to do for *all* variants, provided we can create
pm_runtime_get/put and delay properly to cover all bus traffic
(looks like the patch already does that), plus all the time the card is
signalling busy. The best I can think of is to just return -EBUSY to runtime
PM like this:
if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
return -EBUSY;
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V2 2/4] MIPS: Add board support for Loongson1B
From: Giuseppe CAVALLARO @ 2011-10-24 12:18 UTC (permalink / raw)
To: Kelvin Cheung
Cc: Wu Zhangjin, linux-mips, linux-kernel, ralf, r0bertz, netdev
In-Reply-To: <CAJhJPsVSzXXmBOwLaGNtOsxhVEyC0fAJtiBvEWzcKcSDC8NEcA@mail.gmail.com>
Hello Kelvin.
On 10/24/2011 12:36 PM, Kelvin Cheung wrote:
[snip]
> According to datasheet of Loongson 1B, the buffer size in RX/TX
> descriptor is only 2KB. So the Loongson1B's GMAC could not handle
> jumbo frames. And the second buffer is useless in this case. Am I
> right? Is there a better way than ifdef CONFIG_MACH_LOONGSON1 to
> avoid duplicate code?
Sorry for my misunderstanding.
I think you have to use the normal descriptor and remove the enh_desc
from the platform w/o modifying the driver at all.
The driver will be able to select/configure all automatically (also jumbo).
Let me know.
Note:
IIRC, there is a bit difference in case of normal descriptors for
Synopsys databook newer than the 1.91 (I used for testing this mode).
In any case, I remember that, on some platforms, the normal descriptors
have been used w/o problems also on these new chip generations.
Peppe
^ permalink raw reply
* Re: [PATCH] Add SoundCard driver for OKI SEMICONDUCTOR ML7213 IOH
From: Mark Brown @ 2011-10-24 12:20 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: alsa-devel, Wang, Qi, Takashi Iwai, Wang, Yong Y, linux-kernel,
Ewe, Kok Howg, Liam Girdwood, Clark, Joel
In-Reply-To: <4EA5563A.10703@dsn.lapis-semi.com>
On Mon, Oct 24, 2011 at 09:12:42PM +0900, Tomoya MORINAGA wrote:
> 1. PCI interface function.
> Any current ASoC drivers don't have PCI interface function.
> So I don't know where the function should be in machine driver or
> platform driver.
It depends on what the driver is for. Probably you want a driver which
is some combination of machine driver and the various drivers that are
normally part of the SoC - whatever roles in the system are filled by
this hardware the driver ought to register subsystem drivers for those
roles.
> 2. Register Access
> Can platform driver access register ?
> According to the soc document, platform driver must not access hardware,
> however, some drivers looks accessing their hardware.
What makes you say this? A driver that can't access hardware would be
rather useless...
^ permalink raw reply
* Re: [PATCH] Add SoundCard driver for OKI SEMICONDUCTOR ML7213 IOH
From: Mark Brown @ 2011-10-24 12:20 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Takashi Iwai, perex, linux-kernel, Wang, Qi, Wang, Yong Y,
Clark, Joel, Ewe, Kok Howg, Liam Girdwood, alsa-devel
In-Reply-To: <4EA5563A.10703@dsn.lapis-semi.com>
On Mon, Oct 24, 2011 at 09:12:42PM +0900, Tomoya MORINAGA wrote:
> 1. PCI interface function.
> Any current ASoC drivers don't have PCI interface function.
> So I don't know where the function should be in machine driver or
> platform driver.
It depends on what the driver is for. Probably you want a driver which
is some combination of machine driver and the various drivers that are
normally part of the SoC - whatever roles in the system are filled by
this hardware the driver ought to register subsystem drivers for those
roles.
> 2. Register Access
> Can platform driver access register ?
> According to the soc document, platform driver must not access hardware,
> however, some drivers looks accessing their hardware.
What makes you say this? A driver that can't access hardware would be
rather useless...
^ permalink raw reply
* [Cluster-devel] GFS2 git trees
From: Steven Whitehouse @ 2011-10-24 12:20 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hi,
Thanks to SUCS, there is now a gitweb for the two GFS2 git trees here:
http://sucs.org/gitweb/
Steve.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] batctl: correct ttcrc print format in the tcpdump output
From: Marek Lindner @ 2011-10-24 12:21 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1319027682-2897-1-git-send-email-ordex@autistici.org>
On Wednesday, October 19, 2011 14:34:42 Antonio Quartull wrote:
> The OGM ttcrc field is an unsigned short int, therefore it has to be
> printed using %hu and has to be converted from network to host order using
> ntohs
Patch was applied in revision 9031e43.
Thanks,
Marek
^ permalink raw reply
* [U-Boot] [PATCH 02/39] GCC4.6: Squash warnings in common/usb.c
From: Marek Vasut @ 2011-10-24 12:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA556E7.7010504@denx.de>
Hi Stefano,
actually the value is checked by debug_cond().
Cheers
^ permalink raw reply
* hi
From: massy @ 2011-10-24 12:23 UTC (permalink / raw)
Hello,
it give me a great pleasure to write you i was browsing when i came
across your mail and i free to contact you ,i will be very happy to be in communication with you if you will have the desire with me so that we can get to know each other and see what happened in future. i will be very happy if you can write me back for me to tell you more about my self and give you my picture for a good start. will be waiting to hear from you.have a nice day.
yours miss massy
^ permalink raw reply
* Re: [PATCH V2] i2c-designware: Change readl to readw and writel to writew
From: Baruch Siach @ 2011-10-24 12:23 UTC (permalink / raw)
To: Rajeev kumar
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shiraz HASHIM,
Viresh KUMAR, Bhupesh SHARMA, Pratyush ANAND, Vipin KUMAR,
Deepak SIKRI, Amit VIRDI, Vipul Kumar SAMAR, Armando VISCONTI
In-Reply-To: <4EA5472A.1000400-qxv4g6HH51o@public.gmane.org>
Hi Rajeev,
On Mon, Oct 24, 2011 at 04:38:26PM +0530, Rajeev kumar wrote:
> On 10/24/2011 4:03 PM, Baruch Siach wrote:
> >On Mon, Oct 24, 2011 at 03:28:02PM +0530, Rajeev Kumar wrote:
> >>Since I2C designware registers are 16 bit wide and so we should use
> >>readw/writew.
> >>
> >>Signed-off-by: Rajeev Kumar<rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
> >>---
> >> drivers/i2c/busses/i2c-designware.c | 104 +++++++++++++++++-----------------
> >> 1 files changed, 52 insertions(+), 52 deletions(-)
> >>
> >>diff --git a/drivers/i2c/busses/i2c-designware.c b/drivers/i2c/busses/i2c-designware.c
> >>index 6eaa681..5149a10 100644
> >>--- a/drivers/i2c/busses/i2c-designware.c
> >>+++ b/drivers/i2c/busses/i2c-designware.c
> >>@@ -216,11 +216,11 @@ struct dw_i2c_dev {
> >> u32 abort_source;
> >> int irq;
> >> struct i2c_adapter adapter;
> >>- unsigned int tx_fifo_depth;
> >>- unsigned int rx_fifo_depth;
> >>+ u16 tx_fifo_depth;
> >>+ u16 rx_fifo_depth;
> >> };
> >
> >This looks wrong. The {tx,rx}_fifo_depth fields do not represent bit fields,
> >but numbers. So unsigned int should be better here.
>
> Yes, I agree with you, but I do not see any possibility of value of
> {tx,rx}_fifo_depth fields greater than 2^^16 - 1. So, would not it
> be better to keep them as u16 and save just 4 bytes.
Well, if you are after these 4 bytes just make them 'unsigned short'.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] [PATCH] Allow build of dropbear without wtmp and lastlog support to stop it from generating system log error messages
From: Will Moore @ 2011-10-24 12:24 UTC (permalink / raw)
To: buildroot
Signed-off-by: Will Moore <will.moore@beraninstruments.com>
---
package/dropbear/Config.in | 16 ++++++++++++++++
package/dropbear/dropbear.mk | 8 ++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/package/dropbear/Config.in b/package/dropbear/Config.in
index c30228f..58fed4a 100644
--- a/package/dropbear/Config.in
+++ b/package/dropbear/Config.in
@@ -23,3 +23,19 @@ config BR2_PACKAGE_DROPBEAR_SMALL
Tradeoffs are slower hashes and ciphers, and disabling of the
blowfish cipher and zlib.
+
+config BR2_PACKAGE_DROPBEAR_DISABLE_WTMP
+ bool "disable logging of dropbear access to wtmp"
+ depends on BR2_PACKAGE_DROPBEAR
+ help
+ Disable logging of dropbear access to wtmp. Buildroot does not generate
+ wtmp by default and so by disabling dropbear's use of wtmp this
+ prevents warnings in the system log.
+
+config BR2_PACKAGE_DROPBEAR_DISABLE_LASTLOG
+ bool "disable logging of dropbear access to lastlog"
+ depends on BR2_PACKAGE_DROPBEAR
+ help
+ Disable logging of dropbear access to lastlog. Buildroot does not
+ generate lastlog by default and so by disabling dropbear's use of
+ lastlog this prevents warnings in the system log.
diff --git a/package/dropbear/dropbear.mk b/package/dropbear/dropbear.mk
index e9da42d..0c9c5fc 100644
--- a/package/dropbear/dropbear.mk
+++ b/package/dropbear/dropbear.mk
@@ -46,6 +46,14 @@ DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_BUILD_FEATURED
DROPBEAR_DEPENDENCIES += zlib
endif
+ifeq ($(BR2_PACKAGE_DROPBEAR_DISABLE_WTMP),y)
+DROPBEAR_CONF_OPT += --disable-wtmp
+endif
+
+ifeq ($(BR2_PACKAGE_DROPBEAR_DISABLE_LASTLOG),y)
+DROPBEAR_CONF_OPT += --disable-lastlog
+endif
+
define DROPBEAR_INSTALL_TARGET_CMDS
$(INSTALL) -m 755 $(@D)/dropbearmulti $(TARGET_DIR)/usr/sbin/dropbear
for f in $(DROPBEAR_TARGET_BINS); do \
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] Please Respectfully Don’t Forsake Me!
From: wendy kipkalya @ 2011-10-24 12:25 UTC (permalink / raw)
To: u-boot
Please Respectfully Don?t Forsake Me!
I am writing this mail to you with tears and sorrow from my heart. With due respect , trust and humanity, i appeal to you to exercise a little patient and read through my letter, I wish to contact you personally for a long term business relationship and investment assistance in your Country so i feel quite safe dealing with you in this important business having gone through your remarkable profile, honestly' i got your profile in Google data base when i was searching for a reliable person who could stand as my Trustee, i will really like to have a good relationship with you and i have a special reason why i decided to contact you, i decided to contact you due to the urgency of my situation, Wendy Kipkalya Kones is my name, a girl of 23yrs of age, single and I held from Kenya in East Africa. My father was the former Kenyan road Minister. He and Assistant Minister of Home Affairs Lorna Laboso had been on board the Cessna 210, which was headed to Kericho
and crashed in a remote area called Kajong'a, in western Kenya. The plane crashed on the Tuesday 10th, June, 2008.
You can read more about the crash through the below site:
http://edition.cnn.com/2008/WORLD/africa/06/10/kenya.crash/index.html
After the burial of my father, my stepmother and uncle conspired and sold my father's property to an Italian Expert rate which the shared the money among themselves and live nothing for me. I am constrained to contact you because of the abuse I am receiving from my wicked stepmother and uncle. They planned to take away all my late father's treasury and properties from me since the unexpected death of my beloved Father. Meanwhile i wanted to escape to the USA but they hide away my international passport and other valuable traveling documents.Luckly hey did not discover where i kept my fathers File which contains important documents. So I decided to run to the refugee camp where i am presently seeking asylum under the United Nations High Commission for the Refugee here in Ouagadougou, Republic of Burkina Faso.
One faithful morning, I opened my father's briefcase and found out the documents which he has deposited huge amount of money in bank in Burkina Faso with my name as the next of kin. I traveled to Burkina Faso to withdraw the money for a better life so that I can take care of myself and start a new life, on my arrival, the Bank Director whom I met in person told me that my father's instruction/will to the bank is that the money would only be release to me when I am married or present a trustee who will help me and invest the money overseas. I am in search of an honest and reliable person who will help me and stand as my trustee so that I will present him to the Bank for transfer of the money to his bank account overseas. I have chosen to contact you after my prayers and I believe that you will not betray my trust. But rather take me as your own sister.
Although, you may wonder why I am so soon revealing myself to you without knowing you, well I will say that my mind convinced me that you may be the true person to help me. Moreso, My father of blessed memory deposited the sum of (US$5.800,000) Dollars in Bank with my name as the next of kin. However, I shall forward you with the necessary documents on confirmation of your acceptance to assist me for the transfer and statement of the fund in your country. As you will help me in an investment, and i will like to complete my studies, as i was in my 1year in the university when my beloved father died. It is my intention to compensate you with 30% of the total money for your services and the balance shall be my capital in your establishment. As soon as I receive your positive response showing your interest I will put things into action immediately. In the light of the above. I shall appreciate an urgent message indicating your ability and willingness to
handle this transaction sincerely.
Awaiting your urgent and positive respond. Please do keep this only to your self for now until the bank will transfer the fund. I beg you not to disclose it till i come over because I am afraid of my wicked stepmother who has threatened to kill me and have the money alone ,I thank God Today that am out from my country (KENYA) but now In (Burkina Faso) where my father deposited these money with my name as the next of Kin. I have the documents for the claims.
Yours Sincerely
Miss Wendy Kipkalya kones
^ permalink raw reply
* [PATCH] Add new command and event for LTK storage support
From: Vinicius Costa Gomes @ 2011-10-24 12:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
This documents the new command and event that are to be added to
the Management API to add support for persistent pairing of LE
devices.
---
doc/mgmt-api.txt | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 8d5d8d5..44fef0b 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -356,6 +356,24 @@ Name Information Command
expected for each Device Found event with the Confirm Name
flag set.
+Load Long Term Keys Command
+===========================
+
+ Command Code: 0x0021
+ Controller Index: <controller id>
+ Command Parameters: Debug Keys (1 Octet)
+ Key Count (2 Octets)
+ Key1 {
+ Address (6 Octets)
+ PIN_Length (1 Octet)
+ Encryption Size (1 Octet)
+ Enc. Diversifier (2 Octets)
+ Random Number (8 Octets)
+ Value (16 Octets)
+ }
+ Key2 { }
+ ...
+
Read Tracing Buffer Size Command
================================
@@ -588,3 +606,18 @@ Device Unblocked Event
Event Code 0x00016
Controller Index <controller id>
Event Parameters Address (6 Octets)
+
+New Long Term Key Event
+=======================
+
+Event Code 0x0017
+Controller Index <controller id>
+Event Parameters Store Hint (1 Octet)
+ Key {
+ Address (6 Octets)
+ PIN_Length (1 Octet)
+ Encryption Size (1 Octet)
+ Enc. Diversifier (2 Octets)
+ Random Number (8 Octets)
+ Value (16 Octets)
+ }
--
1.7.7
^ permalink raw reply related
* RE: [PATCH] mmc: boot partition ro lock support
From: Johan RUDHOLM @ 2011-10-24 12:22 UTC (permalink / raw)
To: Chris Ball, Ulf HANSSON
Cc: Sebastian Rasmussen, Linus Walleij, Andrei Warkentin, Per FORLIN,
Lee Jones, John BECKETT, linux-mmc@vger.kernel.org
In-Reply-To: <m2sjmi4s7x.fsf@bob.laptop.org>
Hi,
Chris Ball wrote:
>
> Please could you send a version of the patch that supports power-on r/o
> but not perm r/o, and perhaps also post userspace code for submitting
> the perm r/o command through the ioctl interface? (Perhaps this code
> should eventually be submitted to a disk management tool..)
Ok and ok, we will lose the permanent ro-locking and supply sample code for future reference.
> Also, it looks like it's possible to set read-only for the whole
> device,
> as well as for boot partitions. Could you update the patch to allow
> setting power-on r/o for the entire card, not just the boot partitions?
Will give it a shot!
> > Enable boot partitions to be power and permanently read-only locked
> via
> > a sysfs entry. There will be one sysfs entry for the main mmc device:
> >
> > /sys/block/mmcblkX/boot_partition_ro_lock
>
> I don't follow why this node is necessary, instead of just having the
> nodes in the mmcblkXbootY/ directories. Could you explain?
This was meant to reflect that ro-locking the boot partitions is actually done per card and not per boot partition (so if you lock one boot partition, the other one is locked as well). Is there another way of making this connection clear? Maybe it will be enough to mention it in the Documentation?
> echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
>
> to lock just a boot partition, and:
>
> echo 1 > /sys/block/mmcblkX/ro_lock_until_next_power_on
>
> to lock the entire card (which will cover the boot partition too), with
> echo 0 to unlock.
Ok, this looks good. However, writing 0 will not unlock since the card needs to be power cycled.
> Other review comments: I noticed that your pr_*(); statements are
> missing "\n"s on the end, and you should add documentation on the new
> sysfs nodes to:
> Documentation/mmc/mmc-dev-parts.txt
Ok!
> I think the overlap between your patch and Andrei's
> mmcblkXbootY/force_ro
> node is going to be confusing -- one operates purely in the kernel and
> the other is sent to the card. Do you have any proposal for making the
> difference clearer?
I concur, the same can be said about general purpose partitions as well? Partitions that are configured in hardware rather than software. The current layout in sysfs does not reflect this difference either, below
mmcblk0
we find
mmcblk0p1
mmcblk0boot0
mmcblk0gp0
which are a mix of different partition types. Maybe separate sysfs trees in some way? I am afraid I'll have to pass this question back to you.
Thank you all for your comments.
Kind regards, Johan
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Srivatsa Vaddagiri @ 2011-10-24 12:27 UTC (permalink / raw)
To: Avi Kivity
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
LKML, Suzuki Poulose, Peter Zijlstra
In-Reply-To: <4EA53A7D.300@redhat.com>
* Avi Kivity <avi@redhat.com> [2011-10-24 12:14:21]:
> > +/*
> > + * kvm_pv_wait_for_kick_op : Block until kicked by either a KVM_HC_KICK_CPU
> > + * hypercall or a event like interrupt.
> > + *
> > + * @vcpu : vcpu which is blocking.
> > + */
> > +static void kvm_pv_wait_for_kick_op(struct kvm_vcpu *vcpu)
> > +{
[snip]
> > +}
>
> This hypercall can be replaced by a HLT instruction, no?
Good point. Assuming yield_on_hlt=1, that would allow the vcpu to be put
to sleep and let other vcpus make progress.
I guess with that change, we can also dropthe need for other hypercall
introduced in this patch (kvm_pv_kick_cpu_op()). Essentially a vcpu sleeping
because of HLT instruction can be woken up by a IPI issued by vcpu releasing a
lock.
- vatsa
^ permalink raw reply
* Re: [linux-lvm] Changing dev_t-devname mapping in lvmlib seems to be problematic
From: Zdenek Kabelac @ 2011-10-24 12:28 UTC (permalink / raw)
To: Alexander Lyakas; +Cc: LVM general discussion and development
In-Reply-To: <CAGRgLy5Sm_T19Ex+qLe=rTH3r_nSnYOhW+mU5HZy5Y1y2JnJAw@mail.gmail.com>
2011/10/24 Alexander Lyakas <alex.bolshoy@gmail.com>:
> Hi Zdenek,
>
> It appears that I don't understand part of your comments, or perhaps
> we have a disconnect.
>
>> Not really sure about lvmlib API capabilities - IMHO I'd not use it
>> for anything else then lvs-like operations ATM. �(since there are
>> quite a few rules to avoid deadlocks) If it's not a problem for you
>> app I'd suggest to use lvm2cmd library preferable in a separate forked
>> small process so there could be full control over memory and file
>> descriptors....
> Do you suggest not to use lvmlib at all? And always use command-line
> LVM tools from within a forked process? Currently I use
> command-line/fork only for pvcreate/pvremove, since these APIs are not
> available in lvmlib.
If you expect stable behavior - and the best memory efficiency and the
most supported features
- then I'd go this way for now.
>
>> dm-xxx devices are created dynamicaly - there is currently no way to
>> have a fixed dm device node and it would be quite ugly to provide such
>> feature.
> I did not understand this comment. Do you mean the dm-xxx devices that
> LVM creates for its LVs? I was talking about dm-linear devices that I
> use for PVs.
/dev/dm-xxx gets its 'xxx' value in the order in which they appear
in the kernel processing.
Thus you should never ever depend on any fixed 'xxx' here - i.e. do
not reference /dev/dm-xxx
anywhere in you code - since it may change between reboots.
>> So at dm level - you could use � /dev/mapper/devicename however at lvm
>> level the only supported way �is /dev/vg/lv
>> (even though they are visible through /dev/mapper �- only /dev/vg �are
>> meant to be 'public')
> Again, do you mean the LV dm-xxx devices? I was talking about PV
> devices, which are dm-linear in my case.
Always reference /dev/vgname/lvname to stay safe.
>> Yes, there is locking, so as long as you are using only lvm tools,
>> there should be no collisions.
> What I meant here, is that each time a command-line tool is invoked,
> it has a fresh instance of caches of its own. While in my application,
> if I keep the lvm_t handle open, then the caches within lvm are not
> cleaned up. This (plus the change in dev_t) causes the problem I am
> seeing.
Internal caching knows it's changes devices and should properly flush them.
So if you get there some unexpected behavior - create a simple test case code,
and create regular bug.
(open handle, make few lvm2api operations causing problem)
>> Recent versions of lvm should be getting list of block devices for
>> scanning from udev, and then more filters are applied.
> Is there an option to restrict this list only to certain devices? In
> my system there is no point of scanning all the devices.
lvm.conf - look for setting 'filter='
> All in all, I fixed my code to issue lvm_config_reload() before each
> LVM operation. This cleans all the caches, so I am not seeing the
> problem anymore.
>
> Basically, I looked at the various caches code in the LVM, and they
> seem quite dangerous to me, if not refreshed before each LVM
> operation. Since most LVM usage (I presume) is done via command-line
> tools, which create a new process (i.e., new caches) each time
> invoked, not sure how big is the gain of caching. But I am probably
> not seeing the whole picture.
Yeah, you are not alone ;)
But in this case it looks like a bug you might be hitting - since this
case should work.
Zdenek
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMjpGUcWUp05SkBi1JWL+NFBCcZV5=EaidtYkEbONPheVwhjgw@mail.gmail.com>
On Mon, Oct 24, 2011 at 11:20 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> but the question here is about pinctrl. ?does userspace really need to
> manipulate the pinmapping ? ?if we agree on that, then the question is
> on the userspace interface.
>
> assuming we want this, i can't see the performance argument being made
> here for pinctrl. ?which means doing a sysfs interface here like we
> already have with GPIO makes the most sense. ?GPIO deals in "binary"
> data for the most part (reading/writing 0/1 ints) so the string-based
> sysfs parsing is a bit weird, but pinctrl deals with strings
> everywhere for selecting mapping groups, so sysfs is the natural
> answer.
Hm now I feel I start to agree with you and come back to my
original proposition to do pinctrl in sysfs after all.
I wonder how soon we have a practical use case for this.
We do have this hacked-up driver in ux500:
http://git.linaro.org/gitweb?p=bsp/st-ericsson/linux-3.0-ux500.git;a=tree;f=drivers/staging/ab5500_sim;hb=HEAD
This controls a lot of SIM card pins from userspace...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 12:28 UTC (permalink / raw)
To: Mike Frysinger
Cc: Grant Likely, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CAMjpGUcWUp05SkBi1JWL+NFBCcZV5=EaidtYkEbONPheVwhjgw@mail.gmail.com>
On Mon, Oct 24, 2011 at 11:20 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> but the question here is about pinctrl. does userspace really need to
> manipulate the pinmapping ? if we agree on that, then the question is
> on the userspace interface.
>
> assuming we want this, i can't see the performance argument being made
> here for pinctrl. which means doing a sysfs interface here like we
> already have with GPIO makes the most sense. GPIO deals in "binary"
> data for the most part (reading/writing 0/1 ints) so the string-based
> sysfs parsing is a bit weird, but pinctrl deals with strings
> everywhere for selecting mapping groups, so sysfs is the natural
> answer.
Hm now I feel I start to agree with you and come back to my
original proposition to do pinctrl in sysfs after all.
I wonder how soon we have a practical use case for this.
We do have this hacked-up driver in ux500:
http://git.linaro.org/gitweb?p=bsp/st-ericsson/linux-3.0-ux500.git;a=tree;f=drivers/staging/ab5500_sim;hb=HEAD
This controls a lot of SIM card pins from userspace...
Yours,
Linus Walleij
^ permalink raw reply
* Re: xfs_symlink problem? 3.1 after rc10
From: Carlos Maiolino @ 2011-10-24 12:27 UTC (permalink / raw)
To: Arkadiusz Miśkiewicz; +Cc: xfs
In-Reply-To: <201110241148.39772.arekm@maven.pl>
> My 3.1 (after) rc10 crashed (there was no xfs changes after it afaik).
>
> Could anyone verify that this isn't some nasty xfs problem since it's close to
> final 3.1? Happened only once.
>
> http://ixion.pld-linux.org/~arekm/IMG_6019.JPG
>
> No quota was used, xfs on top of luks on top of ssd drive.
It looks to be caused by a general protection fault, and giving the place where this crashed
I would say this sounds like the bug I've fixed some days ago related with the size of the
symlinks.
I can be wrong though, and this is related with another problem.
--
--Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCHv5 13/19] usb: otg: ulpi: Start using struct usb_otg
From: Igor Grinberg @ 2011-10-24 12:28 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Felipe Balbi, Greg KH, linux-usb, linux-kernel, Peter Chen,
Lin Tony-B19295, Alexander Shishkin
In-Reply-To: <1317036092-3000-14-git-send-email-heikki.krogerus@linux.intel.com>
On 09/26/2011 02:21 PM, Heikki Krogerus wrote:
> Use struct usb_otg members with OTG specific functions instead
> of usb_phy members.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.