* Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
From: Mike Frysinger @ 2009-09-10 7:55 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, linux-mips, linux-i2c, linux-arm-kernel,
uclinux-dist-devel
In-Reply-To: <20090910062609.GA26454@pengutronix.de>
On Thu, Sep 10, 2009 at 02:26, Wolfram Sang wrote:
>> the Blackfin defconfigs refer to an input driver for the PCF8574, not
>> the I2C client driver
>
> Yup, I am aware of that. With the exception of:
>
> blackfin/configs/PNAV-10_defconfig:773:CONFIG_SENSORS_PCF8574=m
thanks for double checking. i'm not sure this board even has this
device. i'll review the hardware.
-mike
^ permalink raw reply
* Re: [PATCH] powerpc: perf_counters: Reduce stack usage of power_check_constraints
From: Michael Ellerman @ 2009-09-10 7:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <19112.40097.974792.747829@drongo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Thu, 2009-09-10 at 16:28 +1000, Paul Mackerras wrote:
> Michael Ellerman reported stack-frame size warnings being produced
> for power_check_constraints(), which uses an 8*8 array of u64 and
> two 8*8 arrays of unsigned long, which are currently allocated on the
> stack, along with some other smaller variables. These arrays come
> to 1.5kB on 64-bit or 1kB on 32-bit, which is a bit too much for the
> stack.
>
> This fixes the problem by putting these arrays in the existing
> per-cpu cpu_hw_counters struct. This is OK because two of the call
> sites have interrupts disabled already; for the third call site we
> use get_cpu_var, which disables preemption, so we know we won't
> get a context switch while we're in power_check_constraints().
> Note that power_check_constraints() can be called during context
> switch but is not called from interrupts.
Yep, it does indeed fix the build warning :D
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: perf_counters: Reduce stack usage of power_check_constraints
From: Paul Mackerras @ 2009-09-10 6:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Michael Ellerman reported stack-frame size warnings being produced
for power_check_constraints(), which uses an 8*8 array of u64 and
two 8*8 arrays of unsigned long, which are currently allocated on the
stack, along with some other smaller variables. These arrays come
to 1.5kB on 64-bit or 1kB on 32-bit, which is a bit too much for the
stack.
This fixes the problem by putting these arrays in the existing
per-cpu cpu_hw_counters struct. This is OK because two of the call
sites have interrupts disabled already; for the third call site we
use get_cpu_var, which disables preemption, so we know we won't
get a context switch while we're in power_check_constraints().
Note that power_check_constraints() can be called during context
switch but is not called from interrupts.
Reported-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kernel/perf_counter.c | 55 +++++++++++++++++++++---------------
1 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
index ccd6b21..7ceefaf 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -32,6 +32,9 @@ struct cpu_hw_counters {
unsigned long mmcr[3];
struct perf_counter *limited_counter[MAX_LIMITED_HWCOUNTERS];
u8 limited_hwidx[MAX_LIMITED_HWCOUNTERS];
+ u64 alternatives[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
+ unsigned long amasks[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
+ unsigned long avalues[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
};
DEFINE_PER_CPU(struct cpu_hw_counters, cpu_hw_counters);
@@ -239,13 +242,11 @@ static void write_pmc(int idx, unsigned long val)
* and see if any combination of alternative codes is feasible.
* The feasible set is returned in event[].
*/
-static int power_check_constraints(u64 event[], unsigned int cflags[],
+static int power_check_constraints(struct cpu_hw_counters *cpuhw,
+ u64 event[], unsigned int cflags[],
int n_ev)
{
unsigned long mask, value, nv;
- u64 alternatives[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
- unsigned long amasks[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
- unsigned long avalues[MAX_HWCOUNTERS][MAX_EVENT_ALTERNATIVES];
unsigned long smasks[MAX_HWCOUNTERS], svalues[MAX_HWCOUNTERS];
int n_alt[MAX_HWCOUNTERS], choice[MAX_HWCOUNTERS];
int i, j;
@@ -260,21 +261,23 @@ static int power_check_constraints(u64 event[], unsigned int cflags[],
if ((cflags[i] & PPMU_LIMITED_PMC_REQD)
&& !ppmu->limited_pmc_event(event[i])) {
ppmu->get_alternatives(event[i], cflags[i],
- alternatives[i]);
- event[i] = alternatives[i][0];
+ cpuhw->alternatives[i]);
+ event[i] = cpuhw->alternatives[i][0];
}
- if (ppmu->get_constraint(event[i], &amasks[i][0],
- &avalues[i][0]))
+ if (ppmu->get_constraint(event[i], &cpuhw->amasks[i][0],
+ &cpuhw->avalues[i][0]))
return -1;
}
value = mask = 0;
for (i = 0; i < n_ev; ++i) {
- nv = (value | avalues[i][0]) + (value & avalues[i][0] & addf);
+ nv = (value | cpuhw->avalues[i][0]) +
+ (value & cpuhw->avalues[i][0] & addf);
if ((((nv + tadd) ^ value) & mask) != 0 ||
- (((nv + tadd) ^ avalues[i][0]) & amasks[i][0]) != 0)
+ (((nv + tadd) ^ cpuhw->avalues[i][0]) &
+ cpuhw->amasks[i][0]) != 0)
break;
value = nv;
- mask |= amasks[i][0];
+ mask |= cpuhw->amasks[i][0];
}
if (i == n_ev)
return 0; /* all OK */
@@ -285,10 +288,11 @@ static int power_check_constraints(u64 event[], unsigned int cflags[],
for (i = 0; i < n_ev; ++i) {
choice[i] = 0;
n_alt[i] = ppmu->get_alternatives(event[i], cflags[i],
- alternatives[i]);
+ cpuhw->alternatives[i]);
for (j = 1; j < n_alt[i]; ++j)
- ppmu->get_constraint(alternatives[i][j],
- &amasks[i][j], &avalues[i][j]);
+ ppmu->get_constraint(cpuhw->alternatives[i][j],
+ &cpuhw->amasks[i][j],
+ &cpuhw->avalues[i][j]);
}
/* enumerate all possibilities and see if any will work */
@@ -307,11 +311,11 @@ static int power_check_constraints(u64 event[], unsigned int cflags[],
* where k > j, will satisfy the constraints.
*/
while (++j < n_alt[i]) {
- nv = (value | avalues[i][j]) +
- (value & avalues[i][j] & addf);
+ nv = (value | cpuhw->avalues[i][j]) +
+ (value & cpuhw->avalues[i][j] & addf);
if ((((nv + tadd) ^ value) & mask) == 0 &&
- (((nv + tadd) ^ avalues[i][j])
- & amasks[i][j]) == 0)
+ (((nv + tadd) ^ cpuhw->avalues[i][j])
+ & cpuhw->amasks[i][j]) == 0)
break;
}
if (j >= n_alt[i]) {
@@ -333,7 +337,7 @@ static int power_check_constraints(u64 event[], unsigned int cflags[],
svalues[i] = value;
smasks[i] = mask;
value = nv;
- mask |= amasks[i][j];
+ mask |= cpuhw->amasks[i][j];
++i;
j = -1;
}
@@ -341,7 +345,7 @@ static int power_check_constraints(u64 event[], unsigned int cflags[],
/* OK, we have a feasible combination, tell the caller the solution */
for (i = 0; i < n_ev; ++i)
- event[i] = alternatives[i][choice[i]];
+ event[i] = cpuhw->alternatives[i][choice[i]];
return 0;
}
@@ -745,7 +749,7 @@ int hw_perf_group_sched_in(struct perf_counter *group_leader,
return -EAGAIN;
if (check_excludes(cpuhw->counter, cpuhw->flags, n0, n))
return -EAGAIN;
- i = power_check_constraints(cpuhw->events, cpuhw->flags, n + n0);
+ i = power_check_constraints(cpuhw, cpuhw->events, cpuhw->flags, n + n0);
if (i < 0)
return -EAGAIN;
cpuhw->n_counters = n0 + n;
@@ -800,7 +804,7 @@ static int power_pmu_enable(struct perf_counter *counter)
cpuhw->flags[n0] = counter->hw.counter_base;
if (check_excludes(cpuhw->counter, cpuhw->flags, n0, 1))
goto out;
- if (power_check_constraints(cpuhw->events, cpuhw->flags, n0 + 1))
+ if (power_check_constraints(cpuhw, cpuhw->events, cpuhw->flags, n0 + 1))
goto out;
counter->hw.config = cpuhw->events[n0];
@@ -1005,6 +1009,7 @@ const struct pmu *hw_perf_counter_init(struct perf_counter *counter)
unsigned int cflags[MAX_HWCOUNTERS];
int n;
int err;
+ struct cpu_hw_counters *cpuhw;
if (!ppmu)
return ERR_PTR(-ENXIO);
@@ -1083,7 +1088,11 @@ const struct pmu *hw_perf_counter_init(struct perf_counter *counter)
cflags[n] = flags;
if (check_excludes(ctrs, cflags, n, 1))
return ERR_PTR(-EINVAL);
- if (power_check_constraints(events, cflags, n + 1))
+
+ cpuhw = &get_cpu_var(cpu_hw_counters);
+ err = power_check_constraints(cpuhw, events, cflags, n + 1);
+ put_cpu_var(cpu_hw_counters);
+ if (err)
return ERR_PTR(-EINVAL);
counter->hw.config = events[n];
--
1.5.5.rc3.7.gba13
^ permalink raw reply related
* Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
From: Wolfram Sang @ 2009-09-10 6:26 UTC (permalink / raw)
To: Mike Frysinger
Cc: linuxppc-dev, linux-mips, linux-i2c, linux-arm-kernel,
uclinux-dist-devel
In-Reply-To: <8bd0f97a0909091654h290180e5ob79178583aca143f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
> the Blackfin defconfigs refer to an input driver for the PCF8574, not
> the I2C client driver
Yup, I am aware of that. With the exception of:
blackfin/configs/PNAV-10_defconfig:773:CONFIG_SENSORS_PCF8574=m
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Sachin Sant @ 2009-09-10 5:32 UTC (permalink / raw)
To: rostedt; +Cc: linuxppc-dev
In-Reply-To: <1252525364.27001.32.camel@gandalf.stny.rr.com>
Steven Rostedt wrote:
> Ah, seems the bug happens to be in the module handling. Does the call
> back always have .mod_return_to_handler?
>
Yes. Every time it ends up in .mod_return_to_handler
Thanks
-Sachin
> This doesn't surprise me any. The module code is a bit harry, and
> function graph does some crazy crap with it.
>
> -- Steve
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH 3/3] ucc_geth: Fix hangs after switching from full to half duplex
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev, Andy Fleming, Timur Tabi
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: mdio@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: mdio@e0102120:00 - Link is Down
PHY: mdio@e0102120:00 - Link is Up - 100/Half
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at c01fcbd0 [verbose debug info unavailable]
NIP: c01fcbd0 LR: c01fcbd0 CTR: c0194e44
...
The cure is to disable the controller before changing speed/duplex
and enable it afterwards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 2a2c973..9ad9015 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1631,9 +1631,13 @@ static void adjust_link(struct net_device *dev)
ugeth->oldspeed = phydev->speed;
}
+ ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
+
out_be32(&ug_regs->maccfg2, tempval);
out_be32(&uf_regs->upsmr, upsmr);
+ ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
+
if (!ugeth->oldlink) {
new_state = 1;
ugeth->oldlink = 1;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] ucc_geth: Rearrange some code to avoid forward declarations
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev, Andy Fleming, Timur Tabi
We'll need ugeth_disable() and ugeth_enable() calls earlier in the
file, so rearrange some code to avoid forward declarations.
The patch doesn't contain any functional changes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 300 ++++++++++++++++++++++++------------------------
1 files changed, 149 insertions(+), 151 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 33ed69e..2a2c973 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1411,6 +1411,155 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
return 0;
}
+static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u32 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Mask GRACEFUL STOP TX interrupt bit and clear it */
+ clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
+ out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
+
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+
+ /* Wait for command to complete */
+ do {
+ msleep(10);
+ temp = in_be32(uccf->p_ucce);
+ } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
+
+ uccf->stopped_tx = 1;
+
+ return 0;
+}
+
+static int ugeth_graceful_stop_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u8 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Clear acknowledge bit */
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
+ out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
+
+ /* Keep issuing command and checking acknowledge bit until
+ it is asserted, according to spec */
+ do {
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
+ ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+ msleep(10);
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
+
+ uccf->stopped_rx = 1;
+
+ return 0;
+}
+
+static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
+ uccf->stopped_tx = 0;
+
+ return 0;
+}
+
+static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
+ 0);
+ uccf->stopped_rx = 0;
+
+ return 0;
+}
+
+static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+ int enabled_tx, enabled_rx;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ enabled_tx = uccf->enabled_tx;
+ enabled_rx = uccf->enabled_rx;
+
+ /* Get Tx and Rx going again, in case this channel was actively
+ disabled. */
+ if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
+ ugeth_restart_tx(ugeth);
+ if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
+ ugeth_restart_rx(ugeth);
+
+ ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
+
+ return 0;
+
+}
+
+static int ugeth_disable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ /* Stop any transmissions */
+ if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
+ ugeth_graceful_stop_tx(ugeth);
+
+ /* Stop any receptions */
+ if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
+ ugeth_graceful_stop_rx(ugeth);
+
+ ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
+
+ return 0;
+}
+
/* Called every time the controller might need to be made
* aware of new link state. The PHY code conveys this
* information through variables in the ugeth structure, and this
@@ -1586,157 +1735,6 @@ static int init_phy(struct net_device *dev)
return 0;
}
-
-
-static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u32 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Mask GRACEFUL STOP TX interrupt bit and clear it */
- clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
- out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
-
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
-
- /* Wait for command to complete */
- do {
- msleep(10);
- temp = in_be32(uccf->p_ucce);
- } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
-
- uccf->stopped_tx = 1;
-
- return 0;
-}
-
-static int ugeth_graceful_stop_rx(struct ucc_geth_private * ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u8 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Clear acknowledge bit */
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
- out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
-
- /* Keep issuing command and checking acknowledge bit until
- it is asserted, according to spec */
- do {
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
- ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
- msleep(10);
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
-
- uccf->stopped_rx = 1;
-
- return 0;
-}
-
-static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
- uccf->stopped_tx = 0;
-
- return 0;
-}
-
-static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
- 0);
- uccf->stopped_rx = 0;
-
- return 0;
-}
-
-static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
- int enabled_tx, enabled_rx;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- enabled_tx = uccf->enabled_tx;
- enabled_rx = uccf->enabled_rx;
-
- /* Get Tx and Rx going again, in case this channel was actively
- disabled. */
- if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
- ugeth_restart_tx(ugeth);
- if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
- ugeth_restart_rx(ugeth);
-
- ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
-
- return 0;
-
-}
-
-static int ugeth_disable(struct ucc_geth_private * ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- /* Stop any transmissions */
- if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
- ugeth_graceful_stop_tx(ugeth);
-
- /* Stop any receptions */
- if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
- ugeth_graceful_stop_rx(ugeth);
-
- ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
-
- return 0;
-}
-
static void ugeth_dump_regs(struct ucc_geth_private *ugeth)
{
#ifdef DEBUG
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] phy/marvell: Make non-aneg speed/duplex forcing work for 88E1111 PHYs
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev, Andy Fleming, Timur Tabi
According to specs, when auto-negotiation is disabled, Marvell PHYs need
a software reset after changing speed/duplex forcing bits. Otherwise,
the modified bits have no effect.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/marvell.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index dd6f54d..6f69b9b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -155,8 +155,27 @@ static int marvell_config_aneg(struct phy_device *phydev)
return err;
err = genphy_config_aneg(phydev);
+ if (err < 0)
+ return err;
- return err;
+ if (phydev->autoneg != AUTONEG_ENABLE) {
+ int bmcr;
+
+ /*
+ * A write to speed/duplex bits (that is performed by
+ * genphy_config_aneg() call above) must be followed by
+ * a software reset. Otherwise, the write has no effect.
+ */
+ bmcr = phy_read(phydev, MII_BMCR);
+ if (bmcr < 0)
+ return bmcr;
+
+ err = phy_write(phydev, MII_BMCR, bmcr | BMCR_RESET);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
}
static int m88e1121_config_aneg(struct phy_device *phydev)
--
1.6.3.3
^ permalink raw reply related
* RE: Queries regarding I2C and GPIO driver for Freescale MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
From: Chen Hongjun-R66092 @ 2009-09-10 0:57 UTC (permalink / raw)
To: Uma Kanta Patro, linuxppc-dev
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACk7Zq0ADiBFlLw+tPrMt1bCgAAAEAAAAFtTs5+/RRJLtaFyAuWiLDoBAAAAAA==@implantaire.com>
[-- Attachment #1: Type: text/plain, Size: 5424 bytes --]
>From the following error message, I2C controller can't receive ACK from
I2C client, so please make sure that the pins of I2C have been
initialized properly, or you can measure the tx signal and rx signal on
the right pins.
B.R,
Hongjun
________________________________
From: Uma Kanta Patro [mailto:upatro@implantaire.com]
Sent: Wednesday, September 09, 2009 9:13 PM
To: Chen Hongjun-R66092; linuxppc-dev@lists.ozlabs.org
Subject: RE: Queries regarding I2C and GPIO driver for Freescale
MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
Hi Chen Hongjun-R66092,
Thanks for your response.
Actually for the GPIO driver I am having some success and it is
in progress.
But regarding the I2C chip(client) driver I am running witout
any progress.
Actually I followed the existing driver
$(LINUX)\drivers\rtc\rtc-m41t80.c (for the RTC M41T62 existing on the
ADS5121Rev4.1 board).
I made a legacy style driver with attach_adapter and
detach_client functions defined.
For testing purpose I geve the chip address as 0x68(address of
M41T62 existing on the board). But when I tried ot insert my driver I
get the error message as:
[root@freescale chips]# insmod dis_fpc.ko
[ 177.808848] i2c 0-0068: uevent
[ 498.528032] In dis_fpc_init
[ 498.531851] i2c-core: driver [dis_fpc] registered
[ 498.532446] In dis_fpc_attach_adapter
[ 498.536827] i2c-adapter i2c-0: found normal entry for adapter
0, addr 0x55
[ 498.537730] i2c-adapter i2c-0: master_xfer[0] W, addr=0x55,
len=0
[ 498.538533] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.539770] I2C: No RXAK
[ 498.540970] In dis_fpc_attach_adapter
[ 498.554500] i2c-adapter i2c-1: found normal entry for adapter
1, addr 0x55
[ 498.555166] i2c-adapter i2c-1: master_xfer[0] W, addr=0x55,
len=0
[ 498.555872] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.556785] I2C: MAL
[ 498.557476] In dis_fpc_attach_adapter
[ 498.565733] i2c-adapter i2c-2: found normal entry for adapter
2, addr 0x55
[ 498.566377] i2c-adapter i2c-2: master_xfer[0] W, addr=0x55,
len=0
[ 498.567082] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.568240] I2C: No RXAK
So can you tell me what other places do I need to change the
configurations( like i2c_platform_data definition, linking the chip to
the specific I2C module(0/1/2) with the adapter, configuring the speed
of I2C communication etc).
I would like to get any suggestion on making the I2C chip driver
inpowerpc platform.
Thanks & Regards,
Uma
From: Chen Hongjun-R66092 [mailto:hong-jun.chen@freescale.com]
Sent: Wednesday, September 09, 2009 5:39 AM
To: Uma Kanta Patro; linuxppc-dev@lists.ozlabs.org
Subject: RE: Queries regarding I2C and GPIO driver for Freescale
MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
One I2C driver has been included in 0603 bsp, you can refer to
it.
It has no specific driver for GPIO, but you can find some
initializing code for GPIO in arch/powerpc/platforms/512x/mpc5125_ads.c.
and mpc512x_pm_test.c.
________________________________
From:
linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.or
g] On Behalf Of Uma Kanta Patro
Sent: Tuesday, September 08, 2009 6:56 PM
To: linuxppc-dev@lists.ozlabs.org
Subject: Queries regarding I2C and GPIO driver for
Freescale MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
Hi all,
I am a newbie to the powerpc linux
kernel, but I have worked on some drivers in arm architecture. I am
finding powerpc architecture to be fully different than that.
I am working on Freescale MPC5121e with the BSP
MPC512xADS_20090603-ltib.iso running in it on the ADS512101 Rev4.1
development kit.
Can anyone help me in finding some documentation for
understanding and working on the powerpc kernel. Any links to the
powerpc forums will also be appreciable.
-> Currently I am going to develop an I2C client driver
for one slave microcontroller of our project.
I have some knowledge in the I2C client driver
making(legacy style and new style).
I made a basic I2C client driver to probe for the chip
address and for testing I gave it the chip address 0x68(I2C chip address
of the M4T162 RTC, present on the board).
But while inserting my driver I am getting failure
message for the detection of my chip.
So I would like to know what other formalities am I
lagging in my I2C chip driver.
-> Also I am in a need for the GPIO driver for my
controller ot get interrupt on ht estate change. When I searched in the
kernel code I could not find any procedure to do that, also I could not
find out the procedure to access either any GPIO pin macros or any
register to remap with ioremap(). So please guide me in finding the
proper way to do the GPIO accessing and interrupt registration.
Will the ioremap() work on powerpc arch? If yes where
can I find the memory mapping(register definitions) to use for my GPIO
driver making.
Thanks for patience in reading my queries.
Any help is appreciable.
Thanks & Regards,
Uma
[-- Attachment #2: Type: text/html, Size: 14782 bytes --]
^ permalink raw reply
* Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
From: Mike Frysinger @ 2009-09-09 23:54 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, linux-mips, linux-i2c, linux-arm-kernel,
uclinux-dist-devel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
On Wed, Sep 9, 2009 at 17:22, Wolfram Sang wrote:
> continuing the quest to clean up and ultimately remove the drivers/i2c/chips
> directory, this patch series removes three drivers for GPIO-expanders which are
> obsoleted and marked as deprecated for more than a year. The newer (and better)
> drivers can be found in drivers/gpio.
>
> As it is ensured that the newer drivers cover the same i2c_device_ids, all
> platform_devices will still match. Some defconfig updates may be necessary
> though, but according to [1] this is left to the arch|platform-maintainers
> (also as most defconfigs are quite outdated). For that reason, I put the
> relevant arch-mailing-lists to Cc. Comments are welcome.
the Blackfin defconfigs refer to an input driver for the PCF8574, not
the I2C client driver
-mike
^ permalink raw reply
* powerpc/ps3: Workaround for flash memory I/O error
From: Geoff Levand @ 2009-09-09 23:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, stable
A workaround for flash memory I/O errors when the PS3 internal
hard disk has not been formatted for OtherOS use.
This error condition mainly effects 'Live CD' users who have not
formatted the PS3's internal hard disk for OtherOS.
Fixes errors similar to these when using the ps3-flash-util
or ps3-boot-game-os programs:
ps3flash read failed 0x2050000
os_area_header_read: read error: os_area_header: Input/output error
main:627: os_area_read_hp error.
ERROR: can't change boot flag
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3stor_lib.c | 65 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 62 insertions(+), 3 deletions(-)
--- a/drivers/ps3/ps3stor_lib.c
+++ b/drivers/ps3/ps3stor_lib.c
@@ -23,6 +23,65 @@
#include <asm/lv1call.h>
#include <asm/ps3stor.h>
+/*
+ * A workaround for flash memory I/O errors when the internal hard disk
+ * has not been formatted for OtherOS use. Delay disk close until flash
+ * memory is closed.
+ */
+
+static struct ps3_flash_workaround {
+ int flash_open;
+ int disk_open;
+ struct ps3_system_bus_device *disk_sbd;
+} ps3_flash_workaround;
+
+static int ps3stor_open_hv_device(struct ps3_system_bus_device *sbd)
+{
+ int error = ps3_open_hv_device(sbd);
+
+ if (error)
+ return error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_FLASH)
+ ps3_flash_workaround.flash_open = 1;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK)
+ ps3_flash_workaround.disk_open = 1;
+
+ return 0;
+}
+
+static int ps3stor_close_hv_device(struct ps3_system_bus_device *sbd)
+{
+ int error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK
+ && ps3_flash_workaround.disk_open
+ && ps3_flash_workaround.flash_open) {
+ ps3_flash_workaround.disk_sbd = sbd;
+ return 0;
+ }
+
+ error = ps3_close_hv_device(sbd);
+
+ if (error)
+ return error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK)
+ ps3_flash_workaround.disk_open = 0;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_FLASH) {
+ ps3_flash_workaround.flash_open = 0;
+
+ if (ps3_flash_workaround.disk_sbd) {
+ ps3_close_hv_device(ps3_flash_workaround.disk_sbd);
+ ps3_flash_workaround.disk_open = 0;
+ ps3_flash_workaround.disk_sbd = NULL;
+ }
+ }
+
+ return 0;
+}
static int ps3stor_probe_access(struct ps3_storage_device *dev)
{
@@ -90,7 +149,7 @@ int ps3stor_setup(struct ps3_storage_dev
int error, res, alignment;
enum ps3_dma_page_size page_size;
- error = ps3_open_hv_device(&dev->sbd);
+ error = ps3stor_open_hv_device(&dev->sbd);
if (error) {
dev_err(&dev->sbd.core,
"%s:%u: ps3_open_hv_device failed %d\n", __func__,
@@ -166,7 +225,7 @@ fail_free_irq:
fail_sb_event_receive_port_destroy:
ps3_sb_event_receive_port_destroy(&dev->sbd, dev->irq);
fail_close_device:
- ps3_close_hv_device(&dev->sbd);
+ ps3stor_close_hv_device(&dev->sbd);
fail:
return error;
}
@@ -193,7 +252,7 @@ void ps3stor_teardown(struct ps3_storage
"%s:%u: destroy event receive port failed %d\n",
__func__, __LINE__, error);
- error = ps3_close_hv_device(&dev->sbd);
+ error = ps3stor_close_hv_device(&dev->sbd);
if (error)
dev_err(&dev->sbd.core,
"%s:%u: ps3_close_hv_device failed %d\n", __func__,
^ permalink raw reply
* Re: [PATCH 3/4] i2c/chips: Remove deprecated pca9539-driver
From: Ben Gardner @ 2009-09-09 23:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mips, linuxppc-dev, linux-i2c, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-4-git-send-email-w.sang@pengutronix.de>
On Wed, Sep 9, 2009 at 4:22 PM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> The pca9539-driver in drivers/i2c/chips which just exports its registers to
> sysfs is superseeded by drivers/gpio/pca953x.c which properly uses the gpiolib.
> As this driver has been deprecated for more than a year, finally remove it.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Ben Gardner <gardner.ben@gmail.com>
> Cc: Jean Delvare <khali@linux-fr.org>
Acked-by: Ben Gardner <gardner.ben@gmail.com>
Thanks for taking care of this.
Ben
^ permalink raw reply
* [PATCH 4/4] i2c/chips: Remove deprecated pcf8574-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, linuxppc-dev, linux-arm-kernel, Jean Delvare,
uclinux-dist-devel, Aurelien Jarno
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pcf8574-driver in drivers/i2c/chips which just exports its register to
sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pcf8574 | 65 ------------
drivers/i2c/chips/Kconfig | 17 ---
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pcf8574.c | 215 ---------------------------------------
4 files changed, 0 insertions(+), 298 deletions(-)
delete mode 100644 Documentation/i2c/chips/pcf8574
delete mode 100644 drivers/i2c/chips/pcf8574.c
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574
deleted file mode 100644
index 235815c..0000000
--- a/Documentation/i2c/chips/pcf8574
+++ /dev/null
@@ -1,65 +0,0 @@
-Kernel driver pcf8574
-=====================
-
-Supported chips:
- * Philips PCF8574
- Prefix: 'pcf8574'
- Addresses scanned: none
- Datasheet: Publicly available at the Philips Semiconductors website
- http://www.semiconductors.philips.com/pip/PCF8574P.html
-
- * Philips PCF8574A
- Prefix: 'pcf8574a'
- Addresses scanned: none
- Datasheet: Publicly available at the Philips Semiconductors website
- http://www.semiconductors.philips.com/pip/PCF8574P.html
-
-Authors:
- Frodo Looijaard <frodol@dds.nl>,
- Philip Edelbrock <phil@netroedge.com>,
- Dan Eaton <dan.eaton@rocketlogix.com>,
- Aurelien Jarno <aurelien@aurel32.net>,
- Jean Delvare <khali@linux-fr.org>,
-
-
-Description
------------
-The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips
-Semiconductors. It is designed to provide a byte I2C interface to up to 16
-separate devices (8 x PCF8574 and 8 x PCF8574A).
-
-This device consists of a quasi-bidirectional port. Each of the eight I/Os
-can be independently used as an input or output. To setup an I/O as an
-input, you have to write a 1 to the corresponding output.
-
-For more informations see the datasheet.
-
-
-Accessing PCF8574(A) via /sys interface
--------------------------------------
-
-The PCF8574(A) is plainly impossible to detect ! Stupid chip.
-So, you have to pass the I2C bus and address of the installed PCF857A
-and PCF8574A devices explicitly to the driver at load time via the
-force=... parameter.
-
-On detection (i.e. insmod, modprobe et al.), directories are being
-created for each detected PCF8574(A):
-
-/sys/bus/i2c/devices/<0>-<1>/
-where <0> is the bus the chip was detected on (e. g. i2c-0)
-and <1> the chip address ([20..27] or [38..3f]):
-
-(example: /sys/bus/i2c/devices/1-0020/)
-
-Inside these directories, there are two files each:
-read and write (and one file with chip name).
-
-The read file is read-only. Reading gives you the current I/O input
-if the corresponding output is set as 1, otherwise the current output
-value, that is to say 0.
-
-The write file is read/write. Writing a value outputs it on the I/O
-port. Reading returns the last written value. As it is not possible
-to read this value from the chip, you need to write at least once to
-this file before you can read back from it.
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 8cd1a7f..f9618f4 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -16,23 +16,6 @@ config DS1682
This driver can also be built as a module. If so, the module
will be called ds1682.
-config SENSORS_PCF8574
- tristate "Philips PCF8574 and PCF8574A (DEPRECATED)"
- depends on EXPERIMENTAL && GPIO_PCF857X = "n"
- default n
- help
- If you say yes here you get support for Philips PCF8574 and
- PCF8574A chips. These chips are 8-bit I/O expanders for the I2C bus.
-
- This driver can also be built as a module. If so, the module
- will be called pcf8574.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pcf857x.c instead.
-
- These devices are hard to detect and rarely found on mainstream
- hardware. If unsure, say N.
-
config SENSORS_TSL2550
tristate "Taos TSL2550 ambient light sensor"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 8cd778d..749cf36 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -11,7 +11,6 @@
#
obj-$(CONFIG_DS1682) += ds1682.o
-obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
diff --git a/drivers/i2c/chips/pcf8574.c b/drivers/i2c/chips/pcf8574.c
deleted file mode 100644
index 6ec3098..0000000
--- a/drivers/i2c/chips/pcf8574.c
+++ /dev/null
@@ -1,215 +0,0 @@
-/*
- Copyright (c) 2000 Frodo Looijaard <frodol@dds.nl>,
- Philip Edelbrock <phil@netroedge.com>,
- Dan Eaton <dan.eaton@rocketlogix.com>
- Ported to Linux 2.6 by Aurelien Jarno <aurel32@debian.org> with
- the help of Jean Delvare <khali@linux-fr.org>
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- 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., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-/* A few notes about the PCF8574:
-
-* The PCF8574 is an 8-bit I/O expander for the I2C bus produced by
- Philips Semiconductors. It is designed to provide a byte I2C
- interface to up to 8 separate devices.
-
-* The PCF8574 appears as a very simple SMBus device which can be
- read from or written to with SMBUS byte read/write accesses.
-
- --Dan
-
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/i2c.h>
-
-/* Addresses to scan: none, device can't be detected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_2(pcf8574, pcf8574a);
-
-/* Each client has this additional data */
-struct pcf8574_data {
- int write; /* Remember last written value */
-};
-
-static void pcf8574_init_client(struct i2c_client *client);
-
-/* following are the sysfs callback functions */
-static ssize_t show_read(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%u\n", i2c_smbus_read_byte(client));
-}
-
-static DEVICE_ATTR(read, S_IRUGO, show_read, NULL);
-
-static ssize_t show_write(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct pcf8574_data *data = i2c_get_clientdata(to_i2c_client(dev));
-
- if (data->write < 0)
- return data->write;
-
- return sprintf(buf, "%d\n", data->write);
-}
-
-static ssize_t set_write(struct device *dev, struct device_attribute *attr, const char *buf,
- size_t count)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct pcf8574_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
-
- if (val > 0xff)
- return -EINVAL;
-
- data->write = val;
- i2c_smbus_write_byte(client, data->write);
- return count;
-}
-
-static DEVICE_ATTR(write, S_IWUSR | S_IRUGO, show_write, set_write);
-
-static struct attribute *pcf8574_attributes[] = {
- &dev_attr_read.attr,
- &dev_attr_write.attr,
- NULL
-};
-
-static const struct attribute_group pcf8574_attr_group = {
- .attrs = pcf8574_attributes,
-};
-
-/*
- * Real code
- */
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pcf8574_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
- const char *client_name;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE))
- return -ENODEV;
-
- /* Now, we would do the remaining detection. But the PCF8574 is plainly
- impossible to detect! Stupid chip. */
-
- /* Determine the chip type */
- if (kind <= 0) {
- if (client->addr >= 0x38 && client->addr <= 0x3f)
- kind = pcf8574a;
- else
- kind = pcf8574;
- }
-
- if (kind == pcf8574a)
- client_name = "pcf8574a";
- else
- client_name = "pcf8574";
- strlcpy(info->type, client_name, I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pcf8574_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- struct pcf8574_data *data;
- int err;
-
- data = kzalloc(sizeof(struct pcf8574_data), GFP_KERNEL);
- if (!data) {
- err = -ENOMEM;
- goto exit;
- }
-
- i2c_set_clientdata(client, data);
-
- /* Initialize the PCF8574 chip */
- pcf8574_init_client(client);
-
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &pcf8574_attr_group);
- if (err)
- goto exit_free;
- return 0;
-
- exit_free:
- kfree(data);
- exit:
- return err;
-}
-
-static int pcf8574_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pcf8574_attr_group);
- kfree(i2c_get_clientdata(client));
- return 0;
-}
-
-/* Called when we have found a new PCF8574. */
-static void pcf8574_init_client(struct i2c_client *client)
-{
- struct pcf8574_data *data = i2c_get_clientdata(client);
- data->write = -EAGAIN;
-}
-
-static const struct i2c_device_id pcf8574_id[] = {
- { "pcf8574", 0 },
- { "pcf8574a", 0 },
- { }
-};
-
-static struct i2c_driver pcf8574_driver = {
- .driver = {
- .name = "pcf8574",
- },
- .probe = pcf8574_probe,
- .remove = pcf8574_remove,
- .id_table = pcf8574_id,
-
- .detect = pcf8574_detect,
- .address_data = &addr_data,
-};
-
-static int __init pcf8574_init(void)
-{
- return i2c_add_driver(&pcf8574_driver);
-}
-
-static void __exit pcf8574_exit(void)
-{
- i2c_del_driver(&pcf8574_driver);
-}
-
-
-MODULE_AUTHOR
- ("Frodo Looijaard <frodol@dds.nl>, "
- "Philip Edelbrock <phil@netroedge.com>, "
- "Dan Eaton <dan.eaton@rocketlogix.com> "
- "and Aurelien Jarno <aurelien@aurel32.net>");
-MODULE_DESCRIPTION("PCF8574 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pcf8574_init);
-module_exit(pcf8574_exit);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/4] i2c/chips: Remove deprecated pca9539-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, Ben Gardner, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pca9539-driver in drivers/i2c/chips which just exports its registers to
sysfs is superseeded by drivers/gpio/pca953x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Ben Gardner <gardner.ben@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pca9539 | 58 ---------------
drivers/i2c/chips/Kconfig | 13 ----
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pca9539.c | 152 ---------------------------------------
4 files changed, 0 insertions(+), 224 deletions(-)
delete mode 100644 Documentation/i2c/chips/pca9539
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
deleted file mode 100644
index 6aff890..0000000
--- a/Documentation/i2c/chips/pca9539
+++ /dev/null
@@ -1,58 +0,0 @@
-Kernel driver pca9539
-=====================
-
-NOTE: this driver is deprecated and will be dropped soon, use
-drivers/gpio/pca9539.c instead.
-
-Supported chips:
- * Philips PCA9539
- Prefix: 'pca9539'
- Addresses scanned: none
- Datasheet:
- http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
-
-Author: Ben Gardner <bgardner@wabtec.com>
-
-
-Description
------------
-
-The Philips PCA9539 is a 16 bit low power I/O device.
-All 16 lines can be individually configured as an input or output.
-The input sense can also be inverted.
-The 16 lines are split between two bytes.
-
-
-Detection
----------
-
-The PCA9539 is difficult to detect and not commonly found in PC machines,
-so you have to pass the I2C bus and address of the installed PCA9539
-devices explicitly to the driver at load time via the force=... parameter.
-
-
-Sysfs entries
--------------
-
-Each is a byte that maps to the 8 I/O bits.
-A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
-
-input[01] - read the current value
-output[01] - sets the output value
-direction[01] - direction of each bit: 1=input, 0=output
-invert[01] - toggle the input bit sense
-
-input reads the actual state of the line and is always available.
-The direction defaults to input for all channels.
-
-
-General Remarks
----------------
-
-Note that each output, direction, and invert entry controls 8 lines.
-You should use the read, modify, write sequence.
-For example. to set output bit 0 of 1.
- val=$(cat output0)
- val=$(( $val | 1 ))
- echo $val > output0
-
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 1b5455e..8cd1a7f 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -33,19 +33,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)"
- depends on EXPERIMENTAL && GPIO_PCA953X = "n"
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pca953x.c instead.
-
config SENSORS_TSL2550
tristate "Taos TSL2550 ambient light sensor"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index fceb377..8cd778d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -11,7 +11,6 @@
#
obj-$(CONFIG_DS1682) += ds1682.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index 270de4e..0000000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- pca9539.c - 16-bit I/O port with interrupt and reset
-
- Copyright (C) 2005 Ben Gardner <bgardner@wabtec.com>
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; version 2 of the License.
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/i2c.h>
-#include <linux/hwmon-sysfs.h>
-
-/* Addresses to scan: none, device is not autodetected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0 = 2,
- PCA9539_OUTPUT_1 = 3,
- PCA9539_INVERT_0 = 4,
- PCA9539_INVERT_1 = 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-/* following are the sysfs callback functions */
-static ssize_t pca9539_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%d\n", i2c_smbus_read_byte_data(client,
- psa->index));
-}
-
-static ssize_t pca9539_store(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- unsigned long val = simple_strtoul(buf, NULL, 0);
- if (val > 0xff)
- return -EINVAL;
- i2c_smbus_write_byte_data(client, psa->index, val);
- return count;
-}
-
-/* Define the device attributes */
-
-#define PCA9539_ENTRY_RO(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO, pca9539_show, NULL, cmd_idx)
-
-#define PCA9539_ENTRY_RW(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO | S_IWUSR, pca9539_show, \
- pca9539_store, cmd_idx)
-
-PCA9539_ENTRY_RO(input0, PCA9539_INPUT_0);
-PCA9539_ENTRY_RO(input1, PCA9539_INPUT_1);
-PCA9539_ENTRY_RW(output0, PCA9539_OUTPUT_0);
-PCA9539_ENTRY_RW(output1, PCA9539_OUTPUT_1);
-PCA9539_ENTRY_RW(invert0, PCA9539_INVERT_0);
-PCA9539_ENTRY_RW(invert1, PCA9539_INVERT_1);
-PCA9539_ENTRY_RW(direction0, PCA9539_DIRECTION_0);
-PCA9539_ENTRY_RW(direction1, PCA9539_DIRECTION_1);
-
-static struct attribute *pca9539_attributes[] = {
- &sensor_dev_attr_input0.dev_attr.attr,
- &sensor_dev_attr_input1.dev_attr.attr,
- &sensor_dev_attr_output0.dev_attr.attr,
- &sensor_dev_attr_output1.dev_attr.attr,
- &sensor_dev_attr_invert0.dev_attr.attr,
- &sensor_dev_attr_invert1.dev_attr.attr,
- &sensor_dev_attr_direction0.dev_attr.attr,
- &sensor_dev_attr_direction1.dev_attr.attr,
- NULL
-};
-
-static struct attribute_group pca9539_defattr_group = {
- .attrs = pca9539_attributes,
-};
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pca9539_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
- return -ENODEV;
-
- strlcpy(info->type, "pca9539", I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pca9539_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- /* Register sysfs hooks */
- return sysfs_create_group(&client->dev.kobj,
- &pca9539_defattr_group);
-}
-
-static int pca9539_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pca9539_defattr_group);
- return 0;
-}
-
-static const struct i2c_device_id pca9539_id[] = {
- { "pca9539", 0 },
- { }
-};
-
-static struct i2c_driver pca9539_driver = {
- .driver = {
- .name = "pca9539",
- },
- .probe = pca9539_probe,
- .remove = pca9539_remove,
- .id_table = pca9539_id,
-
- .detect = pca9539_detect,
- .address_data = &addr_data,
-};
-
-static int __init pca9539_init(void)
-{
- return i2c_add_driver(&pca9539_driver);
-}
-
-static void __exit pca9539_exit(void)
-{
- i2c_del_driver(&pca9539_driver);
-}
-
-MODULE_AUTHOR("Ben Gardner <bgardner@wabtec.com>");
-MODULE_DESCRIPTION("PCA9539 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pca9539_init);
-module_exit(pca9539_exit);
-
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/4] i2c/chips: Remove deprecated pcf8575-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, Bart Van Assche, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pcf8575-driver in drivers/i2c/chips which just exports its register to
sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Bart Van Assche <bart.vanassche@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pcf8575 | 69 --------------
drivers/i2c/chips/Kconfig | 18 ----
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pcf8575.c | 198 ---------------------------------------
4 files changed, 0 insertions(+), 286 deletions(-)
delete mode 100644 Documentation/i2c/chips/pcf8575
delete mode 100644 drivers/i2c/chips/pcf8575.c
diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575
deleted file mode 100644
index 40b268e..0000000
--- a/Documentation/i2c/chips/pcf8575
+++ /dev/null
@@ -1,69 +0,0 @@
-About the PCF8575 chip and the pcf8575 kernel driver
-====================================================
-
-The PCF8575 chip is produced by the following manufacturers:
-
- * Philips NXP
- http://www.nxp.com/#/pip/cb=[type=product,path=50807/41735/41850,final=PCF8575_3]|pip=[pip=PCF8575_3][0]
-
- * Texas Instruments
- http://focus.ti.com/docs/prod/folders/print/pcf8575.html
-
-
-Some vendors sell small PCB's with the PCF8575 mounted on it. You can connect
-such a board to a Linux host via e.g. an USB to I2C interface. Examples of
-PCB boards with a PCF8575:
-
- * SFE Breakout Board for PCF8575 I2C Expander by RobotShop
- http://www.robotshop.ca/home/products/robot-parts/electronics/adapters-converters/sfe-pcf8575-i2c-expander-board.html
-
- * Breakout Board for PCF8575 I2C Expander by Spark Fun Electronics
- http://www.sparkfun.com/commerce/product_info.php?products_id=8130
-
-
-Description
------------
-The PCF8575 chip is a 16-bit I/O expander for the I2C bus. Up to eight of
-these chips can be connected to the same I2C bus. You can find this
-chip on some custom designed hardware, but you won't find it on PC
-motherboards.
-
-The PCF8575 chip consists of a 16-bit quasi-bidirectional port and an I2C-bus
-interface. Each of the sixteen I/O's can be independently used as an input or
-an output. To set up an I/O pin as an input, you have to write a 1 to the
-corresponding output.
-
-For more information please see the datasheet.
-
-
-Detection
----------
-
-There is no method known to detect whether a chip on a given I2C address is
-a PCF8575 or whether it is any other I2C device, so you have to pass the I2C
-bus and address of the installed PCF8575 devices explicitly to the driver at
-load time via the force=... parameter.
-
-/sys interface
---------------
-
-For each address on which a PCF8575 chip was found or forced the following
-files will be created under /sys:
-* /sys/bus/i2c/devices/<bus>-<address>/read
-* /sys/bus/i2c/devices/<bus>-<address>/write
-where bus is the I2C bus number (0, 1, ...) and address is the four-digit
-hexadecimal representation of the 7-bit I2C address of the PCF8575
-(0020 .. 0027).
-
-The read file is read-only. Reading it will trigger an I2C read and will hence
-report the current input state for the pins configured as inputs, and the
-current output value for the pins configured as outputs.
-
-The write file is read-write. Writing a value to it will configure all pins
-as output for which the corresponding bit is zero. Reading the write file will
-return the value last written, or -EAGAIN if no value has yet been written to
-the write file.
-
-On module initialization the configuration of the chip is not changed -- the
-chip is left in the state it was already configured in through either power-up
-or through previous I2C write actions.
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 02d746c..1b5455e 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -33,24 +33,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config PCF8575
- tristate "Philips PCF8575 (DEPRECATED)"
- default n
- depends on GPIO_PCF857X = "n"
- help
- If you say yes here you get support for Philips PCF8575 chip.
- This chip is a 16-bit I/O expander for the I2C bus. Several other
- chip manufacturers sell equivalent chips, e.g. Texas Instruments.
-
- This driver can also be built as a module. If so, the module
- will be called pcf8575.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pcf857x.c instead.
-
- This device is hard to detect and is rarely found on mainstream
- hardware. If unsure, say N.
-
config SENSORS_PCA9539
tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)"
depends on EXPERIMENTAL && GPIO_PCA953X = "n"
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index f4680d1..fceb377 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -13,7 +13,6 @@
obj-$(CONFIG_DS1682) += ds1682.o
obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
-obj-$(CONFIG_PCF8575) += pcf8575.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
diff --git a/drivers/i2c/chips/pcf8575.c b/drivers/i2c/chips/pcf8575.c
deleted file mode 100644
index 07fd7cb..0000000
--- a/drivers/i2c/chips/pcf8575.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- pcf8575.c
-
- About the PCF8575 chip: the PCF8575 is a 16-bit I/O expander for the I2C bus
- produced by a.o. Philips Semiconductors.
-
- Copyright (C) 2006 Michael Hennerich, Analog Devices Inc.
- <hennerich@blackfin.uclinux.org>
- Based on pcf8574.c.
-
- Copyright (c) 2007 Bart Van Assche <bart.vanassche@gmail.com>.
- Ported this driver from ucLinux to the mainstream Linux kernel.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- 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., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/i2c.h>
-#include <linux/slab.h> /* kzalloc() */
-#include <linux/sysfs.h> /* sysfs_create_group() */
-
-/* Addresses to scan: none, device can't be detected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD;
-
-
-/* Each client has this additional data */
-struct pcf8575_data {
- int write; /* last written value, or error code */
-};
-
-/* following are the sysfs callback functions */
-static ssize_t show_read(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct i2c_client *client = to_i2c_client(dev);
- u16 val;
- u8 iopin_state[2];
-
- i2c_master_recv(client, iopin_state, 2);
-
- val = iopin_state[0];
- val |= iopin_state[1] << 8;
-
- return sprintf(buf, "%u\n", val);
-}
-
-static DEVICE_ATTR(read, S_IRUGO, show_read, NULL);
-
-static ssize_t show_write(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct pcf8575_data *data = dev_get_drvdata(dev);
- if (data->write < 0)
- return data->write;
- return sprintf(buf, "%d\n", data->write);
-}
-
-static ssize_t set_write(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct pcf8575_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- u8 iopin_state[2];
-
- if (val > 0xffff)
- return -EINVAL;
-
- data->write = val;
-
- iopin_state[0] = val & 0xFF;
- iopin_state[1] = val >> 8;
-
- i2c_master_send(client, iopin_state, 2);
-
- return count;
-}
-
-static DEVICE_ATTR(write, S_IWUSR | S_IRUGO, show_write, set_write);
-
-static struct attribute *pcf8575_attributes[] = {
- &dev_attr_read.attr,
- &dev_attr_write.attr,
- NULL
-};
-
-static const struct attribute_group pcf8575_attr_group = {
- .attrs = pcf8575_attributes,
-};
-
-/*
- * Real code
- */
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pcf8575_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
- return -ENODEV;
-
- /* This is the place to detect whether the chip at the specified
- address really is a PCF8575 chip. However, there is no method known
- to detect whether an I2C chip is a PCF8575 or any other I2C chip. */
-
- strlcpy(info->type, "pcf8575", I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pcf8575_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- struct pcf8575_data *data;
- int err;
-
- data = kzalloc(sizeof(struct pcf8575_data), GFP_KERNEL);
- if (!data) {
- err = -ENOMEM;
- goto exit;
- }
-
- i2c_set_clientdata(client, data);
- data->write = -EAGAIN;
-
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &pcf8575_attr_group);
- if (err)
- goto exit_free;
-
- return 0;
-
-exit_free:
- kfree(data);
-exit:
- return err;
-}
-
-static int pcf8575_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pcf8575_attr_group);
- kfree(i2c_get_clientdata(client));
- return 0;
-}
-
-static const struct i2c_device_id pcf8575_id[] = {
- { "pcf8575", 0 },
- { }
-};
-
-static struct i2c_driver pcf8575_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = "pcf8575",
- },
- .probe = pcf8575_probe,
- .remove = pcf8575_remove,
- .id_table = pcf8575_id,
-
- .detect = pcf8575_detect,
- .address_data = &addr_data,
-};
-
-static int __init pcf8575_init(void)
-{
- return i2c_add_driver(&pcf8575_driver);
-}
-
-static void __exit pcf8575_exit(void)
-{
- i2c_del_driver(&pcf8575_driver);
-}
-
-MODULE_AUTHOR("Michael Hennerich <hennerich@blackfin.uclinux.org>, "
- "Bart Van Assche <bart.vanassche@gmail.com>");
-MODULE_DESCRIPTION("pcf8575 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pcf8575_init);
-module_exit(pcf8575_exit);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/4] gpio/pcf857x: copy i2c_device_id from old pcf8574-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, David Brownell, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The deprecated pcf8574 driver is going to be removed. Make sure this
replacement-driver inherits all i2c_device_ids for a smooth transition.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Jean Delvare <khali@linux-fr.org>
---
drivers/gpio/pcf857x.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/pcf857x.c b/drivers/gpio/pcf857x.c
index 9525724..3f1ec1e 100644
--- a/drivers/gpio/pcf857x.c
+++ b/drivers/gpio/pcf857x.c
@@ -28,6 +28,7 @@
static const struct i2c_device_id pcf857x_id[] = {
{ "pcf8574", 8 },
+ { "pcf8574a", 8 },
{ "pca8574", 8 },
{ "pca9670", 8 },
{ "pca9672", 8 },
--
1.6.3.3
^ permalink raw reply related
* Removing deprecated drivers from drivers/i2c/chips
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c; +Cc: linuxppc-dev, uclinux-dist-devel, linux-arm-kernel, linux-mips
Hi,
continuing the quest to clean up and ultimately remove the drivers/i2c/chips
directory, this patch series removes three drivers for GPIO-expanders which are
obsoleted and marked as deprecated for more than a year. The newer (and better)
drivers can be found in drivers/gpio.
As it is ensured that the newer drivers cover the same i2c_device_ids, all
platform_devices will still match. Some defconfig updates may be necessary
though, but according to [1] this is left to the arch|platform-maintainers
(also as most defconfigs are quite outdated). For that reason, I put the
relevant arch-mailing-lists to Cc. Comments are welcome.
Regards,
Wolfram
[1] http://lkml.org/lkml/2009/5/7/34
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Mark Bishop @ 2009-09-09 20:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090909182227.GA8215@b07421-ec1.am.freescale.net>
Quoting Scott Wood <scottwood@freescale.com>:
> On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
>> The following patch is needed to correctly assign the IRQs for the
>> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
>> as well as the interrupt lines for the two devices.
>
> And it will incorrectly assign them on older revisions of the chip.
>
> We really should have a u-boot fixup based on SVR.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
I have both versions of the boards and I use two versions of the .dts
file. Actually, four, two to support the old style uboot .dts that
comes with Freescale's BSP and 2 that support the newer uboot.
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kim Phillips @ 2009-09-09 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Roland Lezuo
In-Reply-To: <F7AA2B23-A019-4E11-993D-AF0F6F1FD50A@kernel.crashing.org>
On Wed, 9 Sep 2009 15:28:01 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
>
> > On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> >> The following patch is needed to correctly assign the IRQs for the
> >> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> >> as well as the interrupt lines for the two devices.
> >
> > And it will incorrectly assign them on older revisions of the chip.
> >
> > We really should have a u-boot fixup based on SVR.
definitely.
> I felt like Kim did this.
I never got my hands on a Rev. C board. What's the SVR on it? I think
this is also valid for Rev. B boards, and I don't have one of those
either.
Kim
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kumar Gala @ 2009-09-09 20:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Roland Lezuo
In-Reply-To: <20090909182227.GA8215@b07421-ec1.am.freescale.net>
On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
> On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
>> The following patch is needed to correctly assign the IRQs for the
>> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
>> as well as the interrupt lines for the two devices.
>
> And it will incorrectly assign them on older revisions of the chip.
>
> We really should have a u-boot fixup based on SVR.
I felt like Kim did this.
- k
^ permalink raw reply
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Steven Rostedt @ 2009-09-09 19:42 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev
In-Reply-To: <4AA74AE2.5090001@in.ibm.com>
On Wed, 2009-09-09 at 11:57 +0530, Sachin Sant wrote:
> Steven Rostedt wrote:
> > I'm going through old email, and I found this. Do you still see this
> > error. I don't recall seeing it myself.
> >
> I can still recreate this with 31-rc9. When i enable tracing
> with function_graph i notice the following oops. This happens
> only once. Later if i try to enable/disable tracing i don't
> get this oops message. This behavior is observed only with
> function_graph. Other tracers work fine.
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea ibmveth sg cdrom sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
> NIP: c000000000008f30 LR: c000000000008f04 CTR: 80000000000f6d68
> REGS: c00000003e98f560 TRAP: 0300 Not tainted (2.6.31-rc9)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000422 XER: 00000020
> DAR: 0000000000000008, DSISR: 0000000040000000
> TASK = c00000003e953b20[2483] 'irqbalance' THREAD: c00000003e98c000 CPU: 1
> GPR00: c000000000008f04 c00000003e98f7e0 d00000000117ed38 0000000000000000
> GPR04: 0000000000000000 0000000066000000 00000000000010bf 0000000000000000
> GPR08: 0000000000000000 800000010021bb40 00000000000000ff 800000010021bb60
> GPR12: 0000000000000002 c000000001032800 0000000000000000 ffffffffeffdff68
> GPR16: 00000fffa39fd6a0 00000fffa39e6c38 c00000003ebe9c38 fffffffffffff000
> GPR20: c00000002a6cf980 c00000003e98fdf8 c00000003e98fba8 00000fffa1740000
> GPR24: fffffffffffff000 8001000003000000 ffe0000000000000 0000000000000009
> GPR28: c00000003db40000 0000000000020000 d00000000117da78 c00000003e98f850
> NIP [c000000000008f30] .mod_return_to_handler+0x2c/0x64
> LR [c000000000008f04] .mod_return_to_handler+0x0/0x64
> Call Trace:
> [c00000003e98f7e0] [c00000002a6cf980] 0xc00000002a6cf980 (unreliable)
> [c00000003e98f850] [c000000000008f04] .mod_return_to_handler+0x0/0x64
> [c00000003e98f900] [c000000000008f04] .mod_return_to_handler+0x0/0x64
> [c00000003e98f9a0] [c000000000008f04] .mod_return_to_handler+0x0/0x64
Ah, seems the bug happens to be in the module handling. Does the call
back always have .mod_return_to_handler?
This doesn't surprise me any. The module code is a bit harry, and
function graph does some crazy crap with it.
-- Steve
> [c00000003e98fa30] [c000000000008ed0] .return_to_handler+0x0/0x34 (.bad_page_fault+0xc8/0xe8)
> [c00000003e98fb30] [c000000000008ed0] .return_to_handler+0x0/0x34 (handle_page_fault+0x3c/0x5c)
> [c00000003e98fc20] [c000000000008ed0] .return_to_handler+0x0/0x34 (.ehea_h_query_ehea_port+0x74/0x9c [ehea])
> [c00000003e98fcd0] [c000000000008ed0] .return_to_handler+0x0/0x34 (.ehea_get_stats+0xa0/0x1d0 [ehea])
> [c00000003e98fd80] [c000000000008ed0] .return_to_handler+0x0/0x34 (.dev_get_stats+0x50/0xec)
> [c00000003e98fe30] [c000000000008ed0] .return_to_handler+0x0/0x34 (.dev_seq_show+0x5c/0x140)
> Instruction dump:
> 4e800020 f881ffe0 f861ffe8 f841fff0 fbe1fff8 7c3f0b78 f821ff91 3c800000
> 60840000 788407c6 64840000 60840000 <e8440008> 48126375 60000000 7c6803a6
> ---[ end trace bb43efc994aed790 ]---
>
> function_graph traces are recorded and can be retrieved using
> /sys/kernel/debug/tracing/trace.
>
> 1) 3.936 us | }
> 1) | .release_console_sem() {
> 1) 0.594 us | ._spin_lock_irqsave();
> 1) 0.560 us | ._call_console_drivers();
> 1) 0.580 us | ._call_console_drivers();
> 1) 0.582 us | ._spin_lock_irqsave();
> 1) | .up() {
> 1) 0.592 us | ._spin_lock_irqsave();
> 1) 0.556 us | ._spin_unlock_irqrestore();
> 1) 2.842 us | }
> 1) 0.588 us | ._spin_unlock_irqrestore();
> 1) 9.750 us | }
> 1) + 75.274 us | }
> 1) | .die() {
> 1) | .oops_enter() {
>
> Thanks
> -Sachin
>
^ permalink raw reply
* Re: [PATCH] 82xx: kmalloc failure ignored in ep8248e_mdio_probe()
From: Scott Wood @ 2009-09-09 18:46 UTC (permalink / raw)
To: Roel Kluin; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <4AA7C095.7090009@gmail.com>
On Wed, Sep 09, 2009 at 04:49:57PM +0200, Roel Kluin wrote:
> Prevent NULL dereference if kmalloc() fails. Also clean up if
> of_mdiobus_register() returns an error.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: Question about e300 core decrementer interrupt
From: Scott Wood @ 2009-09-09 18:43 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: linuxppc-dev, Li Tao-B22598
In-Reply-To: <1252494967.10293.6.camel@localhost>
On Wed, Sep 09, 2009 at 01:16:07PM +0200, Kenneth Johansson wrote:
> On Tue, 2009-09-08 at 13:48 +0800, Li Tao-B22598 wrote:
> > Dear all,
> >
> > I have a problem in MPC5121 sleep mode. As you know MPC5121 use e300c4
> > core. When I make the e300c4 core into sleep mode, it will return to
> > full power mode when the“decrementer interrupt” occurred.
> >
> > But in the e300 core reference manual said that the “decrementer
> > interrupt”have no effect when e300 core in sleep mode, because the
> > time
> > base and decrementer are disabled while the core is in sleep mode.
> > Can anybody explain about this procedure ?
I'm not specifically familiar with MPC5121, but I'll answer from the
perspective of MPC83xx which has a similar core:
The decrementer stops ticking when the core goes to sleep. However, if a
decrementer was already pending (but masked with MSR[EE]) before you
enter sleep mode, it will cause a wakeup.
To avoid this, the decrementer is set to a very large value prior to and
after disabling interrupts. See generic_suspend_disable_irqs() in
arch/powerpc/kernel/time.c. Is this not happening for you? Which kernel
version are you using, and what mechanism are you using to go to sleep?
> I'm a bit irritated that it's not as the "solution" can mean hardware
> changes an thus it's potentially expensive.
What sort of hardware changes?
-Scott
^ permalink raw reply
* Re: MPC85xx External/Internal Interrupts
From: Scott Wood @ 2009-09-09 18:28 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linuxppc-dev, Alemao, linux-kernel
In-Reply-To: <20090906110641.GA11350@Chamillionaire.breakpoint.cc>
On Sun, Sep 06, 2009 at 01:06:41PM +0200, Sebastian Andrzej Siewior wrote:
> irq_of_parse_and_map() creates a mapping between the hardware irq number
> as specified in the device tree and the linux number (virq) which is
> used within the linux api in request_irq() for instance.
> irq_of_parse_and_map() is essential to create a mapping between those
> two. The interrupt controller on the MPC8555 (mpic) specifies the first
> few interrupt numbers as external sources followed by internal sources.
> Now, during the init sequenze of the mpic every interrupt source
> (internal and external) becomes its uniqe vector number which identifies
> the source by a number. This number is the hardware interrupt number
> i.e. that thing in the device tree. The init sequence is a for loop
> which starts at 0 for the first interrupt source which happens to be
> external interrupt 0, 1 for external interrupt 1 and so on. At the time
> it reaches the first internal interrupt source the vector number is 16.
> That's why you always have an offset of 16 between every internal
> interupt source number in the MPC855ERM document and those weired
> numbers in the device tree :)
This seems to be a common point of confusion -- we should probably put
something in the dts bindings that explains it. Am I correct in assuming
that this particular internal/external split is Freescale-specific and
not a general OpenPIC thing?
-Scott
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-09-09 18:22 UTC (permalink / raw)
To: Roland Lezuo; +Cc: linuxppc-dev
In-Reply-To: <25940478.1252060285938.JavaMail.root@viefep11.chello.at>
On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> The following patch is needed to correctly assign the IRQs for the
> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> as well as the interrupt lines for the two devices.
And it will incorrectly assign them on older revisions of the chip.
We really should have a u-boot fixup based on SVR.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox