[PATCH] MEDIA CODA: Fix NULL ptr dereference in the encoder.
ctx->mb_err_cnt_ctrl could be NULL in case of failed initialization
(on decoders), and encoders don't use it at all.
Fixes: b2d3bef1aa78 ("media: coda: Add a V4L2 user for control error
macroblocks count")
Signed-off-by: Krzysztof Halasa
Cc: sta...@vger.kernel.org # 5.11+
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 2f42808c43a4..26e37cbfe8dd 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2373,8 +2373,10 @@ static void coda_finish_decode(struct coda_ctx *ctx)
if (err_mb > 0) {
if (__ratelimit(&dev->mb_err_rs))
coda_dbg(1, ctx, "errors in %d macroblocks\n", err_mb);
- v4l2_ctrl_s_ctrl(ctx->mb_err_cnt_ctrl,
-v4l2_ctrl_g_ctrl(ctx->mb_err_cnt_ctrl) +
err_mb);
+ if (ctx->mb_err_cnt_ctrl)
+ v4l2_ctrl_s_ctrl(ctx->mb_err_cnt_ctrl,
+v4l2_ctrl_g_ctrl(ctx->mb_err_cnt_ctrl)
++ err_mb);
}
if (dev->devtype->product == CODA_HX4 ||
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 96802b8f47ea..285c80f87b65 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2062,7 +2062,8 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
if (q_data_dst->fourcc == V4L2_PIX_FMT_JPEG)
ctx->params.gop_size = 1;
ctx->gopcounter = ctx->params.gop_size - 1;
- v4l2_ctrl_s_ctrl(ctx->mb_err_cnt_ctrl, 0);
+ if (ctx->mb_err_cnt_ctrl)
+ v4l2_ctrl_s_ctrl(ctx->mb_err_cnt_ctrl, 0);
ret = ctx->ops->start_streaming(ctx);
if (ctx->inst_type == CODA_INST_DECODER) {
--
Krzysztof Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
[PATCH] Marvell Sky2 Ethernet adapter: fix warning messages.
sky2.c driver uses netdev_warn() before the net device is initialized.
Fix it by using dev_warn() instead.
Signed-off-by: Krzysztof Halasa
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -4806,12 +4806,11 @@ static struct net_device *sky2_init_netdev(struct
sky2_hw *hw, unsigned port,
if (!is_valid_ether_addr(dev->dev_addr)) {
struct sockaddr sa = { AF_UNSPEC };
- netdev_warn(dev,
- "Invalid MAC address, defaulting to random\n");
+ dev_warn(&hw->pdev->dev, "Invalid MAC address, defaulting to
random\n");
eth_hw_addr_random(dev);
memcpy(sa.sa_data, dev->dev_addr, ETH_ALEN);
if (sky2_set_mac_address(dev, &sa))
- netdev_warn(dev, "Failed to set MAC address.\n");
+ dev_warn(&hw->pdev->dev, "Failed to set MAC
address.\n");
}
return dev;
--
Krzysztof Halasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18
"Luis R. Rodriguez" writes: > So we can nuke CONFIG_WANXL_BUILD_FIRMWARE now? I'm uncertain I understand why do you want it, or maybe what are you trying to do at all. And what use would wanxlfw.S (the assembly source) have if the option is removed? >> It's more about delivering the .S source for the firmware, I guess. >> Nobody is expected to build it. The fw is about 2.5 KB and is directly >> linked with the driver. > > :P Future work I guess would be to just use the firmware API and stuff > it into linux-firmware? Who's going to make it happen? The last time I checked (several years ago), wanXL worked. Who's going to test it after the change? I assume linux-firmware could include fw source and there would be means to build the binary. Just to be sure: the wanXL firmware has exactly nothing to do with FW loader, nothing depends on it (nor the other way around), it's just (with the rest of the wanXL code) an old piece of a driver for an old card. The question is, what do we gain by messing with it? -- Krzysztof Halasa
Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18
"Luis R. Rodriguez" writes: > * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE > * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE > > To this day both of these drivers are building driver *firmwares* when > the option CONFIG_PREVENT_FIRMWARE_BUILD is disabled, and they don't > even make use of the firmware API at all. Don't know for sure about Adaptec, but wanXL firmware fits every definition of "stable". BTW it's a 1997 or so early PCI card, built around the PLX PCI9060 bus mastering PCI bridge and Motorola 68360 (the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync serial port. It's more about delivering the .S source for the firmware, I guess. Nobody is expected to build it. The fw is about 2.5 KB and is directly linked with the driver. -- Krzysztof Halasa
Re: [PATCH] Carrier detect ok, don't turn off negotiation
Denis Du writes: >>From the above code, I can get that only Carrier have some change, it > will restart the protocol by hdlc_proto_start(dev);and thus the timer, > the previous timer expired due to protocol fail. > > If carrier keep no change by if (hdlc->carrier == on) > goto carrier_exit; /* no change in DCD line level */It will do > nothing, not start any new protocol and thus the timer. Sorry about being late, just returned home and am trying to get all the backlogs under control. I remember the PPP standard is a bit cloudy about the possible issue, but the latter indeed exists (the PPP state machine was written directly to STD-51). There is related (more visible in practice, though we aren't affected) issue of "active" vs "passive" mode (hdlc_ppp.c is "active", and two "passives" wouldn't negotiate at all). Anyway the problem is real (though not very visible in practice, especially on relatively modern links rather than 300 or 1200 bps dialup connections) and should be fixed. Looking at the patch, my first impression is it makes the code differ from STD-51 a little bit. On the other hand, perhaps applying it as is and forgetting about the issue is the way to go. Ideally, I think the negotiation failure should end up (optionally, in addition to the current behavior) in some configurable sleep, then the negotiation should restart. If it's worth the effort at this point, I don't know. Perhaps I could look at this later, but no promises (this requires pulling on and setting up some legacy hardware). Anyway, since the patch is safe and can solve an existing problem: Acked-by: Krzysztof Halasa -- Krzysztof Halasa
Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments
Kees Cook writes: > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. For *wan/hdlc* Acked-by: Krzysztof Halasa > --- a/drivers/net/wan/hdlc_cisco.c > +++ b/drivers/net/wan/hdlc_cisco.c > @@ -276,8 +276,6 @@ static void cisco_timer(unsigned long arg) > spin_unlock(&st->lock); > > st->timer.expires = jiffies + st->settings.interval * HZ; > - st->timer.function = cisco_timer; > - st->timer.data = arg; > add_timer(&st->timer); > } > > diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c > index de42faca076a..7da2424c28a4 100644 > --- a/drivers/net/wan/hdlc_fr.c > +++ b/drivers/net/wan/hdlc_fr.c > @@ -644,8 +644,6 @@ static void fr_timer(unsigned long arg) > state(hdlc)->settings.t391 * HZ; > } > > - state(hdlc)->timer.function = fr_timer; > - state(hdlc)->timer.data = arg; > add_timer(&state(hdlc)->timer); > } -- Krzysztof Halasa
[PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.
I think this bug needs to be fixed, this way or another.
The platform in question is Cavium CNS3xxx, ARMv6.
A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid
potential stack overflow") converted an explicit setting of
PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for bus-mastering PCIe DMA
read request) to:
+pcie_bus_config = PCIE_BUS_PEER2PEER;
with the following commentary:
"The second part is how the driver sets up the Max_Read_Request_Size
value for the first device/function on bus 1, i.e. the device
plugged directly into the PCIe root port.
For all I can tell, this is in fact incomplete, as it does not
perform the same setting on devices attached to a PCIe switch,
or multi-function devices.
The solution for this part fortunately is even easier: if we
just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER,
all PCIe devices in the system are limited to 128 byte MPS, which
in turn limits the MRRS to 128 bytes for all devices, and we
no longer even need to touch any devices."
The problem is the MRRS setting is never written to the hardware.
I propose the following, though I'm not sure if we can do this safely,
especially given the comments in probe.c. OTOH, this change may be
required in other (all?) cases when the user requests
PCIE_BUS_PEER2PEER.
On this Laguna GW-2388 the following patch fixes BM DMA with:
:00:00.0 PCI bridge: Cavium Networks Device 3400 (rev 01)
:01:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge
:02:0e.0 (PCI devices behind the bridge, these are doing actual BM xfers)
0001:00:00.0 PCI bridge: Cavium Networks Device 3400 (rev 01 - this is
the second lane from the CPU)
pci :00:00.0: Max Payload Size set to 128/ 128 (was 128), Max Read Rq 128
pci :01:00.0: Max Payload Size set to 128/ 512 (was 128), Max Read Rq 128
pci 0001:00:00.0: Max Payload Size set to 128/ 128 (was 128), Max Read Rq 128
Signed-off-by: Krzysztof Hałasa
Fixes: 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow")
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..91713b6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1919,7 +1919,8 @@ static void pcie_write_mrrs(struct pci_dev *dev)
/* In the "safe" case, do not configure the MRRS. There appear to be
* issues with setting MRRS to 0 on a number of devices.
*/
- if (pcie_bus_config != PCIE_BUS_PERFORMANCE)
+ if (pcie_bus_config != PCIE_BUS_PERFORMANCE &&
+ pcie_bus_config != PCIE_BUS_PEER2PEER)
return;
/* For Max performance, the MRRS must be set to the largest supported
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2771625..6f5088a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -756,7 +756,7 @@ enum pcie_bus_config_types {
PCIE_BUS_DEFAULT, /* ensure MPS matches upstream bridge */
PCIE_BUS_SAFE, /* use largest MPS boot-time devices support */
PCIE_BUS_PERFORMANCE, /* use MPS and MRRS for best performance */
- PCIE_BUS_PEER2PEER, /* set MPS = 128 for all devices */
+ PCIE_BUS_PEER2PEER, /* set MPS and MRSS to 128 for all devices */
};
extern enum pcie_bus_config_types pcie_bus_config;
[PATCH] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.
The platform in question is Cavium CNS3xxx, ARMv6.
A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid
potential stack overflow") converted an explicit setting of
PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for bus-mastering PCIe DMA
read request) to:
+pcie_bus_config = PCIE_BUS_PEER2PEER;
with the following commentary:
"The second part is how the driver sets up the Max_Read_Request_Size
value for the first device/function on bus 1, i.e. the device
plugged directly into the PCIe root port.
For all I can tell, this is in fact incomplete, as it does not
perform the same setting on devices attached to a PCIe switch,
or multi-function devices.
The solution for this part fortunately is even easier: if we
just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER,
all PCIe devices in the system are limited to 128 byte MPS, which
in turn limits the MRRS to 128 bytes for all devices, and we
no longer even need to touch any devices."
The problem is the MRRS setting is never written to the hardware.
I propose the following, though I'm not sure if we can do this safely,
especially given the comments in probe.c. OTOH, this change may be
required in other (all?) cases when the user requests
PCIE_BUS_PEER2PEER.
On this Laguna GW-2388 the following patch fixes BM DMA with:
:00:00.0 PCI bridge: Cavium Networks Device 3400 (rev 01)
:01:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge
:02:0e.0 (PCI devices behind the bridge, these are doing actual BM xfers)
0001:00:00.0 PCI bridge: Cavium Networks Device 3400 (rev 01 - this is
the second lane from the CPU)
pci :00:00.0: Max Payload Size set to 128/ 128 (was 128), Max Read Rq 128
pci :01:00.0: Max Payload Size set to 128/ 512 (was 128), Max Read Rq 128
pci 0001:00:00.0: Max Payload Size set to 128/ 128 (was 128), Max Read Rq 128
Signed-off-by: Krzysztof Hałasa
Fixes: 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow")
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..91713b6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1919,7 +1919,8 @@ static void pcie_write_mrrs(struct pci_dev *dev)
/* In the "safe" case, do not configure the MRRS. There appear to be
* issues with setting MRRS to 0 on a number of devices.
*/
- if (pcie_bus_config != PCIE_BUS_PERFORMANCE)
+ if (pcie_bus_config != PCIE_BUS_PERFORMANCE &&
+ pcie_bus_config != PCIE_BUS_PEER2PEER)
return;
/* For Max performance, the MRRS must be set to the largest supported
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2771625..6f5088a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -756,7 +756,7 @@ enum pcie_bus_config_types {
PCIE_BUS_DEFAULT, /* ensure MPS matches upstream bridge */
PCIE_BUS_SAFE, /* use largest MPS boot-time devices support */
PCIE_BUS_PERFORMANCE, /* use MPS and MRRS for best performance */
- PCIE_BUS_PEER2PEER, /* set MPS = 128 for all devices */
+ PCIE_BUS_PEER2PEER, /* set MPS and MRSS to 128 for all devices */
};
extern enum pcie_bus_config_types pcie_bus_config;
Re: [PATCH] net: wan: wanxl.c: Cleaning up declaration of a while loop
Rickard Strandqvist writes:
> Unusual declaration of a while loop.
> However, believe you also want to make sure that the pointer is not NULL
Not really. The code is meant to do exactly what it currently does -
set variable desc and then check desc->stat.
All rx_descs are at this point already initialized and not NULL
(if desc was indeed NULL we better BUG*() or Oops on desc->stat access
instead of failing silently).
> --- a/drivers/net/wan/wanxl.c
> +++ b/drivers/net/wan/wanxl.c
> @@ -196,7 +196,7 @@ static inline void wanxl_tx_intr(port_t *port)
> static inline void wanxl_rx_intr(card_t *card)
> {
> desc_t *desc;
> - while (desc = &card->status->rx_descs[card->rx_in],
> + while (desc = &card->status->rx_descs[card->rx_in] &&
> desc->stat != PACKET_EMPTY) {
> if ((desc->stat & PACKET_PORT_MASK) > card->n_ports)
> pr_crit("%s: received packet for nonexistent port\n",
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/18] ARM: IXP4xx: Switch to sched_clock_register()
Stephen Boyd writes:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
Don't find anything wrong in this.
Acked-by: Krzysztof Halasa
> +++ b/arch/arm/mach-ixp4xx/common.c
> @@ -448,7 +448,7 @@ void __init ixp4xx_sys_init(void)
> /*
> * sched_clock()
> */
> -static u32 notrace ixp4xx_read_sched_clock(void)
> +static u64 notrace ixp4xx_read_sched_clock(void)
> {
> return *IXP4XX_OSTS;
> }
> @@ -466,7 +466,7 @@ unsigned long ixp4xx_timer_freq = IXP4XX_TIMER_FREQ;
> EXPORT_SYMBOL(ixp4xx_timer_freq);
> static void __init ixp4xx_clocksource_init(void)
> {
> - setup_sched_clock(ixp4xx_read_sched_clock, 32, ixp4xx_timer_freq);
> + sched_clock_register(ixp4xx_read_sched_clock, 32, ixp4xx_timer_freq);
>
> clocksource_mmio_init(NULL, "OSTS", ixp4xx_timer_freq, 200, 32,
> ixp4xx_clocksource_read);
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices
Ben Hutchings writes: > I think the problem is that the platform device and the platform data > have not been properly separated. The machine-specific setup functions > should be passing the eth_plat_info and MAC ID into a common ixp4xx > function which would then create the platform device with the correct > DMA mask etc. That's also my idea. Will look at this. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices
Jonas Gorski writes: > ARM requires the cohorent_dma_mask set, so set it for the platform > devices so that the ethernet driver has access to it. I recognize the need to fix this issue and I appreciate your efforts, but... I think this patch tries to make the driver functional again at all costs and this a very bad idea. The IXP4xx Ethernet MACs are not normal platform devices, they are in fact built-in CPU resources. The platform device structs are only used to set parameters. What the patch does is unneeded and IMHO harmful code duplication. It makes completely no sense to set DMA masks in code for individual platforms as it's not something platforms can decide, or *even should know of*. It's simply a CPU attribute, a value that is shared by all IXP4xx CPUs and thus all platforms and systems using it. This is against the "line of code" count rules (or "rules"). Also the dev->dev.parent is IMHO a bad idea. The queue numbers and MAC addresses are in no way "parents" of Ethernet controllers, and even if they somehow were, I find it rather hard to believe they can have DMA masks. I think the previous patch (which sets the masks in one place, in Ethernet driver code) was better, though not perfect. My fault is I haven't fixed it yet. Will try to invent something. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] ARM: ixp4xx: avoid circular header dependency
Arnd Bergmann writes: > With the new linux/reboot.h header file dependency added, we can no > longer build ixp4xx. The easiest way to avoid that is to remove the > inclusion of mach/hardware.h from mach/timex.h, which does not need > that header anyway. > arch/arm/mach-ixp4xx/include/mach/timex.h | 2 +- Acked-by: Krzysztof Halasa -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix IXP4xx coherent allocations
Russell King - ARM Linux writes:
> Right, so, the answer is - yes you are talking about platform devices,
> and the reason that these aren't already set is because if you grep for
> ixp4xx_eth or ixp4xx_hss in arch/arm/mach-ixp4xx, you'll notice that
> _none_ of the device declarations set either of the DMA masks at all.
> They don't even set the dev->dma_mask pointer. That is why the masks
> are zero. For a device which does DMA, that is wrong.
Well, that's new to me. Please tell me how it should be done.
Should I simply add in platform code (on all platforms):
+++ b/arch/arm/mach-ixp4xx/XXX.c
@@ -380,10 +380,12 @@ static struct platform_device device_eth_tab[] = {
.name = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data = eth_plat,
+.dev.coherent_dma_mask = DMA_BIT_MASK(32),
}, {
.name = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev.platform_data = eth_plat + 1,
+.dev.coherent_dma_mask = DMA_BIT_MASK(32),
}
};
This alone isn't going to work, the problem is coherent DMA mask in
net_dev->dev and not in platform_device. So what do I do in the network
drivers? Copy the masks from platform_device to the actual newly created
net_dev->dev?
Should I use the parent device (net_dev->dev.parent which is the
platform_device) as the argument to the allocator? This would probably
work though I'm not sure of its correctness.
BTW the platform code shouldn't IMHO need to declare the masks as they
aren't platform-specific. They are driver-specific (defined by CPU
design) and setting them in the driver seems clean to me (unlike the
platform code).
Several other device drivers simply set their masks directly. Is it the
recommended way?
> If you look at the PCI code, it pre-initializes the DMA mask to be 4GiB:
> drivers/pci/probe.c:dev->dev.coherent_dma_mask = 0xull;
>
> And that is what is missing from the IXP4xx platform code.
>
> However, avoiding the call to dma_set_coherent_mask() from within the
> driver also seems to be questionable as it bypasses the "check if the
> mask is possible" part of the DMA API.
I thought about this for a second but the situation is the mask
is guaranteed to be valid (these are on-chip devices).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix IXP4xx coherent allocations
Russell King - ARM Linux writes:
> I'm having a hard time understanding what is an ARM issue here, what is
> an ARM bug, and what the DMA API requires. The DMA API documentation
> is extremely sparse in describing what's required of the DMA masks,
> what these functions are supposed to do, and what determines whether
> a mask is "possible" or not.
>
> Moreover, I'm also having a hard time understanding what broke in 3.7,
> and why this fixes it.
>
> In other words, I'm completely failing to understand everything about
> this patch.
The ARM issue here is that the coherent DMA mask, by default, is zero
(i.e. coherent allocations are impossible by default UNLESS the device
pointer supplied is NULL - since DMA masks are bound to devices).
On most other platforms, the default DMA mask is 0x = (u32)-1
and this is also required by the DMA API.
In v3.7 (between v3.7-rc6 and v3.7-rc7), Xi Wang noticed that IXP4xx net
drivers call dma_pool_create() with NULL dev argument, and changed them
to use &port->netdev->dev. This broke coherent allocations since now the
device supplied to dma_pool_create() is not NULL and the (zero) mask
prevents coherent allocations. This means the Ethernet and HSS drivers
are since then unusable.
The first part of my patch makes dma_set_coherent_mask (IXP4xx-only
code) actually set the mask. This is needed as on IXP4xx we have (at
least) two different situations:
- PCI devices want "DMA zone" memory (26 bits = 64 MiB)
- built-in devices can use any RAM (32 bits = 4 GiB).
Without the patch, dma_set_coherent_mask only returns 0 or -EIO, it
doesn't change the actual coherent DMA mask and it's then impossible for
coherent allocators to differentiate between the above two cases.
+++ b/arch/arm/mach-ixp4xx/common-pci.c
@@ -454,10 +454,15 @@ int ixp4xx_setup(int nr, struct pci_sys_data *sys)
int dma_set_coherent_mask(struct device *dev, u64 mask)
{
- if (mask >= SZ_64M - 1)
- return 0;
+ if ((mask & DMA_BIT_MASK(26)) != DMA_BIT_MASK(26))
+ return -EIO;
+
+ /* PCI devices are limited to 64 MiB */
+ if (dev_is_pci(dev))
+ mask &= DMA_BIT_MASK(26); /* Use DMA region */
- return -EIO;
+ dev->coherent_dma_mask = mask;
+ return 0;
}
The second part of my patch sets the coherent DMA masks of the Ethernet
and HSS devices to 4 GiB (the value which should already be the
default). This also seems to be a recommended action.
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1423,7 +1423,7 @@ static int eth_init_one(struct platform_device *pdev)
dev->ethtool_ops = &ixp4xx_ethtool_ops;
dev->tx_queue_len = 100;
-
+ dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
netif_napi_add(dev, &port->napi, eth_poll, NAPI_WEIGHT);
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -1367,6 +1367,7 @@ static int hss_init_one(struct platform_device *pdev)
port->dev = &pdev->dev;
port->plat = pdev->dev.platform_data;
+ dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
netif_napi_add(dev, &port->napi, hss_hdlc_poll, NAPI_WEIGHT);
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix IXP4xx coherent allocations
David Miller writes: >> ARM core code currently requires coherent DMA mask to be set. > This requirement is not reasonable. > > The DMA API documentation clearly states what the default must be, > and what drivers are guarenteed will be the default. ARM people - what do you think? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix IXP4xx coherent allocations
Ben Hutchings writes: > I'm failing to see where it says the default can't be narrower than 32 > bits due to platform limits. And how do you think DMA mapping is > supposed to work for PCI devices on these platforms, anyway? The problem on ARM (and probably on powerpc, and on something called "metag" - grep -r 'coherent DMA mask is unset' arch) is that the default coherent DMA mask is zero. IOW, coherent DMA allocations are, by default, disabled. A driver has to dma_set_coherent_mask() or, as many drivers do, set dev->coherent_dma_mask directly (IMHO dev->coherent_dma_mask along with dev->dma_mask are private DMA API stuff and e.g. device drivers have no interest there). The zero default is IMHO, WRT the actual DMA API, an ARM bug (and powerpc's etc). Nevertheless, the patch I posted does everything as required by the API. Specifically, the IXP4xx arch part makes IXP4xx's dma_set_coherent_mask() compliant with DMA API, and the actual dma_set_coherent_mask() calls in drivers are both valid and I guess recommended by the API. The patch doesn't touch the core ARM issue, that's right. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix IXP4xx coherent allocations
ARM core code currently requires coherent DMA mask to be set. Make sure
we limit PCI devices to 64 MiB while allowing on-chip devices to access
the whole 4 GiB address space.
This fixes a v3.7+ regression which broke IXP4xx built-in network devices.
Signed-off-by: Krzysztof Hałasa
Cc:
diff --git a/arch/arm/mach-ixp4xx/common-pci.c
b/arch/arm/mach-ixp4xx/common-pci.c
index ea1933d..8629fc9 100644
--- a/arch/arm/mach-ixp4xx/common-pci.c
+++ b/arch/arm/mach-ixp4xx/common-pci.c
@@ -454,10 +454,15 @@ int ixp4xx_setup(int nr, struct pci_sys_data *sys)
int dma_set_coherent_mask(struct device *dev, u64 mask)
{
- if (mask >= SZ_64M - 1)
- return 0;
+ if ((mask & DMA_BIT_MASK(26)) != DMA_BIT_MASK(26))
+ return -EIO;
+
+ /* PCI devices are limited to 64 MiB */
+ if (dev_is_pci(dev))
+ mask &= DMA_BIT_MASK(26); /* Use DMA region */
- return -EIO;
+ dev->coherent_dma_mask = mask;
+ return 0;
}
EXPORT_SYMBOL(ixp4xx_pci_read);
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 6958a5e..7c08269 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1423,7 +1423,7 @@ static int eth_init_one(struct platform_device *pdev)
dev->netdev_ops = &ixp4xx_netdev_ops;
dev->ethtool_ops = &ixp4xx_ethtool_ops;
dev->tx_queue_len = 100;
-
+ dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
netif_napi_add(dev, &port->napi, eth_poll, NAPI_WEIGHT);
if (!(port->npe = npe_request(NPE_ID(port->id {
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 95d0451..83b4597 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -1367,6 +1367,7 @@ static int hss_init_one(struct platform_device *pdev)
port->id = pdev->id;
port->dev = &pdev->dev;
port->plat = pdev->dev.platform_data;
+ dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
netif_napi_add(dev, &port->napi, hss_hdlc_poll, NAPI_WEIGHT);
if ((err = register_hdlc_device(dev)))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ixp4xx_eth: set the device dma_coherent_mask
Christophe Aeschlimann writes: > Without the mask it is impossible to take the network interface up > since it returns the following error: > >> net eth1: coherent DMA mask is unset >> ifconfig: SIOCSIFFLAGS: Cannot allocate memory > > +++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c > @@ -1398,6 +1398,7 @@ static int eth_init_one(struct platform_device *pdev) > return -ENOMEM; > > SET_NETDEV_DEV(dev, &pdev->dev); > + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > port = netdev_priv(dev); > port->netdev = dev; > port->id = pdev->id; This happens to work but seems to me like a bad "solution". The real issue is that current ARM coherent_dma_mask (and regular dma_mask) handling is just broken (at least on platforms with CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK). I'm thinking how can it be fixed. The problematic parts include the dmabouncer (which takes over DMA operations and provide services similar to swiotlb), the host DMA and coherent DMA masks (which are property of the buses) and the device masks, which should be ANDed with bus masks (but aren't). What the driver should use is: err = dma_set_coherent_mask(xxx); (but the subsystem have to be fixed first). Also, according to DMA-API, 32-bit is the default. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] wan: Remove unnecessary alloc/OOM messages
Joe Perches writes: > alloc failures already get standardized OOM > messages and a dump_stack. > > Hoist assigns from if tests. > > Signed-off-by: Joe Perches > --- > drivers/net/wan/cosa.c| 9 - > drivers/net/wan/farsync.c | 6 ++ > drivers/net/wan/hdlc.c| 9 - > drivers/net/wan/x25_asy.c | 1 - > 4 files changed, 10 insertions(+), 15 deletions(-) Good to see. Acked-by: Krzysztof Halasa -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL REQ] IXP4xx changes for Linux 3.7
Hi, Arnd Bergmann writes: > as mentioned before, all arch/arm/mach-* patches should go through the > arm-soc tree or get an Ack from the arm-soc maintainers. The same thing > is true for the char-misc and the crypto trees. You've seen the changes. They were trivial fixes, touched only IXP4xx-related areas, there was nothing related to char or crypto subsystems there, except file location (well, IXP4xx drivers have to be located somewhere). The patches have been posted to linux-arm-kernel and you knew about them. That they were obviously correct and clean is probably not that important. Nobody bothered to comment the patches. > Also, never rebase your tree immediately before sending a pull > request. I did not, of course. My mail stated: "Build-tested for now. This is based on your current tree tip because it depends on commits following 3.6 release." Normally I wouldn't rebase, but had to (as you well knew) - because you commited a conflicting patch to this very IXP4xx arch. Using your logic, you were supposed to get an Ack from me (or from Imre) for this patch. Actually it wasn't a problem for me, I simply had to rebase. > Finally when sending bug fixes, please annotate any patches with > 'Cc: sta...@vger.kernel.org' if they address bugs that are already > present in older kernels, so that the stable and longterm maintainers > can easily backport the fixes. I do that when I think it makes sense. In this case (two patches for Goramo MultiLink platform) practically all such devices use kernels prepared by me, and I think Greg (and others) have more efficient ways to spend their time than handling almost unused patches. Also, I have much more efficient ways to spend time. Anyway, if I can't have my patches upstream, why should they end up in stable? > Almost all of the platform patches in your tree seem to be bug fixes, > so they are still good for inclusion in v3.7 if you submit them to > arm-soc soon, but please make sure you separate bug fixes from other > changes so we can group them appropriately when forwarding them to > Linus. Unfortunately, as I already explained to you in https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very limited (and this isn't a paid job) and I'm in no way able to do what you require. This, coupled with my inability to make the patches end up upstream any other way, will make me post relevant MAINTAINERS changes shortly. Don't get me wrong. If I had time for this it could be different. Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at this point. Given the raised barriers to participate, probably aimed at paid maintainers, I have to quit doing this. BTW since Imre has probably even much less time, it would be a good time to find someone to maintain IXP4xx code. I will be publishing (from time to time) my tree (I'm using the hw myself), so even simple cherry-picking would probably make some sense. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL REQ] IXP4xx changes for Linux 3.7
Linus,
please pull my ARM IXP4xx changes for 3.7:
The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:
"Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security"
(2012-10-13 11:29:00 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next
for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d:
IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200)
Build-tested for now. This is based on your current tree tip because it
depends on commits following 3.6 release.
Thanks.
Arnd Bergmann (1):
IXP4xx: use __iomem for MMIO
Krzysztof Hałasa (9):
IXP4xx: Fix Goramo MultiLink platform compilation.
IXP4xx: Fix off-by-one bug in Goramo MultiLink platform.
IXP4xx: HW pseudo-random generator is available on IXP45x/46x only.
IXP4xx: ixp4xx_crypto driver requires Queue Manager and NPE drivers.
IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices.
WAN: Remove redundant HDLC info printed by IXP4xx HSS driver.
IXP4xx crypto: MOD_AES{128,192,256} already include key size.
IXP4xx: Always ioremap() Queue Manager MMIO region at boot.
IXP4xx: map CPU config registers within VMALLOC region.
Tim Gardner (1):
ixp4xx: Declare MODULE_FIRMWARE usage
arch/arm/mach-ixp4xx/common-pci.c | 1 +
arch/arm/mach-ixp4xx/common.c | 13 +
arch/arm/mach-ixp4xx/goramo_mlr.c | 3 ++-
arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 4 ++--
arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 46
+++--
arch/arm/mach-ixp4xx/include/mach/qmgr.h| 12 ++--
arch/arm/mach-ixp4xx/ixp4xx_npe.c | 9 -
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c | 12 +---
drivers/char/hw_random/Kconfig | 6 +++---
drivers/char/hw_random/ixp4xx-rng.c | 5 -
drivers/crypto/Kconfig | 2 +-
drivers/crypto/ixp4xx_crypto.c | 12 ++--
drivers/net/wan/ixp4xx_hss.c| 2 +-
13 files changed, 59 insertions(+), 68 deletions(-)
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO
Russell King - ARM Linux writes: >> Note I'm not only doing ARM, but also X86 and MIPS, with additional code >> shared between them, and the "stable" part of it is what I'm paid for. >> I can't simply work with arm-soc, none of my platforms will even boot >> with pure arm-soc. > > I'm assuming that Linus' -rc kernels work for you, yes? No, but it's OK :-) I meant I need additional code for a) ARM and MIPS-based boards (off the shelf by Ubiquity, Gateworks etc., support ported mostly from OpenWRT), b) custom hardware used only by us. I hope to eventually submit a) upstream, then arm-soc and Linus' trees would work for me. I know it's a mess, but for now I have no options. BTW the situation with hardware supported only by OpenWRT is a part of the equation. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO
I realize my work flow is probably suboptimal, though I can't see an easy solution. Russell King - ARM Linux writes: > That makes no sense what so ever. The tree which is used for the next > stable tree will be Linus' tree, which will be the result of merging all > those other trees into Linus' tree. If you base your changes off only > Linus' tree on the run up to the next merge window, then you are preparing > your changes against an _older_ kernel than if you base them off a tree > containing the changes which will be _included_ in the next merge > window. Yes. I have to fix my tree and ask for pull before the end of merge window (fixes could follow, but it's best when there are no fixes needed). I know it's not a great plan. Fortunately I'm not doing heavy, conflicting development on this. Note I'm not only doing ARM, but also X86 and MIPS, with additional code shared between them, and the "stable" part of it is what I'm paid for. I can't simply work with arm-soc, none of my platforms will even boot with pure arm-soc. > If you want to work in total isolation, that's your choice, but in the > long run you will be playing catch-up rather than being prepared early > for the changes which will happen at the next merge window. If you want > -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to > fixing up the merge window breakage, then go ahead. > > Otherwise, participate and be part of the community, and get your changes > into arm-soc, so that others can see what's going on. Unfortunately this seems to require more time on my part, time I don't have. Perhaps I'm missing something? I.e., I can dedicate some time around the merge window (not every one, but this may improve), but not much more. I don't think there are any "others" interested in what's going on on IXP4xx. Simply, there isn't anything of importance here. It won't cause severe conflicts (and "next" helps here), and I post my patches to the list just like all people do. Of course if you can see a better way (given the limitations), I'm open. BTW I still think I'm a part of the community, even if I don't submit code through arm-soc :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO
Arnd Bergmann writes: >> Could you please point me to a statement requiring eg. my changes to go >> through arm-soc? > > We've been doing it like this for some time. Stephen Warren replied > to your request to add your tree to linux-next in > > http://comments.gmane.org/gmane.linux.kernel/1356118 > > explaining how it works. Olof sent a mail last week in > > http://lkml.org/lkml/2012/9/21/31 > > explaining that we're closing the window for 3.7 except for a > few things that were already submitted earlier. No offense, but... You say how does it work for YOU but that's not exactly what I'm asking for. I'm asking for a statement that it's not OK for me to push my IXP4xx changes straight to Linus. > The arm-soc process is definitely meant to make your life easier > as well as help Linus understand what's going on with all of ARM > to the degree that he needs to know, but it only works if everyone > participates. I'd like to know how is it easier for me. Actually, I think it would only make things worse for everyone (mostly for me). Also, I can't see how "it only works if everyone participates" is true. I'm currently supporting (for our internal needs) hw platforms based on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current tree since it's the next stable. The hw is e.g. Gateworks' platforms with code taken from e.g. OpenWRT. I hope to have most of this in Linus' tree when it's eventually ready. Unfortunately, I'm just one man, and the above is only a slim part of my work. Egoistically, I don't think I'm currently willing to spend time with arm-soc tree, if I can't see any real technical benefit to anyone. It would be different if my tree included e.g. core ARM changes - but it doesn't. What's the _real_ reason for asking me to push my changes indirectly? Also, not that it's the most important, but how is it better for anyone to delay changes - which are completely orthogonal to arm-soc - for additional months? Doesn't "release early, release often" make sense anymore? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO
Arnd Bergmann writes: > Krzysztof, please apply in your next branch so this problem goes away in > 3.8. Right, I'll look at it. > I realize it won't make 3.7 any more since the base patches are not > in arm-soc, but it's bad if linux-next is broken. Well, I'm not aware of any requirement to push my IXP4xx changes exclusively through arm-soc. I believe I can still send my tree straight to Linus. My tree is fairly isolated (with one trivial patch in need of ack from Russell, but I can remove that) and, to be honest, I can't see any benefit to anyone, caused by sending through intermediate trees. In fact, now that I have at last a bit of spare time to work on IXP4xx again (acquired some IXP435 devices), such requirement would only mean extra workload to me. Could you please point me to a statement requiring eg. my changes to go through arm-soc? Thanks. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08+09/24] ARM: ixp4xx: use __iomem pointers for MMIO
Actually, there are some minor problems here (both patches merged,
ixp4xx only):
Arnd Bergmann writes:
> --- a/arch/arm/mach-ixp4xx/include/mach/cpu.h
> +++ b/arch/arm/mach-ixp4xx/include/mach/cpu.h
> @@ -37,7 +38,7 @@
>
> static inline u32 ixp4xx_read_feature_bits(void)
> {
> - u32 val = ~*IXP4XX_EXP_CFG2;
> + u32 val = ~__raw_readl(IXP4XX_EXP_CFG2);
>
This is all fine, but
> @@ -51,7 +52,7 @@ static inline u32 ixp4xx_read_feature_bits(void)
>
> static inline void ixp4xx_write_feature_bits(u32 value)
> {
> - *IXP4XX_EXP_CFG2 = ~value;
> + __raw_writel(~cpu_to_le32(value), IXP4XX_EXP_CFG2);
> }
The EXP_CFG2 register is already in host order, no need for
cpu_to_le32() as the replaced code clearly shows.
Can you merge both IXP4xx parts (in the two patches) and fix the above,
please? Thanks.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO
Krzysztof Halasa writes: >> At the moment, this patch conflicts with other patches in linux-next, >> need to sort this out. > > Very nice, I will take care of these 3 patches. I mean, just this one IXP4xx patch :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Another tree for "next"
Stephen Rothwell writes: >> >>> git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git branch: >> >>> next > OK, I have added your tree from today. Thanks a lot. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO
Arnd Bergmann writes: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > At the moment, this patch conflicts with other patches in linux-next, > need to sort this out. Very nice, I will take care of these 3 patches. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Another tree for "next"
Stephen Rothwell writes: >> could you please add the following to your "next" tree? >> >> git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git branch: next > Could you be a bit more clear about what will be in that tree, please? > Also when you repost this request, please post it a bit more widely among > other people/lists who may be interested in this work. Remember that > linux-next is really only for stuff that is ready for Linus to pull into > the next merge window (or bug fixes). Also, would this tree be pulled > directly by Linus, or via some other tree? My plan is to merge all the stuff I'm (eventually) working on in the above tree. For now - mostly IXP4xx (ARM CPU etc.) stuff which goes to Linus, and (from time to time) WAN network drivers pulled by Dave. BTW this includes both current fixes (for "this") and true "next" changes. All of this is low profile and will be frequently empty. Hope that's ok. Alternatively I can add separate trees/branches (currently I'm only working on IXP4xx, at least as far as we're talking about pullable git trees). Just wanted to minimize effort needed on your side. Not sure about these other people/lists, added lkml. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.10 N_GSM tty_io WARNING and lockup
Alan Cox writes: >> BTW I'm not sure if it's a known bug: I closed the /dev/ttyS0 with >> /dev/gsmmuxX still open, and then tried to set N_TTY ldisc on the >> master device. It didn't work so well :-( > > That should be fixed in 3.7. It's unfixable until the lock splitting work > is merged. I see. Thanks. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.10 N_GSM tty_io WARNING and lockup
> In the meantime I've rebased to v3.5.3 and it started to work. Do you > think it is worth it investigating v3.4.10 at this point? BTW I'm not sure if it's a known bug: I closed the /dev/ttyS0 with /dev/gsmmuxX still open, and then tried to set N_TTY ldisc on the master device. It didn't work so well :-( # killall -9 microcom # they use /dev/gsmmux[0-3] # killall -9 iru# the program messing with ldiscs # ps axf 344 ?Ss 0:00 \_ sshd: root@pts/1 346 pts/1Ss 0:00 | \_ -sh 405 pts/1D+ 0:00 | \_ [microcom] 347 ?Ss 0:00 \_ sshd: root@pts/2 349 pts/2Ss 0:00 | \_ -sh 403 pts/2D+ 0:00 | \_ [microcom] 406 ?Ss 0:00 \_ sshd: root@pts/3 408 pts/3Ss 0:00 | \_ -sh 412 pts/3D+ 0:00 | \_ [microcom] 409 ?Ss 0:00 \_ sshd: root@pts/4 411 pts/4Ss 0:00 \_ -sh 413 pts/4D+ 0:00 \_ [microcom] 415 pts/0D 0:00 iru -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ixp4xx: Declare MODULE_FIRMWARE usage
Tim Gardner writes:
> +++ b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
> @@ -116,7 +116,11 @@
> /* NPE mailbox_status value for reset */
> #define RESET_MBOX_STAT 0xF0F0
>
> -const char *npe_names[] = { "NPE-A", "NPE-B", "NPE-C" };
> +#define NPE_A_FIRMWARE "NPE-A"
> +#define NPE_B_FIRMWARE "NPE-B"
> +#define NPE_C_FIRMWARE "NPE-C"
> +
> +const char *npe_names[] = { NPE_A_FIRMWARE, NPE_B_FIRMWARE, NPE_C_FIRMWARE };
>
> #define print_npe(pri, npe, fmt, ...)
> \
> printk(pri "%s: " fmt, npe_name(npe), ## __VA_ARGS__)
> @@ -724,6 +728,9 @@ module_exit(npe_cleanup_module);
>
> MODULE_AUTHOR("Krzysztof Halasa");
> MODULE_LICENSE("GPL v2");
> +MODULE_FIRMWARE(NPE_A_FIRMWARE);
> +MODULE_FIRMWARE(NPE_B_FIRMWARE);
> +MODULE_FIRMWARE(NPE_C_FIRMWARE);
>
> EXPORT_SYMBOL(npe_names);
> EXPORT_SYMBOL(npe_running);
This looks like a good idea, thanks.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
Alan Cox <[EMAIL PROTECTED]> writes: >> Actually I think the _GPL exports are really harmful - somebody >> distributing a binary module may claim he/she doesn't violate the GPL >> because the module uses only non-GPL exports. OTOH GPL symbols give > > They can claim that anyway. The can claim to be alien life forms too. Claim > is not the same as legal decision. Sure but it may be now easier to convince the judge they are right. Of course if they aren't using GPL exports - if they are, perhaps harder. > From what I've seen its helped make binary > module abusers more cautious. Those not using _GPL exports? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
> One may say _GPL is a strong indication that all users are > automatically a derivative works, but it's only that - indication. It > doesn't mean they are really derivative works and it doesn't mean a > module not using any _GPL exports isn't a derivative. Actually I think the _GPL exports are really harmful - somebody distributing a binary module may claim he/she doesn't violate the GPL because the module uses only non-GPL exports. OTOH GPL symbols give _us_ exactly nothing. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Tabs, spaces, indent and 80 character lines
Jan Engelhardt <[EMAIL PROTECTED]> writes: > Now back to coding, oh and don't forget send a patch for CodingStyle > since a mail without one is often taken even less seriously. Someone with a patch to Emacs to use tabs for ident + spaces for alignment maybe? :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
"David Schwartz" <[EMAIL PROTECTED]> writes: > I don't know who told you that or why, but it's obvious nonsense, Correct. > Exports should be marked GPL if and only if they cannot be used > except in a derivative work. If it is possible to use them without taking > sufficient protectable expression, they should not be marked GPL. This isn't very obvious to me. The licence doesn't talk about GPL or non-GPL exports. It doesn't restrict the use, only distribution of the software. One is free to remove _GPL from the code and distribute it anyway (except perhaps for some DMCA nonsense). If a code is a derivative work it has to be distributed (use is not restricted) under GPL, EXPORT _GPL or not _GPL. One may say _GPL is a strong indication that all users are automatically a derivative works, but it's only that - indication. It doesn't mean they are really derivative works and it doesn't mean a module not using any _GPL exports isn't a derivative. I think introducing these _GPL symbols was a mistake in the first place. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Tabs, spaces, indent and 80 character lines
Richard Knutsson <[EMAIL PROTECTED]> writes: >> I guess we could use tabs only at the line start, for indentation >> only. Rather hard to implement, most text editors can't do that yet. >> > You mean for split lines? Syntactic indentation vs alignment (including comments after non-blank, values for struct initialization etc, split lines too). > Hopefully there won't be that many, so there > is just to delete the tabs it added and replace it with spaces. Actually tabs "should" be used for indentation at start of the line, then spaces. "Ideally" :-) I.e., something like if (cond && (cond2 || _cond3)) do_something(); Underline = space. Perhaps some day... > Exactly! But then we can remove the "we use 8 wide tabs in the kernel" > in CodeStyle. I'm not sure it's practically possible now. >> Unpacked sources will be much bigger with not tabs, sure. >> > Without no tabs at all, you mean? With spaces in place of all tabs. All tabs converted to spaces = 20% more? "Alignment" tabs converted to spaces? How cares how much more would it take if it's the correct thing. Except that it's not very practical at this point. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Tabs, spaces, indent and 80 character lines
Richard Knutsson <[EMAIL PROTECTED]> writes: > Why hinder a developer who prefer > 2, 4, 6 or any other != 8 width? I guess we could use tabs only at the line start, for indentation only. Rather hard to implement, most text editors can't do that yet. > By only using tabs as indents, and > changing the CodeStyle to be something like "maximum 80 > characters-wide lines, with a tab-setting of 8 spaces", This changes nothing. > that is > possible + easier to write code-checkers [2]. I doubt it. > Or are we really that concerned about the disk-space? ;) Unpacked sources will be much bigger with not tabs, sure. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jörn Engel <[EMAIL PROTECTED]> writes:
> I strongly disagree. Machine-generated warnings are a great way of
> quickly locating a large amount of questionable code in an otherwise
> overwhelming haystack. It doesn't even matter much, which warnings you
> look for. Almost all code checkers find the same hotspots.
I think you misunderstood. Of course I'm not against warnings in
general. I'm rather talking about _authority_ of human vs machine,
in this specific ("measuring" code complexity) case.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek <[EMAIL PROTECTED]> writes: >> Come on, are you doing Linux kernel development on PDA? > > I review patches on it, sometimes, yes. I take it the "sometimes" is the key word :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Merging of completely unreviewed drivers
Peter Zijlstra <[EMAIL PROTECTED]> writes: > So, yes, I have the screen estate for very long lines, but I find that > long lines require more effort to read (that very much includes leading > whitespace). Also, since long lines are rare (and they should be, if you > nest too deep you have other issues) accommodating them would waste a > lot of screen estate otherwise useful for another column of text. Either they are rare and you can wrap them and still use 80 columns, or it turns out they are not so rare and you may want to use wider windows (not necessarily 132 but perhaps 100). I think the question isn't if they are rare or not, or if people have 3 * 1920 pixels/line or just 1280. The question is: is the code more readable with hard limit equal to 80 characters, or maybe is it better to limit code block complexity instead, and let the maximum number of those small pictures in a line alone? (Limiting at 132 would have technical sense IMHO). Better code readability = less bugs without any additional effort. > Even with e-mail, I can easily show over 200 characters wide with a > large font (say 11pt) but find it harder to read emails that don't > nicely wrap at 78. Sure - because email is not C code. Actually you don't "read" C code, word by word, as you read books - do you? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek <[EMAIL PROTECTED]> writes: > Zaurus is one example, second is small screen where you need big font > to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Linus Torvalds <[EMAIL PROTECTED]> writes: > Will people then try to fake things out by using 4-space indents > and then "deep" indentations will look like just a couple of tabs?) There is no point in faking it as it's only advisory, it's to help the author who should be free to ignore the advice. People upstream won't be fooled by some cheap tab tricks I guess. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Al Viro <[EMAIL PROTECTED]> writes: > IMO the line length overruns make good warnings. Not as in "here's a cheap > way to get more changesets", but as in "that code might have other problems > nearby" kind of heuristics. Sure, it does. However the human looking at the code is far better at spotting such problems. Machine-generated warnings are great when the machine is actually better than human. Anyway, warnings are one thing and line limit is another. We may raise the limit leaving the 80-chars warning in place. Unless there are too many false positives, of course. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Al Viro <[EMAIL PROTECTED]> writes: > ... if your style is lousy. I agree that situation with printks is > not normal in that respect and I certainly have no love for the > checkpatch nonsense, but pressure to keep the fucking nesting depth > low is a Good Thing(tm). Indeed. Unfortunately it is orthogonal to the line length limit. We should limit the nesting level, though I think there is no universally good value. What is good for one case (a function with a short multi-level if/for/etc) is bad for another (a long switch() where any added complexity makes it unparseable). So I think it just have to meet the author's and reviewers' taste. We already depend on this. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jeff Garzik <[EMAIL PROTECTED]> writes: > Every time this discussion comes up, people point out that it remains > highly common to open multiple 80-column terminal windows, making the > 80-column limit still highly relevant in modern times. I guess only because of the limit :-) Raise the limit, terminal windows will follow. I'm using 80-column windows, too. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jeff Garzik <[EMAIL PROTECTED]> writes: > If a driver is full of lines of length >80, that's a problem. I'm not sure. We all have more than 80-chars wide displays for years, don't we? The problem is not the number of characters but code which is too complex and which may sometimes have too many levels of indentation. Unfortunately expressing code complexity in terms of line lengths doesn't seem to work at all. The 80-chars limit harms development, it makes the code less readable, sometimes far less readable. I think we should increase length limit to 132 for the whole kernel code. Obviously printk() _output_ etc. should stay at 80. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
Gene Heskett <[EMAIL PROTECTED]> writes: > Apparently they do not Alan, the pl2303 in particular is a problem child, > throwing several lost com errors a day when doing nothing more strenuous than > talking to my belkin UPS from apcupsd, very small packets there, 20 bytes I > believe at several second intervals. Is your UPS using "modern" hardware handshaking (CTS = PC can send, with RTS practically always asserted)? Or perhaps the "old", "half-duplex" V.24-style (RTS asserted before TX and then waiting for CTS)? Are you sure it uses hw handshaking at all? Most (all?) UPSes I used had only TxD and RxD (for RS-232). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
"Kok, Auke" <[EMAIL PROTECTED]> writes: >>> Don't work by default. "pci=nomsi" fixes the problem. > > actually does not fix anything - it just works around it by falling > back to legacy interrupts. Actually it does, fixes the problem by working around a bug :-) Thanks for info. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
E1000 (PCI-E) doesn't work on nforce430, MSI issue.
Hi, Is it a known problem? Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in e1000e). Don't work by default. "pci=nomsi" fixes the problem. 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: PRO/1000 PT Desktop Adapter (8086:10b9 subsystem 8086:1083) grep eth0 /proc/interrupts 20: 1945 1 IO-APIC-fasteoi eth0 (without "pci=nomsi": 221: 0 0 PCI-MSI-edge eth0) other devices of possible interest: 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) Additional details on request. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: JMicron PATA 2.6.24-rc7 can't find drives
Marcin Gil <[EMAIL PROTECTED]> writes: > +-+-+ > mobo hdd dvd > > I think that cable select would take dvd as master and hdd as slave. > This was not preferable when hdd was my primary drive. I can try > cable-select now since I boot off new SATA drive. Is a master in the middle permitted by the specs at all? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is the kfree() argument const?
"J.A. Magallón" <[EMAIL PROTECTED]> writes:
> That's what __attribute__ ((pure)) is for, but if none of the
> functions is pure, the compiler can not be sure about side effects
> and can not reorder things. Don't forget that functions can do
> anything apart from mangling with their arguments.
Though it seems it could legally transform:
void kfree(const int *x);
{
int v, *ptr = malloc(sizeof(int));
*ptr = 51;
v = *ptr;
kfree(ptr);
printf("%d", v);
into:
{
int v, *ptr = malloc(sizeof(int));
*ptr = 51;
kfree(ptr);
v = *ptr;
printf("%d", v);
}
if it knows that malloc generates unaliased pointers, which seems
reasonable in general.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
[EMAIL PROTECTED] (Lennart Sorensen) writes: > I remember my nforce2 board having totally insane clock behaviour back > around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. > I seem to recall some ATI chipsets were even more insane than the nvidia > at the time, with some running double speed for the system time. Right, I remember some reports about that, probably IOAPIC or other HPET issues. Personally never seen that. Thus the suggestion of kernel upgrade. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen <[EMAIL PROTECTED]> writes: >> So why don't you fix it first? Correct system time is essential. > > I've tried tuning it with adjtimex and everything, and sometimes it > works for days, but then just suddenly the clock starts advancing. Nothing will make it work reliably if the system clock isn't stable. > As I have stated earlier, upgrading Linux has become too painful by > compiling from source, It works for me. > and the distros provide even worse crap as > their stock kernels. That works for me, too. The remaining options are c) to live with present situation, and d) to give up using Linux (computers etc). Or maybe e) to get a motherboard which isn't broken (with the kernel you want to use). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen <[EMAIL PROTECTED]> writes: > It isn't, right after boot. But while the system is on, it sometimes > starts advancing very fast, 15min a day or so. So why don't you fix it first? Correct system time is essential. I guess I would upgrade to some newer version, perhaps one which isn't more than two years old... -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman <[EMAIL PROTECTED]> writes: > Alan, did you double-check that 8 us? I tried to but I seem to not > have trustworthy documentation. I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers, that means at least 1 Maccesses/second = up to 1 microsecond/access. Perhaps IO ports accesses were slower than memory? But 8-12 times? Perhaps port 0x80 was using (slower) 8-bit timings? Bus-mastering ISA cards were able to do ca. 5 MB/s with 8 MHz (10 MHz?) clocking, some old machines didn't like it. Googling suggests that a slave access on 8-bit ISA bus was taking 6 cycles by default (including 4 wait states), 16-bit - 3 cycles (with 1 WS). Respectively 0.75 us and 0.375 us, and 0.25 us for 16-bit 0WS memory access (with standard 8 MHz clock). These values could be changed with BIOS setup, and devices could use 0WS or I/O CHRDY signals if they didn't like the defaults (dir 0WS mean 1 WS for 8-bit devices?). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
Adrian Bunk <[EMAIL PROTECTED]> writes: > This patch removes the EXPERIMENTAL option and all dependencies on > EXPERIMENTAL because they are pointless. Unfortunately I have to agree. The only think it does is confusing users, when they forget to enable it. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 34/59] drivers/net/wan: Add missing "space"
Joe Perches <[EMAIL PROTECTED]> writes:
> --- a/drivers/net/wan/wanxl.c
> +++ b/drivers/net/wan/wanxl.c
> @@ -743,7 +743,7 @@ static int __devinit wanxl_pci_init_one(struct pci_dev
> *pdev,
> }while (time_after(timeout, jiffies));
>
> if (!stat) {
> - printk(KERN_WARNING "wanXL %s: timeout while initializing card"
> + printk(KERN_WARNING "wanXL %s: timeout while initializing card "
> "firmware\n", pci_name(pdev));
> wanxl_pci_remove_one(pdev);
> return -ENODEV;
Acked-by: Krzysztof Halasa <[EMAIL PROTECTED]>
Thanks.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.2
Matt Mackall <[EMAIL PROTECTED]> writes: > What is the proper encoding for a patch that contains hunks in > multiple character sets? 8-bit binary encoding, the same for single charset patch - we don't want mail systems to change the encoding. Unfortunately you can't display anything like that inline I think. That means email may be unreliable in such cases (except maybe when both sides use UTF-8 and the patch contains only UTF-8), git/ftp/etc. will be fine. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
Ben Greear <[EMAIL PROTECTED]> writes: > Bridging eth0 to eth1 should not pay attention to VLAN tags > at all (if the pkt comes in on VLAN 7, it should go out on VLAN 7), > in my opinion. If the NIC is stripping the VLAN header, then this > cannot work unless something re-builds the VLAN header. If the stripped > VLAN header is placed into the skb, then any code that does need to > rebuild it can do so. It may be less efficient, but users can just > not use that NIC hardware for high-end solutions, and at any rate, > less efficient is better than broken. That is all true. The problem arises when you receive a tagged frame on eth0, the chip removes the tag, and then the bridge sends it out untagged on eth1. I think there are two valid models for VLAN + bridging: a) bridging works on "physical" interfaces, all tags are transmitted unchanged. b) every VLAN is a different logical interface, packets from unknown VLANs are dropped on RX (and thus don't show up anywhere, except counters), bridging uses logical interfaces. VLAN 100 on eth0 may become VLAN 200 on eth1 and may be untagged on eth2. "a" requires "soft" VLANs and/or adding the tags back (with accelerated VLANs). This is how unmanaged switches labeled "802.1Q - transparent" work. Not very flexible but usually good enough. "b" is how switches supporting VLANs (and 802.1Q) usually work. I know ability to see exactly all packets as they are received (including tags) is a really nice thing. But maybe we should change the model? Making the ethX only carry untagged frames (even without hw VLAN acceleration)? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
Patrick McHardy <[EMAIL PROTECTED]> writes: > I think there is one more case that matters, which is briding > from a device with VLAN stripping for a VLAN not configured > locally. The tag will be stripped and will be lost for forwarded > packets. I think we should drop such packets on RX. Anyway we shouldn't forward them. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Andreas Mohr <[EMAIL PROTECTED]> writes: > EEPROM dump (VT6306) > 00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02 - GUID > 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73 - subs ID - > 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF > > Your VT6307 chip is in OHCI 1.0 mode Thanks for the data. It's the same as for all my VT6307, excluding GUID (different for every card) and PCI subsystem vendor/device IDs. I guess Stefan could now try to write these values (except GUID and probably PCI subsystem IDs, and with OHCI 1.1 bit) to the "bad" card :-) I wouldn't try with a good card yet, though (unless you know how to repair it and/or you want to risk it, and/or you want to use the DOS utility mentioned by Stefan). I would try myself but I have no VT6306. BTW I don't know where I found the info about VT6306 not working with I^2C EEPROMs but it seems to be false, the datasheets claim both chips can get startup info from 4-wire or I^2C EEPROM. Given that both chips have identical EEPROM interface (except "fast I^2C mode" which means nothing) I'd be surprised if the program can't set OHCI 1.1 on VT6306. > And viewing from a quite problematic angle (card is in running PC, > difficult to view) strongly seems to indicate a VT630_6_ (the "6" is > quite clearly visible). > This means that I currently cannot offer any mfct. date data however, > unfortunately. Yeah. I think (feel or something) VIA does the usual thing with revision numbers so rev 0x46 means always the same silicon (VT6306) and rev 0x80 is always the same VT6307. There might be other revisions but I think we won't find non-VT6306 rev 0x46 or non-VT6307 rev 0x80. And, for someone using the old driver, VT6306 should probably have 8/8 IR/IT contexts while VT6307 - 4/8 (the new driver doesn't seem to show this info and I think VT6306 can be limited to 4 as well). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > For special occasions, Asustek hand out a testing and reprogramming > utility from VIA to their customers (viafire.exe, together with EEPROM > image files and instructions; see the link to the RAR archive at this > page). The documentation of the tool also contains a partial > description of the EEPROM contents. I see. I guess there is no much mystery in the EEPROM, i.e. we know where to place GUID and PCI subsystem IDs and we know how to initialize the rest (for both VT6306 and 6307, as it's almost certainly the same). And we know how to handle VT6307 EEPROM programming. I have no 6306 personally and I haven't connected a logic analyzer to any so programming 6306 EEPROM is a speculation. I will look at their archive "really soon" of course. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Policy on dual licensing?
Remigiusz Modrzejewski <[EMAIL PROTECTED]> writes: > What I propose is implementing a policy on accepting such code. > According to it, every time a maintainer is considering a driver > that is derived from BSD and licensed GPL-only, should request > for dual licensing before accepting the patch. If the submitter is > reluctant to do so - what can we do, it's better to have this inside > this way than not at all. However, this should minimize such cases > and, hopefully, satisfy the claims about Linux maintainers not doing > all that they could to make the world a better place. It doesn't make sense in general. Being derived from *BSD may mean only a tiny fragment comes from *BSD. I can't see any valid reason to force/ask the author to publish his/her code under BSD (GPL + BSD = BSD) instead of GPLv2 as used by the whole Linux. There are exceptions, of course - if you take a *BSD project and include it with no/minor changes it makes sense to use BSD licence, because we really want to cooperate, and because we don't have to fear "evil corporations" taking our code (because it's mostly not "ours"). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > This device is a somewhat buggy PCI card which somebody sent me after > unsuccessful attempts to get it properly working under Linux. Among > more serious trouble, ohci1394 reads a bogus maximum async payload (a > zero value) from the BusOptions register during startup. This has > occasionally been reported for some VT6306 in the past. I haven't > really tested this card myself yet, it's currently stuck in a PC which I > don't use anymore. I see. I think you may be able to cure this problem with my program, adding corrected values in addition to write to 0x11 should do the trick. 93c46 is 16-bit, little-endian here. You'd have to divide the addresses shown by the dump by 2 of course. I'd make sure the values are ok before rebooting, there is some possibility a badly corrupted EEPROM may prevent BIOS from starting. I think I'd leave GUID (16-bit words at 0, 1, 2, 3) and PCI subsystem IDs (words at 0xA and 0xB) unchanged, and for all other locations I'd fill in the 6307 values. Of course I don't know if the program will be able to write to VT6306, so I'd test the broken card first. > VT6306 CardBus card in my main PC: > MMIO=[8000-87ff] Max Packet=[1024] IR/IT contexts=[4/8] > ieee1394: Host added: ID:BUS[2-00:1023] GUID[0011060041cc] The difference is of course at 0x0E, not 0x1E. Maybe the byte at 0x0A is 0x92 for 4 IR contents and 0xA2 for 8 contents. That would also make sense wrt the broken 6306 as it has 0x00 there. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: >> Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver > > I also had to specify "-lpci" on Mandrake 10.1, "-lpci -lz" on Gentoo. Of course you're right, just typed faster than thought. Actually I had to add these two on Fedora, too. > 00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 > Host Controller (rev 46) Ok so it seems rev 80 is VT6307 and (at least) rev 46 is VT6306. I think my googling for lspci reports confirms that. > These are both VT6306, one on the motherboard and one on a PCI card. > > # ./a.out 00:0a.3 > I/O region #1 is at C800 > It seems your VT6307 chip is connected to 93c46 EEPROM Interesting, really. Perhaps they aimed at I2C too with 9306 but screwed up the silicon? Would have to look at the pinout but for now I'm sick and high fever makes it hard. It's all consistent, amazingly. 6306#1 > 00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00 > 10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73 > 20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75 Obviously some values are different than these for my 3 vt6307 (not counting GUID + PCI sub IDs). Though data at 0x20+ is equal. The last 4 bytes are almost certainly rubbish, that asks the question if the contents hasn't been changed through some tests, works on the drivers etc, or if the manufacturer did it right (for example I somehow managed to clear the GUID on I^2C version before I had the code to write to it, quite a mystery (writing correct I^2C sequence for it isn't trivial due to the need of non-all-zeros DEVSEL byte preceded by the start sequence). I wonder if the EEPROM has more non-FF data? IIRC the chips addresses 0x80 bytes, or maybe 0x100? I limited it to 0x40 in the code because the rest is never read by the chip, except if requested by the user. (For 93c46 the program could read any location directly but I didn't implement that). 6306#2 > EEPROM dump: > 00: 00 30 1B AC 00 00 2B A4 04 04 32 55 F8 00 A2 02 > 10: A1 00 40 63 06 11 44 30 03 DF 40 00 00 20 00 73 > 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF Only one different byte (vs my 6307s) at 0x1B if I see correctly. > The "rev 80" chip is a VT6307 on the motherboard. > 00: 00 10 DC 56 00 FE D2 D4 04 04 32 55 F8 00 A2 02 > 10: A1 00 40 63 20 63 62 14 03 DF 40 80 00 20 00 73 > 20: 3C 10 08 00 00 00 FF FF FF FF FF FF FF FF FF FF Same as mine. > The "rev 46" chip is on a CardBus card. So far I believed it to be a > VT6306 but I can't easily open the card's casing... > It seems your VT6307 chip is connected to I^2C (24c01 or > similar) EEPROM Hmm... They say 6306 only supports 93c46, perhaps I should force it based on revision. Or the datasheet doesn't know. > 00: 00 11 06 00 00 00 41 CC 04 04 32 55 F8 00 92 02 > 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73 > 20: 3C 10 00 00 00 00 A0 00 FF FF FF FF FF FF FF FF It seems a difference at 0x1e only, that A0 00 at the end - who knows (would require an analyzer). >> and, if you tried "upgrading" or "downgrading", if it worked. > > I haven't tried it yet. I guess chances for the last card are lower. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Intel FB pixel clock calculation fix
Pavel Machek <[EMAIL PROTECTED]> writes: > On Tue 2007-09-11 14:18:57, Krzysztof Halasa wrote: >> I think 2.6.22 would be overkill, .23 - not sure. > > I don't think this is -stable kind of bug. Given the timeframe, I can only agree once again :-) -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PCI: disable MSI on more ATI NorthBridges
Daniel Barkalow <[EMAIL PROTECTED]> writes: > 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) > > will have the same issue, and use a multi-vendor driver. I think MCP55 HDA did not have such problem, though I may be wrong (AFAIR it worked with shared IRQ and with MSI). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PCI: disable MSI on more ATI NorthBridges
Jeff Garzik <[EMAIL PROTECTED]> writes: > Note that INTX_DISABLE is a recent addition to PCI. It's PCI 2.3. > Older PCI devices > support neither MSI nor INTX-disable, so make sure such devices don't > creep into your sample. MSI has been introduced by PCI 2.2 (and thus PCI-X 1.0) so there may be devices with MSI but without INTx-disable bit. I guess I have some early PCI-X hardware with MSI but I don't know if they have INTx-disable bit and I can't currently test that. And it probably doesn't matter. > In general it is documented that INTX_DISABLE should apply only to > INTx# so devices that disable MSI based on that bit are out of spec. The wording is: 10: This bit disables the device from asserting INTx#. A value of 0 enables the assertion of its INTx# signal. A value of 1 disables the assertion of its INTx# signal. This bit's state after RST# is 0. Refer to Section 6.8.1.3 for control of MSI. So strictly speaking it mandates disabling/enabling INTx but says nothing about other things (e.g. MSI). Some common sense dictates it shouldn't disable MSI, I guess. The "MSI Enable" description doesn't leave any doubt: 0: MSI Enable: If 1, the function is permitted to use MSI to request service and is prohibited from using its INTx# pin [...] > But unfortunately that is rather irrelevant, since we see these > out-of-spec devices in the field today. Right. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Ok. I just put a program on something like http://www.kernel.org/~chris/vt6307ohciver.c Anybody with OHCI-1.0 VT6307* Firewire chip may want to try. Obviously it's based on undocumented features, it may blow your machine etc. Please remove your ohci1394 or firewire-ohci driver before using this program. Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver Examine (and backup) the EEPROM data first: # /sbin/lspci | grep 1394 01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) # ./vt6307ohciver 01:04.0 [some debug info] It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM EEPROM dump: 00: 00 10 DC 00 01 01 D4 F2 04 04 32 55 F8 00 A2 02 10: A1 00 40 63 62 14 0D 25 03 DF 40 80 00 20 00 73 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF ^^ Your VT6307 chip is in OHCI 1.0 mode (If you have only one VIA firewire chip you can use "" as the argument.) I'd check if there is a small SMD 8-pin 24c01 or similar EEPROM near VT6307 if I were you. Alternatively the program may say you have 93c46, also a small 8-pin chip. Now you can try upgrading to OHCI-1.1: # ./vt6307ohciver "" 1.1 It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM writing 0x08 at address 0x22 Please reboot People with 93c46 will see 0x11 address. Do as commanded, reboot (PCI reset) is required for the VT6307 to reload the configuration from its EEPROM. Please let me know if it doesn't work. This program may possibly run on VT6306-based board/card as well, though I don't know what would happen (I suspect it could work, but may need some modifications). The "dump" function should work with any OHCI firewire device, though for non-VIA chips you would have to change PCI device/vendor ID in the source. If you have a VT6306-based card and you run this program, I'd appreciate it if you let me know the EEPROM contents (make sure you mention chip type) and, if you tried "upgrading" or "downgrading", if it worked. In theory VT6306 should be able to run in OHCI-1.1 mode, but I don't really know. VT6306 only supports 93c46 EEPROM so if the program says 24c01 you may want to force it (edit the source) and let me know. VT6305 users may not bother, this chip doesn't support OHCI-1.1. Not sure if anything like it ever existed, though. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > What if we add a whitelisting in the driver which ignores the register > contents which state OHCI 1.0 implementation level, and just treats > these VIA chips as OHCI 1.1 implementations? It would be interesting but I'm not sure it would work. I guess if these chips are in OHCI 1.0 mode the 1.1 functionality may be unavailable (the datasheet seems to suggest that). OTOH I think it's better to change the EEPROM contents anyway, it's a simple program (which I'm going to write when I'm a bit less loaded). I wonder if OHCI 1.0 hardware based on VT6307 (and 6306) is a common thing, or is it just an exception. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
> OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't > only know how to enable it with (only) software. I suspect all those > VT6306 could be "upgraded" as well. BTW: I've looked at it a bit closer and it seems the EEPROM lines are controlled by VT6307 I/O ports (region #1) 0x0 and 0x20: 01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Memory at feafe800 (32-bit, non-prefetchable) [size=2K] I/O ports at d480 [size=128] port 0x20 R/O bit 8 is set in 93c46 mode and reset in I^2C mode port 0x20 bit 4 must be set to drive CS, CLK and DATA-OUT outputs port 0x20 bits 3, 2 and 1 are, respectively, CS, CLK and DATA-OUT pins in 93c46 mode and unused, SCL and SDA pins in I^2C mode port 0x20 R/O bit 0 is DATA-IN input in 93c46 mode port 0x0 bit 8 must be set to enable access port 0x20 must be written 0x20 (bit 5 only) to disable access (clears port 0x0 bit 8). They are all 32-bit I/O ports. The above allows for complete control in 93c46 mode (I'll make the program available later) and unfortunately I don't yet know how to read SDA (and SCL) state in I^2C mode (I can blindly write to the EEPROM and I can read the EEPROM data using GUID PROM register so there is a workaround). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes:
> And are you going to test if and how stable OHCI 1.1 features work?
I've "upgraded" the other machine ("b"), it uses the same VT6307
(not sure the packaging letter but I've already closed the case)
and is made in 2006 (week 22 or 20).
firewire_ohci: Added fw-ohci device :02:03.0, OHCI version 1.10
firewire_core: created new fw device fw0 (0 config rom retries)
firewire_core: created new fw device fw1 (0 config rom retries)
firewire_core: phy config: card 0, new root=ffc1, gap_count=5
Just watching live DV stream across Ethernet from this machine.
OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't
only know how to enable it with (only) software. I suspect all those
VT6306 could be "upgraded" as well.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > What I meant was: First revisions may have had incomplete OHCI 1.1 > support and were sold as OHCI 1.0 chips, and as soon as they stabilized > it they sold them as OHCI 1.1 chips. But that's mere speculation on my > part. I can't think of any other reason though why anybody would hide > OHCI 1.1 compatibility. Perhaps some MS Windows had troubles with 1.1? VIA has a history of similar things (e.g. some C3 CPUs). All 3 chips I have, including that dated 2002, are single revision "80" so I guess there are absolutely no silicon changes. > And are you going to test if and how stable OHCI 1.1 features work? > (Which features are these? Right now only dual buffer reception comes > to my mind.) On this old EPIA? No :-) At least unless I have any doubt. On the other machine (currently) 1.0? Sure, that's why I did it. Is the "dual buffer reception" involved in receiving video from a DV camera, using the new driver? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > And in case of VT6307, I suspect it's VIA who > selects the implementation level (based on chip revision), not the card > vendor. Can't be, the customers (real ones - board makers) would kill them at once and then buy a different brand. That's not selling a different wifi card under the old name. Anyway, I just connected a programmer to the EEPROM (machine "a" in my previous mail = EPIA-M 600 MHz), wrote "8" to the 16-bit word at address 0x11 (93c46 EEPROM), and now this VT6307S dated 0239CD (2002, 39th week) says: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[12] MMIO=[de00-de0007ff] Max Packet=[2048] IR/IT contexts=[4/8] Unfortunately it's not much good for general consumption, and I haven't yet found a way to write to the EEPROM using VT6307 registers (one can easily read it using documented GUID register). Nobody with a good VIA contact? I'm not asking for something extraordinary, am I? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Krzysztof Halasa <[EMAIL PROTECTED]> writes: [VIA VT6306/6307] > I haven't yet checked if it changes OHCI version - I of course > could program the EEPROM externally but I think I'd better find > how to do that from PCI side. Added Cc:lkml, perhaps someone at VIA could find that strictly confidential and destroy-before-reading document and spare me the effort? :-) All I need to know is: a) meaning of the config EEPROM data for VIA firewire chips b) how to read/write the EEPROM from PCI side (i.e., probably EECS, EEDO, EEDI/SDA and EECK/SCL bit locations or however it's done). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Stefan Richter <[EMAIL PROTECTED]> writes: > AFAIK all 6306 are OHCI 1.0. I presume that currently produced 6307 are > OHCI 1.1 and maybe only first revisions of it were 1.0 --- but that's > just my speculation. I would be surprised though if it was merely a > matter of EEPROM contents. Both VT6306 and VT6307 datasheets claim selectable OHCI 1.0/1.1. I guess they did that for compatibility or something like that. The 6307 chip allows for either I^2C (24c01 etc) or 93c64 EEPROM (there is a pin to select), while 6306 works with 93c64 only (4-wire: chip select, clock, data-in, data-out). I examined 3 machines with VT6307 using a simple home-made signal analyzer: a) using 93C46 EEPROM and OHCI 1.0 b) using 24C01A EEPROM and OHCI 1.0 c) using 24C01A EEPROM and OHCI 1.1 All 3 chips have PCI vendorID 1106 and deviceID 3044, revision is 0x80. The VT6307 chip reads the EEPROM (after reset) in the following order: ADDRADDRa) b) c) 4-wire I^2C A 14 subsystem vendor ID B 16 subsystem device ID 10 20 103C103C103Cvalues same on all machines C 18 DF03DF03DF03 D 1A 804080408040 E 1C 200020002000 F 1E 730073007300 11 22 0008 12 24 0 0 40001000config_rom: offset 0E 1 2 0063DC1000DC(GUID) 0C 2 4 0100FD000101 12 3 6 D0D48F75F2D4 10 4 8 040404040404values same on all machines 5 A 553255325532 6 C 00F800F800F8 7 E 02A202A202A2 8 10 00A100A100A1 9 12 634063406340 The only difference (not counting GUID) is at address 0x11 (0x22 for I2C). I haven't yet checked if it changes OHCI version - I of course could program the EEPROM externally but I think I'd better find how to do that from PCI side. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23
Ingo Molnar <[EMAIL PROTECTED]> writes: > - an uncommon embedded config combinatio: if CONFIG_EMBEDDED=y and > CONFIG_BLOCK is unset. (a normally useless combination) Uncommon but far from useless - may be pure initramfs-based. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > but the gist is that IBM has > traditionally bit 0 for MSB and x for LSB. It's a pain to work with: > for one, bits in the same place in a word (say, control register) are > renumbered in 32 vs 64. I wasn't aware of that, but it doesn't really change the bit order, only bit names (numbers actually). Extremely weird BTW but I guess these things weren't that obvious to everyone some 50 years ago. > And I've worked on at least one piece of > hardware in which the hardware designer had a brain-fart and first board > had bit 0 on the CPU wired to bit 0 on the northbridge - should have > been 31 -> 0, 30 -> 1, etc... I suspect the board wasn't able to run any OS, was it? :-) Would make a real example of the different order of bits, though. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Timur Tabi <[EMAIL PROTECTED]> writes:
> I think when the PowerPC is running in little-endian mode, that might
> be the case. It needs to be able to write a byte in big-endian mode,
> and then read that byte back in little-endian mode and have it be the
> same byte.
But this is exactly what excludes changing bit orders :-)
There are other CPU types which can work both LE and BE.
If you write 0x12345678 and switch endianness you get 0x78563412,
but the individual bits are still in the same (natural) order.
In the kernel, to convert from BE to LE or vice versa you need
something like swab32 (assuming 32-bit ints). It doesn't change
the order of the individual bits, it only swaps the (4 in this case)
bytes ("lanes" for hw swapping, PCI etc).
If you, for example, write an 8-bit integer in BE mode and want
it back in LE mode, you have to XOR the address with 0x3, but
the value already comes in the same natural bit order. Of course
swab32 will do as well.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: >> There is no such thing as bit-order. The data lines are numbered, >> say, D0 - D31, with D0 being LSB (bit) and D31 MSB. >> > > Uh-huh. Check out an IBM Power manual some time. Some pointer maybe? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Timur Tabi <[EMAIL PROTECTED]> writes: >> There is no such thing as bit-order. > > Yes, there is. You need to read the article at > http://www.linuxjournal.com/article/6788. Explains what it means for > bits to be in one order versus another. This is from the perspective > of external devices, not the CPU (which is always consistent with > regards to bit order) Have you ever seen a device or platform with the bits reversed? I.e. one on which 0x01 from CPU POV is 0x80 or 0x8000 etc. from device's POV? Perhaps I was too brief, I should've written "there is no such thing WRT the CPU-device connections" because the bit order actually exists on things like serial lines, though it's totally independent from big/little endianness of the CPU and/or peripheral devices, and one can't assume anything matches there. On parallel bus, all bits (at least of an 8-bit byte) are stored and transmitted at the same time and address, so no bit can be first or last. Once again, you shift left (towards MSBit), you multiply, shifting right divides. At least as long as you limit it to a single byte. Perhaps if you tell us what are you exactly trying to achieve... -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Timur Tabi <[EMAIL PROTECTED]> writes: > Yeah, I read that article some time ago when trying to diagnose the > problem I was seeing. It does explain the point I'm trying to make. > We have a device that's used on two product lines: one ARM-based, and > one PowerPC. The ARM is little-endian, and the PowerPC is big-endian. > The device can support little-endian or big-endian data, as long as > the bit-order matches the byte-order. There is no such thing as bit-order. The data lines are numbered, say, D0 - D31, with D0 being LSB (bit) and D31 MSB. You usually write register bits from MSB to LSB, so shift left increments and shift right decrements the value. This is orthogonal to the big/little-endianness. Now your device can be connected straight to the bus or the data lanes (4 on 32-bit PCI) can be crossed. This is platform-dependent. The kernel provides functions/macros to access devices in a independent way, such as writel/readl/pci_map_* etc. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Cute feature: colored printk output
Jan Engelhardt <[EMAIL PROTECTED]> writes: > What we see here might not be "ASCII", but "VGA-specific color values". > It's just that I call it ASCII since it's the mirrored opposite of ANSI. I see. Then perhaps "VGA color value" would be better. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Cute feature: colored printk output
Jan Engelhardt <[EMAIL PROTECTED]> writes: >>I wonder how accurate is it. > > Since I do not use 512-glyph fonts, I do not know. Actually I meant "how accurate my remarks are" :-) Not convinced WRT ASCII color codes, though. ASCII doesn't contain codes for changing colors. Perhaps some specific "extended ASCII"? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Cute feature: colored printk output
Jan Engelhardt <[EMAIL PROTECTED]> writes: > + The value you need to enter here is the ASCII color value ASCII color value? ANSI perhaps? > + composed (OR'ed) by one foreground color, one background > + color and any number of attributes as follows: I'm certainly not a native English writer, though I think it should be "composed of" or maybe "composed from". "one" doesn't sound well in my ears, either. > + Using "highlight foreground" is said not work when you use I'd say "HF is known not to work with VGA console" or just "HF doesn't work with VGA console". I wonder how accurate is it. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New 'Changes-licensed-under' tag introduced for Linux-wireless
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> No, please don't down this legal rat hole. It would cause bullshit like
> people submitting dual licensed patches to the scheduler or GPL only
> patches to the ath5k or ACPI code.
Precisely. Signed-off-by means the patch author already authorized
the patch to be applied. With the patch merged the conditions still
in the file (project etc) apply and not some obscure email tags.
If someone really wants to change licencing conditions then the
licence conditions in the source code must be changed.
> Instead, add a section to Documentation/SubmittingPatches that clearly
> states that all changes to a file are licensed under the same license
> as the original file. I don't feel legally qualified to write the correct
> wording.
Current Documentation/SubmittingPatches:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
^
indicated in the file; or
^
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Intel FB: force even line count in interlaced mode
Intel FB: the chip adds two halflines automatically in interlaced mode,
force even line count for the right timings.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -317,6 +317,14 @@ int intelfbhw_validate_mode(struct intelfb_info *dinfo,
var->yres, VACTIVE_MASK + 1);
return 1;
}
+ if (var->xres < 4) {
+ WRN_MSG("X resolution too small (%d vs 4).\n", var->xres);
+ return 1;
+ }
+ if (var->yres < 4) {
+ WRN_MSG("Y resolution too small (%d vs 4).\n", var->yres);
+ return 1;
+ }
/* Check for doublescan modes. */
if (var->vmode & FB_VMODE_DOUBLE) {
@@ -324,6 +332,11 @@ int intelfbhw_validate_mode(struct intelfb_info *dinfo,
return 1;
}
+ if ((var->vmode & FB_VMODE_INTERLACED) && (var->yres & 1)) {
+ WRN_MSG("Odd number of lines in interlaced mode\n");
+ return 1;
+ }
+
/* Check if clock is OK. */
tmp = 10 / var->pixclock;
if (tmp < MIN_CLOCK) {
@@ -1127,6 +1140,8 @@ int intelfbhw_mode_to_hw(struct intelfb_info *dinfo,
hblank_end);
vactive = var->yres;
+ if (var->vmode & FB_VMODE_INTERLACED)
+ vactive--; /* the chip adds 2 halflines automatically */
vsync_start = vactive + var->lower_margin;
vsync_end = vsync_start + var->vsync_len;
vtotal = vsync_end + var->upper_margin;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Intel FB: more interlaced mode support
Intel FB: allow odd- and even-field-first in interlaced modes, and
proper sync to vertical retrace
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -376,7 +376,7 @@ int intelfbhw_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
dinfo->vsync.pan_offset = offset;
if ((var->activate & FB_ACTIVATE_VBL) &&
- !intelfbhw_enable_irq(dinfo, 0))
+ !intelfbhw_enable_irq(dinfo))
dinfo->vsync.pan_display = 1;
else {
dinfo->vsync.pan_display = 0;
@@ -1240,7 +1240,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
u32 tmp;
const u32 *dpll, *fp0, *fp1, *pipe_conf;
const u32 *hs, *ht, *hb, *vs, *vt, *vb, *ss;
- u32 dpll_reg, fp0_reg, fp1_reg, pipe_conf_reg;
+ u32 dpll_reg, fp0_reg, fp1_reg, pipe_conf_reg, pipe_stat_reg;
u32 hsync_reg, htotal_reg, hblank_reg;
u32 vsync_reg, vtotal_reg, vblank_reg;
u32 src_size_reg;
@@ -1281,6 +1281,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
fp0_reg = FPB0;
fp1_reg = FPB1;
pipe_conf_reg = PIPEBCONF;
+ pipe_stat_reg = PIPEBSTAT;
hsync_reg = HSYNC_B;
htotal_reg = HTOTAL_B;
hblank_reg = HBLANK_B;
@@ -1304,6 +1305,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
fp0_reg = FPA0;
fp1_reg = FPA1;
pipe_conf_reg = PIPEACONF;
+ pipe_stat_reg = PIPEASTAT;
hsync_reg = HSYNC_A;
htotal_reg = HTOTAL_A;
hblank_reg = HBLANK_A;
@@ -1390,6 +1392,17 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
OUTREG(vtotal_reg, *vt);
OUTREG(src_size_reg, *ss);
+ switch (dinfo->info->var.vmode & (FB_VMODE_INTERLACED |
+ FB_VMODE_ODD_FLD_FIRST)) {
+ case FB_VMODE_INTERLACED | FB_VMODE_ODD_FLD_FIRST:
+ OUTREG(pipe_stat_reg, 0x | PIPESTAT_FLD_EVT_ODD_EN);
+ break;
+ case FB_VMODE_INTERLACED: /* even lines first */
+ OUTREG(pipe_stat_reg, 0x | PIPESTAT_FLD_EVT_EVEN_EN);
+ break;
+ default:/* non-interlaced */
+ OUTREG(pipe_stat_reg, 0x); /* clear all status bits only */
+ }
/* Enable pipe */
OUTREG(pipe_conf_reg, *pipe_conf | PIPECONF_ENABLE);
@@ -1955,71 +1968,72 @@ void intelfbhw_cursor_reset(struct intelfb_info *dinfo)
}
}
-static irqreturn_t
-intelfbhw_irq(int irq, void *dev_id) {
- int handled = 0;
+static irqreturn_t intelfbhw_irq(int irq, void *dev_id)
+{
u16 tmp;
struct intelfb_info *dinfo = (struct intelfb_info *)dev_id;
spin_lock(&dinfo->int_lock);
tmp = INREG16(IIR);
- tmp &= VSYNC_PIPE_A_INTERRUPT;
+ if (dinfo->info->var.vmode & FB_VMODE_INTERLACED)
+ tmp &= PIPE_A_EVENT_INTERRUPT;
+ else
+ tmp &= VSYNC_PIPE_A_INTERRUPT; /* non-interlaced */
if (tmp == 0) {
spin_unlock(&dinfo->int_lock);
- return IRQ_RETVAL(handled);
+ return IRQ_RETVAL(0); /* not us */
}
- OUTREG16(IIR, tmp);
+ /* clear status bits 0-15 ASAP and don't touch bits 16-31 */
+ OUTREG(PIPEASTAT, INREG(PIPEASTAT));
- if (tmp & VSYNC_PIPE_A_INTERRUPT) {
- dinfo->vsync.count++;
- if (dinfo->vsync.pan_display) {
- dinfo->vsync.pan_display = 0;
- OUTREG(DSPABASE, dinfo->vsync.pan_offset);
- }
- wake_up_interruptible(&dinfo->vsync.wait);
- handled = 1;
+ OUTREG16(IIR, tmp);
+ if (dinfo->vsync.pan_display) {
+ dinfo->vsync.pan_display = 0;
+ OUTREG(DSPABASE, dinfo->vsync.pan_offset);
}
+ dinfo->vsync.count++;
+ wake_up_interruptible(&dinfo->vsync.wait);
+
spin_unlock(&dinfo->int_lock);
- return IRQ_RETVAL(handled);
+ return IRQ_RETVAL(1);
}
-int
-intelfbhw_enable_irq(struct intelfb_info *dinfo, int reenable) {
-
+int intelfbhw_enable_irq(struct intelfb_info *dinfo)
+{
+ u16 tmp;
if (!test_and_set_bit(0, &dinfo->irq_flags)) {
if (request_irq(dinfo->pdev->irq, intelfbhw_irq, IRQF_SHARED,
-"intelfb", dinfo)) {
+ "intelfb", dinfo)) {
clear_bit(0, &dinfo->irq_flags);
return -EINVAL;
}
spin_lock_irq(&dinfo->int_lock);
- OUTREG16
[PATCH 2/4] Intel FB: obvious changes and corrections
Intel FB: obvious changes and corrections
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -355,7 +355,10 @@ struct intelfb_info {
struct intelfb_output_rec output[MAX_OUTPUTS];
};
-#define IS_I9XX(dinfo) (((dinfo)->chipset == INTEL_915G)||(dinfo->chipset ==
INTEL_915GM)||((dinfo)->chipset == INTEL_945G)||(dinfo->chipset==INTEL_945GM))
+#define IS_I9XX(dinfo) (((dinfo)->chipset == INTEL_915G) ||\
+ ((dinfo)->chipset == INTEL_915GM) ||\
+ ((dinfo)->chipset == INTEL_945G) || \
+ ((dinfo)->chipset==INTEL_945GM))
#ifndef FBIO_WAITFORVSYNC
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -434,14 +434,14 @@ void intelfbhw_setcolreg(struct intelfb_info *dinfo,
unsigned regno,
unsigned red, unsigned green, unsigned blue,
unsigned transp)
{
+ u32 palette_reg = (dinfo->pipe == PIPE_A) ?
+ PALETTE_A : PALETTE_B;
+
#if VERBOSE > 0
DBG_MSG("intelfbhw_setcolreg: %d: (%d, %d, %d)\n",
regno, red, green, blue);
#endif
- u32 palette_reg = (dinfo->pipe == PIPE_A) ?
- PALETTE_A : PALETTE_B;
-
OUTREG(palette_reg + (regno << 2),
(red << PALETTE_8_RED_SHIFT) |
(green << PALETTE_8_GREEN_SHIFT) |
@@ -1305,8 +1305,8 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
count = 0;
do {
- tmp_val[count%3] = INREG(0x7);
- if ((tmp_val[0] == tmp_val[1]) && (tmp_val[1]==tmp_val[2]))
+ tmp_val[count % 3] = INREG(PIPEA_DSL);
+ if ((tmp_val[0] == tmp_val[1]) && (tmp_val[1] == tmp_val[2]))
break;
count++;
udelay(1);
@@ -2004,7 +2004,6 @@ intelfbhw_enable_irq(struct intelfb_info *dinfo, int
reenable) {
void
intelfbhw_disable_irq(struct intelfb_info *dinfo) {
- u16 tmp;
if (test_and_clear_bit(0, &dinfo->irq_flags)) {
if (dinfo->vsync.pan_display) {
@@ -2016,8 +2015,7 @@ intelfbhw_disable_irq(struct intelfb_info *dinfo) {
OUTREG16(IMR, 0x);
OUTREG16(IER, 0x0);
- tmp = INREG16(IIR);
- OUTREG16(IIR, tmp);
+ OUTREG16(IIR, INREG16(IIR)); /* clear IRQ requests */
spin_unlock_irq(&dinfo->int_lock);
free_irq(dinfo->pdev->irq, dinfo);
--- a/drivers/video/intelfb/intelfbhw.h
+++ b/drivers/video/intelfb/intelfbhw.h
@@ -93,7 +93,7 @@
#define IIR0x20A4
#define IMR0x20A8
#define VSYNC_PIPE_A_INTERRUPT (1 << 7)
-#define PIPE_A_EVENT_INTERRUPT (1 << 4)
+#define PIPE_A_EVENT_INTERRUPT (1 << 6)
#define VSYNC_PIPE_B_INTERRUPT (1 << 5)
#define PIPE_B_EVENT_INTERRUPT (1 << 4)
#define HOST_PORT_EVENT_INTERRUPT (1 << 3)
@@ -276,6 +276,8 @@
#define DVOB_SRCDIM0x61144
#define DVOC_SRCDIM0x61164
+#define PIPEA_DSL 0x7
+#define PIPEB_DSL 0x71000
#define PIPEACONF 0x70008
#define PIPEBCONF 0x71008
#define PIPECONF_ENABLE(1 << 31)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Intel FB: whitespace, bracket and other clean-ups
Intel FB: whitespace, bracket and other clean-ups
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -231,8 +231,8 @@ struct intelfb_hwstate {
struct intelfb_heap_data {
u32 physical;
u8 __iomem *virtual;
- u32 offset; // in GATT pages
- u32 size;// in bytes
+ u32 offset; /* in GATT pages */
+ u32 size; /* in bytes */
};
#ifdef CONFIG_FB_INTEL_I2C
@@ -270,9 +270,9 @@ struct intelfb_info {
struct intelfb_hwstate save_state;
/* agpgart structs */
- struct agp_memory *gtt_fb_mem; // use all stolen memory or vram
- struct agp_memory *gtt_ring_mem; // ring buffer
- struct agp_memory *gtt_cursor_mem; // hw cursor
+ struct agp_memory *gtt_fb_mem; /* use all stolen memory or vram */
+ struct agp_memory *gtt_ring_mem; /* ring buffer */
+ struct agp_memory *gtt_cursor_mem; /* hw cursor */
/* use a gart reserved fb mem */
u8 fbmem_gart;
@@ -346,7 +346,7 @@ struct intelfb_info {
/* driver registered */
int registered;
-
+
/* index into plls */
int pll_index;
--- a/drivers/video/intelfb/intelfb_i2c.c
+++ b/drivers/video/intelfb/intelfb_i2c.c
@@ -58,7 +58,8 @@ static void intelfb_gpio_setscl(void *data, int state)
struct intelfb_info *dinfo = chan->dinfo;
u32 val;
- OUTREG(chan->reg, (state ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK |
SCL_VAL_MASK);
+ OUTREG(chan->reg, (state ? SCL_VAL_OUT : 0) |
+ SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK);
val = INREG(chan->reg);
}
@@ -68,7 +69,8 @@ static void intelfb_gpio_setsda(void *data, int state)
struct intelfb_info *dinfo = chan->dinfo;
u32 val;
- OUTREG(chan->reg, (state ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK |
SDA_VAL_MASK);
+ OUTREG(chan->reg, (state ? SDA_VAL_OUT : 0) |
+ SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK);
val = INREG(chan->reg);
}
@@ -97,26 +99,26 @@ static int intelfb_gpio_getsda(void *data)
}
static int intelfb_setup_i2c_bus(struct intelfb_info *dinfo,
-struct
intelfb_i2c_chan *chan,
-const u32 reg,
const char *name)
+struct intelfb_i2c_chan *chan,
+const u32 reg, const char *name)
{
int rc;
- chan->dinfo = dinfo;
- chan->reg = reg;
+ chan->dinfo = dinfo;
+ chan->reg = reg;
snprintf(chan->adapter.name, sizeof(chan->adapter.name),
"intelfb %s", name);
- chan->adapter.owner = THIS_MODULE;
- chan->adapter.id= I2C_HW_B_INTELFB;
+ chan->adapter.owner = THIS_MODULE;
+ chan->adapter.id= I2C_HW_B_INTELFB;
chan->adapter.algo_data = &chan->algo;
chan->adapter.dev.parent= &chan->dinfo->pdev->dev;
- chan->algo.setsda = intelfb_gpio_setsda;
- chan->algo.setscl = intelfb_gpio_setscl;
- chan->algo.getsda = intelfb_gpio_getsda;
- chan->algo.getscl = intelfb_gpio_getscl;
- chan->algo.udelay = 40;
- chan->algo.timeout = 20;
- chan->algo.data = chan;
+ chan->algo.setsda = intelfb_gpio_setsda;
+ chan->algo.setscl = intelfb_gpio_setscl;
+ chan->algo.getsda = intelfb_gpio_getsda;
+ chan->algo.getscl = intelfb_gpio_getscl;
+ chan->algo.udelay = 40;
+ chan->algo.timeout = 20;
+ chan->algo.data = chan;
i2c_set_adapdata(&chan->adapter, chan);
@@ -142,40 +144,44 @@ void intelfb_create_i2c_busses(struct intelfb_info *dinfo)
dinfo->output[i].type = INTELFB_OUTPUT_ANALOG;
/* setup the DDC bus for analog output */
- intelfb_setup_i2c_bus(dinfo, &dinfo->output[i].ddc_bus, GPIOA,
"CRTDDC_A");
+ intelfb_setup_i2c_bus(dinfo, &dinfo->output[i].ddc_bus, GPIOA,
+ "CRTDDC_A");
i++;
-/* need to add the output busses for each device
- - this function is very incomplete
- - i915GM has LVDS and TVOUT for example
-*/
-switch(dinfo->chipset) {
+ /* need to add the output busses for each device
+
[PATCH 0/4] Intel FB: cleanup and misc interlaced mode support
Hi,
I'll attach 4 patches for Intel FB (i830+) here:
1/4 - whitespace, bracket and other clean-ups (rather long)
working with kernel-style brackets instead of:
void
function_name (int arg) {
is a bit easier. I think it would be best to apply it in the
beginning of the "patch period" to avoid potential conflicts.
2/4 - obvious changes and corrections
3/4 - the chip adds two halflines automatically in interlaced mode,
we have to force the number of lines to be even
4/4 - allow odd- and even-field-first in interlaced modes, and
proper sync to vertical retrace. It enables video players
(got it working with MPlayer currently) to play perfect
field-synced stream to RGB-connected (VGA output) TV set.
This patch adds #define FB_VMODE_ODD_FLD_FIRST 4 in
include/linux/fb.h, to be able to force odd field first (analog
broadcast PAL and some PAL DVD discs use it) instead of even
field (bottom) first, as used by NTSC, DV PAL, some PAL
DVDs etc. Interlaced-only thing.
This change need a coresponding change in fbset and probably in
media players which want to set video mode themselves, I will
do the fbset part and maybe MPlayer's if the fb.h patch is ok.
All four patches change only files in drivers/video/intelfb/, except
patch 4/4 which also adds FB_VMODE_ODD_FLD_FIRST in include/linux/fb.h.
Tested on i915G in 1440x576 50 Hz (I) with PAL TV.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
Satyam Sharma <[EMAIL PROTECTED]> writes: > What happened here is simply that in the absence of a "-t" option, > mount(8) defaulted (probably due to incorrect heuristics?) to UDF for > some reason, thereby obviously failing. I think the CD contains both ISO-9660 and UDF filesystems, but the latter is just faulty. The disc would need to be analyzed. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
"David Schwartz" <[EMAIL PROTECTED]> writes: > My point is that you *cannot* prevent a recipient of a derivative work from > receiving any rights under either the GPL or the BSD to any protectable > elements in that work. Of course you can. What rights do you have to BSD-licenced works, made available (under BSD) to MS exclusively? You only get the binary object... You know, this is quite common practice - instead of assigning copyright, you can grant a BSD-style licence (for some fee, something like "do what you want but I will do what I want with my code"). >> If A sold a BSD licence to B only and this B sold a proprietary >> licence (for a derived work) to C, C (without that clause) wouldn't >> have a BSD licence to the original work. This is BTW common scenario. > > C most certainly would have a BSD license, should he choose to comply with > terms, to every protectable element that is in both the original work and > the work he received. But he may have received only binary program image - or the source under NDA. Sure, NDA doesn't cover public information, but BSD doesn't mean public. Now what? > C has no right to license any protectable element he did not author to > anyone else. He cannot set the license terms for those elements to C. Sure, the licence covers the >>>entire work<<<, not some "elements". > Neither the BSD nor the GPL ever give you the right to change the actual > license a work is offered under by the original author. Of course, that's a very distant thing. >> BTW: a work by multiple authors is a different thing than a work >> derived from another. > > In practice it doesn't matter. Of course it does. Only author of a (derived) work can licence it, in this case he/she could change the licence back to BSD, or sell it to MS (if not based on GPL etc). > Would you argue that I can license Disney's "The Lion King" movie to you if > I promise not to sue you over any (no) rights that I possess to it? Sure you can :-) that doesn't mean it would protect me from Disney, but you can. > You are confusing licenses of two very different types. The BSD and GPL > licenses only cover modification and distribution, two rights you do not get > to MS Windows at all. *Use* is not restricted under copyright. I'm told in the USA use = copying from disk to RAM = distribution, isn't it true? :-) It doesn't matter of course. > There is simply nothing remotely comparable to the BSD or GPL license in the > case of MS Windows. There is no grant of additional rights beyond those you > get automatically with lawful possession (such as use). I don't compare them (though you can). You don't get a licence for "original elements" in MS-Windows, do you? > If MS wished to grant someone the right to modify or redistribute Windows, > that person would also need to obtain the right to modify or distribute > protectable elements not authored by Microsoft. The only way they could > obtain those rights, assuming Microsoft didn't have written relicensing > agreements, is from the original author under the original licenses. Yes, but it isn't automatic. Imagine you have received something from MS, under more permissive licence (I think such things did happen). How do you, for example, recognice boundaries of the elements, IOW what additional rights do you have to each line in the code or pixel in the font? The file itself only states: (C) MS portions (C) e.g. Bitstream licenced under their special agreement What extra rights do you receive from Bitstream? Perhaps you should ask them if they have given you some licence? :-) Or another example, redistributable runtime libraries. What extra rights do you have? What you write is true for GPL, but it doesn't mean it's true everytime. It's just that clause in the GPL. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
"David Schwartz" <[EMAIL PROTECTED]> writes: > Theodore Tso writes: hardly > Of course you don't need a license to *use* the derived work. You never need > a license to use a work. (In the United States. Some countries word this a > bit differently but get the same effect.) Really? I thought you need a licence to use, say, MS Windows. Even to possess a copy. But I don't know about USA, I'm told there are strange things happening there :-) > If, however, you wanted to get the right to modify or distribute a > derivative work, you would need to obtain the rights to every protectable > element in that work. Of course. > Read GPL section 6, particularly this part: "Each time you redistribute the > Program (or any work based on the Program), the recipient automatically > receives a license from the original licensor to copy, distribute or modify > the Program subject to > these terms and conditions." Seems fine, your point? In addition to the rights from you (to the whole derived work), the recipient receives rights to the original work, from original author. It makes perfect sense, making sure the original author can't sue you like in the SCO case. If A sold a BSD licence to B only and this B sold a proprietary licence (for a derived work) to C, C (without that clause) wouldn't have a BSD licence to the original work. This is BTW common scenario. > To distribute a derivative work that contains protectable elements from > multiple authors, you are distributing all of those elements and need the > rights to all of them. You need a license to each element and in the absence > of any relicensing arrangements (which the GPL and BSD license are not), > only the original author can grant that to you. Of course. BTW: a work by multiple authors is a different thing than a work derived from another. > It is a common confusion that just because the final author has copyright in > the derivative work, that means he can license the work. Of course he (and only he) can. It doesn't mean the end users can't receive additional rights. Come on, licence = promise not to sue. Why would the copyright holder be unable to promise not to sue? It just doesn't make sense. > He cannot license > anyone else's creative contributions absent a relicensing arrangement. Sure, he can licence only his work, perhaps derived work. Look at MS Windows - it's a work created by a single company, though derived from other works, it's (C) MS and you get a licence for the whole MS Windows from only MS. You may have some additional rights and MS may have to acknowledge additional contributors, based on their licences granted by those contributors (such as using the original UCB licence). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
Adrian Bunk <[EMAIL PROTECTED]> writes: > Or that > "OpenBSD != Linux kernel" > > was wrong since although they are not equal, they are related since they > are both open source operating systems. BTW: never heard someone is using the FreeBSD version of Linux? I did, not once :-) -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
Hannah Schroeter <[EMAIL PROTECTED]> writes: > Right. You may add nearly any copyright *on your own significant > additions/changes*. Such as a patch? Hardly IMHO, a patch is not a work but an output of an automated tool. The copyright is not about fragments of works. You may add a copyright _notice_, not a copyright (a right). The author of a derived work automatically has copyright to the whole derived work, not only to the "fragments" he has created. MS Windows is "Copyright Microsoft", not "Microsoft and others". You can add any licence (not copyright, as it's automatic) to your (derived or not) work. If it's a derived work, you must comply with the original licence(s). Of course, the original work is copyrighted by its original author and licenced under its original conditions, and nobody is able to change that. Now, you don't need a licence from the original author to use the derived work. The author of the derived work only needs a licence from the original author to create a derived work. Do you think Microsoft users have licences from authors of the works MS Windows etc. are based on? :-) You do need a licence from the original author to use the original work, e.g. unmodified original work distributed by third party. I.e., you don't need a licence to use MS Windows from the retail shop, you need it from MS. Is it that hard to understand? > However, BSD/ISC explicitly requires to retain the > BSD/ISC terms, too (applicable to the original part of the combined > work). Where exactly? Have you seen MS EULA maybe? Such requirement would be impossible to fullfit. > No. The derivative work altogether has a *mixed* license. BSD/ISC for > the parts that are original, the other (restrictive, GPL, whatever) > license for the modifications/additions. Look at MS EULA, does MS Windows in your opinion have such a mixed licence too? :-) -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
"Can E. Acar" <[EMAIL PROTECTED]> writes: > Do you believe re-arranging code, renaming functions, splitting code > to multiple files, adding some adaptation code is original enough > to be a derivative work and deserve its own copyright? "Deserve"? The copyright is automatic, the author (of the derivative work) may like it or not. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
