[RFC] ASoC: Add compatible for mt6359-sound device
From: "Shane.Chien"
In the change "[v2,1/2] Add mediatek codec mt6359 driver",
The compatible of mt6359-sound device is removed
due to it is regarded as a part of parent device,
which is only reflecting Linux model instead of hardware.
However, if the device is not given a comaptible,
of_node of struct device is null. I cannot use
devm_iio_channel_get such iio interface to get
auxadc value from iio channel. Because during
using devm_iio_channel_get, of_node of mt6359-sound is a
input parameter of of_iio_channel_get_by_name.
If the of_node is null, devm_iio_channel_get will
eventually return ENODEV error.
static struct iio_channel *of_iio_channel_get_by_name(struct device_node *np,
const char *name)
{
struct iio_channel *chan = NULL;
/* Walk up the tree of devices looking for a matching iio channel */
while (np) { // np is null and will not enter the while loop
}
return chan; // directly return null
}
I add the compatible back to mt6359.c and it
can successfully use devm_iio_channel_get without error.
Is there any suggestions if I need to use this kind of
native interface or can I add the compatible directly?
And I wonder what kind of device can add compatible
under mfd device?
Signed-off-by: Shane.Chien
---
sound/soc/codecs/mt6359.c | 58 +
sound/soc/codecs/mt6359.h |7 ++
2 files changed, 65 insertions(+)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c
index 6de0d74..1fb47f4 100644
--- a/sound/soc/codecs/mt6359.c
+++ b/sound/soc/codecs/mt6359.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2741,6 +2742,37 @@ static void mt6359_codec_remove(struct snd_soc_component
*cmpnt)
.num_dapm_routes = ARRAY_SIZE(mt6359_dapm_routes),
};
+/* dc trim */
+static int mt6359_get_audio_auxadc(struct mt6359_priv *priv, int auxadc_ch)
+{
+ int value = 0;
+ int ret;
+ struct iio_channel *auxadc;
+
+ switch (auxadc_ch) {
+ case AUXADC_HP_OFFSET_CAL:
+ auxadc = priv->hpofs_cal_auxadc;
+ break;
+ case AUXADC_ACCDET:
+ auxadc = priv->accdet_auxadc;
+ break;
+ default:
+ pr_notice("%s() not support\n");
+ break;
+ }
+
+ if (!IS_ERR(auxadc)) {
+ ret = iio_read_channel_processed(auxadc, );
+ if (ret < 0) {
+ pr_err("Error: %s read fail (%d)\n", __func__, ret);
+ return ret;
+ }
+ }
+ pr_info("%s() value %d\n", __func__, value);
+
+ return value;
+}
+
static int mt6359_parse_dt(struct mt6359_priv *priv)
{
int ret;
@@ -2783,6 +2815,25 @@ static int mt6359_parse_dt(struct mt6359_priv *priv)
priv->mux_select[MUX_MIC_TYPE_2] = MIC_TYPE_MUX_IDLE;
}
+ /* get auxadc channel */
+ priv->hpofs_cal_auxadc = devm_iio_channel_get(dev,
+ "pmic_hpofs_cal");
+ ret = PTR_ERR_OR_ZERO(priv->hpofs_cal_auxadc);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev,
+ "%s() Get pmic_hpofs_cal iio ch failed (%d)\n",
+ __func__, ret);
+ }
+ priv->accdet_auxadc = devm_iio_channel_get(dev, "pmic_accdet");
+ ret = PTR_ERR_OR_ZERO(priv->accdet_auxadc);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev,
+ "%s() Get pmic_accdet iio ch failed (%d)\n",
+ __func__, ret);
+ }
+
return 0;
}
@@ -2818,9 +2869,16 @@ static int mt6359_platform_driver_probe(struct
platform_device *pdev)
ARRAY_SIZE(mt6359_dai_driver));
}
+static const struct of_device_id mt6359_of_match[] = {
+ {.compatible = "mediatek,mt6359-sound",},
+ {}
+};
+MODULE_DEVICE_TABLE(of, mt6359_of_match);
+
static struct platform_driver mt6359_platform_driver = {
.driver = {
.name = "mt6359-sound",
+ .of_match_table = mt6359_of_match,
},
.probe = mt6359_platform_driver_probe,
};
diff --git a/sound/soc/codecs/mt6359.h b/sound/soc/codecs/mt6359.h
index 35f806b..52d2398 100644
--- a/sound/soc/codecs/mt6359.h
+++ b/sound/soc/codecs/mt6359.h
@@ -2610,6 +2610,11 @@ enum {
PGA_3_MUX_AIN2,
};
+enum {
+ AUXADC_HP_OFFSET_CAL = 0,
+ AUXADC_ACCDET,
+};
+
struct mt6359_priv {
struct device *dev;
struct regmap *regmap;
@@ -2622,6 +2627,8 @@ struct mt6359_priv {
int hp_gain_ctl;
int hp_hifi_mode;
int mtkaif_protocol;
+ struct iio_channel *hpofs_cal_auxadc;
+ struct iio_channel *accdet_auxadc;
};
[PATCH] ASoC: Remove mt6359_platform_driver_remove
From: "Shane.Chien"
remove mt6359_platform_driver_remove due to it is
useless.
Signed-off-by: Shane.Chien
---
sound/soc/codecs/mt6359.c | 12
1 file changed, 12 deletions(-)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c
index ecdfd57..d37dbd2 100644
--- a/sound/soc/codecs/mt6359.c
+++ b/sound/soc/codecs/mt6359.c
@@ -2817,23 +2817,11 @@ static int mt6359_platform_driver_probe(struct
platform_device *pdev)
ARRAY_SIZE(mt6359_dai_driver));
}
-static int mt6359_platform_driver_remove(struct platform_device *pdev)
-{
- struct mt6359_priv *priv = dev_get_drvdata(>dev);
- int ret;
-
- dev_dbg(>dev, "%s(), dev name %s\n",
- __func__, dev_name(>dev));
-
- return 0;
-}
-
static struct platform_driver mt6359_platform_driver = {
.driver = {
.name = "mt6359-sound",
},
.probe = mt6359_platform_driver_probe,
- .remove = mt6359_platform_driver_remove,
};
module_platform_driver(mt6359_platform_driver)
--
1.7.9.5
[PATCH v3 0/2] Fix vaud18 power leakage of mt6359
From: "Shane.Chien" This series of patches is to fix vaud18 power leakage problem. vaud18 will be enable only when mt6359 audio path is turned on. Change since v2: - fix dt-binnding syntex error Change since v1: - use dapm regulator supply widget for vaud18 control. - add vaud18 regulator property in mt6359 dt-binding. Shane.Chien (2): ASoC: Fix vaud18 power leakage of mt6359 dt-bindings: mediatek: mt6359: Add new property for mt6359 .../devicetree/bindings/sound/mt6359.yaml |9 +++ sound/soc/codecs/mt6359.c | 25 +--- sound/soc/codecs/mt6359.h |8 --- 3 files changed, 10 insertions(+), 32 deletions(-) -- 1.7.9.5
[PATCH v3 1/2] ASoC: Fix vaud18 power leakage of mt6359
From: "Shane.Chien"
vaud18 is power of mt6359 audio path. It
should only enable when audio is used,
instead of in boot up stage.
Once mt6359 audio path is enabled or disabled,
vaud18 is controlled by regulator supply widget
"LDO_VAUD18". Due to vaud18 is controlled by
regulator dapm macro instead of regmap, the macro
MT6359_LDO_VAUD18_CON0 and variable avdd_reg
is no used and removed from mt6359.h.
Signed-off-by: Shane.Chien
---
sound/soc/codecs/mt6359.c | 25 +
sound/soc/codecs/mt6359.h |8
2 files changed, 1 insertion(+), 32 deletions(-)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c
index d20c59a..ecdfd57 100644
--- a/sound/soc/codecs/mt6359.c
+++ b/sound/soc/codecs/mt6359.c
@@ -1943,9 +1943,7 @@ static int mt_ncp_event(struct snd_soc_dapm_widget *w,
SND_SOC_DAPM_SUPPLY_S("CLK_BUF", SUPPLY_SEQ_CLK_BUF,
MT6359_DCXO_CW12,
RG_XO_AUDIO_EN_M_SFT, 0, NULL, 0),
- SND_SOC_DAPM_SUPPLY_S("LDO_VAUD18", SUPPLY_SEQ_LDO_VAUD18,
- MT6359_LDO_VAUD18_CON0,
- RG_LDO_VAUD18_EN_SFT, 0, NULL, 0),
+ SND_SOC_DAPM_REGULATOR_SUPPLY("LDO_VAUD18", 0, 0),
SND_SOC_DAPM_SUPPLY_S("AUDGLB", SUPPLY_SEQ_AUD_GLB,
MT6359_AUDDEC_ANA_CON13,
RG_AUDGLB_PWRDN_VA32_SFT, 1, NULL, 0),
@@ -2807,20 +2805,6 @@ static int mt6359_platform_driver_probe(struct
platform_device *pdev)
dev_set_drvdata(>dev, priv);
priv->dev = >dev;
- priv->avdd_reg = devm_regulator_get(>dev, "vaud18");
- if (IS_ERR(priv->avdd_reg)) {
- dev_err(>dev, "%s(), have no vaud18 supply: %ld",
- __func__, PTR_ERR(priv->avdd_reg));
- return PTR_ERR(priv->avdd_reg);
- }
-
- ret = regulator_enable(priv->avdd_reg);
- if (ret) {
- dev_err(>dev, "%s(), failed to enable regulator!\n",
- __func__);
- return ret;
- }
-
ret = mt6359_parse_dt(priv);
if (ret) {
dev_warn(>dev, "%s() failed to parse dts\n", __func__);
@@ -2841,13 +2825,6 @@ static int mt6359_platform_driver_remove(struct
platform_device *pdev)
dev_dbg(>dev, "%s(), dev name %s\n",
__func__, dev_name(>dev));
- ret = regulator_disable(priv->avdd_reg);
- if (ret) {
- dev_err(>dev, "%s(), failed to disable regulator!\n",
- __func__);
- return ret;
- }
-
return 0;
}
diff --git a/sound/soc/codecs/mt6359.h b/sound/soc/codecs/mt6359.h
index af6f07f..35f806b 100644
--- a/sound/soc/codecs/mt6359.h
+++ b/sound/soc/codecs/mt6359.h
@@ -135,11 +135,6 @@
/* MT6359_DCXO_CW12 */
#define RG_XO_AUDIO_EN_M_SFT 13
-/* LDO_VAUD18_CON0 */
-#define RG_LDO_VAUD18_EN_SFT 0
-#define RG_LDO_VAUD18_EN_MASK 0x1
-#define RG_LDO_VAUD18_EN_MASK_SFT (0x1 << 0)
-
/* AUD_TOP_CKPDN_CON0 */
#define RG_VOW13M_CK_PDN_SFT 13
#define RG_VOW13M_CK_PDN_MASK 0x1
@@ -2132,7 +2127,6 @@
#define MT6359_DCXO_CW11 0x7a6
#define MT6359_DCXO_CW12 0x7a8
-#define MT6359_LDO_VAUD18_CON0 0x1c98
#define MT6359_GPIO_MODE0 0xcc
#define MT6359_GPIO_MODE0_SET 0xce
@@ -2469,7 +2463,6 @@ enum {
enum {
/* common */
SUPPLY_SEQ_CLK_BUF,
- SUPPLY_SEQ_LDO_VAUD18,
SUPPLY_SEQ_AUD_GLB,
SUPPLY_SEQ_HP_PULL_DOWN,
SUPPLY_SEQ_CLKSQ,
@@ -2629,7 +2622,6 @@ struct mt6359_priv {
int hp_gain_ctl;
int hp_hifi_mode;
int mtkaif_protocol;
- struct regulator *avdd_reg;
};
#define CODEC_MT6359_NAME "mtk-codec-mt6359"
--
1.7.9.5
[PATCH v3 2/2] dt-bindings: mediatek: mt6359: Add new property for mt6359
From: "Shane.Chien"
This patch add "LDO_VAUD18-supply" property to
control vaud18 regulator. It is labeled as required
due to mt6359 audio path always need to enable vaud18.
Signed-off-by: Shane.Chien
---
.../devicetree/bindings/sound/mt6359.yaml |9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml
b/Documentation/devicetree/bindings/sound/mt6359.yaml
index a54f466..ef027c7 100644
--- a/Documentation/devicetree/bindings/sound/mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mt6359.yaml
@@ -17,6 +17,11 @@ description: |
Must be a child node of PMIC wrapper.
properties:
+ LDO_VAUD18-supply:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ Regulator of LDO VAUD18 at 1.8V.
+
mediatek,dmic-mode:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -49,11 +54,15 @@ properties:
description: |
Specifies the type of mic type connected to adc2
+required:
+ - LDO_VAUD18-supply
+
additionalProperties: false
examples:
- |
mt6359codec: mt6359codec {
+ LDO_VAUD18-supply = <_vaud18_reg>;
mediatek,dmic-mode = <0>;
mediatek,mic-type-0 = <2>;
};
--
1.7.9.5
[PATCH v2 0/2] Fix vaud18 power leakage of mt6359
From: "Shane.Chien" This series of patches is to fix vaud18 power leakage problem. vaud18 will be enable only when mt6359 audio path is turned on. Change since v1: - use dapm regulator supply widget for vaud18 control. - add vaud18 regulator property in mt6359 dt-binding. Shane.Chien (2): ASoC: Fix vaud18 power leakage of mt6359 dt-bindings: mediatek: mt6359: Add new property for mt6359 .../devicetree/bindings/sound/mt6359.yaml |9 +++ sound/soc/codecs/mt6359.c | 25 +--- sound/soc/codecs/mt6359.h |8 --- 3 files changed, 10 insertions(+), 32 deletions(-) -- 1.7.9.5
[PATCH v2 2/2] dt-bindings: mediatek: mt6359: Add new property for mt6359
From: "Shane.Chien"
This patch add "LDO_VAUD18-supply" property to
control vaud18 regulator. It is labeled as required
due to mt6359 audio path always need to enable vaud18.
Signed-off-by: Shane.Chien
---
.../devicetree/bindings/sound/mt6359.yaml |9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml
b/Documentation/devicetree/bindings/sound/mt6359.yaml
index a54f466..7ccaa8c 100644
--- a/Documentation/devicetree/bindings/sound/mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mt6359.yaml
@@ -17,6 +17,11 @@ description: |
Must be a child node of PMIC wrapper.
properties:
+ LDO_VAUD18-supply:
+ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ Regulator of LDO VAUD18 at 1.8V.
+
mediatek,dmic-mode:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -49,11 +54,15 @@ properties:
description: |
Specifies the type of mic type connected to adc2
+required:
+ - LDO_VAUD18-supply
+
additionalProperties: false
examples:
- |
mt6359codec: mt6359codec {
+ LDO_VAUD18-supply = <_vaud18_reg>;
mediatek,dmic-mode = <0>;
mediatek,mic-type-0 = <2>;
};
--
1.7.9.5
[PATCH v2 1/2] ASoC: Fix vaud18 power leakage of mt6359
From: "Shane.Chien"
vaud18 is power of mt6359 audio path. It
should only enable when audio is used,
instead of in boot up stage.
Once mt6359 audio path is enabled or disabled,
vaud18 is controlled by regulator supply widget
"LDO_VAUD18". Due to vaud18 is controlled by
regulator dapm macro instead of regmap, the macro
MT6359_LDO_VAUD18_CON0 and variable avdd_reg
is no used and removed from mt6359.h.
Signed-off-by: Shane.Chien
---
sound/soc/codecs/mt6359.c | 25 +
sound/soc/codecs/mt6359.h |8
2 files changed, 1 insertion(+), 32 deletions(-)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c
index d20c59a..ecdfd57 100644
--- a/sound/soc/codecs/mt6359.c
+++ b/sound/soc/codecs/mt6359.c
@@ -1943,9 +1943,7 @@ static int mt_ncp_event(struct snd_soc_dapm_widget *w,
SND_SOC_DAPM_SUPPLY_S("CLK_BUF", SUPPLY_SEQ_CLK_BUF,
MT6359_DCXO_CW12,
RG_XO_AUDIO_EN_M_SFT, 0, NULL, 0),
- SND_SOC_DAPM_SUPPLY_S("LDO_VAUD18", SUPPLY_SEQ_LDO_VAUD18,
- MT6359_LDO_VAUD18_CON0,
- RG_LDO_VAUD18_EN_SFT, 0, NULL, 0),
+ SND_SOC_DAPM_REGULATOR_SUPPLY("LDO_VAUD18", 0, 0),
SND_SOC_DAPM_SUPPLY_S("AUDGLB", SUPPLY_SEQ_AUD_GLB,
MT6359_AUDDEC_ANA_CON13,
RG_AUDGLB_PWRDN_VA32_SFT, 1, NULL, 0),
@@ -2807,20 +2805,6 @@ static int mt6359_platform_driver_probe(struct
platform_device *pdev)
dev_set_drvdata(>dev, priv);
priv->dev = >dev;
- priv->avdd_reg = devm_regulator_get(>dev, "vaud18");
- if (IS_ERR(priv->avdd_reg)) {
- dev_err(>dev, "%s(), have no vaud18 supply: %ld",
- __func__, PTR_ERR(priv->avdd_reg));
- return PTR_ERR(priv->avdd_reg);
- }
-
- ret = regulator_enable(priv->avdd_reg);
- if (ret) {
- dev_err(>dev, "%s(), failed to enable regulator!\n",
- __func__);
- return ret;
- }
-
ret = mt6359_parse_dt(priv);
if (ret) {
dev_warn(>dev, "%s() failed to parse dts\n", __func__);
@@ -2841,13 +2825,6 @@ static int mt6359_platform_driver_remove(struct
platform_device *pdev)
dev_dbg(>dev, "%s(), dev name %s\n",
__func__, dev_name(>dev));
- ret = regulator_disable(priv->avdd_reg);
- if (ret) {
- dev_err(>dev, "%s(), failed to disable regulator!\n",
- __func__);
- return ret;
- }
-
return 0;
}
diff --git a/sound/soc/codecs/mt6359.h b/sound/soc/codecs/mt6359.h
index af6f07f..35f806b 100644
--- a/sound/soc/codecs/mt6359.h
+++ b/sound/soc/codecs/mt6359.h
@@ -135,11 +135,6 @@
/* MT6359_DCXO_CW12 */
#define RG_XO_AUDIO_EN_M_SFT 13
-/* LDO_VAUD18_CON0 */
-#define RG_LDO_VAUD18_EN_SFT 0
-#define RG_LDO_VAUD18_EN_MASK 0x1
-#define RG_LDO_VAUD18_EN_MASK_SFT (0x1 << 0)
-
/* AUD_TOP_CKPDN_CON0 */
#define RG_VOW13M_CK_PDN_SFT 13
#define RG_VOW13M_CK_PDN_MASK 0x1
@@ -2132,7 +2127,6 @@
#define MT6359_DCXO_CW11 0x7a6
#define MT6359_DCXO_CW12 0x7a8
-#define MT6359_LDO_VAUD18_CON0 0x1c98
#define MT6359_GPIO_MODE0 0xcc
#define MT6359_GPIO_MODE0_SET 0xce
@@ -2469,7 +2463,6 @@ enum {
enum {
/* common */
SUPPLY_SEQ_CLK_BUF,
- SUPPLY_SEQ_LDO_VAUD18,
SUPPLY_SEQ_AUD_GLB,
SUPPLY_SEQ_HP_PULL_DOWN,
SUPPLY_SEQ_CLKSQ,
@@ -2629,7 +2622,6 @@ struct mt6359_priv {
int hp_gain_ctl;
int hp_hifi_mode;
int mtkaif_protocol;
- struct regulator *avdd_reg;
};
#define CODEC_MT6359_NAME "mtk-codec-mt6359"
--
1.7.9.5
[PATCH] ASoC: Fix vaud18 power leakage of mt6359
From: "Shane.Chien"
vaud18 is power of mt6359 audio path. It
should only enable when audio is used,
instead of in boot up stage.
Once mt6359 audio path is enabled or disabled,
vaud18 is controlled by using regulator in
supply widget "LDO_VAUD18". Due to vaud18 is
controlled by regulator instead of regmap,
the macro MT6359_LDO_VAUD18_CON0 is no used and
remove from mt6359.h.
Signed-off-by: Shane.Chien
---
sound/soc/codecs/mt6359.c | 38 +-
sound/soc/codecs/mt6359.h | 6 --
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c
index d20c59a..52dabdc 100644
--- a/sound/soc/codecs/mt6359.c
+++ b/sound/soc/codecs/mt6359.c
@@ -724,6 +724,32 @@ static SOC_VALUE_ENUM_SINGLE_DECL(pga_3_mux_map_enum,
static const struct snd_kcontrol_new pga_3_mux_control =
SOC_DAPM_ENUM("PGA 3 Select", pga_3_mux_map_enum);
+static int mt_vaud18_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mt6359_priv *priv = snd_soc_component_get_drvdata(cmpnt);
+ int ret = 0;
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ ret = regulator_enable(priv->avdd_reg);
+ if (ret)
+ dev_err(priv->dev, "regulator_enable err: %d\n", ret);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ ret = regulator_disable(priv->avdd_reg);
+ if (ret)
+ dev_err(priv->dev, "regulator_disable err: %d\n", ret);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static int mt_sgen_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol,
int event)
@@ -1944,8 +1970,9 @@ static int mt_ncp_event(struct snd_soc_dapm_widget *w,
MT6359_DCXO_CW12,
RG_XO_AUDIO_EN_M_SFT, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY_S("LDO_VAUD18", SUPPLY_SEQ_LDO_VAUD18,
- MT6359_LDO_VAUD18_CON0,
- RG_LDO_VAUD18_EN_SFT, 0, NULL, 0),
+ SND_SOC_NOPM, 0, 0,
+ mt_vaud18_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_SUPPLY_S("AUDGLB", SUPPLY_SEQ_AUD_GLB,
MT6359_AUDDEC_ANA_CON13,
RG_AUDGLB_PWRDN_VA32_SFT, 1, NULL, 0),
@@ -2814,13 +2841,6 @@ static int mt6359_platform_driver_probe(struct
platform_device *pdev)
return PTR_ERR(priv->avdd_reg);
}
- ret = regulator_enable(priv->avdd_reg);
- if (ret) {
- dev_err(>dev, "%s(), failed to enable regulator!\n",
- __func__);
- return ret;
- }
-
ret = mt6359_parse_dt(priv);
if (ret) {
dev_warn(>dev, "%s() failed to parse dts\n", __func__);
diff --git a/sound/soc/codecs/mt6359.h b/sound/soc/codecs/mt6359.h
index af6f07f..1dfb29a 100644
--- a/sound/soc/codecs/mt6359.h
+++ b/sound/soc/codecs/mt6359.h
@@ -135,11 +135,6 @@
/* MT6359_DCXO_CW12 */
#define RG_XO_AUDIO_EN_M_SFT 13
-/* LDO_VAUD18_CON0 */
-#define RG_LDO_VAUD18_EN_SFT 0
-#define RG_LDO_VAUD18_EN_MASK 0x1
-#define RG_LDO_VAUD18_EN_MASK_SFT (0x1 << 0)
-
/* AUD_TOP_CKPDN_CON0 */
#define RG_VOW13M_CK_PDN_SFT 13
#define RG_VOW13M_CK_PDN_MASK 0x1
@@ -2132,7 +2127,6 @@
#define MT6359_DCXO_CW11 0x7a6
#define MT6359_DCXO_CW12 0x7a8
-#define MT6359_LDO_VAUD18_CON0 0x1c98
#define MT6359_GPIO_MODE0 0xcc
#define MT6359_GPIO_MODE0_SET 0xce
--
1.9.1
[PATCH] ASoC: Use memset_io to access I/O memory
From: "Shane.Chien" Use memset_io to access I/O memory, instead of memset. Signed-off-by: Shane.Chien --- sound/core/pcm_native.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 9e0b2d7..a4efa84 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -756,7 +756,7 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream, /* clear the buffer for avoiding possible kernel info leaks */ if (runtime->dma_area && !substream->ops->copy_user) - memset(runtime->dma_area, 0, runtime->dma_bytes); + memset_io(runtime->dma_area, 0, runtime->dma_bytes); snd_pcm_timer_resolution_change(substream); snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP); -- 1.7.9.5
[PATCH 0/1] Use memset_io to access I/O memory
From: "Shane.Chien" Use memset_io to access I/O memory, instead of memset. Shane.Chien (1): ASoC: Use memset_io to access I/O memory sound/core/pcm_native.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5
Darowizna
Nazywam się SHANE MISSLER, wygrałem loterię o wartości 451 milionów dolarów i postanowiłem przekazać tobie kwotę 5500 000,00 €. Przekazuję wam tę darowiznę za miłość, którą mam dla ludzkości i za pomoc osobom dotkniętym pandemią w waszym kraju.Skontaktuj się ze mną, aby odebrać tę darowiznęDziękuję i Bóg zapłać.pozdrowieniaSHANE MISSLER
Spende von 5 Millionen Euro
Dies ist eine persönliche Mail, die ich an Sie adressiere. Ich bin SHANE MISSLER aus Florida, USA. Wie Sie bereits wissen, habe ich einen Lotto-Jackpot in Höhe von 451 Mio. USD (330 Mio. GBP) gewonnen und das Geld hat mein Leben und mein Familienleben verändert, aber es wird mein Herz nicht verändern, wie ich an dem Tag sagte, an dem ich mein Geld habe, das ich verwenden werde Dieses Geld für die Hilfe der Menschheit. Ich habe beschlossen, Ihnen und Ihrer Gemeinde einen Betrag von 5 Millionen Euro zu spenden, um diese Spende anzufordern. E-Mail: (shanemissl...@gmail.com) Ceci est un courrier personnel que je vous adresse. Je suis SHANE MISSLER, de Floride, États-Unis. Comme vous le savez déjà, j'ai gagné 451 millions de dollars (Lotto Jackpot) et l'argent a changé ma vie et celle de ma famille, mais cela ne changera pas mon cœur, comme je l'ai dit le jour où j'ai mon argent, j'utiliserai cet argent pour l'aide de l'humanité.J'ai décidé de vous donner la somme de 5 millions d'euros à vous et à votre communauté, pour réclamer ce don, email- (shanemissl...@gmail.com) . La informacion contenida en este correo, asi como la contenida en los documentos anexos, puede contener datos personales, por lo que su difusion es responsabilidad de quien los transmite y quien los recibe, en términos de lo dispuesto por las fracciones II y VII del articulo 4, ultimo parrafo del articulo 8, articulo 36 parrafo II, 38 fraccion I y demas aplicables de la Ley de Transparencia y Acceso a la Informacion Publica del Distrito Federal. Los Datos Personales se encuentran protegidos por la Ley de Proteccion de Datos Personales del Distrito Federal, por lo que su difusion se encuentra tutelada en sus articulos 2, 5, 16, 21, 41 y demas relativos y aplicables, debiendo sujetarse en su caso, a las disposiciones relativas a la creacion, modificacion o supresion de datos personales previstos. Asimismo, debera estarse a lo señalado en los numerales 1 , 3, 12, 18, 19, 20, 21, 23, 24, 29, 35 y demas aplicables de los Lineamientos para la Proteccion de Datos Personales en el Distrito Federal. En el uso de las tecnologias de la informacion y comunicaciones del Gobierno del Distrito Federal, debera observarse puntualmente lo dispuesto por la Ley Gobierno Electronico del Distrito Federal, la ley para hacer de la Ciudad de Mexico una Ciudad Mas Abierta, el apartado 10 de la Circular Uno vigente y las Normas Generales que deberan observarse en materia de Seguridad de la Informacion en la Administracion Publica del Distrito Federal.
Spende von 5 Millionen Euro
Dies ist eine persönliche Mail, die ich an Sie adressiere. Ich bin SHANE MISSLER aus Florida, USA. Wie Sie bereits wissen, habe ich einen Lotto-Jackpot in Höhe von 451 Mio. USD (330 Mio. GBP) gewonnen und das Geld hat mein Leben und mein Familienleben verändert, aber es wird mein Herz nicht verändern, wie ich an dem Tag sagte, an dem ich mein Geld habe, das ich verwenden werde Dieses Geld für die Hilfe der Menschheit. Ich habe beschlossen, Ihnen und Ihrer Gemeinde einen Betrag von 5 Millionen Euro zu spenden, um diese Spende anzufordern. E-Mail: (shanemissl...@gmail.com) Ceci est un courrier personnel que je vous adresse. Je suis SHANE MISSLER, de Floride, États-Unis. Comme vous le savez déjà, j'ai gagné 451 millions de dollars (Lotto Jackpot) et l'argent a changé ma vie et celle de ma famille, mais cela ne changera pas mon cœur, comme je l'ai dit le jour où j'ai mon argent, j'utiliserai cet argent pour l'aide de l'humanité.J'ai décidé de vous donner la somme de 5 millions d'euros à vous et à votre communauté, pour réclamer ce don, email- (shanemissl...@gmail.com) . La informacion contenida en este correo, asi como la contenida en los documentos anexos, puede contener datos personales, por lo que su difusion es responsabilidad de quien los transmite y quien los recibe, en términos de lo dispuesto por las fracciones II y VII del articulo 4, ultimo parrafo del articulo 8, articulo 36 parrafo II, 38 fraccion I y demas aplicables de la Ley de Transparencia y Acceso a la Informacion Publica del Distrito Federal. Los Datos Personales se encuentran protegidos por la Ley de Proteccion de Datos Personales del Distrito Federal, por lo que su difusion se encuentra tutelada en sus articulos 2, 5, 16, 21, 41 y demas relativos y aplicables, debiendo sujetarse en su caso, a las disposiciones relativas a la creacion, modificacion o supresion de datos personales previstos. Asimismo, debera estarse a lo señalado en los numerales 1 , 3, 12, 18, 19, 20, 21, 23, 24, 29, 35 y demas aplicables de los Lineamientos para la Proteccion de Datos Personales en el Distrito Federal. En el uso de las tecnologias de la informacion y comunicaciones del Gobierno del Distrito Federal, debera observarse puntualmente lo dispuesto por la Ley Gobierno Electronico del Distrito Federal, la ley para hacer de la Ciudad de Mexico una Ciudad Mas Abierta, el apartado 10 de la Circular Uno vigente y las Normas Generales que deberan observarse en materia de Seguridad de la Informacion en la Administracion Publica del Distrito Federal.
YOU HAVE BEEN CHOSEN
Dear Beneficiary, Greetings to you. Following my Mega Jackpot winning of $451 million on January 5th, 2018 which I hope to use to pursue a variety of passions,help my family and do some good for humanity. I have voluntarily decided to donate some Money to charities across the world hence, be informed that you have been selected to benefit from my charity project aimed at touching lives as God has blessed me. This donation of $1 Million is made out to enable you strengthen your personal issues and generously extend hands of help to the less privileged,orphans and charity organizations within your locality. Should you wish to verify,below are link to that effect: http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU Kindly Forward your Message of Acceptance to: shaness...@yahoo.com Best Regards. Shane Missler
YOU HAVE BEEN CHOSEN
Dear Beneficiary, Greetings to you. Following my Mega Jackpot winning of $451 million on January 5th, 2018 which I hope to use to pursue a variety of passions,help my family and do some good for humanity. I have voluntarily decided to donate some Money to charities across the world hence, be informed that you have been selected to benefit from my charity project aimed at touching lives as God has blessed me. This donation of $1 Million is made out to enable you strengthen your personal issues and generously extend hands of help to the less privileged,orphans and charity organizations within your locality. Should you wish to verify,below are link to that effect: http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU Kindly Forward your Message of Acceptance to: shaness...@yahoo.com Best Regards. Shane Missler
YOU HAVE BEEN CHOSEN
Dear Beneficiary, Greetings to you. Following my Mega Jackpot winning of $451 million on January 5th, 2018 which I hope to use to pursue a variety of passions,help my family and do some good for humanity. I have voluntarily decided to donate some Money to charities across the world hence, be informed that you have been selected to benefit from my charity project aimed at touching lives as God has blessed me. This donation of $1 Million is made out to enable you strengthen your personal issues and generously extend hands of help to the less privileged,orphans and charity organizations within your locality. Should you wish to verify,below are link to that effect: http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU Kindly Forward your Message of Acceptance to: shaness...@yahoo.com Best Regards. Shane Missler
YOU HAVE BEEN CHOSEN
Dear Beneficiary, Greetings to you. Following my Mega Jackpot winning of $451 million on January 5th, 2018 which I hope to use to pursue a variety of passions,help my family and do some good for humanity. I have voluntarily decided to donate some Money to charities across the world hence, be informed that you have been selected to benefit from my charity project aimed at touching lives as God has blessed me. This donation of $1 Million is made out to enable you strengthen your personal issues and generously extend hands of help to the less privileged,orphans and charity organizations within your locality. Should you wish to verify,below are link to that effect: http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU Kindly Forward your Message of Acceptance to: shaness...@yahoo.com Best Regards. Shane Missler
RE: [PATCH] qlogicpti: Return correct error code
Reviewed-by: Shane Seymour <shane.seym...@hpe.com>
RE: [PATCH] qlogicpti: Return correct error code
Reviewed-by: Shane Seymour
RE: [PATCH] snic: correctly check for array overrun on overly long version number
Reviewed-by: Shane Seymour <shane.seym...@hpe.com>
RE: [PATCH] snic: correctly check for array overrun on overly long version number
Reviewed-by: Shane Seymour
RE: [PATCH] ipr: fix out-of-bounds null overwrite
> len = snprintf(fname, 99, "%s", buf); > - fname[len-1] = '\0'; Since it appears that's the only time len is actually used in that function can you please remove the variable len completely as part of the patch? -- 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] ipr: fix out-of-bounds null overwrite
> len = snprintf(fname, 99, "%s", buf); > - fname[len-1] = '\0'; Since it appears that's the only time len is actually used in that function can you please remove the variable len completely as part of the patch? -- 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/2] pci: Update VPD size with correct length
Tested with a HP AE311-60001 PCIe card. It used to repeat the same VPD every 4k for 32k now only the 154 bytes are returned and lspci - reports that the data up to and including the end and that the check sum is good: ... Capabilities: [74] Vital Product Data Product Name: PCI-Express 4Gb Fibre Channel HBA Read-only fields: [PN] Part number: AE311-60001 [EC] Engineering changes: C-4830 [SN] Serial number: CN80847W3U [V0] Vendor specific: PW=15W [V2] Vendor specific: 4847 [MN] Manufacture ID: 50 58 32 35 31 30 34 30 31 2d 37 30 20 20 42 [V1] Vendor specific: 02.22 [V3] Vendor specific: 05.03.15 [V4] Vendor specific: 03.13 [V5] Vendor specific: 02.03 [YA] Asset tag: NA [RV] Reserved: checksum good, 0 byte(s) reserved End ... --- Tested-by: Shane Seymour -- 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] pci: Update VPD definitions
> The 'end' tag is actually 0x0f, it's the representation as a > small resource data type tag that's 0x78 (ie shifted by 3). > This patch also adds helper functions to extract the resource > data type tags for both large and small resource data types. > > Cc: Alexander Duyck > Cc: Bjorn Helgaas > Signed-off-by: Hannes Reinecke Tested-by: Shane Seymour -- 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] pci: Update VPD definitions
> The 'end' tag is actually 0x0f, it's the representation as a > small resource data type tag that's 0x78 (ie shifted by 3). > This patch also adds helper functions to extract the resource > data type tags for both large and small resource data types. > > Cc: Alexander Duyck <alexander.du...@gmail.com> > Cc: Bjorn Helgaas <bhelg...@google.com> > Signed-off-by: Hannes Reinecke <h...@suse.com> Tested-by: Shane Seymour <shane.seym...@hpe.com> -- 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/2] pci: Update VPD size with correct length
Tested with a HP AE311-60001 PCIe card. It used to repeat the same VPD every 4k for 32k now only the 154 bytes are returned and lspci - reports that the data up to and including the end and that the check sum is good: ... Capabilities: [74] Vital Product Data Product Name: PCI-Express 4Gb Fibre Channel HBA Read-only fields: [PN] Part number: AE311-60001 [EC] Engineering changes: C-4830 [SN] Serial number: CN80847W3U [V0] Vendor specific: PW=15W [V2] Vendor specific: 4847 [MN] Manufacture ID: 50 58 32 35 31 30 34 30 31 2d 37 30 20 20 42 [V1] Vendor specific: 02.22 [V3] Vendor specific: 05.03.15 [V4] Vendor specific: 03.13 [V5] Vendor specific: 02.03 [YA] Asset tag: NA [RV] Reserved: checksum good, 0 byte(s) reserved End ... --- Tested-by: Shane Seymour <shane.seym...@hpe.com> -- 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: [PATCHv2] pci: Update VPD size with correct length
> The only 'error' cases I've encountered so far is a read of all zeroes (and a > halting the machine once you've read beyond a certain point) or a read of > 0xff throughout the entire area. So that approach would work for both of them. I should add that I'd tested the previous patch and this patch. I'll retest once v3 is available. I have a card that repeats the vpd data every 4k for all 32k. The patch as it stands truncates that to just the valid data and lspci - shows the vpd data correctly. -- 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: [PATCHv2] pci: Update VPD size with correct length
> The only 'error' cases I've encountered so far is a read of all zeroes (and a > halting the machine once you've read beyond a certain point) or a read of > 0xff throughout the entire area. So that approach would work for both of them. I should add that I'd tested the previous patch and this patch. I'll retest once v3 is available. I have a card that repeats the vpd data every 4k for all 32k. The patch as it stands truncates that to just the valid data and lspci - shows the vpd data correctly. -- 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 v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.
Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour
RE: [PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.
Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour <shane.seym...@hpe.com>
RE: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks
> v4: Check the start/len arguments for overflows prior to feeding the page > cache bogus numbers (that it'll ignore anyway). > Signed-off-by: Darrick J. Wong Reviewed-by: Shane Seymour -- 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 v4] block: create ioctl to discard-or-zeroout a range of blocks
> v4: Check the start/len arguments for overflows prior to feeding the page > cache bogus numbers (that it'll ignore anyway). > Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com> Reviewed-by: Shane Seymour <shane.seym...@hpe.com> -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. If you have someone trying to bypass your sanity checks then if start=18446744073709551104 and len=1024 the result of adding them together will be 512 (subtracting an extra 1 in the patched code to get 511 for end). That will pass the i_size_read check won't it? If so that would cause lstart in truncate_inode_pages_range() to be -512. I don't know what truncate_inode_pages_range() will do with a negative lstart value like that but it seems like an unusual value for your code to be willing to pass into truncate_inode_pages_range(). Shane -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. If you have someone trying to bypass your sanity checks then if start=18446744073709551104 and len=1024 the result of adding them together will be 512 (subtracting an extra 1 in the patched code to get 511 for end). That will pass the i_size_read check won't it? If so that would cause lstart in truncate_inode_pages_range() to be -512. I don't know what truncate_inode_pages_range() will do with a negative lstart value like that but it seems like an unusual value for your code to be willing to pass into truncate_inode_pages_range(). Shane -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> which would make the other checks I suggested to ensure that neither start > or end were more than (uint64_t)LLONG_MAX unnecessary. My apologies I was wrong about what I said above - after thinking about it for longer you still need to make sure that at least len is not greater than (uint64_t)LLONG_MAX because in the calculation: if (start > (uint64_t)LLONG_MAX - len) return -EINVAL; if len was more than (uint64_t)LLONG_MAX it would underflow and become a very large positive number and start would never be greater than that (and I said end when I should have said len). -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. > However, I do see that I forgot to check the padding values, so I'll update > that. Then do you want to at least consider converting end to be of type loff_t to match the type of value returned by i_get_size() and the type of the value passed to truncate_inode_pages_range()? Then you only need one additional check, something like: /* Check for an overflow when adding start+len into end */ if (start > (uint64_t)LLONG_MAX - len) return -EINVAL; Looking at the maximum values if we have start=0 and len=(uint64_t)LLONG_MAX we would still continue but len=(uint64_t)LLONG_MAX+1 would return -EINVAL. Similarly for start=(uint64_t)LLONG_MAX and len=0 it would continue but start=(uint64_t)LLONG_MAX+1 would return -EINVAL and that should allow start + len to be safely added and stored into an loff_t without overflow. With this check start+len can never be more than (uint64_t)LLONG_MAX which would make the other checks I suggested to ensure that neither start or end were more than (uint64_t)LLONG_MAX unnecessary. -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. > However, I do see that I forgot to check the padding values, so I'll update > that. Then do you want to at least consider converting end to be of type loff_t to match the type of value returned by i_get_size() and the type of the value passed to truncate_inode_pages_range()? Then you only need one additional check, something like: /* Check for an overflow when adding start+len into end */ if (start > (uint64_t)LLONG_MAX - len) return -EINVAL; Looking at the maximum values if we have start=0 and len=(uint64_t)LLONG_MAX we would still continue but len=(uint64_t)LLONG_MAX+1 would return -EINVAL. Similarly for start=(uint64_t)LLONG_MAX and len=0 it would continue but start=(uint64_t)LLONG_MAX+1 would return -EINVAL and that should allow start + len to be safely added and stored into an loff_t without overflow. With this check start+len can never be more than (uint64_t)LLONG_MAX which would make the other checks I suggested to ensure that neither start or end were more than (uint64_t)LLONG_MAX unnecessary. -- 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] block: create ioctl to discard-or-zeroout a range of blocks
> which would make the other checks I suggested to ensure that neither start > or end were more than (uint64_t)LLONG_MAX unnecessary. My apologies I was wrong about what I said above - after thinking about it for longer you still need to make sure that at least len is not greater than (uint64_t)LLONG_MAX because in the calculation: if (start > (uint64_t)LLONG_MAX - len) return -EINVAL; if len was more than (uint64_t)LLONG_MAX it would underflow and become a very large positive number and start would never be greater than that (and I said end when I should have said len). -- 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] block: create ioctl to discard-or-zeroout a range of blocks
A quick question about this part of the patch: > + uint64_t end = start + len - 1; > + if (end >= i_size_read(bdev->bd_inode)) return -EINVAL; > + /* Invalidate the page cache, including dirty pages */ > + mapping = bdev->bd_inode->i_mapping; > + truncate_inode_pages_range(mapping, start, end); blk_ioctl_zeroout accepts unsigned values for start and end (uint64_t) but loff_t types are turned from i_size_read() and passed as the 2nd and 3rd values to truncate_inode_pages_range() and loff_t is a signed value. It should be possible to pass in some values would overflow the calculation of end causing the test on the value of end and the result of i_size_read to pass but then end up passing a large unsigned value for in start that would be implicitly converted to signed in truncate_inode_pages_range. I was wondering if you'd tested passing in data that would cause sign conversion issues when passed into truncate_inode_pages_range (does it handle it gracefully?) or should this code: if (start & 511) return -EINVAL; if (len & 511) return -EINVAL; be something more like this (for better sanity checking of your arguments) which will ensure that you don't have implicit conversion issues from unsigned to signed and ensure that the result of adding them together won't either: if ((start & 511) || (start > (uint64_t)LLONG_MAX)) return -EINVAL; if ((len & 511) ) || (len > (uint64_t)LLONG_MAX)) return -EINVAL; if (end > (uint64_t)LLONG_MAX) return -EINVAL; My apologies in advance if I've made a mistake when looking at this and my concerns about unsigned values being implicitly converted to signed are unfounded (I would have hoped for compiler warnings about any implicit conversions though). Thanks Shane -- 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] block: create ioctl to discard-or-zeroout a range of blocks
A quick question about this part of the patch: > + uint64_t end = start + len - 1; > + if (end >= i_size_read(bdev->bd_inode)) return -EINVAL; > + /* Invalidate the page cache, including dirty pages */ > + mapping = bdev->bd_inode->i_mapping; > + truncate_inode_pages_range(mapping, start, end); blk_ioctl_zeroout accepts unsigned values for start and end (uint64_t) but loff_t types are turned from i_size_read() and passed as the 2nd and 3rd values to truncate_inode_pages_range() and loff_t is a signed value. It should be possible to pass in some values would overflow the calculation of end causing the test on the value of end and the result of i_size_read to pass but then end up passing a large unsigned value for in start that would be implicitly converted to signed in truncate_inode_pages_range. I was wondering if you'd tested passing in data that would cause sign conversion issues when passed into truncate_inode_pages_range (does it handle it gracefully?) or should this code: if (start & 511) return -EINVAL; if (len & 511) return -EINVAL; be something more like this (for better sanity checking of your arguments) which will ensure that you don't have implicit conversion issues from unsigned to signed and ensure that the result of adding them together won't either: if ((start & 511) || (start > (uint64_t)LLONG_MAX)) return -EINVAL; if ((len & 511) ) || (len > (uint64_t)LLONG_MAX)) return -EINVAL; if (end > (uint64_t)LLONG_MAX) return -EINVAL; My apologies in advance if I've made a mistake when looking at this and my concerns about unsigned values being implicitly converted to signed are unfounded (I would have hoped for compiler warnings about any implicit conversions though). Thanks Shane -- 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 RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
I found the manual pages really confusing so I had a go at rewriting
them - there were places in the manual page that didn't match the
functionality provided by your code as well as I could tell).
My apologies for a few formatting issues though. I still don't like
parts of epoll_pwait1 but it's less confusing than it was.
You are free to take some or all or none of the changes.
I did have a question I marked with below about what you
describe and what your code does.
1) epoll_ctl_batch
--
NAME
epoll_ctl_batch - batch control interface for an epoll descriptor
SYNOPSIS
#include
int epoll_ctl_batch(int epfd, int flags,
int ncmds, struct epoll_ctl_cmd *cmds);
DESCRIPTION
This system call is an extension of epoll_ctl(). The primary
difference is that this system call allows you to batch multiple
operations with the one system call. This provides a more efficient
interface for updating events on this epoll file descriptor epfd.
The flags argument is reserved and must be 0.
The argument ncmds is the number of cmds entries being passed in.
This number must be greater than 0.
Each operation is specified as an element in the cmds array, defined as:
struct epoll_ctl_cmd {
/* Reserved flags for future extension, must be 0. */
int flags;
/* The same as epoll_ctl() op parameter. */
int op;
/* The same as epoll_ctl() fd parameter. */
int fd;
/* The same as the "events" field in struct epoll_event. */
uint32_t events;
/* The same as the "data" field in struct epoll_event. */
uint64_t data;
/* Output field, will be set to the return code after this
* command is executed by kernel */
int result;
};
This system call is not atomic when updating the epoll descriptor.
All entries in cmds are executed in the order provided. If any cmds
entry fails to be processed no further entries are processed and
the number of successfully processed entries is returned.
Each single operation defined by a struct epoll_ctl_cmd has the same
semantics as an epoll_ctl(2) call. See the epoll_ctl() manual page
for more information about how to correctly setup the members of a
struct epoll_ctl_cmd.
Upon completion of the call the result member of each struct
epoll_ctl_cmd
may be set to 0 (sucessfully completed) or an error code depending on the
result of the command. If the kernel fails to change the result (for
example the location of the cmds argument is fully or partly read only)
the result member of each struct epoll_ctl_cmd may be unchanged.
RETURN VALUE
epoll_ctl_batch() returns a number greater than 0 to indicate the number
of cmnd entries processed. If all entries have been processed this will
equal the ncmds parameter passed in.
If one or more parameters are incorrect the value returned is -1 with
errno set appropriately - no cmds entries have been processed when this
happens.
If processing any entry in the cmds argument results in an error the
number returned is the number of the failing entry - this number will be
less than ncmds. Since ncmds must be greater than 0 a return value of
0 indicates an error associated with the very first cmds entry.
A return value of 0 does not indicate a successful system call.
To correctly test the return value from epoll_ctl_batch() use code
similar
to the following:
ret=epoll_ctl_batch(epfd, flags, ncmds, );
if (ret < ncmds) {
if (ret == -1) {
/* An argument was invalid */
} else {
/* ret contains the number of successful entries
* processed. If you (mis?)use it as a C index
it
* will index directly to the failing entry to
* get the result use cmds[ret].result which
may
* contain the errno value associated with the
* entry.
*/
}
} else {
/* Success */
}
ERRORS
EINVAL flags is non-zero, or ncmds is less than or equal to zero, or
cmds is NULL.
ENOMEM There was insufficient memory to handle the requested op control
operation.
EFAULT The memory area pointed to by cmds is not accessible with read
permissions.
In the event that the
RE: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
I found the manual pages really confusing so I had a go at rewriting
them - there were places in the manual page that didn't match the
functionality provided by your code as well as I could tell).
My apologies for a few formatting issues though. I still don't like
parts of epoll_pwait1 but it's less confusing than it was.
You are free to take some or all or none of the changes.
I did have a question I marked with below about what you
describe and what your code does.
1) epoll_ctl_batch
--
NAME
epoll_ctl_batch - batch control interface for an epoll descriptor
SYNOPSIS
#include sys/epoll.h
int epoll_ctl_batch(int epfd, int flags,
int ncmds, struct epoll_ctl_cmd *cmds);
DESCRIPTION
This system call is an extension of epoll_ctl(). The primary
difference is that this system call allows you to batch multiple
operations with the one system call. This provides a more efficient
interface for updating events on this epoll file descriptor epfd.
The flags argument is reserved and must be 0.
The argument ncmds is the number of cmds entries being passed in.
This number must be greater than 0.
Each operation is specified as an element in the cmds array, defined as:
struct epoll_ctl_cmd {
/* Reserved flags for future extension, must be 0. */
int flags;
/* The same as epoll_ctl() op parameter. */
int op;
/* The same as epoll_ctl() fd parameter. */
int fd;
/* The same as the events field in struct epoll_event. */
uint32_t events;
/* The same as the data field in struct epoll_event. */
uint64_t data;
/* Output field, will be set to the return code after this
* command is executed by kernel */
int result;
};
This system call is not atomic when updating the epoll descriptor.
All entries in cmds are executed in the order provided. If any cmds
entry fails to be processed no further entries are processed and
the number of successfully processed entries is returned.
Each single operation defined by a struct epoll_ctl_cmd has the same
semantics as an epoll_ctl(2) call. See the epoll_ctl() manual page
for more information about how to correctly setup the members of a
struct epoll_ctl_cmd.
Upon completion of the call the result member of each struct
epoll_ctl_cmd
may be set to 0 (sucessfully completed) or an error code depending on the
result of the command. If the kernel fails to change the result (for
example the location of the cmds argument is fully or partly read only)
the result member of each struct epoll_ctl_cmd may be unchanged.
RETURN VALUE
epoll_ctl_batch() returns a number greater than 0 to indicate the number
of cmnd entries processed. If all entries have been processed this will
equal the ncmds parameter passed in.
If one or more parameters are incorrect the value returned is -1 with
errno set appropriately - no cmds entries have been processed when this
happens.
If processing any entry in the cmds argument results in an error the
number returned is the number of the failing entry - this number will be
less than ncmds. Since ncmds must be greater than 0 a return value of
0 indicates an error associated with the very first cmds entry.
A return value of 0 does not indicate a successful system call.
To correctly test the return value from epoll_ctl_batch() use code
similar
to the following:
ret=epoll_ctl_batch(epfd, flags, ncmds, cmds);
if (ret ncmds) {
if (ret == -1) {
/* An argument was invalid */
} else {
/* ret contains the number of successful entries
* processed. If you (mis?)use it as a C index
it
* will index directly to the failing entry to
* get the result use cmds[ret].result which
may
* contain the errno value associated with the
* entry.
*/
}
} else {
/* Success */
}
ERRORS
EINVAL flags is non-zero, or ncmds is less than or equal to zero, or
cmds is NULL.
ENOMEM There was insufficient memory to handle the requested op control
operation.
EFAULT The memory area pointed to by cmds is not accessible with read
permissions.
In the event
3.10.0-rcX vmstat regression
Hello, x86_64 with 32 bit user space, seen on all 3.10.0-rc's A typical 'vmstat 1' run looks like this: ~$ vmstat 1 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 3624776 26060 209808 0 0 1232 7 399 463 1 0 81 18 0 0 0 3624816 26060 209856 0 0 0 0 625 526 0 0 100 0 0 0 0 3624612 26064 209852 0 0 456 1174 1574 0 0 99 1 1 0 0 3624652 26064 209900 0 0 4 0 1501 2126 0 0 100 0 1 0 0 3624576 26076 209888 0 0 8 132 1299 1941 0 0 98 2 1 0 0 3624044 26088 210268 0 0 380 0 1642 2996 0 0 93 7 1 0 0 3628992 26140 219896 0 0 2783 7 1727 3284 0 0 85 15 0 1 0 3588504 26288 244572 0 0 5955 0 2096 3874 0 0 27 73 1 2 0 3572732 26428 253152 0 0 8792 212 1730 2374 0 0 27 73 1 7 0 3566128 26492 257696 0 0 1915 268 1832 2885 0 0 11 89 5 37 0 3527996 26576 270212 0 0 5668 0 2382 5117 0 0 9 91 3 3 0 3471676 26668 284616 0 0 850412 2334 4502 0 0 15 85 1 5 0 3485732 26852 264932 0 0 4556 0 1861 3648 0 0 8 92 3 4 0 3438112 26872 270956 0 0 1822 0 1770 5000 0 0 0 100 5 2 0 3405560 26916 274628 0 0 341396 2360 5571 0 0 9 91 5 1 0 3378800 26952 273024 0 0 1805 0 1968 4489 0 0 0 100 Floating point exception Two problems are shown: the floating point exception and the user and system stats are always 0, it looks like us and sys time are showing up as wait time. CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ_FULL_ALL=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set Sorry if this report is a duplicate, Shane -- 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/
3.10.0-rcX vmstat regression
Hello, x86_64 with 32 bit user space, seen on all 3.10.0-rc's A typical 'vmstat 1' run looks like this: ~$ vmstat 1 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 3624776 26060 209808 0 0 1232 7 399 463 1 0 81 18 0 0 0 3624816 26060 209856 0 0 0 0 625 526 0 0 100 0 0 0 0 3624612 26064 209852 0 0 456 1174 1574 0 0 99 1 1 0 0 3624652 26064 209900 0 0 4 0 1501 2126 0 0 100 0 1 0 0 3624576 26076 209888 0 0 8 132 1299 1941 0 0 98 2 1 0 0 3624044 26088 210268 0 0 380 0 1642 2996 0 0 93 7 1 0 0 3628992 26140 219896 0 0 2783 7 1727 3284 0 0 85 15 0 1 0 3588504 26288 244572 0 0 5955 0 2096 3874 0 0 27 73 1 2 0 3572732 26428 253152 0 0 8792 212 1730 2374 0 0 27 73 1 7 0 3566128 26492 257696 0 0 1915 268 1832 2885 0 0 11 89 5 37 0 3527996 26576 270212 0 0 5668 0 2382 5117 0 0 9 91 3 3 0 3471676 26668 284616 0 0 850412 2334 4502 0 0 15 85 1 5 0 3485732 26852 264932 0 0 4556 0 1861 3648 0 0 8 92 3 4 0 3438112 26872 270956 0 0 1822 0 1770 5000 0 0 0 100 5 2 0 3405560 26916 274628 0 0 341396 2360 5571 0 0 9 91 5 1 0 3378800 26952 273024 0 0 1805 0 1968 4489 0 0 0 100 Floating point exception Two problems are shown: the floating point exception and the user and system stats are always 0, it looks like us and sys time are showing up as wait time. CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ_FULL_ALL=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set Sorry if this report is a duplicate, Shane -- 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/
[RFC] Implementing tape statistics
Before you start reading this I want to apologize in advance for the length of this email. The length is important though to make sure all of the arguments and counter-arguments are represented in asking for feedback about how tape statistics would be best implemented. There is some demand for the provision of tape IO statistics by users of the enterprise distributions, in particular those possessing large scale tape libraries. The provision of interfaces for getting statistics about tape I/O for use by utilities such as sar is a feature present in most commercial UNIX distributions. Several patches have been produced and presented to linux-scsi mailing list but it seems that there are differences of opinion that cannot be reconciled and hence currently no acceptance of the proposed solutions. I have therefore decided to post to the wider kernel list to see if we can come to some consensus on what one of these (or other) should be adopted. No patches are presented in this email for the sake of brevity, it's only a summary of the implementation and consequences along with discussion points for each. Note that this is not an attempt to work around the feedback gained on the linux-scsi mailing list but an attempt to get a wider consensus on what would be an acceptable implementation of a tape statistics interface. Option #1 = Provide device based stats vis sysfs: /sys/class/scsi_tape/stNN/stats (where NN is the tape device instance number) The stat file provides the following in a one line entry suitable for a single fgets() and processing by sscanf(): +/* Tape stats */ + u64 read_byte_cnt; /* bytes read since tape open */ + u64 write_byte_cnt; /* bytes written since tape open */ + u64 in_flight; /* Number of I/Os in flight */ + u64 read_cnt; /* Count of read requests since tape open */ + u64 write_cnt; /* Count of write requests since tape open */ + u64 other_cnt; /* Count of other requests since tape open + either implicit (from driver) or from + user space via ioctl. */ + u64 read_ticks; /* Ticks spent completing read requests */ + u64 write_ticks;/* Ticks spent completing write requests */ + u64 io_ticks; /* Ticks spent doing any I/O */ + u64 stamp; /* holds time request was queued */ The file contents are almost the same as the stat file for disks except the merge statistics are always 0 (since tape drives are sequential merged I/Os don't make sense) and the inflight value is almost always either a 0 or 1 since the st module always only has either one read or write outstanding. An additional field is added to the end of the file - a count of other I/Os - this could be commands issued by the driver within the kernel (e.g. rewind) or via an ioctl from user space. For tape drives some commands involving actions like tape movement can take a long time, it's important to keep track of scsi requests sent to the tape drive other than reads and writes so when delays happen they can be explained. With some future patches to iostat this data will be reported, an example set of data is (the extra other_cnt data allows an average wait for all (a_await) and other I/Os per second (oio/s)): tape: wr/s KiB_write/srd/s KiB_read/s r_await w_await a_await oio/s st0 186.50 46.750.000.000.0000.2760.276 0.00 st1 186.00 93.000.000.000.0000.1800.180 0.00 st2 0.00 0.00 181.50 45.500.3470.0000.347 0.00 st3 0.00 0.00 183.00 45.750.2240.0000.224 0.00 ## This is our preferred method of implementation since it is efficient for both kernel and user-space (also requires fewest code changes), it also matches that already presented for the disk block subsys, see for example: # grep . /sys/block/sd*/stat /sys/block/sda/stat: 27351 6890 609272 22812936810 920727 7660304 13339500 556889 1562009 /sys/block/sdb/stat:2369 6762188903900300 000 405939002 ## SCSI maintainers counter-point: "I'm afraid we can't do it the way you're proposing. files in sysfs must conform to the one value per file rule (so we avoid the ABI nastiness that plagues /proc). You can create a stat directory with a bunch of files, but not a single file that gives all values. ## My counter: I can only assume it (sysfs blk_subsys stat file) was implemented this way for the sake of efficiency, eg avoid a huge amount of file open/read/close calls in sar/iostat. It's not unusual for us to see over a thousand block devices on enterprise servers, multiply that by the number of above entries and you would be talking about 9 x block-dev-count per iostat read
[RFC] Implementing tape statistics
Before you start reading this I want to apologize in advance for the length of this email. The length is important though to make sure all of the arguments and counter-arguments are represented in asking for feedback about how tape statistics would be best implemented. There is some demand for the provision of tape IO statistics by users of the enterprise distributions, in particular those possessing large scale tape libraries. The provision of interfaces for getting statistics about tape I/O for use by utilities such as sar is a feature present in most commercial UNIX distributions. Several patches have been produced and presented to linux-scsi mailing list but it seems that there are differences of opinion that cannot be reconciled and hence currently no acceptance of the proposed solutions. I have therefore decided to post to the wider kernel list to see if we can come to some consensus on what one of these (or other) should be adopted. No patches are presented in this email for the sake of brevity, it's only a summary of the implementation and consequences along with discussion points for each. Note that this is not an attempt to work around the feedback gained on the linux-scsi mailing list but an attempt to get a wider consensus on what would be an acceptable implementation of a tape statistics interface. Option #1 = Provide device based stats vis sysfs: /sys/class/scsi_tape/stNN/stats (where NN is the tape device instance number) The stat file provides the following in a one line entry suitable for a single fgets() and processing by sscanf(): +/* Tape stats */ + u64 read_byte_cnt; /* bytes read since tape open */ + u64 write_byte_cnt; /* bytes written since tape open */ + u64 in_flight; /* Number of I/Os in flight */ + u64 read_cnt; /* Count of read requests since tape open */ + u64 write_cnt; /* Count of write requests since tape open */ + u64 other_cnt; /* Count of other requests since tape open + either implicit (from driver) or from + user space via ioctl. */ + u64 read_ticks; /* Ticks spent completing read requests */ + u64 write_ticks;/* Ticks spent completing write requests */ + u64 io_ticks; /* Ticks spent doing any I/O */ + u64 stamp; /* holds time request was queued */ The file contents are almost the same as the stat file for disks except the merge statistics are always 0 (since tape drives are sequential merged I/Os don't make sense) and the inflight value is almost always either a 0 or 1 since the st module always only has either one read or write outstanding. An additional field is added to the end of the file - a count of other I/Os - this could be commands issued by the driver within the kernel (e.g. rewind) or via an ioctl from user space. For tape drives some commands involving actions like tape movement can take a long time, it's important to keep track of scsi requests sent to the tape drive other than reads and writes so when delays happen they can be explained. With some future patches to iostat this data will be reported, an example set of data is (the extra other_cnt data allows an average wait for all (a_await) and other I/Os per second (oio/s)): tape: wr/s KiB_write/srd/s KiB_read/s r_await w_await a_await oio/s st0 186.50 46.750.000.000.0000.2760.276 0.00 st1 186.00 93.000.000.000.0000.1800.180 0.00 st2 0.00 0.00 181.50 45.500.3470.0000.347 0.00 st3 0.00 0.00 183.00 45.750.2240.0000.224 0.00 ## This is our preferred method of implementation since it is efficient for both kernel and user-space (also requires fewest code changes), it also matches that already presented for the disk block subsys, see for example: # grep . /sys/block/sd*/stat /sys/block/sda/stat: 27351 6890 609272 22812936810 920727 7660304 13339500 556889 1562009 /sys/block/sdb/stat:2369 6762188903900300 000 405939002 ## SCSI maintainers counter-point: I'm afraid we can't do it the way you're proposing. files in sysfs must conform to the one value per file rule (so we avoid the ABI nastiness that plagues /proc). You can create a stat directory with a bunch of files, but not a single file that gives all values. ## My counter: I can only assume it (sysfs blk_subsys stat file) was implemented this way for the sake of efficiency, eg avoid a huge amount of file open/read/close calls in sar/iostat. It's not unusual for us to see over a thousand block devices on enterprise servers, multiply that by the number of above entries and you would be talking about 9 x block-dev-count per iostat read
RE: [3.8-{rc1,rc2}] ata1.00: failed to get Identify Device Data, Emask 0x1
> OK, I see the patch I mentioned to fix the problem was later reverted [1]. > The real fix is "libata: replace sata_settings with devslp_timing" [2]. Yes, please use [2] which can also be found in kernel bugzilla #51881 and is pending on Jeff's acceptance. Sorry for the trouble to you guys. Thanks, Shane
RE: [3.8-{rc1,rc2}] ata1.00: failed to get Identify Device Data, Emask 0x1
OK, I see the patch I mentioned to fix the problem was later reverted [1]. The real fix is libata: replace sata_settings with devslp_timing [2]. Yes, please use [2] which can also be found in kernel bugzilla #51881 and is pending on Jeff's acceptance. Sorry for the trouble to you guys. Thanks, Shane
[PATCH v2] MIPS: MSP71xx: Move include files
Now that Yosemite's gone we can move the MSP71xx include files
one level up.
Signed-off-by: Shane McDonald
---
Patch history:
V1: Original patch
V2: Use format-patch's -M option to indicate file renames
.../cpu-feature-overrides.h|0
.../msp71xx => mach-pmcs-msp71xx}/gpio.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_cic_int.h|0
.../msp_gpio_macros.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_int.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_pci.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_prom.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_regops.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_regs.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_slp_int.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_usb.h|0
.../msp71xx => mach-pmcs-msp71xx}/war.h|0
arch/mips/pmcs-msp71xx/Platform|2 +-
13 files changed, 1 insertions(+), 1 deletions(-)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/cpu-feature-overrides.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx => mach-pmcs-msp71xx}/gpio.h
(100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_cic_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_gpio_macros.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_pci.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_prom.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_regops.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_regs.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_slp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_usb.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx => mach-pmcs-msp71xx}/war.h
(100%)
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
diff --git a/arch/mips/include/asm/pmc-s
[PATCH v2] MIPS: MSP71xx: Move include files
Now that Yosemite's gone we can move the MSP71xx include files
one level up.
Signed-off-by: Shane McDonald mcdonald.sh...@gmail.com
---
Patch history:
V1: Original patch
V2: Use format-patch's -M option to indicate file renames
.../cpu-feature-overrides.h|0
.../msp71xx = mach-pmcs-msp71xx}/gpio.h |0
.../msp71xx = mach-pmcs-msp71xx}/msp_cic_int.h|0
.../msp_gpio_macros.h |0
.../msp71xx = mach-pmcs-msp71xx}/msp_int.h|0
.../msp71xx = mach-pmcs-msp71xx}/msp_pci.h|0
.../msp71xx = mach-pmcs-msp71xx}/msp_prom.h |0
.../msp71xx = mach-pmcs-msp71xx}/msp_regops.h |0
.../msp71xx = mach-pmcs-msp71xx}/msp_regs.h |0
.../msp71xx = mach-pmcs-msp71xx}/msp_slp_int.h|0
.../msp71xx = mach-pmcs-msp71xx}/msp_usb.h|0
.../msp71xx = mach-pmcs-msp71xx}/war.h|0
arch/mips/pmcs-msp71xx/Platform|2 +-
13 files changed, 1 insertions(+), 1 deletions(-)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/cpu-feature-overrides.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx = mach-pmcs-msp71xx}/gpio.h
(100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_cic_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_gpio_macros.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_pci.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_prom.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_regops.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_regs.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_slp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =
mach-pmcs-msp71xx}/msp_usb.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx = mach-pmcs-msp71xx}/war.h
(100%)
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_usb.h
b/arch/mips/include/asm/mach-pmcs-msp71xx
MIPS: MSP71xx: Indicate new location of source files in Platform file
The source files for the MSP71xx support code have been moved in commit 13a347ef60c68e490809dad8fcf79c25eabc4d58, "MIPS: MSP71xx: Move code." Update the Platform file to indicate the new location. Signed-off-by: Shane McDonald --- arch/mips/pmcs-msp71xx/Platform |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/pmcs-msp71xx/Platform b/arch/mips/pmcs-msp71xx/Platform index 17299f9..9a86e29 100644 --- a/arch/mips/pmcs-msp71xx/Platform +++ b/arch/mips/pmcs-msp71xx/Platform @@ -1,7 +1,7 @@ # # PMC-Sierra MSP SOCs # -platform-$(CONFIG_PMC_MSP) += pmc-sierra/ -cflags-$(CONFIG_PMC_MSP) += -I$(srctree)/arch/mips/include/asm/pmc-sierra \ +platform-$(CONFIG_PMC_MSP) += pmcs-msp71xx/ +cflags-$(CONFIG_PMC_MSP) += -I$(srctree)/arch/mips/include/asm/pmc-sierra/msp71xx \ -mno-branch-likely load-$(CONFIG_PMC_MSP) += 0x8010 -- 1.7.2.5 -- 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/
MIPS: MSP71xx: Indicate new location of source files in Platform file
The source files for the MSP71xx support code have been moved in commit 13a347ef60c68e490809dad8fcf79c25eabc4d58, MIPS: MSP71xx: Move code. Update the Platform file to indicate the new location. Signed-off-by: Shane McDonald mcdonald.sh...@gmail.com --- arch/mips/pmcs-msp71xx/Platform |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/pmcs-msp71xx/Platform b/arch/mips/pmcs-msp71xx/Platform index 17299f9..9a86e29 100644 --- a/arch/mips/pmcs-msp71xx/Platform +++ b/arch/mips/pmcs-msp71xx/Platform @@ -1,7 +1,7 @@ # # PMC-Sierra MSP SOCs # -platform-$(CONFIG_PMC_MSP) += pmc-sierra/ -cflags-$(CONFIG_PMC_MSP) += -I$(srctree)/arch/mips/include/asm/pmc-sierra \ +platform-$(CONFIG_PMC_MSP) += pmcs-msp71xx/ +cflags-$(CONFIG_PMC_MSP) += -I$(srctree)/arch/mips/include/asm/pmc-sierra/msp71xx \ -mno-branch-likely load-$(CONFIG_PMC_MSP) += 0x8010 -- 1.7.2.5 -- 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: RM9000 / E9000, MSP71xx class processors, SOCs and eval boards
On Thu, Dec 6, 2012 at 10:00 AM, Ralf Baechle wrote: > Folks, > > since many years the support code for those devices is rusting away in > the lmo git tree and frankly, I'd get rid of it because there's been > very few patch submissions or any kind of indication that somebody > still cares. In short, this has turned into a waste of resource not > least my time. > > So, is anybody still interested in maintaining that code? If so, you > better attach a bunch of patches to your reply. > > Ralf > I'm interested in the MSP71xx eval board, although I may be the only person in the world who cares. Specifically, I use the msp71xx_defconfig. 3.7-rc8 compiles with gcc-4.6.3 without requiring any patches. I don't know when the last time the RM9000 was compilable, but I have no interest in that, nor do I have interest in the FPGA or eval board versions of the MSP7120 (no hardware to test with). I had hoped that someone from PMC-Sierra would respond, but maybe they don't care anymore... Shane McDonald -- 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: RM9000 / E9000, MSP71xx class processors, SOCs and eval boards
On Thu, Dec 6, 2012 at 10:00 AM, Ralf Baechle r...@linux-mips.org wrote: Folks, since many years the support code for those devices is rusting away in the lmo git tree and frankly, I'd get rid of it because there's been very few patch submissions or any kind of indication that somebody still cares. In short, this has turned into a waste of resource not least my time. So, is anybody still interested in maintaining that code? If so, you better attach a bunch of patches to your reply. Ralf I'm interested in the MSP71xx eval board, although I may be the only person in the world who cares. Specifically, I use the msp71xx_defconfig. 3.7-rc8 compiles with gcc-4.6.3 without requiring any patches. I don't know when the last time the RM9000 was compilable, but I have no interest in that, nor do I have interest in the FPGA or eval board versions of the MSP7120 (no hardware to test with). I had hoped that someone from PMC-Sierra would respond, but maybe they don't care anymore... Shane McDonald -- 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: ata4.00: failed to get Identify Device Data, Emask 0x1
> I tried word 78 bit 5(Hardware Feature Control) which does not work, > it is 0 on my HDD sample with log 30h page 08h and DevSlp supported. > > Seems that word 78 bit 5 is only the sufficient condition, not the > essential condition. Do you guys have suggestion? Eventually I received the confirmation from the DevSlp HDD vendor, bit 5 should be and will be set in production drives with log 30h page 08h supported. So I will submit a patch to use it instead. Hi Jeff, I don't know when I will receive some production drives to verify my patch, are you okay if I submit my patch first without testing so as to meet kernel 3.7 bug fix window? Thanks, Shane -- 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: ata4.00: failed to get Identify Device Data, Emask 0x1
I tried word 78 bit 5(Hardware Feature Control) which does not work, it is 0 on my HDD sample with log 30h page 08h and DevSlp supported. Seems that word 78 bit 5 is only the sufficient condition, not the essential condition. Do you guys have suggestion? Eventually I received the confirmation from the DevSlp HDD vendor, bit 5 should be and will be set in production drives with log 30h page 08h supported. So I will submit a patch to use it instead. Hi Jeff, I don't know when I will receive some production drives to verify my patch, are you okay if I submit my patch first without testing so as to meet kernel 3.7 bug fix window? Thanks, Shane -- 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: ata4.00: failed to get Identify Device Data, Emask 0x1
> Agree. If NCQ does not imply support of this log page, we should > definitely refine the check condition used here. > > I suppose Shane will take care of this, but if he doesn't, I'll do that > at a later time. I tried word 78 bit 5(Hardware Feature Control) which does not work, it is 0 on my HDD sample with log 30h page 08h and DevSlp supported. Seems that word 78 bit 5 is only the sufficient condition, not the essential condition. Do you guys have suggestion? Quoting SATA spec: > Word 78: Serial ATA features supported > Bit 5 If bit 5 is set to one, then Hardware Feature Control is > supported (see 13.10). If bit 5 is cleared to zero, then Hardware > Feature Control is not supported and IDENTIFY DEVICE data > word 79 bit 5 shall be cleared to zero. > > If Hardware Feature Control is supported, then: > a) IDENTIFY DEVICE data word 78 bit 5 (see 13.2.1.18) shall be > set to one; > b) the SET FEATURES Select Hardware Feature Control subcommand > shall be supported (see 13.3.8); > c) page 08h of the Identify Device Data log (see 13.7.7) shall > be supported; Thanks, Shane -- 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: ata4.00: failed to get Identify Device Data, Emask 0x1
Agree. If NCQ does not imply support of this log page, we should definitely refine the check condition used here. I suppose Shane will take care of this, but if he doesn't, I'll do that at a later time. I tried word 78 bit 5(Hardware Feature Control) which does not work, it is 0 on my HDD sample with log 30h page 08h and DevSlp supported. Seems that word 78 bit 5 is only the sufficient condition, not the essential condition. Do you guys have suggestion? Quoting SATA spec: Word 78: Serial ATA features supported Bit 5 If bit 5 is set to one, then Hardware Feature Control is supported (see 13.10). If bit 5 is cleared to zero, then Hardware Feature Control is not supported and IDENTIFY DEVICE data word 79 bit 5 shall be cleared to zero. If Hardware Feature Control is supported, then: a) IDENTIFY DEVICE data word 78 bit 5 (see 13.2.1.18) shall be set to one; b) the SET FEATURES Select Hardware Feature Control subcommand shall be supported (see 13.3.8); c) page 08h of the Identify Device Data log (see 13.7.7) shall be supported; Thanks, Shane -- 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] PCI: disable the MSI of AMD RS690
Hi Brice: > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, > > quirk_disable_all_msi); > > This patch disable MSI for the _whole_ system, not only behind the > RS690. Is this on purpose? Is MSI really going to be broken on any > bus that's _not_ behind RS690. If not, you might want to use > quirk_disable_msi() instead (as we do for AMD8131). quirk_disable_msi() can not fix the issue in my debug, quirk_msi_intx_disable_bug() which can fix SB700 SATA MSI bug does not work either. quirk_disable_all_msi is the only workaround I found. If there is any other guy who also has one SB600+RS690 board, and can help to verify this RS690 MSI disablement patch with a new kernel version such as 2.6.24-rc7, that's great. BTW: RS690 MSI disablement should NOT affect SB700 MSI, because as I know, there will not be the combination of RS690+SB700 on the market. Thanks Shane -- 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 the MSI of AMD RS690
Hi Brice: +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi); This patch disable MSI for the _whole_ system, not only behind the RS690. Is this on purpose? Is MSI really going to be broken on any bus that's _not_ behind RS690. If not, you might want to use quirk_disable_msi() instead (as we do for AMD8131). quirk_disable_msi() can not fix the issue in my debug, quirk_msi_intx_disable_bug() which can fix SB700 SATA MSI bug does not work either. quirk_disable_all_msi is the only workaround I found. If there is any other guy who also has one SB600+RS690 board, and can help to verify this RS690 MSI disablement patch with a new kernel version such as 2.6.24-rc7, that's great. BTW: RS690 MSI disablement should NOT affect SB700 MSI, because as I know, there will not be the combination of RS690+SB700 on the market. Thanks Shane -- 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: modify SB700 SATA MSI quirk
Hi Tejun: > Okay, here's reformatted in-line version. Shane, please invest some > time into setting up email environment. Sending patches via email is > an important part of the linux kernel development process and if > you're gonna submit patches, you're just gonna have to do it. Right. In fact, I tried to modify some settings before I sent my mail, but it seems that it does not take effect. I will check it again. Sorry for that and thank you for your help~~ Thanks Shane -- 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] PCI: modify SB700 SATA MSI quirk
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware
level,
but the SB700 revision older than A21 will also be found in the market.
This patch modify the original quirk commit
bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
The patch also removes quirk to 0x4395 because 0x4395 is SB800 device
ID.
Signed-off-by: Shane Huang <[EMAIL PROTECTED]>
diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c
linux-2.6.24-rc7_new/drivers/pci/quirks.c
--- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23
14:44:53.0 +0800
+++ linux-2.6.24-rc7_new/drivers/pci/quirks.c 2008-01-25
12:55:05.0 +0800
@@ -1709,6 +1709,23 @@
{
dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700
+* revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS,
+ NULL);
+ if (!p)
+ return;
+
+ if ((p->revision < 0x3B) && (p->revision >= 0x30))
+ dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ pci_dev_put(p);
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1746,15 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
Thanks
Shane
modify_SB700_MSI_3.patch
Description: modify_SB700_MSI_3.patch
RE: [patch] PCI: modify SB700 SATA MSI quirk
Hi Tejun: > You need to merge the above two messages into one patch description. > > After S-O-B, you can put --- and between it and the patch > body, you can say things which you wanna mention but don't > think should be included in commit message. OK, I'll have to submit another update patch later. Thanks Shane -- 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: modify SB700 SATA MSI quirk
I did some modification to this patch and send it again, Please check
it.
The quirk to 0x4395 has been removed because 0x4395 only belongs to
SB800.
Thanks
Shane
> -Original Message-
> From: Shane Huang
>
> SB700 SATA MSI bug will be fixed in SB700 revision A21 at
> hardware level,
> but the SB700 revision older than A21 will also be found in
> the market.
> This patch modify the original quirk commit
> bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
>
>
> Signed-off-by: Shane Huang <[EMAIL PROTECTED]>
diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c
linux-2.6.24-rc7_new/drivers/pci/quirks.c
--- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23
14:44:53.0 +0800
+++ linux-2.6.24-rc7_new/drivers/pci/quirks.c 2008-01-25
10:55:21.0 +0800
@@ -1709,6 +1709,24 @@
{
dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+ u8 rev = 0;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700
+* revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS,
+ NULL);
+ if (p) {
+ pci_read_config_byte(p, PCI_CLASS_REVISION, );
+ }
+ if ((rev < 0x3B) && (rev >= 0x30)) {
+ dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ }
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1747,15 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
modify_SB700_MSI_2.patch
Description: modify_SB700_MSI_2.patch
[patch] PCI: modify SB700 SATA MSI quirk
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware
level,
but the SB700 revision older than A21 will also be found in the market.
This patch modify the original quirk commit
bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
Signed-off-by: Shane Huang <[EMAIL PROTECTED]>
Since there is some word wrapping problem with my mail client MS
outlook, I also attach the patch as an attachment. Please check it.
diff -ruN old/drivers/pci/quirks.c new/drivers/pci/quirks.c
--- old/drivers/pci/quirks.c2008-01-07 05:45:38.0 +0800
+++ new/drivers/pci/quirks.c2008-01-22 11:31:09.0 +0800
@@ -1709,6 +1709,22 @@
{
dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+ u8 rev = 0;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700 revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS, NULL);
+ if (p!=NULL) {
+ pci_read_config_byte(p, PCI_CLASS_REVISION, );
+ }
+ if ((rev < 0x3B) && (rev >= 0x30)) {
+ dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ }
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1745,17 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
Thanks
Best Regards
Shane
modify_SB700_MSI_issue.patch
Description: modify_SB700_MSI_issue.patch
[patch] PCI: disable the MSI of AMD RS690
This patch recover Tejun's commit 4be8f906435a6af241821ab5b94b2b12cb7d57d8 because there is one MSI bug on RS690+SB600 board which will lead to boot failure. This bug is NOT same as the one in SB700 SATA controller, quirk_msi_intx_disable_bug does not work to SB600. Disablement the MSI of RS690 is the workaround. Signed-off-by: Shane Huang <[EMAIL PROTECTED]> Since there is some word wrapping problem with my mail client MS outlook if I copy the patch into the text, so I'll also attach the patch as an attachment. Please check it. diff -ruN old/drivers/pci/quirks.c new/drivers/pci/quirks.c --- old/drivers/pci/quirks.c2008-01-07 05:45:38.0 +0800 +++ new/drivers/pci/quirks.c2008-01-22 11:02:00.0 +0800 @@ -1623,6 +1623,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); /* Disable MSI on chipsets that are known to not support it */ diff -ruN old/include/linux/pci_ids.h new/include/linux/pci_ids.h --- old/include/linux/pci_ids.h 2008-01-07 05:45:38.0 +0800 +++ new/include/linux/pci_ids.h 2008-01-22 11:01:55.0 +0800 @@ -360,6 +360,7 @@ #define PCI_DEVICE_ID_ATI_RS400_166 0x5a32 #define PCI_DEVICE_ID_ATI_RS400_200 0x5a33 #define PCI_DEVICE_ID_ATI_RS480 0x5950 +#define PCI_DEVICE_ID_ATI_RS690 0x7910 /* ATI IXP Chipset */ #define PCI_DEVICE_ID_ATI_IXP200_IDE 0x4349 #define PCI_DEVICE_ID_ATI_IXP200_SMBUS 0x4353 Thanks Best Regards Shane disable_RS690_MSI.patch Description: disable_RS690_MSI.patch
[patch] PCI: disable the MSI of AMD RS690
This patch recover Tejun's commit 4be8f906435a6af241821ab5b94b2b12cb7d57d8 because there is one MSI bug on RS690+SB600 board which will lead to boot failure. This bug is NOT same as the one in SB700 SATA controller, quirk_msi_intx_disable_bug does not work to SB600. Disablement the MSI of RS690 is the workaround. Signed-off-by: Shane Huang [EMAIL PROTECTED] Since there is some word wrapping problem with my mail client MS outlook if I copy the patch into the text, so I'll also attach the patch as an attachment. Please check it. diff -ruN old/drivers/pci/quirks.c new/drivers/pci/quirks.c --- old/drivers/pci/quirks.c2008-01-07 05:45:38.0 +0800 +++ new/drivers/pci/quirks.c2008-01-22 11:02:00.0 +0800 @@ -1623,6 +1623,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); /* Disable MSI on chipsets that are known to not support it */ diff -ruN old/include/linux/pci_ids.h new/include/linux/pci_ids.h --- old/include/linux/pci_ids.h 2008-01-07 05:45:38.0 +0800 +++ new/include/linux/pci_ids.h 2008-01-22 11:01:55.0 +0800 @@ -360,6 +360,7 @@ #define PCI_DEVICE_ID_ATI_RS400_166 0x5a32 #define PCI_DEVICE_ID_ATI_RS400_200 0x5a33 #define PCI_DEVICE_ID_ATI_RS480 0x5950 +#define PCI_DEVICE_ID_ATI_RS690 0x7910 /* ATI IXP Chipset */ #define PCI_DEVICE_ID_ATI_IXP200_IDE 0x4349 #define PCI_DEVICE_ID_ATI_IXP200_SMBUS 0x4353 Thanks Best Regards Shane disable_RS690_MSI.patch Description: disable_RS690_MSI.patch
[patch] PCI: modify SB700 SATA MSI quirk
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware
level,
but the SB700 revision older than A21 will also be found in the market.
This patch modify the original quirk commit
bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
Signed-off-by: Shane Huang [EMAIL PROTECTED]
Since there is some word wrapping problem with my mail client MS
outlook, I also attach the patch as an attachment. Please check it.
diff -ruN old/drivers/pci/quirks.c new/drivers/pci/quirks.c
--- old/drivers/pci/quirks.c2008-01-07 05:45:38.0 +0800
+++ new/drivers/pci/quirks.c2008-01-22 11:31:09.0 +0800
@@ -1709,6 +1709,22 @@
{
dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+ u8 rev = 0;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700 revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS, NULL);
+ if (p!=NULL) {
+ pci_read_config_byte(p, PCI_CLASS_REVISION, rev);
+ }
+ if ((rev 0x3B) (rev = 0x30)) {
+ dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ }
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1745,17 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
Thanks
Best Regards
Shane
modify_SB700_MSI_issue.patch
Description: modify_SB700_MSI_issue.patch
RE: [patch] PCI: modify SB700 SATA MSI quirk
I did some modification to this patch and send it again, Please check
it.
The quirk to 0x4395 has been removed because 0x4395 only belongs to
SB800.
Thanks
Shane
-Original Message-
From: Shane Huang
SB700 SATA MSI bug will be fixed in SB700 revision A21 at
hardware level,
but the SB700 revision older than A21 will also be found in
the market.
This patch modify the original quirk commit
bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
Signed-off-by: Shane Huang [EMAIL PROTECTED]
diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c
linux-2.6.24-rc7_new/drivers/pci/quirks.c
--- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23
14:44:53.0 +0800
+++ linux-2.6.24-rc7_new/drivers/pci/quirks.c 2008-01-25
10:55:21.0 +0800
@@ -1709,6 +1709,24 @@
{
dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+ u8 rev = 0;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700
+* revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS,
+ NULL);
+ if (p) {
+ pci_read_config_byte(p, PCI_CLASS_REVISION, rev);
+ }
+ if ((rev 0x3B) (rev = 0x30)) {
+ dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ }
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1747,15 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
modify_SB700_MSI_2.patch
Description: modify_SB700_MSI_2.patch
RE: [patch] PCI: modify SB700 SATA MSI quirk
Hi Tejun: You need to merge the above two messages into one patch description. After S-O-B, you can put --- and between it and the patch body, you can say things which you wanna mention but don't think should be included in commit message. OK, I'll have to submit another update patch later. Thanks Shane -- 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] PCI: modify SB700 SATA MSI quirk
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware
level,
but the SB700 revision older than A21 will also be found in the market.
This patch modify the original quirk commit
bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it.
The patch also removes quirk to 0x4395 because 0x4395 is SB800 device
ID.
Signed-off-by: Shane Huang [EMAIL PROTECTED]
diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c
linux-2.6.24-rc7_new/drivers/pci/quirks.c
--- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23
14:44:53.0 +0800
+++ linux-2.6.24-rc7_new/drivers/pci/quirks.c 2008-01-25
12:55:05.0 +0800
@@ -1709,6 +1709,23 @@
{
dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
}
+static void __devinit quirk_msi_intx_disable_ati_bug(struct pci_dev
*dev)
+{
+ struct pci_dev *p;
+
+ /* SB700 MSI issue will be fixed at HW level from revision A21,
+* we need check PCI REVISION ID of SMBus controller to get
SB700
+* revision.
+*/
+ p = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS,
+ NULL);
+ if (!p)
+ return;
+
+ if ((p-revision 0x3B) (p-revision = 0x30))
+ dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+ pci_dev_put(p);
+}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
PCI_DEVICE_ID_TIGON3_5780,
quirk_msi_intx_disable_bug);
@@ -1729,17 +1746,15 @@
quirk_msi_intx_disable_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394,
- quirk_msi_intx_disable_bug);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395,
- quirk_msi_intx_disable_bug);
+ quirk_msi_intx_disable_ati_bug);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373,
quirk_msi_intx_disable_bug);
Thanks
Shane
modify_SB700_MSI_3.patch
Description: modify_SB700_MSI_3.patch
RE: [PATCH] PCI: modify SB700 SATA MSI quirk
Hi Tejun: Okay, here's reformatted in-line version. Shane, please invest some time into setting up email environment. Sending patches via email is an important part of the linux kernel development process and if you're gonna submit patches, you're just gonna have to do it. Right. In fact, I tried to modify some settings before I sent my mail, but it seems that it does not take effect. I will check it again. Sorry for that and thank you for your help~~ Thanks Shane -- 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] videobuf-core.c locking fixes
> Yes it does! I was just going to send the same patch myself :) But, I am now seeing some errors that weren't there in 2.6.23 kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). These happen occasionally and it causes an EIO DQBUF error and the application has to re queue the buffers but it recovers OK. Not sure if it causes some sort of internal kernel corruption that will only be noticed later possibly? I am using 15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- 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] videobuf-core.c locking fixes
On Dec 12, 2007 2:44 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote:
> > On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote:
> > > On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > ...
> > > > The proper solution is provided by this changeset:
> > > > http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc
> > >
> > > I applied this and it seems fine with a bttv card.
> >
> > Ugh, after further testing with a bttv card it seems this is not fine.
> >
> > vbi doesn't work anymore and my application gets stuck in a Zombie,
> > unkillable, have to reboot state :(
> >
> > mythtv3683 1 -3 2.4 0.0 0 0 ?Z > 00:00:06 [mythbackend]
> >
> > Reverting Mauro's patch above does fix the problem.
>
> Thanks for testing, does the patch below fix it?
>
> > Shane
>
> cu
> Adrian
>
>
> <-- snip -->
>
>
> After commit 19fb1457990b6b7e15586ec7331541a184233acc the callers in
> videobuf-core.c that already hold the lock must call
> __videobuf_read_start() instead of videobuf_read_start().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/media/video/videobuf-core.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> e1f8b4a49d86746f699919531c17fd154787e308
> diff --git a/drivers/media/video/videobuf-core.c
> b/drivers/media/video/videobuf-core.c
> index 81f77d2..c8a5cb5 100644
> --- a/drivers/media/video/videobuf-core.c
> +++ b/drivers/media/video/videobuf-core.c
> @@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
> if (q->streaming)
> goto done;
> if (!q->reading) {
> - retval = videobuf_read_start(q);
> + retval = __videobuf_read_start(q);
> if (retval < 0)
> goto done;
> }
> @@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
> struct videobuf_buffer, stream);
> } else {
> if (!q->reading)
> - videobuf_read_start(q);
> + __videobuf_read_start(q);
> if (!q->reading) {
> rc = POLLERR;
> } else if (NULL == q->read_buf) {
>
Yes it does! I was just going to send the same patch myself :)
Shane
--
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.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!
On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > ... > > The proper solution is provided by this changeset: > > http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc > > I applied this and it seems fine with a bttv card. Ugh, after further testing with a bttv card it seems this is not fine. vbi doesn't work anymore and my application gets stuck in a Zombie, unkillable, have to reboot state :( mythtv3683 1 -3 2.4 0.0 0 0 ?Z Reverting Mauro's patch above does fix the problem. Shane -- 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.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: ... > The proper solution is provided by this changeset: > http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc I applied this and it seems fine with a bttv card. Mauro and Adrian, Thanks for your prompt attention to this and for promptly pushing the fix to Linus. Regards, Shane -- 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.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: ... The proper solution is provided by this changeset: http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc I applied this and it seems fine with a bttv card. Mauro and Adrian, Thanks for your prompt attention to this and for promptly pushing the fix to Linus. Regards, Shane -- 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.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
On Dec 12, 2007 11:37 AM, Shane [EMAIL PROTECTED] wrote: On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: ... The proper solution is provided by this changeset: http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc I applied this and it seems fine with a bttv card. Ugh, after further testing with a bttv card it seems this is not fine. vbi doesn't work anymore and my application gets stuck in a Zombie, unkillable, have to reboot state :( mythtv3683 1 -3 2.4 0.0 0 0 ?Zl 13:40:35 00:00:06 [mythbackend] defunct Reverting Mauro's patch above does fix the problem. Shane -- 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] videobuf-core.c locking fixes
On Dec 12, 2007 2:44 PM, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote:
On Dec 12, 2007 11:37 AM, Shane [EMAIL PROTECTED] wrote:
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
...
The proper solution is provided by this changeset:
http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc
I applied this and it seems fine with a bttv card.
Ugh, after further testing with a bttv card it seems this is not fine.
vbi doesn't work anymore and my application gets stuck in a Zombie,
unkillable, have to reboot state :(
mythtv3683 1 -3 2.4 0.0 0 0 ?Zl 13:40:35
00:00:06 [mythbackend] defunct
Reverting Mauro's patch above does fix the problem.
Thanks for testing, does the patch below fix it?
Shane
cu
Adrian
-- snip --
After commit 19fb1457990b6b7e15586ec7331541a184233acc the callers in
videobuf-core.c that already hold the lock must call
__videobuf_read_start() instead of videobuf_read_start().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/videobuf-core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
e1f8b4a49d86746f699919531c17fd154787e308
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 81f77d2..c8a5cb5 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
if (q-streaming)
goto done;
if (!q-reading) {
- retval = videobuf_read_start(q);
+ retval = __videobuf_read_start(q);
if (retval 0)
goto done;
}
@@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
struct videobuf_buffer, stream);
} else {
if (!q-reading)
- videobuf_read_start(q);
+ __videobuf_read_start(q);
if (!q-reading) {
rc = POLLERR;
} else if (NULL == q-read_buf) {
Yes it does! I was just going to send the same patch myself :)
Shane
--
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] videobuf-core.c locking fixes
Yes it does! I was just going to send the same patch myself :) But, I am now seeing some errors that weren't there in 2.6.23 kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). These happen occasionally and it causes an EIO DQBUF error and the application has to re queue the buffers but it recovers OK. Not sure if it causes some sort of internal kernel corruption that will only be noticed later possibly? I am using 15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- 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/
2.6.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!
In 2.6.24-rc5+, I hit this problem with videobuf_read_start not being exported. Patch attached, only compile tested. CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CC [M] drivers/media/video/videobuf-core.o Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 202 modules ERROR: "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Shane diff --git a/drivers/media/video/videobuf-core.c b/drivers/media/video/videobuf-core.c index de2f56b..44fa76b 100644 --- a/drivers/media/video/videobuf-core.c +++ b/drivers/media/video/videobuf-core.c @@ -1058,6 +1058,7 @@ EXPORT_SYMBOL_GPL(videobuf_dqbuf); EXPORT_SYMBOL_GPL(videobuf_streamon); EXPORT_SYMBOL_GPL(videobuf_streamoff); +EXPORT_SYMBOL_GPL(videobuf_read_start); EXPORT_SYMBOL_GPL(videobuf_read_stop); EXPORT_SYMBOL_GPL(videobuf_stop); EXPORT_SYMBOL_GPL(videobuf_read_stream);
2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
In 2.6.24-rc5+, I hit this problem with videobuf_read_start not being exported. Patch attached, only compile tested. CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CC [M] drivers/media/video/videobuf-core.o Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 202 modules ERROR: videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Shane diff --git a/drivers/media/video/videobuf-core.c b/drivers/media/video/videobuf-core.c index de2f56b..44fa76b 100644 --- a/drivers/media/video/videobuf-core.c +++ b/drivers/media/video/videobuf-core.c @@ -1058,6 +1058,7 @@ EXPORT_SYMBOL_GPL(videobuf_dqbuf); EXPORT_SYMBOL_GPL(videobuf_streamon); EXPORT_SYMBOL_GPL(videobuf_streamoff); +EXPORT_SYMBOL_GPL(videobuf_read_start); EXPORT_SYMBOL_GPL(videobuf_read_stop); EXPORT_SYMBOL_GPL(videobuf_stop); EXPORT_SYMBOL_GPL(videobuf_read_stream);
Re: 2.6.24-rc3-git4 NFS crossmnt regression
On Dec 10, 2007 9:19 AM, Maxim Levitsky <[EMAIL PROTECTED]> wrote: > ... > > It is best not to use nohide - we should probably mark it as > > 'legacy'. > > > > Simply export the top level mountpoint as 'crossmnt' and everything > > below there will be exported. > > > > > Where should I put those options in root file-system export or in > > > submount export? > > > > crossmnt goes at the top. nohide goes in the submount. Both have > > the same general effect though with subtle differences. > > You don't need both (though that doesn't hurt). > > Just use crossmnt at the top, Then you don't need to mention the > > lower level filesystems at all. > > > > > > ... > > > (I decided to switch to NFS4 only due to the lack of ability to see > > > underlying mounts) > > > > > > > All of this should work fine with v3. Once you have the right patch > > for the crossmnt bug applied, if you have further problems post them > > to [EMAIL PROTECTED] > > > > NeilBrown > > > > Big thanks, > > Still NFS server just don't want to accept the connection > I noticed that if I first mount with > -tnfs, unmount, and then mount with -tnfs4, it works > > > Assuming that > [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate > is the fix for crossmnt bug, I applied it to both client and server, > but no luck. I'm using NFSv3, but I applied two patches. The one you mention from Eric and the patch Trond posted in this thread. > > Still see empty folders. That was the symptom I had without Trond's patch. Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 10, 2007 9:19 AM, Maxim Levitsky [EMAIL PROTECTED] wrote: ... It is best not to use nohide - we should probably mark it as 'legacy'. Simply export the top level mountpoint as 'crossmnt' and everything below there will be exported. Where should I put those options in root file-system export or in submount export? crossmnt goes at the top. nohide goes in the submount. Both have the same general effect though with subtle differences. You don't need both (though that doesn't hurt). Just use crossmnt at the top, Then you don't need to mention the lower level filesystems at all. ... (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts) All of this should work fine with v3. Once you have the right patch for the crossmnt bug applied, if you have further problems post them to [EMAIL PROTECTED] NeilBrown Big thanks, Still NFS server just don't want to accept the connection I noticed that if I first mount with -tnfs, unmount, and then mount with -tnfs4, it works Assuming that [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate is the fix for crossmnt bug, I applied it to both client and server, but no luck. I'm using NFSv3, but I applied two patches. The one you mention from Eric and the patch Trond posted in this thread. Still see empty folders. That was the symptom I had without Trond's patch. Shane -- 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.24-rc4] proc: Remove/Fix proc generic d_revalidate
On Dec 7, 2007 11:25 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> Ultimately to implement /proc perfectly we need an implementation
> of d_revalidate because files and directories can be removed behind
> the back of the VFS, and d_revalidate is the only way we can let
> the VFS know that this has happened.
>
> Unfortunately the linux VFS can not cope with anything in the path
> to a mount point going away. So a proper d_revalidate method that
> calls d_drop also needs to call have_submounts which is moderately
> expensive, so you really don't want a d_revalidate method that
> unconditionally calls it, but instead only calls it when the
> backing object has really gone away.
>
> proc generic entries only disappear on module_unload (when
> not counting the fledgling network namespace) so it is quite rare
> that we actually encounter that case and has not actually caused
> us real world trouble yet.
>
> So until we get a proper test for keeping dentries in the dcache
> fix the current d_revalidate method by completely removing it. This
> returns us to the current status quo.
>
> So with CONFIG_NETNS=n things should look as they have always looked.
>
> For CONFIG_NETNS=y things work most of the time but there are a few
> rare corner cases that don't behave properly. As the network namespace
> is barely present in 2.6.24 this should not be a problem.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
> fs/proc/generic.c |7 ---
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
> index 8d49838..6a2fe51 100644
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
> return 1;
> }
>
> -static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata
> *nd)
> -{
> - d_drop(dentry);
> - return 0;
> -}
> -
> static struct dentry_operations proc_dentry_operations =
> {
> .d_delete = proc_delete_dentry,
> - .d_revalidate = proc_revalidate_dentry,
> };
>
> /*
> --
> 1.5.3.rc6.17.g1911
Confirmed. This patch fixes the problem for me.
Shane
--
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.24-rc4] proc: Remove/Fix proc generic d_revalidate
On Dec 7, 2007 11:25 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
Unfortunately the linux VFS can not cope with anything in the path
to a mount point going away. So a proper d_revalidate method that
calls d_drop also needs to call have_submounts which is moderately
expensive, so you really don't want a d_revalidate method that
unconditionally calls it, but instead only calls it when the
backing object has really gone away.
proc generic entries only disappear on module_unload (when
not counting the fledgling network namespace) so it is quite rare
that we actually encounter that case and has not actually caused
us real world trouble yet.
So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it. This
returns us to the current status quo.
So with CONFIG_NETNS=n things should look as they have always looked.
For CONFIG_NETNS=y things work most of the time but there are a few
rare corner cases that don't behave properly. As the network namespace
is barely present in 2.6.24 this should not be a problem.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/proc/generic.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 8d49838..6a2fe51 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
return 1;
}
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata
*nd)
-{
- d_drop(dentry);
- return 0;
-}
-
static struct dentry_operations proc_dentry_operations =
{
.d_delete = proc_delete_dentry,
- .d_revalidate = proc_revalidate_dentry,
};
/*
--
1.5.3.rc6.17.g1911
Confirmed. This patch fixes the problem for me.
Shane
--
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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 7:15 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Sat, 8 Dec 2007 03:00:43 +0300 > Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote: > > > On Saturday, 8 of December 2007, Andrew Morton wrote: > > > > On Fri, 07 Dec 2007 17:51:58 -0500 > > > > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote: > > > > > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote: > > > > > > ... > > > > > > > Confirmed working in rc4-git5. I'll deploy this kernel in a few > > > > > > > more > > > > > > > spots and check for other regressions. > > > > > > > > > > > > Hmm, I installed a new kernel built from the same sources on the NFS > > > > > > server. And now I don't see anything at all in the crossmnt dirs. > > > > > > > > > > > > ls /dirA/dirB/dirC --> zero output (empty dir) > > > > > > > > > > > > Are there any other pending fixes? > > > > > > > > > > > > Shane > > > > > > > > > > You've probably fallen afoul of > > > > > > > > > >http://bugzilla.kernel.org/show_bug.cgi?id=9504 > > > > > > > > > > > > > Yeah. > > > > > > > > I have a tentative fix below but I can't seem to get Eric and Denis to > > > > get > > > > a suitable fix nailed down. It's urgent! > > > > > > Well, how about asking Linus to revert commit > > > 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over > > > again? > > > > > > It apparently causes more trouble than the issue it was supposed to fix. > > > > I very much agree. ->shadow_proc is so ugly, so it's not funny anymore. > > Adding such hook for proc part of networking _and_ for modules is just > > asking > > for trouble as was demonstrated. > > OK, perhaps a revert is the best thing to do here. I don't think anyone > will be expecting fully finalised and robust netns support in 2.6.24. I reverted 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 and it does fix the NFS server problem with crossmnt's for me. Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote: ... > Confirmed working in rc4-git5. I'll deploy this kernel in a few more > spots and check for other regressions. Hmm, I installed a new kernel built from the same sources on the NFS server. And now I don't see anything at all in the crossmnt dirs. ls /dirA/dirB/dirC --> zero output (empty dir) Are there any other pending fixes? Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 1:55 PM, Shane <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 1:46 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote: > ... > > This problem has already been reported. The fix (which I'm planning on > > sending to Linus soon) is appended. > > Thanks Trond. Sorry for the duplicate report, I did actually do some > searching... > > I will confirm the fix. Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check for other regressions. Thanks again, Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 1:46 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote: ... > This problem has already been reported. The fix (which I'm planning on > sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did actually do some searching... I will confirm the fix. Shane -- 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.24-rc3-git4 NFS crossmnt regression
> I will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Okie, the problem was introduced in 2.6.24-rc3-git2. 2.6.24-rc3-git1 Good 2.6.24-rc3-git2 Bad The exact output from one 'ls' command is: ls: /dirA/dirB/dirC: Stale NFS file handle ls: /dirA/dirB/dirC: Stale NFS file handle Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 7:02 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: ... > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and > > is unchanged. > > hm, there have been no nfs changes since 2.6.24-rc4. Ok, but the problem seems to have appeared before 2.6.24-rc4. > > It is easily reproducible here, hopefully for the person who > > knows how to debug it too :) > > > > I guess a full set of the commands which you typed to reproduce this would > help. Server is 2.6.23-rc9 and is exporting: /dirA/dirB 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt) /dirA/dirB/dirC 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure) /dirA/dirB/dirD 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure) The NFS client (Core2 SMP) 2.6.24-rc3-git4: NFS-server:/dirA/dirB /dirA/dirBnfs auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0 Then on the client when the new kernel has booted: ls /dirA/dirB --> normal listing ls /dirA/dirB/dirC --> Stale NFS file handle ls /dirA/dirB/dirD --> Stale NFS file handle I will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Will report back shortly, Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 7:02 AM, Andrew Morton [EMAIL PROTECTED] wrote: ... 2.6.24-rc3-git1 is last known good kernel. The problem also exists with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and is unchanged. hm, there have been no nfs changes since 2.6.24-rc4. Ok, but the problem seems to have appeared before 2.6.24-rc4. It is easily reproducible here, hopefully for the person who knows how to debug it too :) I guess a full set of the commands which you typed to reproduce this would help. Server is 2.6.23-rc9 and is exporting: /dirA/dirB 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt) /dirA/dirB/dirC 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure) /dirA/dirB/dirD 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure) The NFS client (Core2 SMP) 2.6.24-rc3-git4: NFS-server:/dirA/dirB /dirA/dirBnfs auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0 Then on the client when the new kernel has booted: ls /dirA/dirB -- normal listing ls /dirA/dirB/dirC -- Stale NFS file handle ls /dirA/dirB/dirD -- Stale NFS file handle I will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Will report back shortly, Shane -- 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.24-rc3-git4 NFS crossmnt regression
I will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Okie, the problem was introduced in 2.6.24-rc3-git2. 2.6.24-rc3-git1 Good 2.6.24-rc3-git2 Bad The exact output from one 'ls' command is: ls: /dirA/dirB/dirC: Stale NFS file handle ls: /dirA/dirB/dirC: Stale NFS file handle Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 1:46 PM, Trond Myklebust [EMAIL PROTECTED] wrote: ... This problem has already been reported. The fix (which I'm planning on sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did actually do some searching... I will confirm the fix. Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 1:55 PM, Shane [EMAIL PROTECTED] wrote: On Dec 7, 2007 1:46 PM, Trond Myklebust [EMAIL PROTECTED] wrote: ... This problem has already been reported. The fix (which I'm planning on sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did actually do some searching... I will confirm the fix. Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check for other regressions. Thanks again, Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 2:16 PM, Shane [EMAIL PROTECTED] wrote: ... Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check for other regressions. Hmm, I installed a new kernel built from the same sources on the NFS server. And now I don't see anything at all in the crossmnt dirs. ls /dirA/dirB/dirC -- zero output (empty dir) Are there any other pending fixes? Shane -- 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.24-rc3-git4 NFS crossmnt regression
On Dec 7, 2007 7:15 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 8 Dec 2007 03:00:43 +0300 Alexey Dobriyan [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote: On Saturday, 8 of December 2007, Andrew Morton wrote: On Fri, 07 Dec 2007 17:51:58 -0500 Trond Myklebust [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 14:39 -0500, Shane wrote: On Dec 7, 2007 2:16 PM, Shane [EMAIL PROTECTED] wrote: ... Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check for other regressions. Hmm, I installed a new kernel built from the same sources on the NFS server. And now I don't see anything at all in the crossmnt dirs. ls /dirA/dirB/dirC -- zero output (empty dir) Are there any other pending fixes? Shane You've probably fallen afoul of http://bugzilla.kernel.org/show_bug.cgi?id=9504 Yeah. I have a tentative fix below but I can't seem to get Eric and Denis to get a suitable fix nailed down. It's urgent! Well, how about asking Linus to revert commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again? It apparently causes more trouble than the issue it was supposed to fix. I very much agree. -shadow_proc is so ugly, so it's not funny anymore. Adding such hook for proc part of networking _and_ for modules is just asking for trouble as was demonstrated. OK, perhaps a revert is the best thing to do here. I don't think anyone will be expecting fully finalised and robust netns support in 2.6.24. I reverted 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 and it does fix the NFS server problem with crossmnt's for me. Shane -- 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/
