* [PATCH 02/14] KVM: PPC: e500: Eliminate preempt_disable in local_sid_destroy_all
From: Alexander Graf @ 2011-10-31 7:53 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm list, Marcelo Tosatti, Scott Wood
In-Reply-To: <1320047596-20577-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
The only place it makes sense to call this function already needs
to have preemption disabled.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/e500_tlb.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 22624a7..b976d80 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -116,13 +116,11 @@ static inline int local_sid_lookup(struct id *entry)
return -1;
}
-/* Invalidate all id mappings on local core */
+/* Invalidate all id mappings on local core -- call with preempt disabled */
static inline void local_sid_destroy_all(void)
{
- preempt_disable();
__get_cpu_var(pcpu_last_used_sid) = 0;
memset(&__get_cpu_var(pcpu_sids), 0, sizeof(__get_cpu_var(pcpu_sids)));
- preempt_enable();
}
static void *kvmppc_e500_id_table_alloc(struct kvmppc_vcpu_e500 *vcpu_e500)
--
1.6.0.2
^ permalink raw reply related
* [PULL 00/14] ppc patch queue 2011-10-31
From: Alexander Graf @ 2011-10-31 7:53 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm list, Marcelo Tosatti
Hi Avi / Marcelo,
This is my current patch queue for ppc. Please pull.
Alex
The following changes since commit b796a09c5d808f4013f27ad45953db604dac18fd:
Marcelo Tosatti (1):
Merge remote-tracking branch 'upstream/master' into kvm-devel
are available in the git repository at:
git://github.com/agraf/linux-2.6.git kvm-ppc-next
Alexander Graf (7):
KVM: PPC: Fix build failure with HV KVM and CBE
Revert "KVM: PPC: Add support for explicit HIOR setting"
KVM: PPC: Add generic single register ioctls
KVM: PPC: Add support for explicit HIOR setting
KVM: PPC: Whitespace fix for kvm.h
KVM: Fix whitespace in kvm_para.h
KVM: PPC: E500: Support hugetlbfs
Bharat Bhushan (1):
PPC: Fix race in mtmsr paravirt implementation
Scott Wood (6):
KVM: PPC: e500: don't translate gfn to pfn with preemption disabled
KVM: PPC: e500: Eliminate preempt_disable in local_sid_destroy_all
KVM: PPC: e500: clear up confusion between host and guest entries
KVM: PPC: e500: MMU API
KVM: PPC: e500: tlbsx: fix tlb0 esel
KVM: PPC: e500: Don't hardcode PIR=0
Documentation/virtual/kvm/api.txt | 122 ++++++
arch/powerpc/include/asm/kvm.h | 49 ++-
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_e500.h | 46 ++-
arch/powerpc/include/asm/kvm_ppc.h | 5 +
arch/powerpc/include/asm/mmu-book3e.h | 1 +
arch/powerpc/kernel/exceptions-64s.S | 6 +-
arch/powerpc/kernel/kvm_emul.S | 10 +-
arch/powerpc/kvm/book3s_pr.c | 12 +-
arch/powerpc/kvm/booke.c | 4 +-
arch/powerpc/kvm/e500.c | 8 +-
arch/powerpc/kvm/e500_emulate.c | 12 +-
arch/powerpc/kvm/e500_tlb.c | 674 +++++++++++++++++++++++----------
arch/powerpc/kvm/e500_tlb.h | 55 +--
arch/powerpc/kvm/powerpc.c | 92 +++++
include/linux/kvm.h | 50 +++
include/linux/kvm_para.h | 1 -
17 files changed, 865 insertions(+), 284 deletions(-)
^ permalink raw reply
* [PATCH 05/14] KVM: PPC: e500: tlbsx: fix tlb0 esel
From: Alexander Graf @ 2011-10-31 7:53 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm list, Marcelo Tosatti, Scott Wood
In-Reply-To: <1320047596-20577-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
It should contain the way, not the absolute TLB0 index.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/e500_tlb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index f19ae2f..ec17148 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -853,6 +853,8 @@ int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb)
}
if (gtlbe) {
+ esel &= vcpu_e500->gtlb_params[tlbsel].ways - 1;
+
vcpu_e500->mas0 = MAS0_TLBSEL(tlbsel) | MAS0_ESEL(esel)
| MAS0_NV(vcpu_e500->gtlb_nv[tlbsel]);
vcpu_e500->mas1 = gtlbe->mas1;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 1/1] gatchat: Add IPv6 CP support
From: Denis Kenzior @ 2011-10-31 7:43 UTC (permalink / raw)
To: ofono
In-Reply-To: <1319638832-22487-2-git-send-email-oleg.zhurakivskyy@intel.com>
[-- Attachment #1: Type: text/plain, Size: 21316 bytes --]
Hi Oleg,
On 10/26/2011 09:20 AM, Oleg Zhurakivskyy wrote:
> ---
> Makefile.am | 2 +-
> gatchat/gatppp.c | 58 +++++++++-
> gatchat/gatppp.h | 2 +
> gatchat/gsmdial.c | 6 +
> gatchat/ppp.h | 23 ++++
> gatchat/ppp_ipv6cp.c | 306 +++++++++++++++++++++++++++++++++++++++++++++++++
> gatchat/test-server.c | 17 +++-
> 7 files changed, 410 insertions(+), 4 deletions(-)
> create mode 100644 gatchat/ppp_ipv6cp.c
>
This looks like a good start. However, please separate this patch into
several, like this:
- One adding the bulk of IPv6CP protocol
- One for hooks in gatppp itself & ipv6cp
- One for gsmdial
- One for test-server.
> diff --git a/Makefile.am b/Makefile.am
> index 83b7737..44fdfff 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -76,7 +76,7 @@ gatchat_sources = gatchat/gatchat.h gatchat/gatchat.c \
> gatchat/ppp.h gatchat/ppp_cp.h \
> gatchat/ppp_cp.c gatchat/ppp_lcp.c \
> gatchat/ppp_auth.c gatchat/ppp_net.c \
> - gatchat/ppp_ipcp.c
> + gatchat/ppp_ipcp.c gatchat/ppp_ipv6cp.c
>
> gisi_sources = gisi/client.c gisi/client.h gisi/common.h \
> gisi/iter.c gisi/iter.h \
> diff --git a/gatchat/gatppp.c b/gatchat/gatppp.c
> index f767f4a..41f9dff 100644
> --- a/gatchat/gatppp.c
> +++ b/gatchat/gatppp.c
> @@ -62,6 +62,7 @@ struct _GAtPPP {
> enum ppp_phase phase;
> struct pppcp_data *lcp;
> struct pppcp_data *ipcp;
> + struct pppcp_data *ipv6cp;
> struct ppp_net *net;
> struct ppp_chap *chap;
> GAtHDLC *hdlc;
> @@ -157,7 +158,8 @@ static inline gboolean ppp_drop_packet(GAtPPP *ppp, guint16 protocol)
> return TRUE;
> case PPP_PHASE_NETWORK:
> if (protocol != LCP_PROTOCOL && protocol != CHAP_PROTOCOL &&
> - protocol != IPCP_PROTO)
> + protocol != IPCP_PROTO &&
> + protocol != IPV6CP_PROTO)
> return TRUE;
> break;
> case PPP_PHASE_LINK_UP:
> @@ -222,6 +224,10 @@ static void ppp_receive(const unsigned char *buf, gsize len, void *data)
> case IPCP_PROTO:
> pppcp_process_packet(ppp->ipcp, packet, len - offset);
> break;
> + case IPV6CP_PROTO:
> + if (ppp->ipv6cp)
> + pppcp_process_packet(ppp->ipv6cp, packet, len - offset);
> + break;
> case CHAP_PROTOCOL:
> if (ppp->chap) {
> ppp_chap_process_packet(ppp->chap, packet,
> @@ -381,6 +387,13 @@ void ppp_auth_notify(GAtPPP *ppp, gboolean success)
>
> ppp_enter_phase(ppp, PPP_PHASE_NETWORK);
>
> + /* Send UP & OPEN events to the IPv6 CP */
> + if (ppp->ipv6cp) {
> + pppcp_signal_open(ppp->ipv6cp);
> + pppcp_signal_up(ppp->ipv6cp);
> + return;
> + }
> +
Can IPV6CP and IPCP co-exist? In theory there is such a concept as
dual-stack contexts, however I don't know whether any modem in existence
does this with PPP.
> /* Send UP & OPEN events to the IPCP layer */
> pppcp_signal_open(ppp->ipcp);
> pppcp_signal_up(ppp->ipcp);
> @@ -435,6 +448,28 @@ void ppp_ipcp_finished_notify(GAtPPP *ppp)
> pppcp_signal_close(ppp->lcp);
> }
>
> +void ppp_ipv6cp_up_notify(GAtPPP *ppp, const char *local, const char *peer)
> +{
> + DBG(ppp, "local: %s, peer: %s", local, peer);
> +}
> +
> +void ppp_ipv6cp_down_notify(GAtPPP *ppp)
> +{
> + DBG(ppp, "");
> +}
> +
> +void ppp_ipv6cp_finished_notify(GAtPPP *ppp)
> +{
> + DBG(ppp, "");
> +
> + if (ppp->phase != PPP_PHASE_NETWORK)
> + return;
> +
> + ppp->disconnect_reason = G_AT_PPP_REASON_IPV6CP_FAIL;
> + pppcp_signal_close(ppp->ipv6cp);
> + pppcp_signal_close(ppp->lcp);
> +}
> +
> void ppp_lcp_up_notify(GAtPPP *ppp)
> {
> /* Wait for the peer to send us a challenge if we expect auth */
> @@ -732,6 +767,8 @@ void g_at_ppp_unref(GAtPPP *ppp)
>
> lcp_free(ppp->lcp);
> ipcp_free(ppp->ipcp);
> + if (ppp->ipv6cp)
> + ipv6cp_free(ppp->ipv6cp);
>
> if (ppp->ppp_dead_source) {
> g_source_remove(ppp->ppp_dead_source);
> @@ -772,6 +809,25 @@ void g_at_ppp_set_pfc_enabled(GAtPPP *ppp, gboolean enabled)
> lcp_set_pfc_enabled(ppp->lcp, enabled);
> }
>
> +void g_at_ppp_set_ipv6cp_info(GAtPPP *ppp, const char *local, const char *peer)
> +{
> + struct in6_addr local_addr;
> + struct in6_addr peer_addr;
> +
> + if (local)
> + inet_pton(AF_INET6, local, &local_addr);
> + else
> + memset(&local_addr, 0, sizeof(local_addr));
> +
What if inet_pton fails?
> + if (peer)
> + inet_pton(AF_INET6, peer, &peer_addr);
> + else
> + memset(&peer_addr, 0, sizeof(peer_addr));
> +
> + ppp->ipv6cp = ipv6cp_new(ppp, (void *) &local_addr.s6_addr[8],
> + (void *) &peer_addr.s6_addr[8]);
> +}
> +
> static GAtPPP *ppp_init_common(gboolean is_server, guint32 ip)
> {
> GAtPPP *ppp;
> diff --git a/gatchat/gatppp.h b/gatchat/gatppp.h
> index b5a2234..9099d6b 100644
> --- a/gatchat/gatppp.h
> +++ b/gatchat/gatppp.h
> @@ -37,6 +37,7 @@ typedef enum _GAtPPPDisconnectReason {
> G_AT_PPP_REASON_UNKNOWN,
> G_AT_PPP_REASON_AUTH_FAIL, /* Failed to authenticate */
> G_AT_PPP_REASON_IPCP_FAIL, /* Failed to negotiate IPCP */
> + G_AT_PPP_REASON_IPV6CP_FAIL, /* Failed to negotiate IPV6CP */
> G_AT_PPP_REASON_NET_FAIL, /* Failed to create tun */
> G_AT_PPP_REASON_PEER_CLOSED, /* Peer initiated a close */
> G_AT_PPP_REASON_LINK_DEAD, /* Link to the peer died */
> @@ -81,6 +82,7 @@ void g_at_ppp_set_server_info(GAtPPP *ppp, const char *remote_ip,
>
> void g_at_ppp_set_acfc_enabled(GAtPPP *ppp, gboolean enabled);
> void g_at_ppp_set_pfc_enabled(GAtPPP *ppp, gboolean enabled);
> +void g_at_ppp_set_ipv6cp_info(GAtPPP *ppp, const char *local, const char *peer);
>
> #ifdef __cplusplus
> }
> diff --git a/gatchat/gsmdial.c b/gatchat/gsmdial.c
> index be159eb..8f30309 100644
> --- a/gatchat/gsmdial.c
> +++ b/gatchat/gsmdial.c
> @@ -59,6 +59,7 @@ static gchar *option_pppdump = NULL;
> static gboolean option_bluetooth = FALSE;
> static gboolean option_acfc = FALSE;
> static gboolean option_pfc = FALSE;
> +static gchar *option_ipv6 = NULL;
>
> static GAtPPP *ppp;
> static GAtChat *control;
> @@ -372,6 +373,9 @@ static void connect_cb(gboolean ok, GAtResult *result, gpointer user_data)
> if (option_pppdump)
> g_at_ppp_set_recording(ppp, option_pppdump);
>
> + if (option_ipv6)
> + g_at_ppp_set_ipv6cp_info(ppp, option_ipv6, NULL);
> +
> g_at_ppp_set_credentials(ppp, option_username, option_password);
>
> g_at_ppp_set_acfc_enabled(ppp, option_acfc);
> @@ -687,6 +691,8 @@ static GOptionEntry options[] = {
> "Use Protocol Field Compression" },
> { "acfc", 0, 0, G_OPTION_ARG_NONE, &option_acfc,
> "Use Address & Control Field Compression" },
> + { "ipv6", '6', 0, G_OPTION_ARG_STRING, &option_ipv6,
> + "Specify IPv6 address" },
> { NULL },
> };
>
> diff --git a/gatchat/ppp.h b/gatchat/ppp.h
> index a20fe85..5cb79f8 100644
> --- a/gatchat/ppp.h
> +++ b/gatchat/ppp.h
> @@ -24,7 +24,9 @@
> #define LCP_PROTOCOL 0xc021
> #define CHAP_PROTOCOL 0xc223
> #define IPCP_PROTO 0x8021
> +#define IPV6CP_PROTO 0x8057
> #define PPP_IP_PROTO 0x0021
> +#define PPP_IPV6_PROTO 0x0057
> #define MD5 5
>
> #define DBG(p, fmt, arg...) do { \
> @@ -44,6 +46,19 @@ struct ppp_header {
> guint8 info[0];
> } __attribute__((packed));
>
> +struct eui64 {
> + union {
> + guint8 __e8[8];
> + guint16 __e16[4];
> + guint32 __e32[2];
> + } __u;
> +#define e6_addr __u.__e8
> +#define e6_addr16 __u.__e16
> +#define e6_addr32 __u.__e32
> +};
I really don't like this actually. I would either simply use an
unsigned char[8] array or use guint64.
> +
> +#define EUI64_ANY_INIT { { { 0, 0, 0, 0, 0, 0, 0, 0 } } }
> +
This initializer doesn't seem necessary, and if it was, then it doesn't
belong here, but inside ipv6cp.c since this is the only place using it.
> struct packed_short {
> guint16 s;
> } __attribute__((packed));
> @@ -95,6 +110,11 @@ void ipcp_free(struct pppcp_data *data);
> void ipcp_set_server_info(struct pppcp_data *ipcp, guint32 peer_addr,
> guint32 dns1, guint32 dns2);
>
> +/* IPv6 CP related functions */
> +struct pppcp_data *ipv6cp_new(GAtPPP *ppp, const struct eui64 *local_addr,
> + const struct eui64 *peer_addr);
Thinking more about it, why don't you make this function take const char
* arguments instead, and hide away all the nasty details inside
ipv6cp.c? This way all these funky structs are hidden away in the
implementation, and you can use whatever is the most convenient.
> +void ipv6cp_free(struct pppcp_data *data);
> +
> /* CHAP related functions */
> struct ppp_chap *ppp_chap_new(GAtPPP *ppp, guint8 method);
> void ppp_chap_free(struct ppp_chap *chap);
> @@ -120,6 +140,9 @@ void ppp_ipcp_up_notify(GAtPPP *ppp, const char *local, const char *peer,
> const char *dns1, const char *dns2);
> void ppp_ipcp_down_notify(GAtPPP *ppp);
> void ppp_ipcp_finished_notify(GAtPPP *ppp);
> +void ppp_ipv6cp_up_notify(GAtPPP *ppp, const char *local, const char *peer);
> +void ppp_ipv6cp_down_notify(GAtPPP *ppp);
> +void ppp_ipv6cp_finished_notify(GAtPPP *ppp);
> void ppp_lcp_up_notify(GAtPPP *ppp);
> void ppp_lcp_down_notify(GAtPPP *ppp);
> void ppp_lcp_finished_notify(GAtPPP *ppp);
> diff --git a/gatchat/ppp_ipv6cp.c b/gatchat/ppp_ipv6cp.c
> new file mode 100644
> index 0000000..b30d38a
> --- /dev/null
> +++ b/gatchat/ppp_ipv6cp.c
> @@ -0,0 +1,306 @@
> +/*
> + *
> + * oFono - Open Source Telephony
> + *
> + * Copyright (C) 2009-2011 Intel Corporation. All rights reserved.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include <config.h>
> +#endif
> +
> +#include <arpa/inet.h>
> +#include <sys/socket.h>
> +#include <netinet/in.h>
> +
> +#include <string.h>
> +
> +#include <glib.h>
> +
> +#include "gatppp.h"
> +#include "ppp.h"
> +
> +#define IPV6CP_SUPPORTED_CODES ((1 << PPPCP_CODE_TYPE_CONFIGURE_REQUEST) | \
> + (1 << PPPCP_CODE_TYPE_CONFIGURE_ACK) | \
> + (1 << PPPCP_CODE_TYPE_CONFIGURE_NAK) | \
> + (1 << PPPCP_CODE_TYPE_CONFIGURE_REJECT) | \
> + (1 << PPPCP_CODE_TYPE_TERMINATE_REQUEST) | \
> + (1 << PPPCP_CODE_TYPE_TERMINATE_ACK) | \
> + (1 << PPPCP_CODE_TYPE_CODE_REJECT))
> +
> +enum ipv6cp_option_types {
> + IPV6CP_INTERFACE_ID = 1,
> + IPV6CP_COMPRESSION_PROTO = 2,
The latest RFC 5072 doesn't even have this option, so you can probably
get rid of it.
> +};
> +
> +#define OPTIONS_COPY(_options, _len, _req, _type, _var, _opt_len) \
> + if (_req) { \
> + _options[_len] = _type; \
> + _options[_len + 1] = _opt_len + 2; \
> + memcpy(_options + _len + 2, _var, _opt_len); \
> + _len += _opt_len + 2; \
> + }
> +
> +/* We request only IPv6 Interface Id */
> +#define MAX_IPV6CP_CONFIG_OPTION_SIZE 10
> +#define MAX_IPV6CP_FAILURE 3
> +
> +struct ipv6cp_data {
> + guint8 options[MAX_IPV6CP_CONFIG_OPTION_SIZE];
> + guint16 options_len;
> + guint8 req_options;
> + struct eui64 local_addr;
> + struct eui64 peer_addr;
> +};
> +
> +static const struct eui64 eui64_any = EUI64_ANY_INIT;
> +
> +static void ipv6cp_generate_config_options(struct ipv6cp_data *ipv6cp)
> +{
> + guint16 len = 0;
> +
> + OPTIONS_COPY(ipv6cp->options, len,
> + ipv6cp->req_options & IPV6CP_INTERFACE_ID,
> + IPV6CP_INTERFACE_ID, &ipv6cp->local_addr,
> + sizeof(ipv6cp->local_addr));
> +
> + ipv6cp->options_len = len;
> +}
> +
> +static void ipv6cp_reset_config_options(struct ipv6cp_data *ipv6cp)
> +{
> + ipv6cp->req_options = IPV6CP_INTERFACE_ID;
> +
> + ipv6cp_generate_config_options(ipv6cp);
> +}
> +
> +static void ipv6cp_up(struct pppcp_data *pppcp)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> + struct in6_addr local_addr, peer_addr;
> + char local[INET6_ADDRSTRLEN], peer[INET6_ADDRSTRLEN];
> +
> + memset(&local_addr, 0, sizeof(local_addr));
> + memcpy(&local_addr.s6_addr[8], &ipv6cp->local_addr,
> + sizeof(ipv6cp->local_addr));
> + memset(&peer_addr, 0, sizeof(peer_addr));
> + memcpy(&peer_addr.s6_addr[8], &ipv6cp->peer_addr,
> + sizeof(ipv6cp->peer_addr));
> + ppp_ipv6cp_up_notify(pppcp_get_ppp(pppcp),
> + inet_ntop(AF_INET6, &local_addr, local, INET6_ADDRSTRLEN),
> + inet_ntop(AF_INET6, &peer_addr, peer, INET6_ADDRSTRLEN));
> +}
> +
> +static void ipv6cp_down(struct pppcp_data *pppcp)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> +
> + ipv6cp_reset_config_options(ipv6cp);
> +
> + pppcp_set_local_options(pppcp, ipv6cp->options, ipv6cp->options_len);
> + ppp_ipv6cp_down_notify(pppcp_get_ppp(pppcp));
> +}
> +
> +static void ipv6cp_finished(struct pppcp_data *pppcp)
> +{
> + ppp_ipv6cp_finished_notify(pppcp_get_ppp(pppcp));
> +}
> +
> +static enum rcr_result ipv6cp_peer_addr_check(struct ipv6cp_data *ipv6cp,
> + const void *data)
> +{
> + if (memcmp(&eui64_any, data, sizeof(eui64_any)) == 0)
> + return RCR_NAK;
> +
If we're playing the server role, then we might want to NAK non-zero
peer interface ids as well.
> + return RCR_ACCEPT;
> +}
> +
> +static enum rcr_result ipv6cp_rcr(struct pppcp_data *pppcp,
> + const struct pppcp_packet *packet,
> + guint8 **new_options, guint16 *new_len)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> + struct ppp_option_iter iter;
> + enum rcr_result result = RCR_ACCEPT;
> + guint16 len = 0, max_len = ntohs(packet->length) - 4;
> + guint8 *options = g_new0(guint8, max_len);
> + gboolean copy = TRUE;
> +
> + ppp_option_iter_init(&iter, packet);
> +
> + while (ppp_option_iter_next(&iter) == TRUE) {
> + guint8 type = ppp_option_iter_get_type(&iter);
> + const guint8 *data = ppp_option_iter_get_data(&iter);
> +
> + switch (type) {
> + case IPV6CP_INTERFACE_ID:
> + if (result == RCR_ACCEPT) {
> +
> + result = ipv6cp_peer_addr_check(ipv6cp, data);
> +
> + if (result == RCR_ACCEPT)
> + memcpy(&ipv6cp->peer_addr, data,
> + sizeof(ipv6cp->peer_addr));
> + else
> + data = ipv6cp->peer_addr.e6_addr;
> + }
> + break;
> + default:
> + if (result == RCR_NAK) {
> + copy = FALSE;
> + } else if (result != RCR_REJECT) {
> + result = RCR_REJECT;
> + len = 0;
> + }
> + break;
> + }
> +
> + OPTIONS_COPY(options, len, TRUE, type, data,
> + ppp_option_iter_get_length(&iter));
> + }
> +
> + if (!len) {
> + g_free(options);
> + options = NULL;
> + }
> +
> + *new_len = len;
> + *new_options = options;
> +
Is there a particular reason you did not structure this function in the
same manner as ipcp_server/client_rcr? They are pretty much optimized
with no allocations on the fast (non-reject) path and I'd like to have
consistency in the code.
> + return result;
> +}
> +
> +static void ipv6cp_rca(struct pppcp_data *pppcp,
> + const struct pppcp_packet *packet)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> + struct ppp_option_iter iter;
> +
> + ppp_option_iter_init(&iter, packet);
> +
> + while (ppp_option_iter_next(&iter) == TRUE) {
> + const guint8 *data = ppp_option_iter_get_data(&iter);
> +
> + switch (ppp_option_iter_get_type(&iter)) {
> + case IPV6CP_INTERFACE_ID:
> + if (memcmp(&ipv6cp->local_addr, data,
> + sizeof(ipv6cp->local_addr)))
> + DBG(pppcp_get_ppp(pppcp), "");
> + break;
> + default:
> + break;
> + }
> + }
> +}
> +
> +static void ipv6cp_rcn_nak(struct pppcp_data *pppcp,
> + const struct pppcp_packet *packet)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> + struct ppp_option_iter iter;
> +
> + ppp_option_iter_init(&iter, packet);
> +
We have to be a bit careful here, if we are playing the server role then
we should not let the client dictate our interface ID. The reason being
that e.g. ConnMan might be allocating our interface ids from its own
pool and we can't really change it at this point.
> + while (ppp_option_iter_next(&iter) == TRUE) {
> + const guint8 *data = ppp_option_iter_get_data(&iter);
> +
> + switch (ppp_option_iter_get_type(&iter)) {
> + case IPV6CP_INTERFACE_ID:
> + memcpy(&ipv6cp->local_addr, data,
> + sizeof(ipv6cp->local_addr));
You might also want to make sure to set the flag to request the
interface id, though this is more of a problem with IPCP.
> + break;
> + default:
> + break;
> + }
> + }
> +
> + ipv6cp_generate_config_options(ipv6cp);
> + pppcp_set_local_options(pppcp, ipv6cp->options, ipv6cp->options_len);
> +}
> +
> +static void ipv6cp_rcn_rej(struct pppcp_data *pppcp,
> + const struct pppcp_packet *packet)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(pppcp);
> + struct ppp_option_iter iter;
> +
> + ppp_option_iter_init(&iter, packet);
> +
> + while (ppp_option_iter_next(&iter) == TRUE) {
> + switch (ppp_option_iter_get_type(&iter)) {
> + case IPV6CP_INTERFACE_ID:
> + ipv6cp->req_options &= ~IPV6CP_INTERFACE_ID;
> + memset(&ipv6cp->local_addr, 0,
> + sizeof(ipv6cp->local_addr));
This means that the peer refused to configure this option, it doesn't
mean that our idea of our interface (e.g. if we're the server) should be
reset...
> + break;
> + default:
> + break;
> + }
> + }
> +
> + ipv6cp_generate_config_options(ipv6cp);
> + pppcp_set_local_options(pppcp, ipv6cp->options, ipv6cp->options_len);
> +}
> +
> +struct pppcp_proto ipv6cp_proto = {
> + .proto = IPV6CP_PROTO,
> + .name = "ipv6cp",
> + .supported_codes = IPV6CP_SUPPORTED_CODES,
> + .this_layer_up = ipv6cp_up,
> + .this_layer_down = ipv6cp_down,
> + .this_layer_finished = ipv6cp_finished,
> + .rca = ipv6cp_rca,
> + .rcn_nak = ipv6cp_rcn_nak,
> + .rcn_rej = ipv6cp_rcn_rej,
> + .rcr = ipv6cp_rcr,
> +};
> +
> +struct pppcp_data *ipv6cp_new(GAtPPP *ppp, const struct eui64 *local_addr,
> + const struct eui64 *peer_addr)
> +{
> + struct ipv6cp_data *ipv6cp;
> + struct pppcp_data *pppcp;
> +
> + ipv6cp = g_try_new0(struct ipv6cp_data, 1);
> + if (ipv6cp == NULL)
> + return NULL;
> +
> + pppcp = pppcp_new(ppp, &ipv6cp_proto, FALSE, MAX_IPV6CP_FAILURE);
> + if (pppcp == NULL) {
> + g_free(ipv6cp);
> + return NULL;
> + }
> +
> + memcpy(&ipv6cp->local_addr, local_addr, sizeof(ipv6cp->local_addr));
> + memcpy(&ipv6cp->peer_addr, peer_addr, sizeof(ipv6cp->peer_addr));
> +
> + pppcp_set_data(pppcp, ipv6cp);
> +
> + ipv6cp_reset_config_options(ipv6cp);
> +
> + pppcp_set_local_options(pppcp, ipv6cp->options, ipv6cp->options_len);
> +
> + return pppcp;
> +}
> +
> +void ipv6cp_free(struct pppcp_data *data)
> +{
> + struct ipv6cp_data *ipv6cp = pppcp_get_data(data);
> +
> + g_free(ipv6cp);
> + pppcp_free(data);
> +}
> diff --git a/gatchat/test-server.c b/gatchat/test-server.c
> index 6f1d06d..59bbbe1 100644
> --- a/gatchat/test-server.c
> +++ b/gatchat/test-server.c
> @@ -58,6 +58,8 @@ static int modem_creg = 0;
> static int modem_cgreg = 0;
> static int network_status = 4;
> static int network_attach = 0;
> +static const char *ipv6_local_addr = NULL;
> +static const char *ipv6_peer_addr = NULL;
>
> struct sock_server{
> int server_sock;
> @@ -176,6 +178,9 @@ static gboolean setup_ppp(GAtServer *server)
> g_at_ppp_set_server_info(ppp, "192.168.1.2",
> "10.10.10.10", "10.10.10.11");
>
> + if (ipv6_local_addr || ipv6_peer_addr)
> + g_at_ppp_set_ipv6cp_info(ppp, ipv6_local_addr, ipv6_peer_addr);
> +
> return TRUE;
> }
>
> @@ -1118,11 +1123,13 @@ static void usage(void)
> {
> g_print("test-server - AT Server testing\n"
> "Usage:\n");
> - g_print("\ttest-server [-t type]\n");
> + g_print("\ttest-server [-t type] [-6 addr]\n");
Hm, this message makes no sense.
> g_print("Types:\n"
> "\t0: Pseudo TTY port (default)\n"
> "\t1: TCP sock at port 12346)\n"
> "\t2: Unix sock at ./server_sock\n");
> + g_print("-l\tSpecify local IPv6 address\n");
> + g_print("-p\tSpecify peer IPv6 address\n");
> }
>
> int main(int argc, char **argv)
> @@ -1130,11 +1137,17 @@ int main(int argc, char **argv)
> int opt, signal_source;
> int type = 0;
>
> - while ((opt = getopt(argc, argv, "ht:")) != EOF) {
> + while ((opt = getopt(argc, argv, "hl:p:t:")) != EOF) {
> switch (opt) {
> case 't':
> type = atoi(optarg);
> break;
> + case 'l':
> + ipv6_local_addr = optarg;
> + break;
> + case 'p':
> + ipv6_peer_addr = optarg;
> + break;
> case 'h':
> usage();
> exit(1);
Regards,
-Denis
^ permalink raw reply
* [U-Boot] [PATCH] arm: jadecpu: Readd MACH_TYPE_JADECPU
From: Igor Grinberg @ 2011-10-31 7:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320045986-3282-1-git-send-email-weisserm@arcor.de>
On 10/31/11 09:26, Matthias Weisser wrote:
> MACH_TYPE_JADECPU was removed from mach-types.h. Add it to board
> config file.
>
> Signed-off-by: Matthias Weisser <weisserm@arcor.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> board/syteco/jadecpu/jadecpu.c | 1 -
> include/configs/jadecpu.h | 6 ++++++
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c
> index 63a0d33..72288fe 100644
> --- a/board/syteco/jadecpu/jadecpu.c
> +++ b/board/syteco/jadecpu/jadecpu.c
> @@ -40,7 +40,6 @@ int board_init(void)
> writel(0x00000010, &ccnt->cmux_md);
>
> gd->flags = 0;
> - gd->bd->bi_arch_number = MACH_TYPE_JADECPU;
> gd->bd->bi_boot_params = PHYS_SDRAM + PHYS_SDRAM_SIZE - 0x10000;
>
> icache_enable();
> diff --git a/include/configs/jadecpu.h b/include/configs/jadecpu.h
> index a239efc..42cb858 100644
> --- a/include/configs/jadecpu.h
> +++ b/include/configs/jadecpu.h
> @@ -37,6 +37,12 @@
> #define CONFIG_USE_ARCH_MEMCPY
> #define CONFIG_USE_ARCH_MEMSET
>
> +#ifndef MACH_TYPE_JADECPU
> +#define MACH_TYPE_JADECPU 2636
> +#endif
> +
> +#define CONFIG_MACH_TYPE MACH_TYPE_JADECPU
> +
> /*
> * Environment settings
> */
--
Regards,
Igor.
^ permalink raw reply
* Re: [PATCH 1/2] Avoid use after free
From: Jes Sorensen @ 2011-10-31 7:41 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid, dledford
In-Reply-To: <20111031104358.24632497@notabene.brown>
On 10/31/11 00:43, NeilBrown wrote:
> On Fri, 28 Oct 2011 21:50:50 +0200 Jes.Sorensen@redhat.com wrote:
>
>> > From: Jes Sorensen <Jes.Sorensen@redhat.com>
>> >
>> > If picking just one spare disk from the container, jump out of the
>> > loop once freeing the list. Otherwise we end up accessing the list
>> > that we just freed.
>> >
>> > Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>> > ---
>> > util.c | 2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/util.c b/util.c
>> > index 2cf617d..1bbd87f 100644
>> > --- a/util.c
>> > +++ b/util.c
>> > @@ -1766,6 +1766,7 @@ struct mdinfo *container_choose_spares(struct supertype *st,
>> > if (get_one) {
>> > sysfs_free(*dp);
>> > d->next = NULL;
>> > + goto out;
>> > }
>> > } else {
>> > *dp = d->next;
>> > @@ -1773,5 +1774,6 @@ struct mdinfo *container_choose_spares(struct supertype *st,
>> > sysfs_free(d);
>> > }
>> > }
>> > +out:
>> > return disks;
>> > }
>
> Hi Jes,
> I dont' think patch is needed.
> The while loop that it jumps out of is
> while (*dp)
>
> at the place you put the goto,
> dp == &d->next
> As d->next was just set to NULL, *dp will be NULL, so the loop will
> exit with the need for a goto.
Hi Neil,
It has to be said, I didn't actually come up with this one on my own, it
was found by the Coverity security checker. I stared at this one for
quite a while. It is well obfuscated. So far I managed to convince
myself several times that you were right and also that Coverity is
correct. In the end I think that you are right indeed and this is a
false positive.
However, in order to avoid the confusion, how about changing the d->next
= NULL assignment to *dp = NULL instead? It should make it a lot more
clear for anyone reading the code what is going on.
Cheers,
Jes
^ permalink raw reply
* Re: powerpc 476, Little-endian, pte fault
From: Santosh Kumar @ 2011-10-31 7:38 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CAJw04pAh5QDQMkUHbj9=rRPiUCZejimHiydCJFMAoZeSd_ydhA@mail.gmail.com>
This is not the first user-space instruction. While executing this
process kernel has added two TLB entries with TID(process id) 1. while
trying to map 0x100000fc it is raising pte faults .
Santosh Kumar .A
Vision without Action is a daydream... Action without Vision is a nightmare=
...
On 31 October 2011 12:05, Santosh Kumar <santoshkumar.a@gmail.com> wrote:
> I have built a cross compiler for ppc440 in little endian mode and
> using it to build the kernel.
>
> Yes i am running Linux in Little-Endian. This is the first user space
> process. I wrote the below program and running it as init from
> /sbin/init. I have also set the permissions with chmod +s.
>
> main()
> {
>
> while(1){
> printf("hello world");
> sleep(1);
> =A0}
> }
>
> I have attached the patch.
>
> -
> Santosh Kumar .A
>
> Vision without Action is a daydream... Action without Vision is a nightma=
re...
>
>
>
> On 31 October 2011 11:21, Michael Neuling <mikey@neuling.org> wrote:
>> Adding linuxppc-dev list to the CC
>>
>>> KERNEL: linux 2.6.39.4
>>> POWERPC: 476, little endian.
>>>
>>> I am trying to get linux 2.6.39.4 up on PPC 476 i have done done
>>> Big-endian to little endian Changes in:
>>
>> Can you explain what you are trying to do in more detail? =A0What does "=
i
>> have done Big-endian to little endian Changes" mean?
>>
>>> 1) bitops header file.
>>> 2) while reading the device tree.
>>> 3) the PTE read/computed in head_32.S
>>> 4) added E bit in the TLB entries.
>>>
>>> with all the above changes the kernel_init is done but and inited is
>>> mounted.
>>
>> Can you post your patch?
>>
>> Are you trying to boot the kernel in little endian or just run userspace
>> in little endian?
>>
>>> But while spawning init process the kernel continuously hits pte
>>> faults at address 0x100000fc and never comes out. Please let me know
>>> where i should be looking into.
>>
>> Is this the very first userspace instruction?
>>
>> Mikey
>>
>>
>
^ permalink raw reply
* Re: powerpc 476, Little-endian, pte fault
From: Santosh Kumar @ 2011-10-31 7:38 UTC (permalink / raw)
To: Michael Neuling; +Cc: linux-kernel, linuxppc-dev, Tony Breeds
In-Reply-To: <CAJw04pAh5QDQMkUHbj9=rRPiUCZejimHiydCJFMAoZeSd_ydhA@mail.gmail.com>
This is not the first user-space instruction. While executing this
process kernel has added two TLB entries with TID(process id) 1. while
trying to map 0x100000fc it is raising pte faults .
Santosh Kumar .A
Vision without Action is a daydream... Action without Vision is a nightmare...
On 31 October 2011 12:05, Santosh Kumar <santoshkumar.a@gmail.com> wrote:
> I have built a cross compiler for ppc440 in little endian mode and
> using it to build the kernel.
>
> Yes i am running Linux in Little-Endian. This is the first user space
> process. I wrote the below program and running it as init from
> /sbin/init. I have also set the permissions with chmod +s.
>
> main()
> {
>
> while(1){
> printf("hello world");
> sleep(1);
> }
> }
>
> I have attached the patch.
>
> -
> Santosh Kumar .A
>
> Vision without Action is a daydream... Action without Vision is a nightmare...
>
>
>
> On 31 October 2011 11:21, Michael Neuling <mikey@neuling.org> wrote:
>> Adding linuxppc-dev list to the CC
>>
>>> KERNEL: linux 2.6.39.4
>>> POWERPC: 476, little endian.
>>>
>>> I am trying to get linux 2.6.39.4 up on PPC 476 i have done done
>>> Big-endian to little endian Changes in:
>>
>> Can you explain what you are trying to do in more detail? What does "i
>> have done Big-endian to little endian Changes" mean?
>>
>>> 1) bitops header file.
>>> 2) while reading the device tree.
>>> 3) the PTE read/computed in head_32.S
>>> 4) added E bit in the TLB entries.
>>>
>>> with all the above changes the kernel_init is done but and inited is
>>> mounted.
>>
>> Can you post your patch?
>>
>> Are you trying to boot the kernel in little endian or just run userspace
>> in little endian?
>>
>>> But while spawning init process the kernel continuously hits pte
>>> faults at address 0x100000fc and never comes out. Please let me know
>>> where i should be looking into.
>>
>> Is this the very first userspace instruction?
>>
>> Mikey
>>
>>
>
^ permalink raw reply
* [U-Boot] [PATCH] gplugD: Fix for error:MACH_TYPE_SHEEVAD undeclared
From: Ajay Bhargav @ 2011-10-31 7:36 UTC (permalink / raw)
To: u-boot
This patch fix the build failure (error: 'MACH_TYPE_SHEEVAD' undeclared
(first use in this function)) for gplugD due to recent sync of
mach-types.h with its linux original.
Signed-off-by: Ajay Bhargav <ajay.bhargav@einfochips.com>
---
include/configs/gplugd.h | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h
index 24bf767..9813309 100644
--- a/include/configs/gplugd.h
+++ b/include/configs/gplugd.h
@@ -32,6 +32,16 @@
#define __CONFIG_GPLUGD_H
/*
+ * FIXME: fix for error caused due to recent update to mach-types.h
+ */
+#include <asm/mach-types.h>
+#ifdef MACH_TYPE_SHEEVAD
+#error "MACH_TYPE_SHEEVAD has been defined properly, please remove this."
+#else
+#define MACH_TYPE_SHEEVAD 2625
+#endif
+
+/*
* Version number information
*/
#define CONFIG_IDENT_STRING "\nMarvell-gplugD"
@@ -42,7 +52,7 @@
#define CONFIG_SHEEVA_88SV331xV5 1 /* CPU Core subversion */
#define CONFIG_ARMADA100 1 /* SOC Family Name */
#define CONFIG_ARMADA168 1 /* SOC Used on this Board */
-#define CONFIG_MACH_SHEEVAD /* Machine type */
+#define CONFIG_MACH_TYPE MACH_TYPE_SHEEVAD /* Machine type */
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
#define CONFIG_SYS_TEXT_BASE 0x00f00000
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/5] drm/i915: don't bail out of intel_wait_ring_buffer too early
From: Daniel Vetter @ 2011-10-31 7:37 UTC (permalink / raw)
To: Ben Widawsky; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20111030182913.511d8d53@bwidawsk.net>
On Sun, Oct 30, 2011 at 06:29:13PM -0700, Ben Widawsky wrote:
> I didn't really check to see if there is actually an issue here, but
> instead of 60, do you want to play nice with timeouts such as
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT (ie. the min of all the timeouts and
> 60)?
Yeah, 60s should be half the default hung task timeout. But people who
muck around with these settings should know what they're doing, so I don't
care. Worst case we splatter the dmesg with hung task backtraces before we
continue (and then splatter the dmesg with gpu hung warnings).
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* [U-Boot] [PATCH] sh: Add a flag which controls the DDR ECC mode of sh7757lcr
From: Yoshihiro Shimoda @ 2011-10-31 7:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320034944-15419-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
Hi,
2011/10/31 13:22, Nobuhiro Iwamatsu wrote:
> When DDR-ECC is effective, the physical memory which can be used
> reduces this boardby half. However, this mode can chenge to disable.
> When it was disabled, user can use 512 MB of physical memory.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> CC: "Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>
Thank you for the patch.
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Thanks,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
From: Deepthi Dharwar @ 2011-10-31 7:32 UTC (permalink / raw)
To: Arjan van de Ven
Cc: khilman, venki, ak, len.brown, peterz, rjw, santosh.shilimkar,
lenb, linux-pm, linux-sh, linux-kernel, linux-acpi, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <4EAABB07.3000305@linux.intel.com>
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
>> The cpuidle_device->prepare() mechanism causes updates to the
>> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
>> to tell the governor not to chose a state on a per-cpu basis at
>> run-time. State demotion is now handled by the driver and it returns
>> the actual state entered. Hence, this mechanism is not required.
>> Also this removes per-cpu flags from cpuidle_state enabling
>> it to be made global.
>>
>
> having worked on some newer platforms....
> this one is really still needed. doing this inside the actual states
> does not work,
> because if the deepest 3 states are invalid, the same (somewhat
> expensive) test would have to be done 3 times,
> and each of the states would have to fail before the 4th one gets chosen.
> that's just not going to work
>
> (in the state handler you can't know what other state to fall back to,
> and especially not how to enter such a fallback state)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp
> XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim
> O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML
> hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo
> xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f
> fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0=
> =FL6o
> -----END PGP SIGNATURE-----
>
Hi Arjan,
Thanks for the review.
We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE
but still allow the dev->enter() to return index ?
So by retaining it, transition to the idle states
would be much quicker in case one more states are invalid.
Also to note is that in the newer design, we have split the
cpuidle_state structure. One global struct, cpuidle_states[] that
contains all the state related information including flags, and
the other cpuidle_device that contain statistics and other data
that are per-cpu basis.
So the flags are not per cpu per state basis but
maintained globally as per state basis.
So if we have to enable CPUIDLE_FLAG_IGNORE flag in this
current new design, then I am thinking if we needed to have this
on a per-cpu basis. If so, then flags have to be moved into cpuidle_device
struct rather than cpuidle_state struct.
Is it a good idea to retain these flags as global (part of cpuidle_states)
or make it per-cpu basis ?
-Thanks
Deepthi
^ permalink raw reply
* [PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
From: Deepthi Dharwar @ 2011-10-31 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAABB07.3000305@linux.intel.com>
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
>> The cpuidle_device->prepare() mechanism causes updates to the
>> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
>> to tell the governor not to chose a state on a per-cpu basis at
>> run-time. State demotion is now handled by the driver and it returns
>> the actual state entered. Hence, this mechanism is not required.
>> Also this removes per-cpu flags from cpuidle_state enabling
>> it to be made global.
>>
>
> having worked on some newer platforms....
> this one is really still needed. doing this inside the actual states
> does not work,
> because if the deepest 3 states are invalid, the same (somewhat
> expensive) test would have to be done 3 times,
> and each of the states would have to fail before the 4th one gets chosen.
> that's just not going to work
>
> (in the state handler you can't know what other state to fall back to,
> and especially not how to enter such a fallback state)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp
> XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim
> O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML
> hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo
> xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f
> fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0=
> =FL6o
> -----END PGP SIGNATURE-----
>
Hi Arjan,
Thanks for the review.
We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE
but still allow the dev->enter() to return index ?
So by retaining it, transition to the idle states
would be much quicker in case one more states are invalid.
Also to note is that in the newer design, we have split the
cpuidle_state structure. One global struct, cpuidle_states[] that
contains all the state related information including flags, and
the other cpuidle_device that contain statistics and other data
that are per-cpu basis.
So the flags are not per cpu per state basis but
maintained globally as per state basis.
So if we have to enable CPUIDLE_FLAG_IGNORE flag in this
current new design, then I am thinking if we needed to have this
on a per-cpu basis. If so, then flags have to be moved into cpuidle_device
struct rather than cpuidle_state struct.
Is it a good idea to retain these flags as global (part of cpuidle_states)
or make it per-cpu basis ?
-Thanks
Deepthi
^ permalink raw reply
* Re: [PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
From: Deepthi Dharwar @ 2011-10-31 7:32 UTC (permalink / raw)
To: Arjan van de Ven
Cc: khilman, venki, ak, len.brown, peterz, linux-pm, linux-kernel,
linux-acpi, linux-sh, linux-pm, linux-omap, linux-arm-kernel
In-Reply-To: <4EAABB07.3000305@linux.intel.com>
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
>> The cpuidle_device->prepare() mechanism causes updates to the
>> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
>> to tell the governor not to chose a state on a per-cpu basis at
>> run-time. State demotion is now handled by the driver and it returns
>> the actual state entered. Hence, this mechanism is not required.
>> Also this removes per-cpu flags from cpuidle_state enabling
>> it to be made global.
>>
>
> having worked on some newer platforms....
> this one is really still needed. doing this inside the actual states
> does not work,
> because if the deepest 3 states are invalid, the same (somewhat
> expensive) test would have to be done 3 times,
> and each of the states would have to fail before the 4th one gets chosen.
> that's just not going to work
>
> (in the state handler you can't know what other state to fall back to,
> and especially not how to enter such a fallback state)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp
> XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim
> O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML
> hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo
> xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f
> fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0=
> =FL6o
> -----END PGP SIGNATURE-----
>
Hi Arjan,
Thanks for the review.
We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE
but still allow the dev->enter() to return index ?
So by retaining it, transition to the idle states
would be much quicker in case one more states are invalid.
Also to note is that in the newer design, we have split the
cpuidle_state structure. One global struct, cpuidle_states[] that
contains all the state related information including flags, and
the other cpuidle_device that contain statistics and other data
that are per-cpu basis.
So the flags are not per cpu per state basis but
maintained globally as per state basis.
So if we have to enable CPUIDLE_FLAG_IGNORE flag in this
current new design, then I am thinking if we needed to have this
on a per-cpu basis. If so, then flags have to be moved into cpuidle_device
struct rather than cpuidle_state struct.
Is it a good idea to retain these flags as global (part of cpuidle_states)
or make it per-cpu basis ?
-Thanks
Deepthi
^ permalink raw reply
* [U-Boot] [PATCH 1/5] arm/km: adapt bootcounter evaluation
From: Prafulla Wadaskar @ 2011-10-31 7:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAAAA45.5060109@keymile.com>
> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck at keymile.com]
> Sent: Friday, October 28, 2011 6:43 PM
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; Valentin Longchamp
> Subject: Re: [PATCH 1/5] arm/km: adapt bootcounter evaluation
>
> Hi Prafulla,
>
> On 09/14/2011 10:41 AM, Holger Brunck wrote:
> > The bootcounter (stored in the RAM) is not enough protected
> with the 4 Bytes
> > BOOTCOUNT_MAGIC against bit errors due to short power loss or
> holding a system
> > in RESET. It has been seen, that the bootcounter value has
> been changed due to
> > a bit flip on a system holding in RESET, but the
> BOOTCOUNT_MAGIC was still valid.
> >
> > A bit pattern with 4000 bytes (after BOOTCOUNT_MAGIC) has
> been implemented,
> > which should be enough to detect a bit error.
> >
> > Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> > Signed-off-by: Valentin Longchamp
> <valentin.longchamp@keymile.com>
> > cc: Prafulla Wadaskar <prafulla@marvell.com>
> > ---
> > board/keymile/km_arm/km_arm.c | 32
> +++++++++++++++++++++++++++-----
> > 1 files changed, 27 insertions(+), 5 deletions(-)
> >
>
> ...ping...
>
> Or should this serie not go through your tree? If so then
> please let me know.
Generally not, this was done earlier by Wolfgang or Albert.
So I was assuming someone will pull.
Hi Wolfgang,
Please flag if I need to pull them.
Regards..
Prafulla . . .
>
> Same question for these two patches:
> http://lists.denx.de/pipermail/u-boot/2011-
> September/102534.html
> http://lists.denx.de/pipermail/u-boot/2011-
> September/102535.html
>
> Best regards
> Holger
^ permalink raw reply
* [U-Boot] [PATCH] ARM: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Jens Scharsig @ 2011-10-31 7:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAD27CB.9020907@aribaud.net>
Am 30.10.2011 11:32, schrieb Albert ARIBAUD:
> Hi Jens, Marek,
>
> Le 30/10/2011 00:47, Marek Vasut a ?crit :
>>> * re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
>>>
>>> Signed-off-by: Jens Scharsig<js_at_ng@scharsoft.de>
>>> ---
>>> include/configs/eb_cpux9k2.h | 4 ++++
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
>>> index 4324172..e437f25 100644
>>> --- a/include/configs/eb_cpux9k2.h
>>> +++ b/include/configs/eb_cpux9k2.h
>>> @@ -42,6 +42,10 @@
>>> #define CONFIG_BOARD_EARLY_INIT_F
>>>
>>> /*------------------------------------------------------------------------
>>> --*/
>>> +#ifndef MACH_TYPE_EB_CPUX9K2
>>> +#define MACH_TYPE_EB_CPUX9K2 1977
>>> +#endif
>>> +/*------------------------------------------------------------------------
>>> --*/
>>> #define CONFIG_SYS_TEXT_BASE 0x00000000
>>> #define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load address */
>>
>> You don't need the ifndef. Cheers
>
> I'd even say you need to not have them: this way, when the MACH_ID shows
> up eventually in machine-type, the preprocessor will emit a warning for
> the redefinition in the config file, thus letting us know it is time to
> remove the temporary MACH_TYPE there.
>
> Amicalement,
Ok, I will send a straightforward variant as V2 patch
Regards
Jens
^ permalink raw reply
* Re: is there a filesystem issue with kernel 3.0.x on pandaboards?
From: Koen Kooi @ 2011-10-31 7:27 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Yocto discussion list
In-Reply-To: <alpine.DEB.2.02.1110290915450.7280@localhost6.localdomain6>
Op 29 okt. 2011, om 15:19 heeft Robert P. J. Day het volgende geschreven:
>
> possibly off-topic but i'm sitting in a fedora/ARM talk right this
> minute at FSOSS/linuxfest at york u, and the presenter mentioned that
> when building fedora for pandaboards, they had to back off from kernel
> 3.0.4 to 2.6.35 because, in that situation, the filesystem had a bad
> habit of switching unpredictably into read-only mode.
>
> is this a known issue in any yocto context? again, sorry if this is
> wandering far afield but yocto on a pandaboard was at the top of my
> TODO list for this coming week.
I'm not seeing that problem on the pandaboard that's running 3.0.x and angstrom. The default in angstrom/meta-ti is 2.6.35 due to multimedia acceleration madness.
^ permalink raw reply
* [U-Boot] [PATCH] arm: jadecpu: Readd MACH_TYPE_JADECPU
From: Matthias Weisser @ 2011-10-31 7:26 UTC (permalink / raw)
To: u-boot
MACH_TYPE_JADECPU was removed from mach-types.h. Add it to board
config file.
Signed-off-by: Matthias Weisser <weisserm@arcor.de>
---
board/syteco/jadecpu/jadecpu.c | 1 -
include/configs/jadecpu.h | 6 ++++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c
index 63a0d33..72288fe 100644
--- a/board/syteco/jadecpu/jadecpu.c
+++ b/board/syteco/jadecpu/jadecpu.c
@@ -40,7 +40,6 @@ int board_init(void)
writel(0x00000010, &ccnt->cmux_md);
gd->flags = 0;
- gd->bd->bi_arch_number = MACH_TYPE_JADECPU;
gd->bd->bi_boot_params = PHYS_SDRAM + PHYS_SDRAM_SIZE - 0x10000;
icache_enable();
diff --git a/include/configs/jadecpu.h b/include/configs/jadecpu.h
index a239efc..42cb858 100644
--- a/include/configs/jadecpu.h
+++ b/include/configs/jadecpu.h
@@ -37,6 +37,12 @@
#define CONFIG_USE_ARCH_MEMCPY
#define CONFIG_USE_ARCH_MEMSET
+#ifndef MACH_TYPE_JADECPU
+#define MACH_TYPE_JADECPU 2636
+#endif
+
+#define CONFIG_MACH_TYPE MACH_TYPE_JADECPU
+
/*
* Environment settings
*/
--
1.7.4.1
^ permalink raw reply related
* [U-Boot] [PATCH V2] ARM: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Jens Scharsig @ 2011-10-31 7:26 UTC (permalink / raw)
To: u-boot
* re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de>
---
include/configs/eb_cpux9k2.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
index 4324172..ad51906 100644
--- a/include/configs/eb_cpux9k2.h
+++ b/include/configs/eb_cpux9k2.h
@@ -41,6 +41,8 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
+#define MACH_TYPE_EB_CPUX9K2 1977
+
/*--------------------------------------------------------------------------*/
#define CONFIG_SYS_TEXT_BASE 0x00000000
#define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load address */
--
1.7.3.4
^ permalink raw reply related
* Re: Building for pandaboard
From: Koen Kooi @ 2011-10-31 7:25 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: yocto
In-Reply-To: <alpine.DEB.2.02.1110281009190.7011@localhost6.localdomain6>
Op 28 okt. 2011, om 16:10 heeft Robert P. J. Day het volgende geschreven:
> On Thu, 27 Oct 2011, Brian Park wrote:
>
>> Hi,
>
>> I'm interested in using Yocto to build linux for PandaBoard. It
>> seems there are already patches some where that I can use to build
>> for panda, as I found some discussions mentioning PandaBoard patch
>> in the archive. But I could not apply it. I'd appreciate some
>> pointers on how to find and apply the right patch.
>>
>> Just trying to apply
>> http://article.gmane.org/gmane.linux.embedded.yocto.general/2037/match=pandaboard as a patch
>> using "git am" command gave the following error. I'm using release 1.1 Edison.
>>
>> briansp@LinuxMint11 ~/poky $ git am < ~/Documents/pandaboard.patch
>> previous rebase directory /home/briansp/poky/.git/rebase-apply still exists but mbox given.
>>
>> I'm new to developing for linux and yocto. So, any help would be appreciated.
>
> i am particulartly interested in this topic as i have two
> pandaboards waiting to be yocto-ized. might this be a more
> appropriate topic for the pandaboard mailing list?
The best pandaboard support is present in the meta-ti layer, to use it just follow the instructions at http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
regards,
Koen
^ permalink raw reply
* Re: Building for pandaboard
From: Koen Kooi @ 2011-10-31 7:25 UTC (permalink / raw)
To: Brian Park; +Cc: yocto
In-Reply-To: <CAFNE1kT5F9DXDBVsYwduvCRJ8GxOxc8u9h_FVjuTpO9+4y8VKg@mail.gmail.com>
Op 28 okt. 2011, om 19:06 heeft Brian Park het volgende geschreven:
> Thanks for the info.
> As I'm very new to Yocto, I'd not know how to create local.conf to build for panda, even knowing that the kernel will support pandaboard. How would I go about configuring Yocto to build for panda? If you can point me to some documentation showing how to do it, I'd appreciate it.
>
> I'm just learning yocto, in my spare time, and just went through the quick start guide to build for x86qemu image and skimmed through the development manual. But I'm not too sure how to go about configuring for pandaboard. I figured, I can build for beagle board and then modify config to make it work for panda. However, I'm having build issue when trying to build for beagle board.
>
> If there is already an existing pandaboard config, I'd like to try it.
The best pandaboard support is present in the meta-ti layer, to use it just follow the instructions at http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
regards,
Koen
^ permalink raw reply
* [PATCH for 3.2] fs/direct-io.c: Calculate fs_count correctly in get_more_blocks.
From: Tao Ma @ 2011-10-31 7:24 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-devel, Christoph Hellwig, Al Viro, Andrew Morton
In-Reply-To: <20111029105856.GA6479@infradead.org>
From: Tao Ma <boyu.mt@taobao.com>
In get_more_blocks, we use dio_count to calculate fs_count and do some
tricky things to increase fs_count if dio_count isn't aligned. But
actually it still has some cornor case that can't be coverd. See the
following example:
./dio_write foo -s 1024 -w 4096(direct write 4096 bytes at offset 1024).
The same goes if the offset isn't aligned to fs_blocksize.
In this case, the old calculation counts fs_count to be 1, but actually
we will write into 2 different blocks(if fs_blocksize=4096). The old code
just works, since it will call get_block twice(and may have to allocate
and create extent twice for file systems like ext4). So we'd better call
get_block just once with the proper fs_count.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
---
Christoph, this is the updated version. I have done some tests against it and
it works. And the only difference between the old and this one is the change
from dio to sdio. Thanks.
fs/direct-io.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index d740ab6..5582183 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -580,9 +580,8 @@ static int get_more_blocks(struct dio *dio, struct dio_submit *sdio,
{
int ret;
sector_t fs_startblk; /* Into file, in filesystem-sized blocks */
+ sector_t fs_endblk; /* Into file, in filesystem-sized blocks */
unsigned long fs_count; /* Number of filesystem-sized blocks */
- unsigned long dio_count;/* Number of dio_block-sized blocks */
- unsigned long blkmask;
int create;
/*
@@ -593,11 +592,9 @@ static int get_more_blocks(struct dio *dio, struct dio_submit *sdio,
if (ret == 0) {
BUG_ON(sdio->block_in_file >= sdio->final_block_in_request);
fs_startblk = sdio->block_in_file >> sdio->blkfactor;
- dio_count = sdio->final_block_in_request - sdio->block_in_file;
- fs_count = dio_count >> sdio->blkfactor;
- blkmask = (1 << sdio->blkfactor) - 1;
- if (dio_count & blkmask)
- fs_count++;
+ fs_endblk = (sdio->final_block_in_request - 1) >>
+ sdio->blkfactor;
+ fs_count = fs_endblk - fs_startblk + 1;
map_bh->b_state = 0;
map_bh->b_size = fs_count << dio->inode->i_blkbits;
--
1.7.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v3 03/13] qemu-timer: move common code to qemu_rearm_alarm_timer
From: TeLeMan @ 2011-10-31 7:23 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <1319214405-20388-4-git-send-email-pbonzini@redhat.com>
On Sat, Oct 22, 2011 at 00:26, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> qemu-timer.c | 129 ++++++++++++++++++++++++----------------------------------
> 1 files changed, 53 insertions(+), 76 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index acf7a15..e2551f3 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -153,7 +153,7 @@ struct qemu_alarm_timer {
> char const *name;
> int (*start)(struct qemu_alarm_timer *t);
> void (*stop)(struct qemu_alarm_timer *t);
> - void (*rearm)(struct qemu_alarm_timer *t);
> + void (*rearm)(struct qemu_alarm_timer *t, int64_t nearest_delta_ns);
> #if defined(__linux__)
> int fd;
> timer_t timer;
> @@ -181,12 +181,46 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
> return !!t->rearm;
> }
>
> +static int64_t qemu_next_alarm_deadline(void)
> +{
> + int64_t delta;
> + int64_t rtdelta;
> +
> + if (!use_icount && vm_clock->active_timers) {
> + delta = vm_clock->active_timers->expire_time -
> + qemu_get_clock_ns(vm_clock);
> + } else {
> + delta = INT32_MAX;
> + }
> + if (host_clock->active_timers) {
> + int64_t hdelta = host_clock->active_timers->expire_time -
> + qemu_get_clock_ns(host_clock);
> + if (hdelta < delta) {
> + delta = hdelta;
> + }
> + }
> + if (rt_clock->active_timers) {
> + rtdelta = (rt_clock->active_timers->expire_time -
> + qemu_get_clock_ns(rt_clock));
> + if (rtdelta < delta) {
> + delta = rtdelta;
> + }
> + }
> +
> + return delta;
> +}
> +
> static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
> {
> - if (!alarm_has_dynticks(t))
> + int64_t nearest_delta_ns;
> + assert(alarm_has_dynticks(t));
"mmtimer" and "win32" alarms have no rearm. Should we remove these two alarms?
> + if (!rt_clock->active_timers &&
> + !vm_clock->active_timers &&
> + !host_clock->active_timers) {
> return;
> -
> - t->rearm(t);
> + }
> + nearest_delta_ns = qemu_next_alarm_deadline();
> + t->rearm(t, nearest_delta_ns);
> }
>
> /* TODO: MIN_TIMER_REARM_NS should be optimized */
> @@ -196,23 +230,23 @@ static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
>
> static int mm_start_timer(struct qemu_alarm_timer *t);
> static void mm_stop_timer(struct qemu_alarm_timer *t);
> -static void mm_rearm_timer(struct qemu_alarm_timer *t);
> +static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);
>
> static int win32_start_timer(struct qemu_alarm_timer *t);
> static void win32_stop_timer(struct qemu_alarm_timer *t);
> -static void win32_rearm_timer(struct qemu_alarm_timer *t);
> +static void win32_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);
>
> #else
>
> static int unix_start_timer(struct qemu_alarm_timer *t);
> static void unix_stop_timer(struct qemu_alarm_timer *t);
> -static void unix_rearm_timer(struct qemu_alarm_timer *t);
> +static void unix_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);
>
> #ifdef __linux__
>
> static int dynticks_start_timer(struct qemu_alarm_timer *t);
> static void dynticks_stop_timer(struct qemu_alarm_timer *t);
> -static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
> +static void dynticks_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);
>
> #endif /* __linux__ */
>
> @@ -715,8 +749,6 @@ void qemu_run_all_timers(void)
> qemu_run_timers(host_clock);
> }
>
> -static int64_t qemu_next_alarm_deadline(void);
> -
> #ifdef _WIN32
> static void CALLBACK host_alarm_handler(PVOID lpParam, BOOLEAN unused)
> #else
> @@ -781,33 +813,6 @@ int64_t qemu_next_icount_deadline(void)
> return delta;
> }
>
> -static int64_t qemu_next_alarm_deadline(void)
> -{
> - int64_t delta;
> - int64_t rtdelta;
> -
> - if (!use_icount && vm_clock->active_timers) {
> - delta = vm_clock->active_timers->expire_time -
> - qemu_get_clock_ns(vm_clock);
> - } else {
> - delta = INT32_MAX;
> - }
> - if (host_clock->active_timers) {
> - int64_t hdelta = host_clock->active_timers->expire_time -
> - qemu_get_clock_ns(host_clock);
> - if (hdelta < delta)
> - delta = hdelta;
> - }
> - if (rt_clock->active_timers) {
> - rtdelta = (rt_clock->active_timers->expire_time -
> - qemu_get_clock_ns(rt_clock));
> - if (rtdelta < delta)
> - delta = rtdelta;
> - }
> -
> - return delta;
> -}
> -
> #if defined(__linux__)
>
> #include "compatfd.h"
> @@ -860,20 +865,13 @@ static void dynticks_stop_timer(struct qemu_alarm_timer *t)
> timer_delete(host_timer);
> }
>
> -static void dynticks_rearm_timer(struct qemu_alarm_timer *t)
> +static void dynticks_rearm_timer(struct qemu_alarm_timer *t,
> + int64_t nearest_delta_ns)
> {
> timer_t host_timer = t->timer;
> struct itimerspec timeout;
> - int64_t nearest_delta_ns = INT64_MAX;
> int64_t current_ns;
>
> - assert(alarm_has_dynticks(t));
> - if (!rt_clock->active_timers &&
> - !vm_clock->active_timers &&
> - !host_clock->active_timers)
> - return;
> -
> - nearest_delta_ns = qemu_next_alarm_deadline();
> if (nearest_delta_ns < MIN_TIMER_REARM_NS)
> nearest_delta_ns = MIN_TIMER_REARM_NS;
>
> @@ -915,19 +913,12 @@ static int unix_start_timer(struct qemu_alarm_timer *t)
> return 0;
> }
>
> -static void unix_rearm_timer(struct qemu_alarm_timer *t)
> +static void unix_rearm_timer(struct qemu_alarm_timer *t,
> + int64_t nearest_delta_ns)
> {
> struct itimerval itv;
> - int64_t nearest_delta_ns = INT64_MAX;
> int err;
>
> - assert(alarm_has_dynticks(t));
> - if (!rt_clock->active_timers &&
> - !vm_clock->active_timers &&
> - !host_clock->active_timers)
> - return;
> -
> - nearest_delta_ns = qemu_next_alarm_deadline();
> if (nearest_delta_ns < MIN_TIMER_REARM_NS)
> nearest_delta_ns = MIN_TIMER_REARM_NS;
>
> @@ -1014,23 +1005,14 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
> timeEndPeriod(mm_period);
> }
>
> -static void mm_rearm_timer(struct qemu_alarm_timer *t)
> +static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
> {
> - int nearest_delta_ms;
> -
> - assert(alarm_has_dynticks(t));
> - if (!rt_clock->active_timers &&
> - !vm_clock->active_timers &&
> - !host_clock->active_timers) {
> - return;
> - }
> -
> - timeKillEvent(mm_timer);
> -
> - nearest_delta_ms = (qemu_next_alarm_deadline() + 999999) / 1000000;
> + int nearest_delta_ms = (delta + 999999) / 1000000;
> if (nearest_delta_ms < 1) {
> nearest_delta_ms = 1;
> }
> +
> + timeKillEvent(mm_timer);
> mm_timer = timeSetEvent(nearest_delta_ms,
> mm_period,
> mm_alarm_handler,
> @@ -1082,19 +1064,14 @@ static void win32_stop_timer(struct qemu_alarm_timer *t)
> }
> }
>
> -static void win32_rearm_timer(struct qemu_alarm_timer *t)
> +static void win32_rearm_timer(struct qemu_alarm_timer *t,
> + int64_t nearest_delta_ns)
> {
> HANDLE hTimer = t->timer;
> int nearest_delta_ms;
> BOOLEAN success;
>
> - assert(alarm_has_dynticks(t));
> - if (!rt_clock->active_timers &&
> - !vm_clock->active_timers &&
> - !host_clock->active_timers)
> - return;
> -
> - nearest_delta_ms = (qemu_next_alarm_deadline() + 999999) / 1000000;
> + nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
> if (nearest_delta_ms < 1) {
> nearest_delta_ms = 1;
> }
> --
> 1.7.6
>
>
>
>
^ permalink raw reply
* RE: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Ganir, Chen @ 2011-10-31 7:19 UTC (permalink / raw)
To: Anderson Lizardo
Cc: Luiz Augusto von Dentz, Mat Martineau, Claudio Takahasi,
linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
ingas@codeaurora.org
In-Reply-To: <CAJdJm_MWFbfwZ6LGdUnJV6LzT4XRLFC17rsKXV4jMwSAOd5PSQ@mail.gmail.com>
Anderson,
> Hi Chen,
>
> We have been talking about consistence inside a single host. What has
> another "xyz" stack to do with making sure apps on the *same host* can
> run together and even access the same services?
>
I agree. Let's keep it simple for now.
> (This is not how it works on current implementation, but we already
> know that right?) You just keep reading the Value property in some
> loop in your code:
>
> while <blah>:
> read-Value-property
>
> If the connection is up, the ATT commands will be sent as soon as
> possible. If not, connection is triggered, and then the ATT read
> request/command is sent, and then PropertyChanged signal (should be)
> sent.
>
That's ok with me. We need to implement it in the DBUS API. We need to try and read the char value and return it as part of the response.
>
> Anyway, in Proximity, the characteristic values are not supposed to be
> polled (TX Power, for instance, should only read it once on each
> connection). So at least for Value reads, it is not useful as example.
>
I agree. Proximity is a bad example. Health thermometer on the other hand is a good example for the need to poll the value.
> Same reason as above. The rationale I gave you is based on how attio
> connection callbacks work, if the Generic API does not use it yet for
> reading values, surely this rationale does not apply to the current
> implementation. We are still discussing the API, right?
Yes, we are. I'm just trying to figure out how it's currently implemented
> Ok, I see a trend here :) We are now discussing about the current
> Generic API implementation and not about doc/attribute-api.txt nor
> your patch right? Ideally the .txt doc should always reflect the .c
> code, but currently it is not the case. I suggest we get back to the
> API discussion, then we can fix the code to behave like documented. Is
> that ok?
>
Unless I misunderstood, the doc/attribute-api.txt describes the generic API? Or is it called somewhat else? I'm talking about the DBUS interface which enables external GATT Clients to be implemented on top of DBUS.
>
> If it was meant to be some cache, I think it could be mentioned on the
> API document. The reason it is only read once is implementation
> limitation, not the API.
>
Ok. I understand this now. You were responding as if you were totally aware of the problematic current implementation, and this is why it was so strange and difficult to understand your arguments. Now that we agree on the fact that the property "Value" Should always be read, Can we also make sure that the Value property should be omitted from the "get_properties" response, in case there is no connection? What about writing the value? Should we allow the user to set the value with either Write request/Write Command/Write signed or do we really want to keep that internal (like read/read blob) ?
>
> It seems you are mapping the Core Spec's "client" definition as a
> D-Bus client. This will *not* work. A client (as per Core spec) is
> BlueZ. If it it provides external D-Bus API, it is out of scope for
> the specification.
>
> BTW, it seems the client.c code already do something like that
> (update_char_value()):
>
> else if (status == ATT_ECODE_INSUFF_ENC) {
> GIOChannel *io = g_attrib_get_channel(gatt->attrib);
>
> if (bt_io_set(io, BT_IO_L2CAP, NULL,
> BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_HIGH,
> BT_IO_OPT_INVALID)) {
> gatt_read_char(gatt->attrib, chr->handle, 0,
> update_char_value, current);
> return;
> }
> }
>
> But for sure it will require review after we agree on how to handle
> this.
>
>
> Again, you are assuming a Core spec's "client" as a D-Bus client. This
> may mean we have not been on the same page since long :)
>
Why do you think it will not work ? the DBUS for me is just a transparent transport for GATT operations. It should not have too much logic in it. The code mentioned above is also a bit problematic for me, since it hides some of the GATT functionality, and I'm not sure I'm still comfortable with this kind of encapsulation. Why do you think allowing the user to set the security level correctly before reading, or after getting the ATT_ECODE_INSUFF_ENC is wrong ? What do we benefit from hiding so much from the DBUS user who implements the profile? As I said before, I would rather let the DBUS client implementing the profile as much flexibility and control, to prevent future major changes to API when we realize we forgot something important.
Best regards,
Chen Ganir.
^ permalink raw reply
* Re: [Qemu-trivial] [Qemu-devel] [PATCH] cmd: Fix potential NULL pointer dereference
From: Pavel Borzenkov @ 2011-10-31 7:18 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-trivial, qemu-devel
In-Reply-To: <m3pqhdn09j.fsf@blackfin.pond.sub.org>
On Mon, Oct 31, 2011 at 10:27 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Pavel Borzenkov <pavel.borzenkov@gmail.com> writes:
>
>> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
>> ---
>> Note, that almost all code in the file violates CODING STYLE. The changed lines
>> are written wrt CODING STYLE (like commits 7d7d975c and c32d766a).
>>
>> ---
>>
>> cmd.c | 11 +++--------
>> 1 files changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/cmd.c b/cmd.c
>> index f77897e..abcf206 100644
>> --- a/cmd.c
>> +++ b/cmd.c
>> @@ -49,7 +49,7 @@ void
>> add_command(
>> const cmdinfo_t *ci)
>> {
>> - cmdtab = realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> + cmdtab = g_realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> cmdtab[ncmds - 1] = *ci;
>> qsort(cmdtab, ncmds, sizeof(*cmdtab), compare);
>> }
>
> Inconsistent indentation.
>
> Either stick to the original indentation, or reindent the whole
> function.
I'll send second version with coding style fixes made in a separate commit.
--
Pavel
>
> [More of the same...]
>
^ 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.