[PATCH] add missing MPSC to X86_INTEL_USERCOPY and _USE_PPRO_CHECKSUM
Debugging some bizare memory corruption in certain kernel configs on some machines, I noticed MPSC (1st gen Intel X64 Nocona) is missing in selecting X86_INTEL_USERCOPY and X86_USE_PPRO_CHECKSUM. Unless someone has a good reason not to, I think MPSC should select the two, and maybe MATOM should also made select X86_INTEL_USERCOPY? Signed-of-by: René Rebe --- linux-5.10/arch/x86/Kconfig.cpu.vanilla 2021-01-27 16:09:20.163930078 +0100 +++ linux-5.10/arch/x86/Kconfig.cpu 2021-01-27 16:36:35.064014421 +0100 @@ -336,11 +336,11 @@ config X86_INTEL_USERCOPY def_bool y - depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MCORE2 + depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MCORE2 || MPSC config X86_USE_PPRO_CHECKSUM def_bool y - depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM + depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM || MPSC config X86_USE_3DNOW def_bool y -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de
[PATCH v3] zstd compressed firmware loading
Now with zstd compressed kernel & initrd upstream, we would rather
compress everything with one type of compressor, so I added support
for zstd compressed firmware loading, too. Renamed FW_LOADER_COMPRESS
to FW_LOADER_COMPRESS_XZ to indicate algorithm used.
Tested on x86_64, sparc64 and mips64.
Signed-off-by: René Rebe
diff --git a/drivers/base/firmware_loader/Kconfig
b/drivers/base/firmware_loader/Kconfig
index 5b24f3959255..92e6bec4605a 100644
--- a/drivers/base/firmware_loader/Kconfig
+++ b/drivers/base/firmware_loader/Kconfig
@@ -155,8 +155,8 @@ config FW_LOADER_USER_HELPER_FALLBACK
If you are unsure about this, say N here.
-config FW_LOADER_COMPRESS
- bool "Enable compressed firmware support"
+config FW_LOADER_COMPRESS_XZ
+ bool "Enable XZ compressed firmware support"
select FW_LOADER_PAGED_BUF
select XZ_DEC
help
@@ -169,6 +169,16 @@ config FW_LOADER_COMPRESS
be compressed with either none or crc32 integrity check type (pass
"-C crc32" option to xz command).
+config FW_LOADER_COMPRESS_ZSTD
+ bool "Enable Zstd compressed firmware support"
+ select FW_LOADER_PAGED_BUF
+ select ZSTD_DECOMPRESS
+ help
+ This option enables the support for loading Zstd compressed firmware
+ files. The caller of firmware API receives the decompressed file
+ content. The compressed file is loaded as a fallback, only after
+ loading the raw file failed at first.
+
config FW_CACHE
bool "Enable firmware caching during suspend"
depends on PM_SLEEP
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 78355095e00d..0b1ea5e0708d 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -34,7 +34,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -365,7 +367,7 @@ int fw_map_paged_buf(struct fw_priv *fw_priv)
/*
* XZ-compressed firmware support
*/
-#ifdef CONFIG_FW_LOADER_COMPRESS
+#ifdef CONFIG_FW_LOADER_COMPRESS_XZ
/* show an error and return the standard error code */
static int fw_decompress_xz_error(struct device *dev, enum xz_ret xz_ret)
{
@@ -459,7 +461,186 @@ static int fw_decompress_xz(struct device *dev, struct
fw_priv *fw_priv,
else
return fw_decompress_xz_pages(dev, fw_priv, in_size, in_buffer);
}
-#endif /* CONFIG_FW_LOADER_COMPRESS */
+#endif /* CONFIG_FW_LOADER_COMPRESS_XZ */
+
+/*
+ * Zstd-compressed firmware support
+ */
+#ifdef CONFIG_FW_LOADER_COMPRESS_ZSTD
+/* show an error and return the standard error code */
+static int handle_zstd_error(size_t ret)
+{
+ const int err = ZSTD_getErrorCode(ret);
+
+ if (!ZSTD_isError(ret))
+ return 0;
+
+ switch (err) {
+ case ZSTD_error_memory_allocation:
+ printk("ZSTD decompressor ran out of memory");
+ break;
+ case ZSTD_error_prefix_unknown:
+ printk("Input is not in the ZSTD format (wrong magic bytes)");
+ break;
+ case ZSTD_error_dstSize_tooSmall:
+ case ZSTD_error_corruption_detected:
+ case ZSTD_error_checksum_wrong:
+ printk("ZSTD-compressed data is corrupt");
+ break;
+ default:
+ printk("ZSTD-compressed data is probably corrupt");
+ break;
+ }
+ return -1;
+}
+
+/* single-shot decompression onto the pre-allocated buffer */
+static int fw_decompress_zstd_single(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+ const size_t wksp_size = ZSTD_DCtxWorkspaceBound();
+ void *wksp = large_malloc(wksp_size);
+ ZSTD_DCtx *dctx = ZSTD_initDCtx(wksp, wksp_size);
+ int err;
+ size_t ret;
+
+ if (dctx == NULL) {
+ dev_warn(dev, "Out of memory while allocating ZSTD_DCtx");
+ err = -1;
+ goto out;
+ }
+ /* Find out how large the frame actually is, there may be junk at
+* the end of the frame that ZSTD_decompressDCtx() can't handle.
+*/
+ ret = ZSTD_findFrameCompressedSize(in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+ in_size = (long)ret;
+
+ ret = ZSTD_decompressDCtx(dctx, fw_priv->data, fw_priv->allocated_size,
in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+
+ fw_priv->size = ret;
+
+out:
+ if (wksp != NULL)
+ large_free(wksp);
+ return err;
+}
+
+/* decompression on paged buffer and map it */
+static int fw_decompress_zstd_pages(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+ ZSTD_inBuffer in;
+ ZSTD_outBuffer out;
+ ZSTD_frameParams params;
+ void *wksp = NULL;
[PATCH v3] use cpu_to_le{16,32} instead of __constant_cpu_to_*
Joe Perches wrote:
> > - __constant_cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
> > + cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
>
> trivia: this now fits on a single line.
> > Whether __constant_cpu_to_le16() is used or cpu_to_le16(), the compiler
> > generates exactly the same code. The name of the cpu_to_le16() function
> > however
> > is shorter. I recommend cpu_to_le16() because of its shorter name and
> > because
> > that's what other kernel drivers use.
As per recommendation, convert a few remaining __constant_cpu_to_le{16,32}
instances in the qla2xxx, qla4xxx and cifs to just cpu_to_le{16,32}.
The later was apparently left over in f5307104e757 ("cifs: don't use
__constant_cpu_to_le32()").
Signed-off-by: René Rebe
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index fbb80a043b4f..3de6bf94ccc0 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -3583,7 +3583,7 @@ static int __qlt_send_term_imm_notif(struct scsi_qla_host
*vha,
/* terminate */
nack->u.isp24.flags |=
- __constant_cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
+ cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
nack->u.isp24.srr_rx_id = ntfy->u.isp24.srr_rx_id;
nack->u.isp24.status = ntfy->u.isp24.status;
diff --git a/drivers/scsi/qla2xxx/qla_tmpl.c b/drivers/scsi/qla2xxx/qla_tmpl.c
index 8dc82cfd38b2..f83b2f5fb490 100644
--- a/drivers/scsi/qla2xxx/qla_tmpl.c
+++ b/drivers/scsi/qla2xxx/qla_tmpl.c
@@ -912,7 +912,7 @@ qla27xx_driver_info(struct qla27xx_fwdt_template *tmp)
tmp->driver_info[0] = cpu_to_le32(
v[3] << 24 | v[2] << 16 | v[1] << 8 | v[0]);
tmp->driver_info[1] = cpu_to_le32(v[5] << 8 | v[4]);
- tmp->driver_info[2] = __constant_cpu_to_le32(0x12345678);
+ tmp->driver_info[2] = cpu_to_le32(0x12345678);
}
static void
diff --git a/drivers/scsi/qla4xxx/ql4_init.c b/drivers/scsi/qla4xxx/ql4_init.c
index 4a7ef971a387..cc4cd54eb7a8 100644
--- a/drivers/scsi/qla4xxx/ql4_init.c
+++ b/drivers/scsi/qla4xxx/ql4_init.c
@@ -120,8 +120,8 @@ int qla4xxx_init_rings(struct scsi_qla_host *ha)
* the interrupt_handler to think there are responses to be
* processed when there aren't.
*/
- ha->shadow_regs->req_q_out = __constant_cpu_to_le32(0);
- ha->shadow_regs->rsp_q_in = __constant_cpu_to_le32(0);
+ ha->shadow_regs->req_q_out = cpu_to_le32(0);
+ ha->shadow_regs->rsp_q_in = cpu_to_le32(0);
wmb();
writel(0, >reg->req_q_in);
diff --git a/drivers/scsi/qla4xxx/ql4_iocb.c b/drivers/scsi/qla4xxx/ql4_iocb.c
index a8df2d7eb069..dd25f917b5e6 100644
--- a/drivers/scsi/qla4xxx/ql4_iocb.c
+++ b/drivers/scsi/qla4xxx/ql4_iocb.c
@@ -161,7 +161,7 @@ static void qla4xxx_build_scsi_iocbs(struct srb *srb,
if (!scsi_bufflen(cmd) || cmd->sc_data_direction == DMA_NONE) {
/* No data being transferred */
- cmd_entry->ttlByteCnt = __constant_cpu_to_le32(0);
+ cmd_entry->ttlByteCnt = cpu_to_le32(0);
return;
}
diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
index bc8de7d402d5..02396da2acd4 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -646,8 +646,8 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Fill in the request and response queue information. */
init_fw_cb->rqq_consumer_idx = cpu_to_le16(ha->request_out);
init_fw_cb->compq_producer_idx = cpu_to_le16(ha->response_in);
- init_fw_cb->rqq_len = __constant_cpu_to_le16(REQUEST_QUEUE_DEPTH);
- init_fw_cb->compq_len = __constant_cpu_to_le16(RESPONSE_QUEUE_DEPTH);
+ init_fw_cb->rqq_len = cpu_to_le16(REQUEST_QUEUE_DEPTH);
+ init_fw_cb->compq_len = cpu_to_le16(RESPONSE_QUEUE_DEPTH);
init_fw_cb->rqq_addr_lo = cpu_to_le32(LSDW(ha->request_dma));
init_fw_cb->rqq_addr_hi = cpu_to_le32(MSDW(ha->request_dma));
init_fw_cb->compq_addr_lo = cpu_to_le32(LSDW(ha->response_dma));
@@ -657,20 +657,20 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Set up required options. */
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_SESSION_MODE |
+ cpu_to_le16(FWOPT_SESSION_MODE |
FWOPT_INITIATOR_MODE);
if (is_qla80XX(ha))
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_ENABLE_CRBDB);
+ cpu_to_le16(FWOPT_ENABLE_CRBDB);
- init_fw_cb->fw_options &= __constant_cpu_to_le16(~FWOPT_TARGET_MODE);
+ init_fw_cb->fw_options &= cpu_to_le16(~FWOPT_TARGET_MODE);
init_fw_cb->add_fw_options = 0;
init_fw_cb->add_fw_options |=
-
[PATCH v2] use cpu_to_le{16,32} instead of __constant_cpu_to_*
Bart Van Assche wrote:
> Hi René,
>
> Whether __constant_cpu_to_le16() is used or cpu_to_le16(), the compiler
> generates exactly the same code. The name of the cpu_to_le16() function
> however
> is shorter. I recommend cpu_to_le16() because of its shorter name and because
> that's what other kernel drivers use.
As per recommendation, convert a few remaining __constant_cpu_to_le{16,32}
instances in the qla2xxx, qla4xxx and cifs to just cpu_to_le{16,32}.
The later was apparently left over in f5307104e757 ("cifs: don't use
__constant_cpu_to_le32()").
Signed-off-by: René Rebe
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index fbb80a043b4f..3de6bf94ccc0 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -3583,7 +3583,7 @@ static int __qlt_send_term_imm_notif(struct scsi_qla_host
*vha,
/* terminate */
nack->u.isp24.flags |=
- __constant_cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
+ cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
nack->u.isp24.srr_rx_id = ntfy->u.isp24.srr_rx_id;
nack->u.isp24.status = ntfy->u.isp24.status;
diff --git a/drivers/scsi/qla2xxx/qla_tmpl.c b/drivers/scsi/qla2xxx/qla_tmpl.c
index 8dc82cfd38b2..f83b2f5fb490 100644
--- a/drivers/scsi/qla2xxx/qla_tmpl.c
+++ b/drivers/scsi/qla2xxx/qla_tmpl.c
@@ -912,7 +912,7 @@ qla27xx_driver_info(struct qla27xx_fwdt_template *tmp)
tmp->driver_info[0] = cpu_to_le32(
v[3] << 24 | v[2] << 16 | v[1] << 8 | v[0]);
tmp->driver_info[1] = cpu_to_le32(v[5] << 8 | v[4]);
- tmp->driver_info[2] = __constant_cpu_to_le32(0x12345678);
+ tmp->driver_info[2] = cpu_to_le32(0x12345678);
}
static void
diff --git a/drivers/scsi/qla4xxx/ql4_init.c b/drivers/scsi/qla4xxx/ql4_init.c
index 4a7ef971a387..cc4cd54eb7a8 100644
--- a/drivers/scsi/qla4xxx/ql4_init.c
+++ b/drivers/scsi/qla4xxx/ql4_init.c
@@ -120,8 +120,8 @@ int qla4xxx_init_rings(struct scsi_qla_host *ha)
* the interrupt_handler to think there are responses to be
* processed when there aren't.
*/
- ha->shadow_regs->req_q_out = __constant_cpu_to_le32(0);
- ha->shadow_regs->rsp_q_in = __constant_cpu_to_le32(0);
+ ha->shadow_regs->req_q_out = cpu_to_le32(0);
+ ha->shadow_regs->rsp_q_in = cpu_to_le32(0);
wmb();
writel(0, >reg->req_q_in);
diff --git a/drivers/scsi/qla4xxx/ql4_iocb.c b/drivers/scsi/qla4xxx/ql4_iocb.c
index a8df2d7eb069..dd25f917b5e6 100644
--- a/drivers/scsi/qla4xxx/ql4_iocb.c
+++ b/drivers/scsi/qla4xxx/ql4_iocb.c
@@ -161,7 +161,7 @@ static void qla4xxx_build_scsi_iocbs(struct srb *srb,
if (!scsi_bufflen(cmd) || cmd->sc_data_direction == DMA_NONE) {
/* No data being transferred */
- cmd_entry->ttlByteCnt = __constant_cpu_to_le32(0);
+ cmd_entry->ttlByteCnt = cpu_to_le32(0);
return;
}
diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
index bc8de7d402d5..02396da2acd4 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -646,8 +646,8 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Fill in the request and response queue information. */
init_fw_cb->rqq_consumer_idx = cpu_to_le16(ha->request_out);
init_fw_cb->compq_producer_idx = cpu_to_le16(ha->response_in);
- init_fw_cb->rqq_len = __constant_cpu_to_le16(REQUEST_QUEUE_DEPTH);
- init_fw_cb->compq_len = __constant_cpu_to_le16(RESPONSE_QUEUE_DEPTH);
+ init_fw_cb->rqq_len = cpu_to_le16(REQUEST_QUEUE_DEPTH);
+ init_fw_cb->compq_len = cpu_to_le16(RESPONSE_QUEUE_DEPTH);
init_fw_cb->rqq_addr_lo = cpu_to_le32(LSDW(ha->request_dma));
init_fw_cb->rqq_addr_hi = cpu_to_le32(MSDW(ha->request_dma));
init_fw_cb->compq_addr_lo = cpu_to_le32(LSDW(ha->response_dma));
@@ -657,20 +657,20 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Set up required options. */
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_SESSION_MODE |
+ cpu_to_le16(FWOPT_SESSION_MODE |
FWOPT_INITIATOR_MODE);
if (is_qla80XX(ha))
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_ENABLE_CRBDB);
+ cpu_to_le16(FWOPT_ENABLE_CRBDB);
- init_fw_cb->fw_options &= __constant_cpu_to_le16(~FWOPT_TARGET_MODE);
+ init_fw_cb->fw_options &= cpu_to_le16(~FWOPT_TARGET_MODE);
init_fw_cb->add_fw_options = 0;
init_fw_cb->add_fw_options |=
- __constant_cpu_to_le16(ADFWOPT_SERIALIZE_TASK_MGMT);
+ cpu_to_le16(ADFWOPT_SERIALIZE_TASK_MGMT);
init_fw_cb->add_fw_options |=
-
[PATCH] use cpu_to_le{16,32} instead of __constant_cpu_to_
Bart Van Assche wrote:
> Hi René,
>
> Whether __constant_cpu_to_le16() is used or cpu_to_le16(), the compiler
> generates exactly the same code. The name of the cpu_to_le16() function
> however
> is shorter. I recommend cpu_to_le16() because of its shorter name and because
> that's what other kernel drivers use.
So following your recommendation here is a RFC removing all the other
few remaining __constant_cpu_to_le{16,32} instances.
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index fbb80a043b4f..3de6bf94ccc0 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -3583,7 +3583,7 @@ static int __qlt_send_term_imm_notif(struct scsi_qla_host
*vha,
/* terminate */
nack->u.isp24.flags |=
- __constant_cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
+ cpu_to_le16(NOTIFY_ACK_FLAGS_TERMINATE);
nack->u.isp24.srr_rx_id = ntfy->u.isp24.srr_rx_id;
nack->u.isp24.status = ntfy->u.isp24.status;
diff --git a/drivers/scsi/qla2xxx/qla_tmpl.c b/drivers/scsi/qla2xxx/qla_tmpl.c
index 8dc82cfd38b2..f83b2f5fb490 100644
--- a/drivers/scsi/qla2xxx/qla_tmpl.c
+++ b/drivers/scsi/qla2xxx/qla_tmpl.c
@@ -912,7 +912,7 @@ qla27xx_driver_info(struct qla27xx_fwdt_template *tmp)
tmp->driver_info[0] = cpu_to_le32(
v[3] << 24 | v[2] << 16 | v[1] << 8 | v[0]);
tmp->driver_info[1] = cpu_to_le32(v[5] << 8 | v[4]);
- tmp->driver_info[2] = __constant_cpu_to_le32(0x12345678);
+ tmp->driver_info[2] = cpu_to_le32(0x12345678);
}
static void
diff --git a/drivers/scsi/qla4xxx/ql4_init.c b/drivers/scsi/qla4xxx/ql4_init.c
index 4a7ef971a387..cc4cd54eb7a8 100644
--- a/drivers/scsi/qla4xxx/ql4_init.c
+++ b/drivers/scsi/qla4xxx/ql4_init.c
@@ -120,8 +120,8 @@ int qla4xxx_init_rings(struct scsi_qla_host *ha)
* the interrupt_handler to think there are responses to be
* processed when there aren't.
*/
- ha->shadow_regs->req_q_out = __constant_cpu_to_le32(0);
- ha->shadow_regs->rsp_q_in = __constant_cpu_to_le32(0);
+ ha->shadow_regs->req_q_out = cpu_to_le32(0);
+ ha->shadow_regs->rsp_q_in = cpu_to_le32(0);
wmb();
writel(0, >reg->req_q_in);
diff --git a/drivers/scsi/qla4xxx/ql4_iocb.c b/drivers/scsi/qla4xxx/ql4_iocb.c
index a8df2d7eb069..dd25f917b5e6 100644
--- a/drivers/scsi/qla4xxx/ql4_iocb.c
+++ b/drivers/scsi/qla4xxx/ql4_iocb.c
@@ -161,7 +161,7 @@ static void qla4xxx_build_scsi_iocbs(struct srb *srb,
if (!scsi_bufflen(cmd) || cmd->sc_data_direction == DMA_NONE) {
/* No data being transferred */
- cmd_entry->ttlByteCnt = __constant_cpu_to_le32(0);
+ cmd_entry->ttlByteCnt = cpu_to_le32(0);
return;
}
diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
index bc8de7d402d5..02396da2acd4 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -646,8 +646,8 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Fill in the request and response queue information. */
init_fw_cb->rqq_consumer_idx = cpu_to_le16(ha->request_out);
init_fw_cb->compq_producer_idx = cpu_to_le16(ha->response_in);
- init_fw_cb->rqq_len = __constant_cpu_to_le16(REQUEST_QUEUE_DEPTH);
- init_fw_cb->compq_len = __constant_cpu_to_le16(RESPONSE_QUEUE_DEPTH);
+ init_fw_cb->rqq_len = cpu_to_le16(REQUEST_QUEUE_DEPTH);
+ init_fw_cb->compq_len = cpu_to_le16(RESPONSE_QUEUE_DEPTH);
init_fw_cb->rqq_addr_lo = cpu_to_le32(LSDW(ha->request_dma));
init_fw_cb->rqq_addr_hi = cpu_to_le32(MSDW(ha->request_dma));
init_fw_cb->compq_addr_lo = cpu_to_le32(LSDW(ha->response_dma));
@@ -657,20 +657,20 @@ int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha)
/* Set up required options. */
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_SESSION_MODE |
+ cpu_to_le16(FWOPT_SESSION_MODE |
FWOPT_INITIATOR_MODE);
if (is_qla80XX(ha))
init_fw_cb->fw_options |=
- __constant_cpu_to_le16(FWOPT_ENABLE_CRBDB);
+ cpu_to_le16(FWOPT_ENABLE_CRBDB);
- init_fw_cb->fw_options &= __constant_cpu_to_le16(~FWOPT_TARGET_MODE);
+ init_fw_cb->fw_options &= cpu_to_le16(~FWOPT_TARGET_MODE);
init_fw_cb->add_fw_options = 0;
init_fw_cb->add_fw_options |=
- __constant_cpu_to_le16(ADFWOPT_SERIALIZE_TASK_MGMT);
+ cpu_to_le16(ADFWOPT_SERIALIZE_TASK_MGMT);
init_fw_cb->add_fw_options |=
- __constant_cpu_to_le16(ADFWOPT_AUTOCONN_DISABLE);
+ cpu_to_le16(ADFWOPT_AUTOCONN_DISABLE);
if (qla4xxx_set_ifcb(ha, _cmd[0], _sts[0], init_fw_cb_dma)
[PATCH v2] zstd compressed firmware loading
Now with zstd compressed kernel & initrd upstream, we would rather
compress everything with one type of compressor, so I added support
for zstd compressed firmware loading, too.
Tested on x86-64, sparc64 and mips64.
Signed-off-by: René Rebe
diff --git a/drivers/base/firmware_loader/Kconfig
b/drivers/base/firmware_loader/Kconfig
index 5b24f3959255..30d440bec257 100644
--- a/drivers/base/firmware_loader/Kconfig
+++ b/drivers/base/firmware_loader/Kconfig
@@ -169,6 +169,16 @@ config FW_LOADER_COMPRESS
be compressed with either none or crc32 integrity check type (pass
"-C crc32" option to xz command).
+config FW_LOADER_COMPRESS_ZSTD
+ bool "Enable Zstd compressed firmware support"
+ select FW_LOADER_PAGED_BUF
+ select ZSTD_DECOMPRESS
+ help
+ This option enables the support for loading Zstd compressed firmware
+ files. The caller of firmware API receives the decompressed file
+ content. The compressed file is loaded as a fallback, only after
+ loading the raw file failed at first.
+
config FW_CACHE
bool "Enable firmware caching during suspend"
depends on PM_SLEEP
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 9da0c9d5f538..cd3bd6f9a64b 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -33,7 +33,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -435,6 +437,185 @@ static int fw_decompress_xz(struct device *dev, struct
fw_priv *fw_priv,
}
#endif /* CONFIG_FW_LOADER_COMPRESS */
+/*
+ * Zstd-compressed firmware support
+ */
+#ifdef CONFIG_FW_LOADER_COMPRESS_ZSTD
+/* show an error and return the standard error code */
+static int handle_zstd_error(size_t ret)
+{
+ const int err = ZSTD_getErrorCode(ret);
+
+ if (!ZSTD_isError(ret))
+ return 0;
+
+ switch (err) {
+ case ZSTD_error_memory_allocation:
+ printk("ZSTD decompressor ran out of memory");
+ break;
+ case ZSTD_error_prefix_unknown:
+ printk("Input is not in the ZSTD format (wrong magic bytes)");
+ break;
+ case ZSTD_error_dstSize_tooSmall:
+ case ZSTD_error_corruption_detected:
+ case ZSTD_error_checksum_wrong:
+ printk("ZSTD-compressed data is corrupt");
+ break;
+ default:
+ printk("ZSTD-compressed data is probably corrupt");
+ break;
+ }
+ return -1;
+}
+
+/* single-shot decompression onto the pre-allocated buffer */
+static int fw_decompress_zstd_single(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+ const size_t wksp_size = ZSTD_DCtxWorkspaceBound();
+ void *wksp = large_malloc(wksp_size);
+ ZSTD_DCtx *dctx = ZSTD_initDCtx(wksp, wksp_size);
+ int err;
+ size_t ret;
+
+ if (dctx == NULL) {
+ dev_warn(dev, "Out of memory while allocating ZSTD_DCtx");
+ err = -1;
+ goto out;
+ }
+ /* Find out how large the frame actually is, there may be junk at
+* the end of the frame that ZSTD_decompressDCtx() can't handle.
+*/
+ ret = ZSTD_findFrameCompressedSize(in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+ in_size = (long)ret;
+
+ ret = ZSTD_decompressDCtx(dctx, fw_priv->data, fw_priv->allocated_size,
in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+
+ fw_priv->size = ret;
+
+out:
+ if (wksp != NULL)
+ large_free(wksp);
+ return err;
+}
+
+/* decompression on paged buffer and map it */
+static int fw_decompress_zstd_pages(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+ ZSTD_inBuffer in;
+ ZSTD_outBuffer out;
+ ZSTD_frameParams params;
+ void *wksp = NULL;
+ size_t wksp_size;
+ ZSTD_DStream *dstream;
+ int err = 0;
+ size_t ret;
+
+ struct page *page;
+
+ fw_priv->is_paged_buf = true;
+ fw_priv->size = 0;
+
+ /* Set the first non-empty input buffer. */
+ in.src = in_buffer;
+ in.pos = 0;
+ in.size = in_size;
+
+ /*
+* We need to know the window size to allocate the ZSTD_DStream.
+* Since we are streaming, we need to allocate a buffer for the sliding
+* window. The window size varies from 1 KB to ZSTD_WINDOWSIZE_MAX
+* (8 MB), so it is important to use the actual value so as not to
+* waste memory when it is smaller.
+*/
+ ret = ZSTD_getFrameParams(, in.src, in.size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+ if (ret != 0) {
+
[PATCH] zstd compressed firmware loading
Now with zstd compressed kernel & initrd upstream, we would rather
compress everything with one type of compressor, so I added support
for zstd compressed firmware loading, too.
Tested on x86-64, sparc64 and mips64.
Signed-off-by: René Rebe
diff --git a/drivers/base/firmware_loader/Kconfig
b/drivers/base/firmware_loader/Kconfig
index 5b24f3959255..30d440bec257 100644
--- a/drivers/base/firmware_loader/Kconfig
+++ b/drivers/base/firmware_loader/Kconfig
@@ -169,6 +169,16 @@ config FW_LOADER_COMPRESS
be compressed with either none or crc32 integrity check type (pass
"-C crc32" option to xz command).
+config FW_LOADER_COMPRESS_ZSTD
+ bool "Enable Zstd compressed firmware support"
+ select FW_LOADER_PAGED_BUF
+ select ZSTD_DECOMPRESS
+ help
+ This option enables the support for loading Zstd compressed firmware
+ files. The caller of firmware API receives the decompressed file
+ content. The compressed file is loaded as a fallback, only after
+ loading the raw file failed at first.
+
config FW_CACHE
bool "Enable firmware caching during suspend"
depends on PM_SLEEP
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 9da0c9d5f538..5deb73dbe81e 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -33,7 +33,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -435,6 +437,140 @@ static int fw_decompress_xz(struct device *dev, struct
fw_priv *fw_priv,
}
#endif /* CONFIG_FW_LOADER_COMPRESS */
+/*
+ * Zstd-compressed firmware support
+ */
+#ifdef CONFIG_FW_LOADER_COMPRESS_ZSTD
+/* show an error and return the standard error code */
+static int handle_zstd_error(size_t ret)
+{
+ const int err = ZSTD_getErrorCode(ret);
+
+ if (!ZSTD_isError(ret))
+ return 0;
+
+ switch (err) {
+ case ZSTD_error_memory_allocation:
+ printk("ZSTD decompressor ran out of memory");
+ break;
+ case ZSTD_error_prefix_unknown:
+ printk("Input is not in the ZSTD format (wrong magic bytes)");
+ break;
+ case ZSTD_error_dstSize_tooSmall:
+ case ZSTD_error_corruption_detected:
+ case ZSTD_error_checksum_wrong:
+ printk("ZSTD-compressed data is corrupt");
+ break;
+ default:
+ printk("ZSTD-compressed data is probably corrupt");
+ break;
+ }
+ return -1;
+}
+
+/* single-shot decompression onto the pre-allocated buffer */
+static int fw_decompress_zstd_single(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+ const size_t wksp_size = ZSTD_DCtxWorkspaceBound();
+ void *wksp = large_malloc(wksp_size);
+ ZSTD_DCtx *dctx = ZSTD_initDCtx(wksp, wksp_size);
+ int err;
+ size_t ret;
+
+ printk("zstd_single\n");
+
+ if (dctx == NULL) {
+ dev_warn(dev, "Out of memory while allocating ZSTD_DCtx");
+ err = -1;
+ goto out;
+ }
+ /* Find out how large the frame actually is, there may be junk at
+* the end of the frame that ZSTD_decompressDCtx() can't handle.
+*/
+ ret = ZSTD_findFrameCompressedSize(in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+ in_size = (long)ret;
+
+ ret = ZSTD_decompressDCtx(dctx, fw_priv->data, fw_priv->allocated_size,
in_buffer, in_size);
+ err = handle_zstd_error(ret);
+ if (err)
+ goto out;
+
+ fw_priv->size = ret;
+
+out:
+ if (wksp != NULL)
+ large_free(wksp);
+ return err;
+}
+
+/* decompression on paged buffer and map it */
+static int fw_decompress_zstd_pages(struct device *dev, struct fw_priv
*fw_priv,
+ size_t in_size, const void *in_buffer)
+{
+#if 0
+ struct zstd_dec *zstd_dec;
+ struct zstd_buf zstd_buf;
+ enum zstd_ret zstd_ret;
+ struct page *page;
+ int err = 0;
+
+ printk("zstd_pages\n");
+
+ zstd_dec = zstd_dec_init(ZSTD_DYNALLOC, (u32)-1);
+ if (!zstd_dec)
+ return -ENOMEM;
+
+ zstd_buf.in_size = in_size;
+ zstd_buf.in = in_buffer;
+ zstd_buf.in_pos = 0;
+
+ fw_priv->is_paged_buf = true;
+ fw_priv->size = 0;
+ do {
+ if (fw_grow_paged_buf(fw_priv, fw_priv->nr_pages + 1)) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ /* decompress onto the new allocated page */
+ page = fw_priv->pages[fw_priv->nr_pages - 1];
+ zstd_buf.out = kmap(page);
+ zstd_buf.out_pos = 0;
+ zstd_buf.out_size = PAGE_SIZE;
+ zstd_ret = zstd_dec_run(zstd_dec,
Re: [PATCH] applesmc: add sysfs file to report OSK
On 10.12.2012, at 22:24, Alexander Graf wrote: > On 10.12.2012, at 21:43, Rene Rebe wrote: > >> On 10.12.2012, at 21:19, Alexander Graf wrote: >>> >>> On 10.12.2012, at 20:54, Henrik Rydberg wrote: >>> >>>> Hi Guenter, >>>> >>>>> On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote: >>>>>> The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not >>>>>> reported in the key count and index by default. These keys are used by >>>>>> the OS X boot sequence, and normally don't matter when running Linux. >>>>>> >>>>>> This patch creates a sysfs entry which reports the value of these keys >>>>>> as an ASCII string, to help emulators (such as QEMU) load OS X when >>>>>> running on genuine Apple hardware. >>>>>> >>>>>> Signed-off-by: Gabriel L. Somlo >>>>>> --- >>>>>> >>>>>> For extra context: To boot OS X as a guest, QEMU must (among others) >>>>>> emulate the AppleSMC. To boot successfully, OS X insists on querying >>>>>> the (emulated) SMC for the value of OSK0 and OSK1. Currently, these >>>>>> values must be supplied on the QEMU command line as >>>>>> >>>>>> -device applesmc,osk="...concatenated values of OSK0 and OSK1..." >>>>>> >>>>>> With the availability of /sys/devices/platform/applesmc.768/osk, the >>>>>> emulated QEMU AppleSMC could acquire this string directly from the >>>>>> (Apple-manufactured) host machine. >>>>> Hmm ... this is a non-hwmon attribute which doesn't really belong into >>>>> hwmon >>>>> in the first place ... like several other attributes in the same driver. >>>>> >>>>> So I'll leave it up to the maintainer to decide if we should accept it. >>>>> Henrik ? >>>> >>>> Indeed, the reaons against this patch are too many. I was just about >>>> to reply with the below: >>>> >>>> Gabriel, >>>> >>>> The OSK string seems constant accross machines, which renders the >>>> patch rather pointless, no? And even if the OSK differs between a >>>> couple of machines, the emulator could easily handle it gracefully. >>> >>> The point is that the return value of the OSK is a copyrighted string, we >>> can not include in any other layer. The only way to make this legally savvy >>> is to read the key from the host. >>> >>>> >>>> There are also some technical issues with the patch below, to keep in >>>> mind for future submissions. >>> >>> Sigh - most of the comments below go back to earlier review from me. He >>> basically had a version almost exactly like what you're asking him to do >>> :). Funny how code style taste differs. >> >> And this is exactly the reason why I'm less and less motivated to waste my >> lifetime with upstream work ... > > It's nit that bad really. Gabriel can just send his earlier version again > with the ret variable name changed and then it shouldn't be an issue to get > it in. > > Reading the key really is an important bit in creating a legally safe and > easy method to virtualize Mac OS X on Linux. Just believe us on this one :). Sure, you do not need to convince me about that ;-) -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de -- 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] applesmc: add sysfs file to report OSK
On 10.12.2012, at 21:19, Alexander Graf wrote:
>
> On 10.12.2012, at 20:54, Henrik Rydberg wrote:
>
>> Hi Guenter,
>>
>>> On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote:
The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not
reported in the key count and index by default. These keys are used by
the OS X boot sequence, and normally don't matter when running Linux.
This patch creates a sysfs entry which reports the value of these keys
as an ASCII string, to help emulators (such as QEMU) load OS X when
running on genuine Apple hardware.
Signed-off-by: Gabriel L. Somlo
---
For extra context: To boot OS X as a guest, QEMU must (among others)
emulate the AppleSMC. To boot successfully, OS X insists on querying
the (emulated) SMC for the value of OSK0 and OSK1. Currently, these
values must be supplied on the QEMU command line as
-device applesmc,osk="...concatenated values of OSK0 and OSK1..."
With the availability of /sys/devices/platform/applesmc.768/osk, the
emulated QEMU AppleSMC could acquire this string directly from the
(Apple-manufactured) host machine.
>>> Hmm ... this is a non-hwmon attribute which doesn't really belong into hwmon
>>> in the first place ... like several other attributes in the same driver.
>>>
>>> So I'll leave it up to the maintainer to decide if we should accept it.
>>> Henrik ?
>>
>> Indeed, the reaons against this patch are too many. I was just about
>> to reply with the below:
>>
>> Gabriel,
>>
>> The OSK string seems constant accross machines, which renders the
>> patch rather pointless, no? And even if the OSK differs between a
>> couple of machines, the emulator could easily handle it gracefully.
>
> The point is that the return value of the OSK is a copyrighted string, we can
> not include in any other layer. The only way to make this legally savvy is to
> read the key from the host.
>
>>
>> There are also some technical issues with the patch below, to keep in
>> mind for future submissions.
>
> Sigh - most of the comments below go back to earlier review from me. He
> basically had a version almost exactly like what you're asking him to do :).
> Funny how code style taste differs.
And this is exactly the reason why I'm less and less motivated to waste my
lifetime with upstream work ...
> Alex
>
>>
>>> drivers/hwmon/applesmc.c | 18 ++
>>> 1 files changed, 18 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
>>> index b41baff..0c7cc71 100644
>>> --- a/drivers/hwmon/applesmc.c
>>> +++ b/drivers/hwmon/applesmc.c
>>> @@ -1013,6 +1013,23 @@ static ssize_t applesmc_key_at_index_store(struct
>>> device *dev,
>>>return count;
>>> }
>>>
>>> +static ssize_t applesmc_osk_show(struct device *dev,
>>> +struct device_attribute *attr, char *sysfsbuf)
>>> +{
>>> +int fail;
>>
>> All other functions use 'ret' here...
>>
>>> +
>>> +mutex_lock();
>>> +fail = read_smc(APPLESMC_READ_CMD, "OSK0", sysfsbuf, 32) ||
>>> + read_smc(APPLESMC_READ_CMD, "OSK1", sysfsbuf + 32, 32);
>>
>> The read function should propagate error messages, i.e., keep the
>> return values here. And please read to buffers instead.
>>
>>> +mutex_unlock();
>>> +if (fail)
>>> +return -1;
>>
>> Return error here.
>>
>>> +
>>> +sysfsbuf[64] = '\n';
>>> +sysfsbuf[65] = '\0';
>>> +return 65;
>>
>> A snprintf here, please.
>>
>>> +}
>>> +
>>> static struct led_classdev applesmc_backlight = {
>>>.name= "smc::kbd_backlight",
>>>.default_trigger= "nand-disk",
>>> @@ -1027,6 +1044,7 @@ static struct applesmc_node_group info_group[] = {
>>>{ "key_at_index_type", applesmc_key_at_index_type_show },
>>>{ "key_at_index_data_length", applesmc_key_at_index_data_length_show },
>>>{ "key_at_index_data", applesmc_key_at_index_read_show },
>>> +{ "osk", applesmc_osk_show },
>>
>> Unfortunately this is not a good place to put random things going
>> forward.
>>
>>>{ }
>>> };
>>>
>>> --
>>> 1.7.7.6
>>
>> Given the above issues together with the weak rationale for the patch
>> in the first place, this patch will not be applied.
>>
>> Thanks.
>> Henrik
>
--
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] applesmc: add sysfs file to report OSK
On 10.12.2012, at 21:19, Alexander Graf ag...@suse.de wrote:
On 10.12.2012, at 20:54, Henrik Rydberg wrote:
Hi Guenter,
On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote:
The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not
reported in the key count and index by default. These keys are used by
the OS X boot sequence, and normally don't matter when running Linux.
This patch creates a sysfs entry which reports the value of these keys
as an ASCII string, to help emulators (such as QEMU) load OS X when
running on genuine Apple hardware.
Signed-off-by: Gabriel L. Somlo so...@cmu.edu
---
For extra context: To boot OS X as a guest, QEMU must (among others)
emulate the AppleSMC. To boot successfully, OS X insists on querying
the (emulated) SMC for the value of OSK0 and OSK1. Currently, these
values must be supplied on the QEMU command line as
-device applesmc,osk=...concatenated values of OSK0 and OSK1...
With the availability of /sys/devices/platform/applesmc.768/osk, the
emulated QEMU AppleSMC could acquire this string directly from the
(Apple-manufactured) host machine.
Hmm ... this is a non-hwmon attribute which doesn't really belong into hwmon
in the first place ... like several other attributes in the same driver.
So I'll leave it up to the maintainer to decide if we should accept it.
Henrik ?
Indeed, the reaons against this patch are too many. I was just about
to reply with the below:
Gabriel,
The OSK string seems constant accross machines, which renders the
patch rather pointless, no? And even if the OSK differs between a
couple of machines, the emulator could easily handle it gracefully.
The point is that the return value of the OSK is a copyrighted string, we can
not include in any other layer. The only way to make this legally savvy is to
read the key from the host.
There are also some technical issues with the patch below, to keep in
mind for future submissions.
Sigh - most of the comments below go back to earlier review from me. He
basically had a version almost exactly like what you're asking him to do :).
Funny how code style taste differs.
And this is exactly the reason why I'm less and less motivated to waste my
lifetime with upstream work ...
Alex
drivers/hwmon/applesmc.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index b41baff..0c7cc71 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -1013,6 +1013,23 @@ static ssize_t applesmc_key_at_index_store(struct
device *dev,
return count;
}
+static ssize_t applesmc_osk_show(struct device *dev,
+struct device_attribute *attr, char *sysfsbuf)
+{
+int fail;
All other functions use 'ret' here...
+
+mutex_lock(smcreg.mutex);
+fail = read_smc(APPLESMC_READ_CMD, OSK0, sysfsbuf, 32) ||
+ read_smc(APPLESMC_READ_CMD, OSK1, sysfsbuf + 32, 32);
The read function should propagate error messages, i.e., keep the
return values here. And please read to buffers instead.
+mutex_unlock(smcreg.mutex);
+if (fail)
+return -1;
Return error here.
+
+sysfsbuf[64] = '\n';
+sysfsbuf[65] = '\0';
+return 65;
A snprintf here, please.
+}
+
static struct led_classdev applesmc_backlight = {
.name= smc::kbd_backlight,
.default_trigger= nand-disk,
@@ -1027,6 +1044,7 @@ static struct applesmc_node_group info_group[] = {
{ key_at_index_type, applesmc_key_at_index_type_show },
{ key_at_index_data_length, applesmc_key_at_index_data_length_show },
{ key_at_index_data, applesmc_key_at_index_read_show },
+{ osk, applesmc_osk_show },
Unfortunately this is not a good place to put random things going
forward.
{ }
};
--
1.7.7.6
Given the above issues together with the weak rationale for the patch
in the first place, this patch will not be applied.
Thanks.
Henrik
--
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] applesmc: add sysfs file to report OSK
On 10.12.2012, at 22:24, Alexander Graf wrote: On 10.12.2012, at 21:43, Rene Rebe r...@exactcode.com wrote: On 10.12.2012, at 21:19, Alexander Graf ag...@suse.de wrote: On 10.12.2012, at 20:54, Henrik Rydberg wrote: Hi Guenter, On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote: The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not reported in the key count and index by default. These keys are used by the OS X boot sequence, and normally don't matter when running Linux. This patch creates a sysfs entry which reports the value of these keys as an ASCII string, to help emulators (such as QEMU) load OS X when running on genuine Apple hardware. Signed-off-by: Gabriel L. Somlo so...@cmu.edu --- For extra context: To boot OS X as a guest, QEMU must (among others) emulate the AppleSMC. To boot successfully, OS X insists on querying the (emulated) SMC for the value of OSK0 and OSK1. Currently, these values must be supplied on the QEMU command line as -device applesmc,osk=...concatenated values of OSK0 and OSK1... With the availability of /sys/devices/platform/applesmc.768/osk, the emulated QEMU AppleSMC could acquire this string directly from the (Apple-manufactured) host machine. Hmm ... this is a non-hwmon attribute which doesn't really belong into hwmon in the first place ... like several other attributes in the same driver. So I'll leave it up to the maintainer to decide if we should accept it. Henrik ? Indeed, the reaons against this patch are too many. I was just about to reply with the below: Gabriel, The OSK string seems constant accross machines, which renders the patch rather pointless, no? And even if the OSK differs between a couple of machines, the emulator could easily handle it gracefully. The point is that the return value of the OSK is a copyrighted string, we can not include in any other layer. The only way to make this legally savvy is to read the key from the host. There are also some technical issues with the patch below, to keep in mind for future submissions. Sigh - most of the comments below go back to earlier review from me. He basically had a version almost exactly like what you're asking him to do :). Funny how code style taste differs. And this is exactly the reason why I'm less and less motivated to waste my lifetime with upstream work ... It's nit that bad really. Gabriel can just send his earlier version again with the ret variable name changed and then it shouldn't be an issue to get it in. Reading the key really is an important bit in creating a legally safe and easy method to virtualize Mac OS X on Linux. Just believe us on this one :). Sure, you do not need to convince me about that ;-) -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de -- 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: Linux 2.6.16.47-rc1
Hi Adrian, first front off: thanks for the phantastic 2.6.16 stable maintenance. Currently I wonder if you have any plan for doing the 2.6.16 review for let's say "years", or if you "soon" pick some new series such as 2.6.20 or so for long-term maintenance. I ask because I wonder if I should wait a bit with a production 2.6.17 kernel line I maintain right now for just one installation base, if you choose some 2.6.2x I can hop on, or whether it is wiser to just downdate this series and profit from the "long-term" 2.6.16 maintenance that is no fun to replicate for 2.6.17 just for this one install pool ... Thanks in advance, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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.16.47-rc1
Hi Adrian, first front off: thanks for the phantastic 2.6.16 stable maintenance. Currently I wonder if you have any plan for doing the 2.6.16 review for let's say years, or if you soon pick some new series such as 2.6.20 or so for long-term maintenance. I ask because I wonder if I should wait a bit with a production 2.6.17 kernel line I maintain right now for just one installation base, if you choose some 2.6.2x I can hop on, or whether it is wiser to just downdate this series and profit from the long-term 2.6.16 maintenance that is no fun to replicate for 2.6.17 just for this one install pool ... Thanks in advance, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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.21-rc5: Thinkpad X60 gets critical thermal shutdowns
On Sunday 01 April 2007 20:57:57 Kyle Moffett wrote: > On Mar 31, 2007, at 02:36:08, Jeremy Fitzhardinge wrote: > > When I run 2.6.21-rc5 + Andi's x86 patches + paravirt_ops patches, > > I've been getting my machine shut down with critical thermal > > shutdown messages: > > > > Mar 30 23:19:03 localhost kernel: ACPI: Critical trip point > > Mar 30 23:19:03 localhost kernel: Critical temperature reached (128 > > C), shutting down. > > Mar 30 23:19:03 localhost kernel: Critical temperature reached (128 > > C), shutting down. > > Mar 30 23:19:03 localhost shutdown[19417]: shutting down for system > > halt > > > > and the machine does feel pretty hot. Interestingly, when the > > machine reboots, the fan spins up to a noticeably higher speed, so > > it seems that maybe something is getting fan speed control wrong. > > Well, 128C is more than hot enough to boil water and well above the > thermal tolerances of most CPUs, so I would imagine that were your > CPU actually that hot it wouldn't be capable of printing the > "Critical temperature reached" messages, let alone properly rebooting. IIRC a MSI Megabook S270 (I formerly owned) BIOS notifies this "Critical temperature reached (128C)" when the battery run empty when the OS did no action due to battery low indications. I guess the BIOS people thought this is a good last resort to let the OS really shutdown before the box just turns off. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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.21-rc5: Thinkpad X60 gets critical thermal shutdowns
On Sunday 01 April 2007 20:57:57 Kyle Moffett wrote: On Mar 31, 2007, at 02:36:08, Jeremy Fitzhardinge wrote: When I run 2.6.21-rc5 + Andi's x86 patches + paravirt_ops patches, I've been getting my machine shut down with critical thermal shutdown messages: Mar 30 23:19:03 localhost kernel: ACPI: Critical trip point Mar 30 23:19:03 localhost kernel: Critical temperature reached (128 C), shutting down. Mar 30 23:19:03 localhost kernel: Critical temperature reached (128 C), shutting down. Mar 30 23:19:03 localhost shutdown[19417]: shutting down for system halt and the machine does feel pretty hot. Interestingly, when the machine reboots, the fan spins up to a noticeably higher speed, so it seems that maybe something is getting fan speed control wrong. Well, 128C is more than hot enough to boil water and well above the thermal tolerances of most CPUs, so I would imagine that were your CPU actually that hot it wouldn't be capable of printing the Critical temperature reached messages, let alone properly rebooting. IIRC a MSI Megabook S270 (I formerly owned) BIOS notifies this Critical temperature reached (128C) when the battery run empty when the OS did no action due to battery low indications. I guess the BIOS people thought this is a good last resort to let the OS really shutdown before the box just turns off. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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: hdparm for lib_pata
On Saturday 03 February 2007 09:55:52 Patrick Ale wrote: > Hi, > > The problem is even worse, the drive falls back to PIO mode and there > is no way I can get it back to dma mode (like I could by using > hdparm). The only thing i can do is reboot the machine so it will see > the drive is UDMA capable. > > If there is some beta/gamma software around or something you'd like to > have tested, you can mail me directly, my machine is your private > prostitute at the moment, it's not like i have something important to > do with the machine anyway (not related to this problem):) The libata expoted disls have a SCSI ioctl interface, sdparm should work on those. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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: hdparm for lib_pata
On Saturday 03 February 2007 09:55:52 Patrick Ale wrote: Hi, The problem is even worse, the drive falls back to PIO mode and there is no way I can get it back to dma mode (like I could by using hdparm). The only thing i can do is reboot the machine so it will see the drive is UDMA capable. If there is some beta/gamma software around or something you'd like to have tested, you can mail me directly, my machine is your private prostitute at the moment, it's not like i have something important to do with the machine anyway (not related to this problem):) The libata expoted disls have a SCSI ioctl interface, sdparm should work on those. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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] Open Firmware device tree virtual filesystem
Hi, On Sunday 31 December 2006 11:49, David Miller wrote: > From: David Kahn <[EMAIL PROTECTED]> > Date: Sun, 31 Dec 2006 02:11:53 -0800 > > > All we've done is created a trivial implementation for exporting > > the device tree to userland that isn't burdened by the powerpc > > and sparc legacy code that's in there now. > > So now we'll have _3_ different implementations of exporting > the OFW device tree via procfs. Your's, the proc_devtree > of powerpc, and sparc's /proc/openprom > > That doesn't make any sense to me, having 3 ways of doing the same > exact thing and making no attempt to share code at all. > > If you want to do something new that consolidates everything, with the > goal of deprecating the existing stuff, that's great! But with they > way you're doing this, all the sparc and powerpc implementations > really can't take advantage of it. > > Am I the only person who sees something very wrong with this? Nope you aren't, ACK to a unified user-space export from my side as well. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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] Open Firmware device tree virtual filesystem
Hi, On Sunday 31 December 2006 11:49, David Miller wrote: From: David Kahn [EMAIL PROTECTED] Date: Sun, 31 Dec 2006 02:11:53 -0800 All we've done is created a trivial implementation for exporting the device tree to userland that isn't burdened by the powerpc and sparc legacy code that's in there now. So now we'll have _3_ different implementations of exporting the OFW device tree via procfs. Your's, the proc_devtree of powerpc, and sparc's /proc/openprom That doesn't make any sense to me, having 3 ways of doing the same exact thing and making no attempt to share code at all. If you want to do something new that consolidates everything, with the goal of deprecating the existing stuff, that's great! But with they way you're doing this, all the sparc and powerpc implementations really can't take advantage of it. Am I the only person who sees something very wrong with this? Nope you aren't, ACK to a unified user-space export from my side as well. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - 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: [Crosspost] GNU/Linux userland?
Hi, [EMAIL PROTECTED] wrote: On 04/13/05 14:40:31, Oliver Korpilla wrote: You might also look at www.openembedded.org It has support for cross compiling, and with one command can build an entire userland. Not sure if it is exactly a fit for what you want to do, but it seems very close. Thanks, this sounds great, and together with the directions I got about Gentoo and Heretix/Rubyx seems to precisely match my request. The T2 System Developmen Environment (http://www.t2-project.org/) might also be interesting for you. Greetings, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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: [Crosspost] GNU/Linux userland?
Hi, [EMAIL PROTECTED] wrote: On 04/13/05 14:40:31, Oliver Korpilla wrote: You might also look at www.openembedded.org It has support for cross compiling, and with one command can build an entire userland. Not sure if it is exactly a fit for what you want to do, but it seems very close. Thanks, this sounds great, and together with the directions I got about Gentoo and Heretix/Rubyx seems to precisely match my request. The T2 System Developmen Environment (http://www.t2-project.org/) might also be interesting for you. Greetings, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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: Atheros wi-fi card drivers (?)
Hi, Raphael Jacquot wrote: as your name appears european, there are no software patents (yet ?) so you should be able to release that code as required for interoperability The release of that source does not depend on software patents (which seem to be acked yesterday for europe ... ;-() However with software patents a company could sue you for violating a patent wheter you wrote the code or reverse engeneered it. E.g. for a "transmitting information without cables, e.g. binary encoded via a radio signal modulated this and that way. claims: any implementation that transmit information without cables (including birds in the air) ... and so on the usual patent fluff ..." patent. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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: Atheros wi-fi card drivers (?)
Hi, Raphael Jacquot wrote: as your name appears european, there are no software patents (yet ?) so you should be able to release that code as required for interoperability The release of that source does not depend on software patents (which seem to be acked yesterday for europe ... ;-() However with software patents a company could sue you for violating a patent wheter you wrote the code or reverse engeneered it. E.g. for a transmitting information without cables, e.g. binary encoded via a radio signal modulated this and that way. claims: any implementation that transmit information without cables (including birds in the air) ... and so on the usual patent fluff ... patent. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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/
The never ending hpusbscsi storry
Hi, Matthias Kindtner wrote: scanimage -L scanimage: symbol lookup error: /usr/lib/sane/libsane-avision.so.1: undefined symbol: sanei_usb_set_timeout With the latest backed you need to update include/sane/sanei_usb.h and sanei/sanei_usb.c from my SVN repository (will go into SANE CVS in the next day). device `avision:/dev/sg0' is a Minolta Dimage Scan Dual II film scanner Don't ever use hpusbscsi. I though I already told all vedors it is that broken that they should never ever ship it. It is the first thing that will be removed in Linux 2.7. If it would be me it would be removed from _all kernels right now_ ... Mar 4 23:40:51 runningdug scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0 Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device A simple plug-out plug-in of the usb solve the problem and I can start once again ... hpusbscsi as it lifes ... I hope there are all messages you need in the mail, otherwise I send it to. You have any Idea for me?? find /lib/modules -name hpusbscsi.*o | xargs rm -fv (or so - assuming no spaces in filenames ...) and build the backend with the updated sanei_usb* files. Or alternatively use a avision backed that is two weeks old (man svn) which does not need the updated sanei functionality. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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/
The never ending hpusbscsi storry
Hi, Matthias Kindtner wrote: scanimage -L scanimage: symbol lookup error: /usr/lib/sane/libsane-avision.so.1: undefined symbol: sanei_usb_set_timeout With the latest backed you need to update include/sane/sanei_usb.h and sanei/sanei_usb.c from my SVN repository (will go into SANE CVS in the next day). device `avision:/dev/sg0' is a Minolta Dimage Scan Dual II film scanner Don't ever use hpusbscsi. I though I already told all vedors it is that broken that they should never ever ship it. It is the first thing that will be removed in Linux 2.7. If it would be me it would be removed from _all kernels right now_ ... Mar 4 23:40:51 runningdug scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0 Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device Mar 4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device A simple plug-out plug-in of the usb solve the problem and I can start once again ... hpusbscsi as it lifes ... I hope there are all messages you need in the mail, otherwise I send it to. You have any Idea for me?? find /lib/modules -name hpusbscsi.*o | xargs rm -fv (or so - assuming no spaces in filenames ...) and build the backend with the updated sanei_usb* files. Or alternatively use a avision backed that is two weeks old (man svn) which does not need the updated sanei functionality. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 - 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
Greg KH wrote:
Except the patch is malformed, and even after light editing, does not
apply to the 2.6.11 kernel :(
Sorry - to match linux-kernel style I pasted it from gvim into
thunderbird to make kernel folks happy. Here you find the patch as it
applies to 2.6.11 attached.
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Tiny compile fix for the raid6 PowerPC/Altivec code.
- Rene Rebe <[EMAIL PROTECTED]>
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02 16:45:22.424152560
+0100
@@ -108,7 +108,7 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
- return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+ return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
}
#endif
[PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100
@@ -108,7 +108,7 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
- return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+ return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
}
#endif
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
-
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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
Greg KH wrote:
Except the patch is malformed, and even after light editing, does not
apply to the 2.6.11 kernel :(
Sorry - to match linux-kernel style I pasted it from gvim into
thunderbird to make kernel folks happy. Here you find the patch as it
applies to 2.6.11 attached.
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Tiny compile fix for the raid6 PowerPC/Altivec code.
- Rene Rebe [EMAIL PROTECTED]
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02 16:45:22.424152560
+0100
@@ -108,7 +108,7 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
- return cur_cpu_spec-cpu_features CPU_FTR_ALTIVEC;
+ return cur_cpu_spec[0]-cpu_features CPU_FTR_ALTIVEC;
}
#endif
[PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100
@@ -108,7 +108,7 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
- return cur_cpu_spec-cpu_features CPU_FTR_ALTIVEC;
+ return cur_cpu_spec[0]-cpu_features CPU_FTR_ALTIVEC;
}
#endif
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
-
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 IDE UDMA Mode x -> CRC-ERRORs (2.4.0-testxx)
Hi! Thanks for the fast reply - but I can't follow. What is the _tuning aspect_ and how is it modified? Andre Hedrick <[EMAIL PROTECTED]> wrote: > > There is a problem that it does not downgrade the IO if all you have is > iCRC errors. The threshold is 10 events without other errors and it > should skip you from ATA-66 to ATA-44. If you did not enable the tuning > aspect of the chipset then do so now. > > Regards, > > Andre Hedrick > CTO Timpanogas Research Group > EVP Linux Development, TRG > Linux ATA Development > k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE UDMA Mode x - CRC-ERRORs (2.4.0-testxx)
Hi! Thanks for the fast reply - but I can't follow. What is the _tuning aspect_ and how is it modified? Andre Hedrick [EMAIL PROTECTED] wrote: There is a problem that it does not downgrade the IO if all you have is iCRC errors. The threshold is 10 events without other errors and it should skip you from ATA-66 to ATA-44. If you did not enable the tuning aspect of the chipset then do so now. Regards, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA IDE UDMA Mode x -> CRC-ERRORs (2.4.0-testxx)
Hi!
I have an Asus K7M motherboard with an AMD Irongate and a VIA VT82C686
connected to an IBM-DPTA-372050 and/or IBM-DTLA-307030.
I ever had IDE-DMA problems since I got the board in the beginning of
this year.
Until Kernel 2.4.0-test7 (or test6 or 8?) it was not possible to use a
ATA-66 cable and DMA. I got a never ending list of:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
My hack solution was to use a normal and cheap 40pol cable and was
able to use UDMA Mode 2.
Since test8 (the bigger via change - or so) I get the same CRC-error
with the normal 40pol cable, too. But after a IDE-Bus reset: "ide0:
reset: success" to MDMA Mode 2 I'm able to use the harddisc - a bit
slower. Since then I'm able to use a 80pol cable and get the same
(much lines of error and a reset) result.
I get the same results with a IBM-DPTA-372050 or IBM-DTLA-307030.
With test10 and a 80pol cable I did a bit more testing a few minutes
ago:
When I connect one of the discs to the second ide-channel this second
hd runs fine in DMA Mode 4 without any problem!
When I connect on of the discs as slave to the same channel this
second disc runs fine in UDMA Mode 4 !!?!
I did a short test with test11-pre7 with the same strange results. All
kernels where compiled with gcc-2.95.2 on RockLinux-1.3.9.
The "ATA/IDE/MFM/RLL support", "Include IDE/ATA-2 DISK support" ,
"VIA82CXXX chipset support", "Generic 4 drives/port support" and "Use
PCI DMA by default when available" are compiled into the kernel.
A friend has the same board and kernels and had no problems with DMA
modes. But he has a Seagate or Western disc. IBM only problem?? I
don't have non IBM discs to test here ...
A longer cut from syslog:
<6>Uniform Multi-Platform E-IDE driver Revision: 6.31
<4>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
<4>VP_IDE: IDE controller on PCI bus 00 dev 21
<4>VP_IDE: chipset revision 6
<4>VP_IDE: not 100% native mode: will probe irqs later
<6>VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:4.1
<4>ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
<4>ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
<4>hda: IBM-DTLA-307030, ATA DISK drive
<4>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
<4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
<6>hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(66)
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x53 { DriveReady SeekComplete
Index Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:34 jackson kernel: hda: dma_intr: status=0x53 {DriveReady SeekComplete
Index Error }
-- CUT much lines of this style --
Nov 18 22:31:34 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 18 22:31:35 jackson kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
Nov 18 22:31:35
